「Linuxで動かしながら学ぶTCP/IPネットワーク入門」を読みました

読みました。

ネットワークの勉強をしようと思ったきっかけ

最近はデータベース周り担当のインフラエンジニア業をしているのですが、Docker や Kubernetes の台頭によりネットワーク周りの知識の不足が目立つようになってきたためです。具体的に以下のような点で危機感を感じることが増えてきました。

  • Docker を使っているときの ip addr show の読み方が分からない。veth や bridge って何?
  • Kubernetes のネットワーク周りの話についていけない。いつの間にみんな NAT や iptables に詳しくなっていたの??

特に、以下のページが理解できなかったことはネットワークの勉強をちゃんとやろうと思ったきっかけとなりました。

kubernetes.io

speakerdeck.com

この本に手を出してみた理由

Kindle の試し読みで以下の点が気に入ったからです。

  • Linux の Network Namespace を使って説明している
    実験用のネットワークを VM で構築する方法と比べて軽量という理由で Network Namespace が採用されたようですが、Docker のネットワークがよく分かっていなかった私にとっては Network Namespace での説明のほうが都合がよかったです。
  • 本当によく使われる基礎的なコマンドを利用している
    ip, ping, tcpdump といった実際よく使われる基礎的なコマンドで説明されているので、学習以外で使うことはないであろうよく分からないネットワークシミュレータの使い方の学習のために時間を割く必要がありません。

最後まで読んでみた感想

  • 知りたかった内容は一通り学べた
    L2, L3 と NAT まわりについて学びたかったのですが、それぞれ3章、4章、7章で学べたので満足しています。5章、6章、8章は L4, L7, ソケットプログラミング について扱っている章でしたが、これについてはだいたい知っている内容でした。
  • Network Namespace を使った説明は有用
    大学ではネットワークの講義で原理を勉強しただけでルーターのコンフィグを書いて実験してみるようなことはなかったので、あまり学習した内容が身についていなかった自覚がありました。Linux の Network Namespace ではホスト間を接続したりルーターを設置したりすることがコマンドだけで実現できるので学習用途にも便利だと思いました。
  • ネットワークまわりのトラブルシューティングの習得にも役に立つかも
    本書では何かを実装した後に必ず tcpdump での確認を行う流れを取っています。ARP のリクエストを tcpdump で確認してみるといったこともやっているので、下のレイヤーをブラックボックス扱いすることはありません。私はネットワーク周りのトラブルがあった時にはとりあえず設定を戻してみたりと、ネットワークをブラックボックス扱いしたトラブルシューティングをしていたのですが、今後はちゃんと tcpdump で状態を確認しながらトラブルシューティングをしていきたいと思います。

おわりに

「ネットワーク周りのことを詳しく知らなくても Kubernetes は使える」という意見について、どうも私にはそうとは思えず、今後は避けては通れないのではないかと焦りを感じていたところだったので、ちょうどよいタイミングで本書が発売されて助かりました。

本書の著者のブログにはたびたびお世話になっているので紹介記事を書いてみました。

blog.amedama.jp

自作缶バッジを作ってイベントで配ってみた

ACM-ICPC OB/OG の会 という団体の認知を高めるためにグッズを作ってイベントで配ってみました。

どうして缶バッジ?

IT系のイベントでノベルティとしてよく配布されているのは

  • クリアファイル
  • ボールペン
  • 手帳
  • ステッカー
  • Tシャツ

あたりだと思います。

会社員になってから紙に記録したり紙の資料を持ち運んだりすることが激減してしまったので最初の3つは別にいらないかな、という感じになり、ステッカーやTシャツもよく考えると余るほど貰っているような気がしたので、コーナーケースを攻めるつもりで缶バッジを制作してみました。

業者選び

「缶バッジ」で検索すると少量から製造してくれる業者がたくさん見つかり、どういう観点で選べばいいのか最初はよく分からないのですが、今回は pixivFACTORY を使ってみました。理由はすでに pixiv のアカウントを持っていたからというだけです。

factory.pixiv.net

デザイン作成

Adobe Illustrator のような特殊なツールが必要にならないか心配していたのですが、缶バッジの場合はそんなことはなく、JPEGPNG をアップロードするだけで入稿できます。デザイン用のツールを持っていなかったので PowerPoint で作成したものを PNG にエクスポートして入稿しました。

注意点としては、丸形の缶バッジの場合、きっとあなたが想像しているよりも大きい余白が必要です。余白が足りなかったため、私は図の修正を2回くらいやり直しました。

注文

pixivFACTORY の場合は30個以上の製造で1個当たりの価格が最安となるので、今回は30個を注文してみました。

良かった点

簡単に作れた

