「Linuxブートキャンプ」を読んだ

投稿時刻2023年3月24日 06:40

「Linuxブートキャンプ サーバ操作/OSのしくみ/UNIXネットワーク」を 2,023 年 03 月 24 日に読んだ。

目次

メモ

Linux ディストリビューションの選択と入手 p3

たしかにLinuxはいろいろなディストリビューションが用意されていて、選択に迷うことが多いよな。
業務システムではRHEL (Red Hat Enterprise Linux) が使われることが多いけど、
簡単なシステムならRHEL クローンのCentOSとか、最近はUbuntuを使うことも増えてきているな。

ネットワーク接続の確認 p6

今回は、インストール時にネットワーク接続の設定を行っていないため、
DHCPを使って自動的にIPアドレスが取得されるようになっています。
また、 VirtualBox で作成した仮想マシンは、デフォルトではNATを使って外部ネットワークに接続できるようになっています。
しかし、外部から、あるいはホストOSからは仮想マシンにはアクセスできません。
ちょうど、ブロードバンドルータのようなネットワーク機器が間に入っているイメージです。

まず、IPアドレスが正しく設定されているかを確認しましょう。
確認にはipコマンドを実行します(図9)。

この実行例では、2つ目に 「enp0s3」 というネットワークインターフェースが動作しており、
「10.0.2.15」というIPアドレスが割り当てられているのが確認できます。 

次に、インターネットに接続できることを確認しましょう。
確認方法はさまざまありますが、ここでは curl コマンドを使って外部のWebサーバにアクセスできることを確認します (図10)。

swap パーティション p73

次に考えるのは swap パーティションのサイズ (あるいはまったく使わないか)です。
swap は、メモリが不足したときにあまりつかっていないデータを書き出して、メモリを開けるために使われます。
また、システムをハイバネートするときには、全メモリ内容を退避するのにも使われます。
swap のサイズはなかなか難しい問題です。

sudo p65

sudo は、 root やほかのユーザーに成り代わってコマンドを実行できます。
実行にはユーザーのパスワードを入力します。
sudo を実行できるユーザーはシステムの設定で決めることができ、パスワード入力不要にも設定できます。

Ubuntu は、当初より rootの利用を禁止し、インストール時に作った1人のユーザーを sudo が使えるようにしました。
これはかなり画期的な提案だったと思います。
Ubuntuの広まりと同時 に、rootでLinuxシステムを使い続ける人は減ったのではないでしょうか。

su p64

suはほかのユーザーに成り代わり (substitue) ます。
成り代わるには、そのユーザーのパスワードを入力する必要があります。
たとえば、 root になりたい場合は、 root のパスワードが必要です。
オプションも引数も指定しなければ root シェルが起動します。

グループの用途 p58

Linux システムでは、ユーザーをまとめる「グループ」という単位も用意されています。
一般ユーザーを数人まとめて作業用のグループを作って権限を与えることができます。
Webサーバを実行するユーザーと、Webコンテンツを管理する一般ユーザーを同じグループにまとめてコンテンツの編集作業を容易にするなどのメリットがあります。

ユーザーの種類 p57

Linuxシステムにおいてディレクトリやファイルへのアクセス権限はユーザーに付与されます。

Linuxのユーザーは次の3種類があります。
・root (スーパーユーザー) 
・システムユーザー 
・一般ユーザー 

「システムユーザー」は、Webサーバやメールサーバ、各種サービスを実行するユーザーとして用意されます。
Linux では、システムユーザは rpm や deb パッケージによりインストールされた際にユーザーとして作成されます。

root ではなく、システムユーザーでサービスを起動するのは、セキュリティ対策でもあります。
たとえばhttpdなどのサービスに脆弱性が存在した場合、攻撃されてもほかのサービス、
ほかのシステムファイルに影響が出ないようにするためです。
サービスがシステムユーザーの権限で動作していれば、影響はそのシステムユーザーの権限内に収められるからです。

設定ファイルのバックアップをとる p25

また「(チルダ) や (アンダースコア) のようなサフィックスを用いる場合もあります。

cp hosts hosts.20211212

sudo ではルート権限で行えることを制限できる p18

sudo がなかったとしたらルート権限が必要なユーザすべてにルートのIDとパスワードを配布しなければなりません。
不特定多数が使うサーバで、管理者以外のユーザがルート権限を行使できるとしたら、サーバの安定稼働も個人情報保護もへったくれもありません。
それくらいルート権限は強大ですので、不慮の事故を防ぐ意味でも、普段は極力一般ユーザアカウントでsudoだけを使うようにして、
ルートアカウントでのアクセスは必要最小限にするというのが正しいサーバ運用の姿です。

FHS によるディレクトリ構造の標準化 p15

