April 17, 2014

Manage multiple distributions with reprepro

本日Trustyがリリースされるということで、職場で使っているrepreproにTrusty用のローカルアーカイブを追加しました。 Preciseの設定をコピーして列挙すればよいだけですね。

設定内容

conf/distributions

preciseの部分をtrustyに変えて追記するだけ。

Origin: myrepo
Label: myrepo
Suite: precise
Codename: precise
Architectures: amd64 i386 source
Components: custom
UDebComponents: custom
Description: my repository for Ubuntu precise
SignWith: yes

Origin: myrepo
Label: myrepo
Suite: trusty
Codename: trusty
Architectures: amd64 i386 source
Components: custom
UDebComponents: custom
Description: my repository for Ubuntu trusty
SignWith: yes

conf/incoming

distributionsと同じ。

Name: precise
IncomingDir: incoming
TempDir: tmp
LogDir: log
Allow: precise
Default: precise

Name: trusty
IncomingDir: incoming
TempDir: tmp
LogDir: log
Allow: trusty
Default: trusty

conf/options

これは変更なし。

verbose
basedir /var/lib/debpkg-custom/ubuntu
ask-passphrase

DB生成

PreciseやWheezy用のローカルアーカイブには、私のメンテナンスしているパッケージやその依存パッケージをバックポートしたり、 社内で開発＆利用しているツールをDebianパッケージにして管理しています。 私のメンテナンスしているパッケージはひと通りTrustyに入っているので、とりあえず必要ないので空のDBを生成します。

$ pwd
/var/lib/debpkg-custom/ubuntu
$ reprepro export trusty

余談。

Wheezy用には、パス自体分けて(/var/lib/debpkg-custom/debian)運用していたのですが、 なんか分けないで混ぜていても良かったなぁと思いました。が、まぁ特に困らないのでいいや。

投稿者 mkouhei

カテゴリー: Debian

タグ: reprepro, Debian, Ubuntu

Leave a comment

April 16, 2014

Retrieve and generate debian package of Oracle JDK

I have written script for retrieving Oracle JDK tarball automatically, why I wanted to retrieve and make debian package with make-jpkg command on Jenkins.

1. Retrieve JDK 7 and JDK 8 download page urls from Oracle JDK Download site.

2. Retrieve JDK tarball URL.

3. Check the save file local directory.

4. Download with “wget” command.

Requirements

• python-requests

• python-query

• wget

• java-package

Prepare as following script for Jenkins.

#!/bin/sh

python retrieve_jdk.py -j $1
echo -e '\n\n' | make-jpkg $(ls -1 jdk-*-linux-x64.tar.gz | tail -1)

See also

• How to automate download and installation of Java JDK on Linux?

投稿者 mkouhei

カテゴリー: Python

タグ: Debian, Python, make-jpkg, Jenkins

Leave a comment

April 12, 2014

How to build custom Debian package automatically by Jenkins

以前、OpenSSH LDAP Public key パッチ(openssh-lpk)を、Ubuntu 12.04 LTS(Precise)とDebian GNU/Linux WheezyのそれぞれのOpenSSHに適用したカスタムビルドパッケージを作りました。 1 2 OpenSSHのパッケージが更新される度に、

1. このパッチを適用し

2. pbuilderを使ってPrecise, Wheezyでビルド

3. 実環境にインストールしてテスト

4. GPG key sign

5. reprepro管理下のローカルアーカイブに登録

するという作業を行っています。といっても、PreciseやWheezyでもOpenSSHのパッケージ自体のアップデートが最近までほとんどなかったので、手動でメンテナンスを行っていたのですが、この1ヶ月くらいで何回かアップデートがあったことや、先日Jenkinsを作ったこと (Issue deploying Jenkins to Tomcat7 Debian package in Wheezy)もあったこと、職場で私以外に作業できる人がいない、という問題があるので、Jenkinsでビルドするようにしました。

OpenSSHパッケージのDebianバージョンとOpenSSH LPKパッチの関係

これを図にすると下記のようになります。 Debianのパッケージが更新されるたびに、”+cust1”を付加したバージョンをリリースするわけです。

Preciseの場合も基本的に同じです。

pbuilderのイメージ準備

Jenkinsを動かしているのは前回の通りWheezyなので、Wheezy用のbase.tgzは次のように作成します。

$ sudo pbuilder --create --distribution wheezy --basetgz /var/cache/pbuilder/wheezy-base.tgz