注文したデザイン自体が単純ということもありましたが

  • 業者選び
  • デザイン作成
  • 注文

までの工程が2時間程度で終わったと言えば、どれだけ簡単に作れたか想像いただけると思います。

品質には満足

詳しくないので評価は難しいですが、実物の色味や余白の大きさなどはディスプレイ上でデザインしたときに想像したとおりのものが出来ていると思います。表面の加工などにも不満はありません。

次回はどうする?

次に缶バッジを作ることがあったら以下の点を再考してみるかもしれません。

より価格が低い業者を探す

30個注文したところ、1個あたりの価格が80円で送料が1,100円でした。

30個注文したときの1個あたりの価格は他のサービスと比べると20~30円高く、おそらく pixiv 社への仲介料と思われます。

より衝撃的なのは送料で、「n 円以上で送料無料」に慣れてしまった現代人からすると「ぐえー」という感じです。

その他付加サービスについて検討する

他の業者では追加の料金を支払うことで以下のようなサービスを追加できる場合があります。

  • フックピンから安全ピンに変更する
  • ピンではなくクリップに変更する
  • 個包装する

今回は参加者が大学生相当以上の年齢のイベントだったためあまり気にしていませんでしたが、別のイベントで参加者層が違う場合には検討する価値があります。

最後に

喜んでくれた人がいるようなのでぼくは満足です。

APT の設定 (/etc/apt/sources.list) をちゃんと理解する

/etc/apt/sources.list の設定内容の意味をよく理解していなかったので調べた。

とある Ubuntu 18.04 のサーバーの設定は以下のようになっており、この設定内容を理解することが目的である。

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://jp.archive.ubuntu.com/ubuntu bionic main restricted
# deb-src http://jp.archive.ubuntu.com/ubuntu bionic main restricted

# # Major bug fix updates produced after the final release of the
# # distribution.
deb http://jp.archive.ubuntu.com/ubuntu bionic-updates main restricted
# deb-src http://jp.archive.ubuntu.com/ubuntu bionic-updates main restricted

# # N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
# # team. Also, please note that software in universe WILL NOT receive any
# # review or updates from the Ubuntu security team.
deb http://jp.archive.ubuntu.com/ubuntu bionic universe
# deb-src http://jp.archive.ubuntu.com/ubuntu bionic universe
deb http://jp.archive.ubuntu.com/ubuntu bionic-updates universe
# deb-src http://jp.archive.ubuntu.com/ubuntu bionic-updates universe

# # N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
# # team, and may not be under a free licence. Please satisfy yourself as to
# # your rights to use the software. Also, please note that software in
# # multiverse WILL NOT receive any review or updates from the Ubuntu
# # security team.
deb http://jp.archive.ubuntu.com/ubuntu bionic multiverse
# deb-src http://jp.archive.ubuntu.com/ubuntu bionic multiverse
deb http://jp.archive.ubuntu.com/ubuntu bionic-updates multiverse
# deb-src http://jp.archive.ubuntu.com/ubuntu bionic-updates multiverse

# # N.B. software from this repository may not have been tested as
# # extensively as that contained in the main release, although it includes
# # newer versions of some applications which may provide useful features.
# # Also, please note that software in backports WILL NOT receive any review
# # or updates from the Ubuntu security team.
deb http://jp.archive.ubuntu.com/ubuntu bionic-backports main restricted universe multiverse
# deb-src http://jp.archive.ubuntu.com/ubuntu bionic-backports main restricted universe multiverse

# # Uncomment the following two lines to add software from Canonical's
# # 'partner' repository.
# # This software is not part of Ubuntu, but is offered by Canonical and the
# # respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu bionic partner
# deb-src http://archive.canonical.com/ubuntu bionic partner

deb http://security.ubuntu.com/ubuntu bionic-security main restricted
# deb-src http://security.ubuntu.com/ubuntu bionic-security main restricted
deb http://security.ubuntu.com/ubuntu bionic-security universe
# deb-src http://security.ubuntu.com/ubuntu bionic-security universe
deb http://security.ubuntu.com/ubuntu bionic-security multiverse
# deb-src http://security.ubuntu.com/ubuntu bionic-security multiverse

書式

sources.list の書式は以下のようになっている。

deb uri distribution [component1] [component2] [...]

たとえば以下の例を考えよう。

deb http://security.ubuntu.com/ubuntu bionic-security main restricted
  • urihttp://security.ubuntu.com/ubuntu
  • distribution は bionic-security
  • component は mainrestricted

APT のリポジトリには distributioncomponent という2つの軸があるということに注意する。component はパッケージの収録ポリシーを、distribution はパッケージのアップデートのポリシーを表している。

component