実はLinux Foundation という非営利団体が各ディレクトリの標準化を行っているFHSというものがすでにあったりするんだ。
各ディストリビューションではFHSに沿ったディレクトリ構造がすでに採用されている。
FHS (File system Hierarchy Standard; ファイルシステム階層標準) とはLinux を含む UNIX 系OSにおけるディレクトリ名とその内容を定めているものです。
FHSが制定される以前は、慣習的に使われていたディレクトリ名とその用途を、各Linuxディストリビューション開発者がそれぞれ独自解釈して用いていたので、
結果としてディストリビューションごとにディレクトリの使われ方が異なるという状況でした。

そこでLinux でのファイルシステム階層標準化の試みが1993年より開始され、その後ほかのUNIX系OSも参加して現在に至ります。
FHSは現在、 2015年6月3日に公開されたv3.0が最新版となっています。

ホストOSからWeb サーバへのアクセス p9

VirtualBox の仮想マシンはデフォルトで NATに設定されており、DHCPでIPアドレス なども自動的に割り当てられるため、
何もしないでもインターネットに接続できました。
しかし、この状態ではホストOSからはアクセスできないので、さまざまな検証を行うための環境としては不十分です。
VirtualBox は仮想ネットワークの設定を変更することで、ホストOSから、あるいは外部のPCからも仮想マシンにアクセスできるようになります。
ここでは「ホストオンリーアダプタ」を設定して、ホストOS上で動作している Web ブラウザから仮想マシン上で動作している Webサーバにアクセスできるようにします。

道筋を知る p106

インターネットっていろんなルータを通って目的地までたどり着くんですよね?
tracerouteコマンドを使うとパケットが通る道筋を知ることができるよ。
パケットがどんな経路を通っているのかを知るために、 traceroute というコマンドがあります。

SELinuxについて p121

Red Hat系ではSELinというセキュリティ機能の存在も意識する必要があります。
本場では SELinux は有効にした状態を前提として説明しますが、厳格なアクセス制御を実現する機能のため、セキュリティが強固になる反面、
トラブルの要因になることも多い機能ですので、業務サーバでは無効にすることが多いと思います。

いい感じにファイルを同期する p158

rsync はファイルを同期することもできます。
もちろんネットワークでつながれた2台のマシン間でできます。
バックアップが別のサーバにある場合や、システムを移設する場合などによく使います。
rsync は、すべてのデータではなく差分のみコピーするため同期に最適です。
なお、コピー元・先両方のサーバに rsync がインストールされている必要があります。

安全なファイルコピーから同期、バックアップに使えるrsyncコマンド p157

rsync は高速で、優秀なファイルをコピーするツールです。
移設時のデータ移行、データ同期、またサービス運用の中で重要な要素であるバックアップとそのリストアを実施する場面で活躍します。

ssh で簡易 VPN p156

sshはコマンドライン操作だけではなく、リモート処理だけでもなく、通信の転送もできます。
ssh通信に相乗りできるのがミソです。
ssh がトンネルとなり、ほかの通信を通すことができるのです。
まずsshの効用で暗号化や圧縮が適用されます。
そしてssh接続しか許可されていないファイアウォールの向こう側のシステムに、自在にアクセスできるようになります。

具体的には ssh接続元のポートへのアクセスを、 ssh接続先で特定IPアドレス・ポートへ転送することができます。
そのためSSH さえ疎通すれば、接続先サーバからアクセスできる範囲は自由にアクセスできます。

図1はローカル PC から Server1 へ ssh接続し、同時にローカルPCの5911ポートを127.0. 01:5901 (Server1 自身の5901 ポート) に転送する例です。
これをLocal Forward と呼び、コマンドオプションは「-L」で次のように実行します。
$ ssh -L 5911:127.0.0.1:5901 username@Server1

たとえば、 KVM上の仮想サーバの画面を見るために VNC接続したいが、
KVM は 127.0.0.1:5901 を LISTENしているとき、ローカル接続しか許可していないアプリケーションサーバ (php-fpm, unicorn gunicorn など) や MySQL に接続するときなどに重宝します。
最近では、手元のMySQL Workbench をクラウド上のRDBサービス (Amazon RDS など)に安全に接続するためによく利用します。

なお、この例では転送先が ssh 接続先自身(接続先ホストから見て127.0.0.1) ですが、ほかのサーバを指定することもできます。
たとえば、 ssh -L 3306:192.168.0.200:3306 username@Server1 の場合、 Server1を発信元とし 192.168.0.200:3306 に接続します。

Local Forward とは逆に、接続先サーバのポートでデータを待ち受け、接続元で特定IPアドレスポートへ転送することもできます。
これを Remote Forward (コマンドオプション「-R」)と言います。

ssh が SOCKS プロキシになり、接続元からの通信を接続先発にしてくれる Dynamic Forward (コマンドオプション「-D」) を利用するとさらに VPNらしくなります。
Dynamic Forward とブラウザのProxy 設定切り替えアドオンを利用することで、
社外からは接続できない社内用Webシステムにアクセスすることができて、たいへん捗ります。

知らないとセキュリティ的にはちょっと怖い気もしますね。
このあたりもsshがサーバ管理者の証たるゆえんだと思います。