一方、Precise用のbase.tgzは、別途Preciseをインストールしたサーバ上で同様に作成し、そのtarballを/Jenkins用のサーバに転送＆配置します。 3

WheezyやPrecise用のbase.tgzのAPT Lineにはupdatesやsecurityのものは含まれていないので、

$ sudo pbuilder --login --save-after-login --basetgz /vat/cache/pbuilder/wheezy-base.tgz

でchroot環境にログインし、変更しておきます。 4 また、合わせて、repreproで作成したローカルアーカイブ用のGPG公開鍵をapt-key addコマンドで追加しておきます。

パッチ置き場と一次ビルドの出力先の作成

openssh-lpkパッチと、debian/rulesのパッチをを任意のWebサーバにWheezy用、Precise用とそれぞれ用意しました。下記のようなURLです。

• http://repo.example.org/wheezy/openssh-lpk.patch

• http://repo.example.org/wheezy/rules.patch

• http://repo.example.org/precise/openssh-lpk.patch

• http://repo.example.org/precise/rules.patch

また、一次ビルドで出力するソースパッケージは、/var/tmp/resultディレクトリを作成し、後述のスクリプトでそこに出力するようにします。

$ sudo install -d -o tomcat7 -g tomcat7 --mode 0700 /var/tmp/result

一次ビルド、といっているのはパッチを適用した状態で、一度debuildを実行して出力されるソースパッケージのことです。その出力されたソースパッケージを用いて、pbudilerでクリーンビルドする、という流れです。

ソースツリーからpbuilderを実行するpdebuildコマンドを使えば、そんな面倒なことをする必要はありません。が、Wheezy上でPreciseの公開鍵をインポートしなくてはいけない点と、PreciseとWheezyとで基本的に同じ手順で行いたい、という二点から、pbuilderを2回実行する形にしました。

ジョブ用のスクリプト

Wheezy, preciseとで基本同じなので、先頭の2行のみを環境に合わせて変更します。Wheezyの場合は、codenameをwheezy, distroにはstableにしますが、Preciseの場合には両方共preciseです。 5

codename=wheezy
distro=stable
bin_package=openssh-server
src_package=openssh
arch=$(dpkg-architecture -qDEB_HOST_ARCH)

# check version
cat << EOF > check_version.sh
apt-cache show $bin_package | grep Version: | sort | tail -1 | grep -v +cust > /var/tmp/result/${BUILD_ID}.txt
exit 0
EOF
sudo pbuilder --update --basetgz /var/cache/pbuilder/${codename}-base.tgz
sudo pbuilder --execute --basetgz /var/cache/pbuilder/${codename}-base.tgz --bindmounts "/var/tmp/result" -- check_version.sh
test -s /var/tmp/result/${BUILD_ID}.txt || exit

deb_version=$(awk -F: '{print $3}' /var/tmp/result/${BUILD_ID}.txt)
orig_version=$(echo $deb_version | awk -F"-" '{print $1}')

# retrieve source package and patches
cat << EOF > build.sh
apt-get -qq -y install curl devscripts quilt patch libdistro-info-perl fakeroot libldap2-dev
apt-get -qq -y build-dep $bin_package

apt-get source $src_package

curl -O http://repo.example.org/${codename}/openssh-lpk.patch
curl -O http://repo.example.org/${codename}/rules.patch
(
export DEBFULLNAME="Auto Build"
export DEBEMAIL=autobuild@example.org

cd ${src_package}-${orig_version}
echo "### applying patch ###"
patch -p1 --dry-run < ../openssh-lpk.patch || exit 1
patch -p1 < ../openssh-lpk.patch

echo "### commiting patch ###"
echo | dpkg-source --commit . openssh-lpk.patch ../openssh-lpk.patch

echo "### update Build-Depends ###"
sed -i 's/^\(Build-Depends: .*\)$/\1, libldap2-dev/' debian/control

echo "### update compile options ###"
patch -p1 --dry-run < ../rules.patch
patch -p1 < ../rules.patch

echo "### update changelog ###"
dch -l+cust -D${distro} "Applied OpenSSH LPK patch."

echo "### build package ###"
debuild -us -uc
)

cp -f ${src_package}_${deb_version}+cust1.debian.tar.gz ${src_package}_${orig_version}.orig.tar.gz ${src_package}_${deb_version}+cust1.dsc /var/tmp/result/
EOF