Ubuntu 公式リポジトリに収録されているすべてのソフトウェアは「Ubuntu チームによってサポートされているか」と「フリーソフトウェア哲学に合致しているか」の2つの観点によって4つのカテゴリに分けられ、それぞれのパッケージがいずれかの component に登録されている。

component Ubuntu チームによるサポート 「フリー」なソフトウェア
main
restricted
universe
multiverse

Ubuntu チームによるサポートが無いソフトウェアを利用したくないならば universe と multiverse を sources.list から外すこともできる。同様に、「フリー」でないソフトウェアを利用したくないならば restricted と multiverse を外すこともできる。

distribution

xenial-securitybionic-updates といった名前がついている部分のことを distribution と呼ぶ。

release

-security-updates といったサフィックスが付いていない distributionは release と呼ばれる。たとえば xenialbionic は release である。

Ubuntu は基本的に、正式版のリリース後にはパッケージがフリーズされる。フリーズ時のパッケージが収録されているのが release である。apt-cache policy ${PACKAGE} で表示される一番古いバージョンは release 由来のものになるだろう。

$ apt-cache policy nginx
nginx:
  Installed: 1.14.0-0ubuntu1.6
  Candidate: 1.14.0-0ubuntu1.6
  Version table:
 *** 1.14.0-0ubuntu1.6 500
        500 http://jp.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        500 http://jp.archive.ubuntu.com/ubuntu bionic-updates/main i386 Packages
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu bionic-security/main i386 Packages
        100 /var/lib/dpkg/status
     1.14.0-0ubuntu1 500
        500 http://jp.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        500 http://jp.archive.ubuntu.com/ubuntu bionic/main i386 Packages
$

security & updates

前述の通り、Ubuntu のリリース時にパッケージはフリーズされ、release のパッケージはアップデートされない。アップデートは ${CODENAME}-security${CODENAME}-updates で配信される。security ではセキュリティに関するアップデートが配信され、updates では security のアップデートに加えてセキュリティ以外の問題の修正も含むアップデートが配信される。

デフォルト設定では security と updates の両方が有効になっているが、ソフトウェアのアップデートは単なるバグ修正であってもリグレッションのような問題を伴うことがある。選択肢の一つとして、updates を利用しないように設定することで、セキュリティに関するアップデートでない場合はアップデートを延期するような運用を行うことも可能である。

security に配信された内容は updates にもコピーされるが、ミラーへの配信が遅れることもある。そのようなセキュリティリスクを減らすため ${CODENAME}-security は security.ubuntu.com を参照することが推奨されている。Ubuntu はデフォルトでこの設定になっている。

とある環境で apt-cache policy systemd を実行したときの結果は以下のようになった。最新版の 237-3ubuntu10.31 は bionic-updates から配信されているが、それより少し古い 237-3ubuntu10.29 が bionic-security から配信されている。このことから、セキュリティに関する修正を含むアップデートが security から配信された後に、セキュリティ以外の修正を含むアップデートが updates から配信されたことが分かる。

$ apt-cache policy systemd
systemd:
  Installed: 237-3ubuntu10.25
  Candidate: 237-3ubuntu10.31
  Version table:
     237-3ubuntu10.31 500
        500 http://ftp.iij.ad.jp/pub/linux/ubuntu/archive bionic-updates/main amd64 Packages
     237-3ubuntu10.29 500
        500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages
 *** 237-3ubuntu10.25 100
        100 /var/lib/dpkg/status
     237-3ubuntu10 500
        500 http://ftp.iij.ad.jp/pub/linux/ubuntu/archive bionic/main amd64 Packages
$

unattended-upgrades

security は保守的なポリシーで運用されているため、security のアップデートは確認無しで自動で適用してしまってもよいのではないか、という考え方もある。手動で cron を設定することもできるが、unattended-upgrades というパッケージが提供されているので、これを使うとよい。ちなみにこのパッケージの component は main である。

注意として、以下のページにも書いてあるが、リブートが必要なアップデートがあった場合に自動で再起動する機能 (Unattended-Upgrade::Automatic-Reboot) を使う場合は update-notifier-common パッケージのインストールが必要らしい。

backports

前述の通り、Ubuntu の公式リポジトリでは機能変更を伴うアップデートは基本的に行われない。しかしながら、需要があるパッケージについては ${CODENAME}-backports という distribution で新しいバージョンのパッケージが利用可能になることがある。

昔の Ubuntu(10.10 以前?)では backports distribution の設定を sources.list に追加すると確認無しで新しいバージョンのパッケージがインストールされていたらしいが、最近の Ubuntu では明示的に ${PACKAGE}/${CODENAME}-backports をインストールしない限りインストールされなくなったらしい。よって sources.list で backports distribution が有効になっていても勝手に新しいバージョンがインストールされることはない。