sudo pbuilder --execute --basetgz /var/cache/pbuilder/${codename}-base.tgz --bindmounts "/var/tmp/result" -- build.sh

# clean build
sudo pbuilder --build --basetgz /var/cache/pbuilder/${codename}-base.tgz /var/tmp/result/${src_package}_${deb_version}+cust1.dsc

# installing test
sudo piuparts -b /var/cache/pbuilder/${codename}-base.tgz -d $codename --keep-sources-list /var/cache/pbuilder/result/${src_package}_${deb_version}+cust1_${arch}.changes

大まかな流れとしては次のとおりです。

1. カスタムビルドパッケージよりも更新されたバージョンがリリースされていないかのチェック

2. pbuilderを使い、chroot環境内でのソースパッケージとパッチの取得・適用及びビルド

3. ビルドして生成されたソースパッケージを用い、pbuilderでクリーンビルド

4. クリーンビルドしてできたパッケージを、piupartsでインストールテスト

公式パッケージで更新されてパッチ適用したバージョンよりも新しいバージョンがリリースされている場合、このジョブを実行すると、パッチ適用してビルドされたパッケージが、Jenkinsサーバの/var/cache/pbuilder/resultディレクトリ下に作成されます。

後は別のジョブでdebsignでGPG key signし、repreproのincomingディレクトリにpushすれば良いわけです。 6

この記事のオチ

さて、これで自動ビルドできるようになったので楽できるわー、と思ったら、このジョブを仕込んた翌日に、 OpenSSH 6.2 以降で

• AuthorizedKeysCommand

• AuthorizedKeysCommandUser

というオプションが使えるようになったことを同僚に教えてもらいました。つまり、「もはやOpenSSH LPKなんて不要になった！」ワケです。素晴らしい。

来週リリース予定のUbuntu 14.04 LTS(Trusty)ではOpenSSH 6.6ですし、WheezyでもBackportsに6.5にあるのでわざわざこんな手の混んだことをしなくても、ミラーをすればよいのです。 なので、このジョブそのものはたった一日で不要になってしまいました。

ただし、Precise用にはWheezyのBackportsのソースパッケージをリビルドする必要があるので、今回やった事自体は役立ちそうです。このジョブに比べたら（リビルドさえちゃんと確認できれば）なんてこと無いですね。

もっと簡単にマルチディストリビューション向けに自動(カスタム)クリーンビルドする方法があれば、どなたか教えて下さい。

追記

• check_version.shに exit 0 を忘れていたので、ローカルアーカイブの方にパッチ適用済みのパッケージが存在すると、ジョブがコケてしまう、ので修正しました。

• @mizuno_as さんに複数環境向けにビルドするならpbuilder-distの方が便利ですよ、と教えてもらったので、後日検証しようと思います。

追記2

• –bindmounts オプションを /var/tmp/result /tmp としていたのですが、pbuilderのbindmountsオプションの挙動を勘違いしていました。こうするとホストの/var/tmp/resultとchroot内の/var/tmp/result、そしてホストの/tmpとchroot内の/tmpがbind-mountされるので、今回であれば/var/tmp/resultだけを記述すれば良かった、ということでした。(修正済み)

Footnotes

1

OpenSSH LDAP public key

2

Applying openssh-lpk to Wheezy

3

cowbuildreを使うことも検討したのですが、Precise上で cowbuilder –create すると失敗するためpbuilderを使うことにしました。

4

exitコマンドではなく、Ctrl + dでログアウトすると、”–save-after-login” オプションをつけていても変更が保存されないようです。

5

Wheezyでは、dchコマンドの”-D”オプションでのディストリビューションの指定には、Ubuntuと違ってコードネームの”wheezy”ではなく、”stable”でないとエラーになります。

6

今回はdebsign, repreproへのpushについては書きませんが。

投稿者 mkouhei

カテゴリー: Debian

タグ: pbuilder, Jenkins, openssh-lpk, reprepro, Wheezy, Precise, piuparts

Leave a comment

March 27, 2014

Issue deploying Jenkins to Tomcat7 Debian package in Wheezy

travis-ciはよく使っているのですが、JenkinsはあのWeb UIに馴染めなくて今まで使っていませんでした。が、この度仕事でJenkinsを用意する必要が出てきたの 1 で、Debian GNU/Linux Wheezyでサーバを用意することにしました。

用意するにあたり、upstreamからwarファイルをダウンロードし、直接実行する方法で、まず全体設定やセキュリティ関連の設定を試しました。そのあとで、DebianパッケージのTomcat7上で動かそうとした際にちょっとハマりました。これはそのメモです。ググった限りでは同様の問題にハマっている人は多分いないのでしょう。

直接実行の場合

OpenJDKを使うため、default-jre-headless パッケージをインストールします。あとは、warファイルをダウンロードして直接実行するだけです。

$ sudo apt-get intall default-jre-headless
$ wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war
$ java -jar jenkins.war

検証途中で、権限周りの設定をしている時に間違えてEnterを打ってしまい、何もできなくなるというエライことに。きっと これよくある問題 なんでしょうね。

DebianパッケージのTomcat上で動かす場合

本題です。Tomcat7をまずDebianパッケージでインストールします。

$ sudo apt-get install tomcat7 tomcat7-admin

インストールしたら自動的にTomcatが起動しますが、何の権限も無くてtomcatのweb管理画面にもアクセスできないので、/etc/tomcat7/tomcat-users.xmlを変更し、下記を<tomcat-users>の子要素として追加します。ユーザ名、パスワードは適当に設定して下さい。

<tomcat-users>
    (snip)
        <role rolename="manager"/>
        <role rolename="manager-gui"/>
        <role rolename="admin-gui"/>
        <user username="tomcat" password="passw0rd" roles="manager,manager-gui,admin-gui"/>
</tomcat-users>

設定したら、tomcat7を再起動します。

$ sudo service tomcat7 restart

これで、設定したユーザ、パスワードを使って、 http://tomcat.example.org:8080/manager/ からTomcat管理画面にアクセスできます。あとは、先ほどダウンロードしたwarファイルを使ってデプロイしてやれば、 Jenkinsが起動します。

と思ったら大間違いで、デプロイできても起動できません。

原因は、tomcat7パッケージで作られるtomcat7ユーザのホームディレクトリの位置です。 tomcat7ユーザのホームディレクトリは、/usr/share/tomcat7になっているのですが、/usr以下のディレクトリはパッケージのインストール以外で置かれる静的ファイル以外は基本置かれません。しかし、Jenkinsは実行ユーザのホームディレクトリの直下に、.jenkinsディレクトリを作成し、そこに各種出力をします。/usr/share/tomcat7の所有権はrootユーザおよびrootグループであり、自由に書き込みはできません。

なので、次のようにしてやることで、この問題を回避できます。 2

$ sudo install -d -o tomcat7 -g tomcat7 -m 700 /var/lib/jenkins
$ sudo ln -s /var/lib/jenkins /usr/share/tomcat7/.jenkins

あとは、tomcatを再起動すれば、Jenkinsが起動します。

この問題、TomcatもUpstreamのwarファイルを使うか、あるいはJenkinsも公式のDebianパッケージ 3 を使えば発生しない現象ですね、おそらく。しかし、Wheezyでは残念ながら公式パッケージにJenkinsは含まれていないので、Debianパッケージを用意するならSidからのバックポートが必要になります。が、ビルドの依存関係多いので、jenkins以外にもバックポートが多数必要という罠。今回バックポートせずにJenkinsだけをwarファイル使ったのは、たんに私の甘え＆ゆとりです。

Footnotes

1

本来のきっかけとは別に、SidからWheezyやPrecise向けにDebianパッケージをバックポートしたり、自前のツールをDebianパッケージにする際のオートビルド環境として、jenkins-debian-glue が良いよ、と @lurdan に教えて頂いたので、それも動機となっています。

2

/usr/share/tomcat7/.jenkinsディレクトリを作って、所有権をtomcat7:tomcat7にする、というのでも動きますが、お行儀悪いのでやめましょう。

3

Upstreamが配布しているDebianパッケージもあります が、これはDebianの公式パッケージではないので、私は使いません。

投稿者 mkouhei

カテゴリー: Debian

タグ: Debian, Jenkins, Tomcat

Leave a comment

March 26, 2014

How to encrypt ansible-vault in the TLS certificate

先週、Sidのansibleパッケージが1.4.5+dfsg-1から1.5.3+dfsg-1に上がったので、待望のansible-vaultを使ってみました。パスワードなどを暗号化するために使うのが主でしょうが、今回の私の目的は、TLS証明書を及びその秘密鍵の暗号化です。仕事で使っているplaybookに、PEM形式の証明書や秘密鍵を含めるのがいやだったのが動機です。

IMAPサーバ用のplaybookを例にします。

.
|-- development
|-- group_vars
|   |-- all
|   |-- development
|   `-- production
|-- imapd.yml
|-- production
|-- roles
(snip)
|   |-- dovecot
|   |   |-- handlers
|   |   |   `-- main.yml
|   |   |-- tasks
|   |   |   `-- main.yml
|   |   |-- templates
(snip)
|   |   |   |-- 10-ssl.conf.j2
    (snip)
|   |   |   |-- key.j2
|   |   |   `-- cert.j2
|   |   `-- vars
|   |       `-- main.yml
(snip)
`-- site.yml

ansible-vaultで暗号化する対象は、roles/dovecot/templatesディレクトリの下にある、key.j2とcert.j2の2つのテンプレートの中に出力する文字列です。 証明書とprivate keyを配布するだけなら、filesディレクトリの下に、証明書およびprivate keyファイル自体を配置し、copyモジュールでコピーすれば良いだけです。 しかし、 ドキュメントにもあるとおり ansible-vaultで対象に暗号化の対象にできるのは各種の変数だけなので、filesディレクトリ下の添付ファイルは復号できません。そこで、templateモジュールを使う必要があります。暗号化する文字列自体は、roles/dovecot/vars/main.ymlの中に記述します。

PEM形式の文字列は、

-----BEGIN CERTIFICATE-----
MIIFtTCCA52gAwIBAgIIYY3HhjsBggUwDQYJKoZIhvcNAQEFBQAwRDEWMBQGA1UE
AwwNQUNFRElDT00gUm9vdDEMMAoGA1UECwwDUEtJMQ8wDQYDVQQKDAZFRElDT00x
CzAJBgNVBAYTAkVTMB4XDTA4MDQxODE2MjQyMloXDTI4MDQxMzE2MjQyMlowRDEW
(snip)
-----END CERTIFICATE-----

のような形式になっているので、これをtemplateモジュールを使って、ファイルを配置するには、templates/cert.j2などのテンプレートに、

{{ cert_pem }}

とだけ記述し、vars/main.ymlには、

---
- cert_pem: "-----BEGIN CERTIFICATE-----\nMIIFtTCCA52gAwIBAgIIYY3HhjsBggUwDQYJKoZIhvcNAQEFBQAwRDEWMBQGA1UE\nAwwNQUNFRElDT00gUm9vdDEMMAoGA1UECwwDUEtJMQ8wDQYDVQQKDAZFRElDT00x\nCzAJBgNVBAYTAkVTMB4XDTA4MDQxODE2MjQyMloXDTI4MDQxMzE2MjQyMlowRDEW\n...(snip)...\n-----END CERTIFICATE-----"
- key_pem: "..."

のように、改行を”n”に変更して一行の文字列とし、それをダブルクォートかシングルクォートで括って指定します。 これで動作確認ができたら、vars/main.ymlを暗号化します。

$ ansible-vault encrypt roles/dovecot/vars/main.yml

暗号化されたファイルは下記のようになります。

$ANSIBLE_VAULT;1.1;AES256
39613864343833373066386636333338653831383630623938643138366230323336656234326234
3833663562396237393333363665643631653331386566660a653530326636666137633731373361
34653163626664376432393433303435333433303535626437623935313962626430643038623464
(snip)

暗号化された変数を使って、playbookを実行するには、 --ask-vault-pass オプションをつけてansible-playbookコマンドを実行すれば良いだけです。 このオプションをつけると、実行時にだけメモリ上に復号されます。

まとめ

今まで、パスワードなどはvars_promptで都度入力し、TLS証明書＆秘密鍵などは別途配布する、という方法でやっていました。 これでplaybook自体にansible-vaultで暗号化して管理できるので、vautl passwordのみ、keepassなどで管理すれば良さそうです。

投稿者 mkouhei

カテゴリー: ansible

タグ: Debian, ansible

Leave a comment

— ブログアーカイブ —

• « 次の投稿
• 前の投稿 »

最近の投稿

• LEGO 展示棚を設置しました
• Google Nest Hub, Google Home mini 復活
• ABUS Bordo Lite Mini 6055/60
• ヘッドライトとリアライト
• Brompton M6L を入手しました
• pipenv 環境でのコマンドを直接実行する
• 2017年の振り返りと2018年の抱負
• 再びpython-debianのお話
• VirtualBoxをPowerShellで操作する
• ThinkPad T470sに乗り換え

Search

カテゴリー

• ansible (2)
• Bike (3)
• book (23)
• cat (63)
• Celery (1)
• Cloud (1)
• computer (195)
• CouchDB (35)
• Debian (425)
• Dev (26)
• emacs (1)
• error (74)
• gadget (117)
• Git (14)
• git-buildpackage (1)
• Golang (2)
• Kids (1)
• LDAP (3)
• life (798)
• lint (1)
• MacBook (137)
• meeting (107)
• network (84)
• nonsense (208)
• Ops (90)
• Packaging (3)
• PowerDNS (1)
• programming (7)
• Python (19)
• Ruby (2)
• security (54)
• TeX (13)
• Unix/Linux (238)
• virt. (109)
• Windows (1)
• work (261)

タグ

ansible (2), Ansible (2), ansible galaxy (1), Apache (1), AppArmor (1), apt (3), Armadillo-9 (1), auto install (1), b-mobile WiFi (1), Bash (1), blockdiag (3), blog (1), bootstrap-py (1), Brompton (3), C (1), Cat (1), Celery (3), CentOS (3), Cisco ASA (1), ClamAV (1), CouchDB (4), CouchDB JP (1), daemontools (1), Debian (48), Debian Pure Blend (1), DebianUbuntuAdvent2012 (1), DebianUbuntuAdvent2013 (5), DebianUbuntuAdvent2017 (1), debsign (1), Display manager (1), dnsmasq (2), Dovecot (1), dovecot (1), dvipdfmx (1), e-Tax (2), El Capitan (1), emacs (2), Erlang (4), fastcgi (1), fetchmail (1), gdm (1), Genenga (1), Git (9), git-filter-branch (1), GitLab (2), GitPython (1), Gmail (1), GNU/Linux (1), GnuPG (1), Golang (3), Google Home mini (1), Google Nest Hub (1), Gosh (2), GPT (1), grub2 (3), grubs (1), hddtemp (1), Heroku (1), Hiki (1), hiki (1), i2c-tools (1), include_csv (1), iori (1), IPv6 (2), iPXE (1), Jenkins (5), JetDrive (1), JSON (1), lambda (1), ldapvi (2), LEGO (1), Lenny (4), libvirt (1), lighttpd (4), Linkdraw (1), lint (1), Linux (3), lm-sensors (1), Lua (1), lv (1), lxc (5), MacBook (4), MacBookPro (3), make-jpkg (1), Mercurial (2), mkpasswd (1), mock (1), MVNO (1), MySQL (2), net-tools (1), nginx (2), Nginx (3), nslcd (1), nwfilter (1), omame (3), OpenBlockS (3), OpenConnect (1), OpenLDAP (14), OpenMicroServer (2), OpenSSH (3), openssh-lpk (3), OpenStack (3), Oracle (1), OS X (2), packaging (1), pbuilder (1), pep8 (1), Perl (1), PHP (1), pidgin (1), pipenv (1), piuparts (1), PlantUML (1), plantuml-mode (1), PoE (1), Postfix (2), Power unit (1), PowerDNS (2), PowerShell (1), Precise (1), preseed (2), procmail (1), pylibmc (1), Pyramid (1), pystache (1), Python (16), python (4), python-debian (1), Python-LDAP (1), Python2.6 (1), Python2.7 (1), python_debian (1), python_gnupg (1), RabbitMQ (1), Redmine (1), redmine (1), REPL (1), reportbug (1), reprepro (2), rpm (1), RSA SecurID (1), rsyslog (1), RTX830 (1), Ruby (2), Scratch (1), Sendmail (1), Sid (1), Sinatra (1), slim (1), smbclient (1), sphinx (2), Sphinx (2), Squeeze (1), SSD/Linux (1), sshd (1), sudo (1), Swift (1), Switch (1), Sylpheed (1), sysbench (1), systemd (1), sysvinit (1), TACACS+ (1), td2planet (3), ThinkPad (1), tinkerer (7), Tomcat (1), TonicDNS (3), trac (1), Ubuntu (11), upstart (1), uscan (1), vi (1), virt-manager (1), VirtualBox (3), Vyatta (2), Wheezy (3), wheezy (1), wifi (1), Windows (1), Windows 10 (1), Windows 8.1 (1), work (3), yrmcds (1), ブログ移行 (1), 個人番号カード (2), 確定申告 (2), 自宅サーバの思い出 Advent Calendar 2016 (1)