ConoHaとArch LinuxではじめるLinux

ごあいさつ

Hi, there! はるかみです。

この記事はConoha Advent Calendar 2018の7日目として書かれたものだよ。 いままでChienomiを見たことある人もない人も楽しんでいってね。

基本的にChienomiはedgeな記事を書くことが多いけれど、Advent Calendarのときだけは初心者向けの記事を書いたりしているんだ。 Chienomiでは最近で最もアツかったのは高EQ AIに関する記事だよ!

本当はConoHa WINGに関する記事を書こうかと思ったけど、Advent Calendarで書くようなものじゃないと思ったんだ。 考えていたものは検証に5, 6日必要だとわかったから協賛でもしてもらわないと無理だとわかったんだよ。

それにConoHa WINGでConoHa Advent Calendarのハードルも下がって、今年はWINGに関する記事がたくさん載るだろうからね。え?毒が少ないって?さすがに同じAdvent Calendarの記事に毒を吐くのは来年にとっておくよ。

あなたはLinuxを使っているだろうか。

最近はLinuxというとドヤりツールになっていたり、あるいはミーハーなものになっていたりもする。 あとは、仕事のための箔付けだろうか。

それはLinuxのなんたるかがわかっていない…と思うのだが、ここではそんな話はおいて、とりあえずLinuxを触ってみたいという人のお手伝いをしよう。

この記事にかかれていることはかなりの部分、過去の記事や他で書いたことと重複してしまうのだが、Advent Calendarの記事ということでご容赦願いたい。

今回はLinuxを全く使ったことのないWindowser向けにエクスプレスで進めていく。 スキル不足が直接に迷惑になるサーバー構築ではなく、またデスクトップ用途でもない。

なお、Linuxそのものを体験して評したいのならばメインマシンにLinuxをインストールするよりない。 LinuxのUXはWindowsのそれよりはるかに優れているが、それはさすがにVPSでわかるようなものではない。

また、副次的に性能の低いコンピュータを使っている人の場合、月1000円から2000円程度で強力なコンピュータにオフロードできる、という面でも話していこうと思う。

SSHを用意する

Windows 10では2017 Fall Creator UpdateからOpenSSHが標準採用になっている。ちなみに、2018 Aprilではサーバーも入っている。 とりあえずまだWindows 10ですらない、という人のことはあまり考えたくないので、そこから話を進めよう。

まずはcmdを検索、あるいは“プログラムを指定して実行”からcmd

Windowsでcmd.exeを探す

ssh -VでOpenSSHを確認。

C:\Users\Harukamy>ssh -V
OpenSSH_for_Windows_7.6p1, LibreSSL 2.6.4

ssh-keygenで鍵を作成する。 Microsoftが提供するWindowsアプリでありながらUnixスタイルとWindowsスタイルが混在してとてもわかりづらいことになる。 OpenSSHが使うディレクトリは相変わらず%HOME%\.sshなのだが、Explorerでドットファイルが作れないのでコマンドライン上で行う。

>mkdir .ssh

その上でSSH鍵を生成する。

>ssh-keygen -f .ssh/conoha_rsa
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in .ssh/conoha_rsa.
Your public key has been saved on .ssh/conoha_rsa.pub.
The key fingerprint is
SGA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX harukamy@HACKMAN
the key's randomart image is:
+---[RSA 2048]----+
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
|                 |
+---[RSA 2048]----+

このパスフレーズは秘密鍵を暗号化しておき、使用するときに解除して使用するためのパスフレーズである。 システムが十分に安全かつ強固に保護され、運用されているのであれば(物理的に盗まれることも、ネットワークごしに盗まれることも、ディスクをコピーされたとしても使われることも)ないのであればパスフレーズはなくても構わないし、まず考えられない程度に強固なのであればほどほどに強固なパスフレーズでも構わないだろう。

これでホームディレクトリ以下.ssh/conoha_rsa(秘密鍵)と.ssh/conoha_rsa.pub(公開鍵)のペアが作成される。

Explorerではとてもホームディレクトリにアクセスしづらいので、そこをなんとかしておこう。 ExplorerでC:\Users\ユーザー名に移動し、“クイックアクセス”を右クリックして“現在のフォルダーをクイック アクセスにピン留め”を選択する。

あと、適切なエディタがないのも困るので、インストールしておくといい。 無難なのはみんな大好きNotepad++。

ConoHaでサーバーを立てる

ConoHaでの契約については公式のページをみてほしい。

それではConoHaにログインし、“サーバー追加”からサーバーを追加しよう。 練習用なら512MBで良いだろうし、パフォーマンスオフロードを期待するなら1GB以上にしよう。 OSはもちろん、Arch Linuxである。

ConohaでArch Linuxインスタンスを立てる

Rootパスワードは本当に強固なものにすること。 ここはあまり心配のない部分だが、それでも24文字以上くらいにはして欲しいところだ。

オプションを開き、接続許可ポートを設定する。 IPv4/IPv6ともSSHのみを許可するように設定する。 IPv6のない環境からアクセスするのであればIPv4のみでも構わないし、IPv6でのアクセスが確実な接続形式をとっているのならIPv6のみのほうが良い。

ConohaでポートとSSHキーの設定

そしてSSH Keyセクションは “キーを新規作成” を選択し、“登録方法”に“インポート”を選択する。 そして“パブリックキー”のところに、作成した~/.ssh/conoha_rsa.pub (.pubファイル!!!)の内容をコピペする。

この時点で鍵登録しておくとSSHのパスワード認証が無効化された状態でインスタンスが立つので安全な状態になる。

インスタンスを作成し、起動したら、ConoHaのサーバー一覧からサーバーを開くと“VPS設定”からI逆引きホスト名を知ることができる。

それでは例えばここがv0-0-0-0.a00a.tyo0.static.cnode.ioだと仮定しよう。

SSHでログインする

ではいよいよWindowsに戻ってログインしよう。 OpenSSHの-iオプションに秘密鍵を指定する。引数はSSHのホストだが、その前にユーザーが必要だ。

>ssh -i .ssh/conoha_rsa root@v0-0-0-0.a00a.tyo0.static.cnode.io

ログインできたらexitして一旦SSHを抜ける

# exit

もう少し楽にログインできるように設定をしておこう。 .sshディレクトリにconfigというテキストファイルを作成する。拡張子はない。 UTF-8+LFで編集してくれるエディタを使うのが良いかもしれない。

このファイルは次のような感じだ。

Host conoha-root
  HostName v0-0-0-0.a00a.tyo0.static.cnode.io
  Port 22
  User root
  IdentityFile .ssh\conoha_rsa

これで

>ssh conoha-root

とするだけでログインできるようになる。

OpenSSHが使えない場合

TeraTermを使う方法が公式で紹介されている。

TeraTermの使い方公開鍵の使い方が紹介されている。

ユーザーを作成する

Windowsでは歴史的経緯から曖昧だが、rootユーザーというのは全権を持つ「神」であり、普段使うべきではない。 それどころか、rootのシェルプロセスがあるだけでも望ましくないくらいだ。

Archはインストール時にユーザーを作成しない。自ら作成する必要がある。

ではログインして作業しよう。 ユーザー作成コマンドはuseraddだが、オプションとしては-U(ユーザープライマリグループを作成する), -G(グループを指定する), -m(ホームディレクトリを作成する)を使用する。 このユーザーは管理ユーザーとなるのでwheelグループに加えておこう。

# useradd -U -G users,wheel -m conohachan

ユーザーのパスワードを設定する。とても強固なものが良い。

# passwd conohachan

ユーザー用の鍵を登録しよう。ここではOpenSSHを前提に進める。 Windowsでもうひとつcmdを立ち上げ、先程と同じ要領でキーを作る。

>ssh-keygen -f .ssh/conoha-user_rsa

configを追加する。今度は鍵とユーザーが異なる。

Host conoha
  HostName v0-0-0-0.a00a.tyo0.static.cnode.io
  Port 22
  User conohachan
  IdentityFile .ssh\conoha-user_rsa

鍵をアップロードする。まだrootでしかログインできないので、rootで送る。

>scp .ssh/conoha-user_rsa.pub conoha-root:.

これでConoHaのrootホームディレクトリにコピーされるので、これをSSHに戻ってセットアップする。 まずはユーザーの.sshディレクトリを作る

# mkdir ~conohachan/.ssh

そして、authorized_keysというファイルとして配置する。

# mv conoha-user_rsa.pub ~conohachan/.ssh/authorized_keys

このままだとrootユーザー所有ファイルになってしまうので、直しておく。

# chown -R conohachan:conohachan ~conohachan

.sshディレクトリはオーナーのみアクセス可能であることが求められるため、パーミッションを修正する。

# chmod 700 ~conohachan/.ssh

これでユーザーとしてログイン可能になったはずだ。

>ssh conoha

初期設定

まだrootのセッションも閉じないでおこう。 この状態では管理作業ができるのはrootだけなので、conohachanにも許すようにしたいところだ。

/etc/sudoersというファイルを編集するのだが、これは直接編集してはならない。 visudoというコマンドを使う。エディタにVIが入っていないのでエディタも指定してあげる必要がある。

# EDITOR=nano visudo

下の方にこんな行がある。

# %wheel ALL=(ALL) ALL

このコメントアウトを外しておく。次のように。

%wheel ALL=(ALL) ALL

オーケー。Ctrl+Oして保存し、Ctrl+Xで終了しよう。

ConoHaでは最近、script側でアップデートするようなので不要に思えるけど、一応アップデートしよう。この作業は定期的にしなければならない。

# pacman -Syu

カーネルパッケージ(linuxというパッケージ)が更新対象に含まれていた場合は再起動する。SSHのセッションは切られる。

# reboot

もう少し使いやすく…

とりあえずここからはLinuxを長年使っている身として「それなりに使いやすい環境を整える」ところをやっておきたいと思う。 特にArch Linuxはミニマルなので足りないと感じるものは色々あるだろう。

パッケージを揃える

まずはユーザーログインする。

>ssh conoha
Enter passphrase for key 'C:\Users\harukamy\.ssh\conoha-user_rsa':

$

ちょっとrootでの作業が続くのでrootになる。

$ sudo bash -l
[sudo] password for conohachan: 
# 

サーバーなら必要ないのだけど、まずはユーザーで電源切ったり再起動したりできるようにしておこう。pacmanはArch Linuxのパッケージ管理ソフトウェアであり、ソフトウェアをインストールしたりアンインストールしたりアップグレードしたりできる。

# pacman -S polkit

これでsystemctl poweroffsystemctl rebootがユーザーでできるようになる。

VI, vim, Zshはなくてはならないソフトウェアだ。あと、ターミナルデュプレクサも欲しいのでtmuxも入れておこう。 Zshはgrml-zsh-configパッケージをインストールするとすごく使いやすくなる。 あと、このあとyayを入れる関係でgoとgitも入れておく。

# pacman -S vi vim vim-plugins zsh grml-zsh-config tmux go git

いい感じになってきた。ここで一旦rootを抜け、tmuxを起動する。

# exit
$ tmux

tmuxはプレフィックスキーを押したあとになにかキーを押すとtmuxに対する指示になるようになっている。 デフォルトのプレフィックスキーはCtrl+bで、?を入力することによりキーバインドの一覧が表示される。

とりあえずcが新しいウィンドウを作成するコマンドなので、Ctrl+b Ctrl+cと入力しよう。

これでわかりにくいがふたつのウィンドウができた。nコマンドによりこのウィンドウを行き来できる。

pacmanが扱うことができるのはArch Linuxの公式パッケージだけだ。 AURという、非公式の(しかし、運営自体は公式に行われている)パッケージも扱いたいので、yayというソフトウェアをインストールする。 手順は

  1. Gitを使ってyayのリポジトリをコピー
  2. yayディレクトリに移動
  3. makepkgでパッケージを作成
  4. pacmanで作成したパッケージをインストール
$ git clone 'https://aur.archlinux.org/yay.git'
$ cd yay
$ makepkg
$ sudo pacman -U *.pkg.tar.xz

これでAURのパッケージもインストールすることができる。 もし、yayに不満ならばついでにもうひとつのAURヘルパーであるtrizenもインストールしておこう。pacmanと違い、AURヘルパーはユーザーとして実行する。

$ yay -S trizen

yayやTrizenは公式のパッケージも扱うことができる。

見やすく、使いやすく

まずはすごく簡単な話として、Bashなど投げ捨ててZshにしよう。 Bashなんてゴミだ。

まずは.zshrcを作っておく。

$ touch .zshrc

オーケー。Zshにしよう。

$ chsh
Changing shell for conohachan.
Password: 
New shell [/bin/bash]
> /bin/zsh

chshはログインシェルを変更するだけなので、今のシェルは変更されない。 一刻も早くBashやZshに変えたいので、Zshでログインしよう。

$ zsh -l
%

Poifect! grml-zsh-configをインストールしているのでとても快適に仕上がっているはずだ。 とりあえず途中でわからなくなったら、わかるところまで打ってからTAB連打で切り抜けられる。オプションやオプション引数なんかもだ。 あと、f/b/b<TAB>foo/bar/bazに展開する、なんてこともできるようになる。

さらにZshを強化して、Zshから離れられない体にしてやろう。

$ yay -S zsh-completions zsh-syntax-highlighting

Syntax Highlightを使用するため、.zshrcに次のような記述を行う。 vimが使えるならvimを使えばいいし、ダメならnanoでもいい。

grml-zsh-configはヒストリを辿ったときに「既に第一ワードを入力している場合は第一ワードを確定として、途中の場合は第一ワードの検索開始時カーソル位置までを確定として辿り、カーソルは末尾に移動する」という挙動になっているのだが、「常にカーソル位置までを確定として履歴を辿る」という機能も欲しいのではないだろうか。 というわけで、PgUp/PgDownでそのような検索ができるように.zshrcを追記する。

うーん、beautiful!

さて、ここからはちょっと複雑なことをする。 わかりやすく美しいZshプロンプトのPowerlevel9kを使いたいと思うのだが、これはWindowsだとひと手間ふた手間ある感じだ。

とりあえずインストールだけはしておこう。

$ sudo pacman -S zsh-theme-powerlevel9k

ここからは一旦ログアウトして(各シェルのログアウトしたあとSSHからログアウトするのを忘れずに)Windowsだ。まずはGit for Windowsをインストールする。

これで様々な問題を解消できるようになる。別にMSYS2を入れてもらっても構わないのだが、Git Bashが各種設定を済ませてあるので話が早い。

そして、次にCicaフォントをインストールする。 完全なPowerlineグリフを持っているので話が一番てっとりばやい。このフォント、グリフが豊富で見やすく、制限された状況で本当に便利だ。

で、Git Bashを起動して、右クリックからのOptionsで、フォントをCicaにする。ここまでやっておかないと後で困る。 それではGit Bashからログインしてみよう。

$ ssh conoha

通常Git Bashでも.exeは省略できないのだが、sshはGit Bash側で定義されており、省略できる。

minttyになったことでだいぶ見やすくなったのではないだろうか。Cicaフォントだし。 で、powerlevel9kなのだけど、とりあえず私がサーバーで使っている設定を晒そう。

これはVIモードで使うことを前提にしているので、一般化すると次のような感じか。

で、powerlevel9kなのだけど、とりあえず私がサーバーで使っている設定を晒そう。

grml-zsh-configを使っている関係で先にprompt offするのは必須。 FOREGROUNDとBACKGROUNDの色はお好みで、という感じだ。 Zsh上で(つまり、ログインしたConoha上で)

% for i in {000..255}; do print -P "$i %K{$i}     %k"; done

とやれば、番号ごとにどんな色か把握できる。 もちろん、もっと好みに設定を変更しても構わないだろう。

これも.zshrcに記述する。

この設定は作業中のミスをなくすために行っているもので、実のところ私は普段はPowerlevel9kを使っていない。 だが、SSHから入ったときだけPowerlevel9kになるようにしており、ホストごとに色を変えてある。このことにより、「ローカルホストかリモートホストかを間違える」事故を防止している。

実際、普段はgrmlデフォルト

このホストにSSHで入るとこうなる。

フォントが設定されていないcmd.exeから入ると表示が乱れている。右側のウィジットが次行に表示されているので使えないこともないが…

Git Bashなら正しく表示される。

Powerlevel9kの利用は好みの問題だと思うけれど、Git Bash + Cicaという組み合わせはやって損がないのではないだろうか。

Powerlevel9kの利用は好みの問題だと思うけれど、Git Bash + Cicaという組み合わせはやって損がないのではないだろうか。

自動アップグレード

とりあえず毎日朝6時にアップグレードするようにしてみよう。 Arch LinuxのinitであるSystemdというものを利用する。SystemdにはSystemdタイマーというジョブスケジューラがあるので、これを使うのだが、説明はとても難しいのでとりあえず例示にとどめよう。

rootとして/etc/systemd/update.serviceを作成する。

% sudo nano /etc/systemd/update.service

続いて/etc/systemd/update.timerを作成する。

% sudo nano /etc/systemd/update.timer

時は来たれり

バッチリだ。ここまで来れば、 サービスや他者に迷惑をかけない範囲であれば 君が学んだことを存分に発揮できる場が出来上がったはずだ。

例えばvimを練習したいのなら

% vim vim-training-file

とかやればいいし、Pythonでプログラムを書きたいなら

% vim myfirst.py

とかやればいい。

Linuxについて教えると話は無限に長くなるし、そもそもここまでの一連の作業でそれなりにLinuxに慣れる要素もあったので、Advent Calendarの記事としてはこれくらいで良いではないかと思っている。 この記事のソースファイルはこの行が606行目だし。

というわけで、世の中の人がちょっとでもLinuxに、そしてコンピュータに関心を持ってくれれば幸いだ。 ついでに、こんなふうに簡単にサーバーを立てて、練習やアウトソースにも使えるConoHaは素晴らしいサービスです!(おべっか)

Linuxについての突っ込んだ話はこのChienomiでしているから、関心がある人はぜひチェックして欲しい。 コンピュータやLinuxについて学びたい、教えて欲しいという人はぜひMimir Yokohamaへどうぞ。

それでは今年もこのへんで。はるかみ☆でした♪

Linux zsh/デュプレクサ/ssh設定の勘所

ここのところ大作をいくつも書いているため、忙しさも手伝ってなかなかアップロードできない。 この話もLinuxを使えるようセットアップする話をまとめようと思っていたのだが、それはあまりに時間がかかってしまうので、かいつまんで解説しようと思う。

世の中にはLinuxをインストールだけ繰り返すという人もいるのだが、だいたいそういう人はセットアップをしない。

1台だけのコンピュータを使う人、というのも、実はLinux手練(というよりも達人)の中でも結構多いのだが、1台だけ使っているうちにはその中で順次セットアップを煮詰めていけば良いのだが、Linuxは複数台使ってこそその真価を発揮するし、そうなると素早く適切にセットアップすることが求められる。 特にConoHaでインスタンスを立てたり閉じたりする場合にはなかなか重要だ。

ここでは頻繁にセットアップを行うがまだ手順を確立していない人、あるいはセットアップ自体確立していない人のために私のコツをご紹介しよう。

なお、ここでは前提としてManjaro Linuxあるいは(サーバーにおいては)Arch Linuxをセットアップする前提にあり、その中で極力少ない労力でセットアップしようとしている。 基本的な方針は他のディストリビューションでも応用できるはずだが、労力の多寡に関してはこの限りではない。

また、シェルはZshを使っていることを前提としている。 Bashを使っている人はZshに乗り換えてしまえば良いと思うが、Fishを使っている人に関しては私はわからないので留意していただきたい。

初期セットアップに関して

とりあえずアップデートして再起動

# pacman -Syu
# reboot

vimがないと設定に困るのでvimを用意する。 viも別パッケージであるのだが、むしろ不便なのでシンボリックリンクにする。 vim-pluginsが入っていればだいたい良いので、一緒にいれておく。これでvimで苦痛を感じることなく使うことができるようになる。 (デスクトップではvimではなくgvimを入れる。そうするとXセレクションを扱えるようになる)

# pacman -S vim vim-plugins
# (cd /bin; ln -s vim vi)

設定ファイルをViなんかで書けるか! Emacsにしろ! という人はEmacsも入れる。 私はEmacsを使わないのであまり詳しくない。 こちらもデスクトップではemacsパッケージを入れる。

# pacman -S emacs-nox

ここで一般ユーザーを作っておく。もちろん、Manjaroでは必要のない作業。 Manjaroでは一般的なデスクトップユーザーに追加すべきグループが多いので留意する必要がある。

# useradd -m -U -c "First User" -s /bin/zsh -G wheel,storage,sys,network luser
# passwd luser

wheelグループにsudoを許すようにする。 $wheelの行のコメントアウトを外す。NOPASSWDになっている行ではないほうが良いだろう。

# visudo

Zshをログインシェルにしたが、まだ設定していないのでbashで入る。

# sudo -u luser bash -l

AURを扱うのであればとりあえずyayを入れるのがお勧め。 Archでも2パッケージで済むからだ。それにタイプ数も少ない

$ sudo pacman -S go
$ git clone 'https://aur.archlinux.org/yay.git
$ cd yay
$ makepkg
$ sudo pacman -U yay*.pkg.tar.xz

あとはほしければTrizenでも入れておけば良い。 yaourtとpacaurは「安全ではないソフトウェア」になりつつあるらしいので、とりあえずお勧めはしない。

$ yay -S trizen

w3mとlvがあればとりあえず文書を読むのは楽になる。 コンソール作業する場合は必須

$ yay -S w3m lv

ターミナルマルチプレクサを入れる。Powerlevel9kはGNU Screenで位置がバグる問題があるので、ここでtmuxを入れておく。 一応、screenも入れておく。

$ yay -S screen tmux

Moshは便利だと思うけれど、私はUDPを透過するファイアウォール設定をしたくないため、ここではMoshの話はしない。

Zshとターミナルマルチプレクサ

とりあえず

私が新インスタンスに対して最初にすることは、Zshを導入しセットアップすることである。

ZshからFishに変えた、あるいはZshが使えなくてBashがいいという人の多くはZshのセットアップができていない。 ディストリビューションに良いZshの設定が含まれていることは稀だし、Zshの設定は非常に多くて難しい。 マニュアルを読んで設定を作り上げてこそなのだが、それをしない人が圧倒的に多い。 (似たようなことはVimにも言えるが、Vimの場合はそれが気になるケースは少ないかもしれない)

実は話は実に簡単で

$ sudo pacman -S grml-zsh-config zsh-completions

これで再ログインすれば立派に使えるZshが出来上がっている。

grmlの設定は非常に練られていて、多くの場合これで十分だろう。 (場合によっては調整がいるかもしれない)

なお、Archのgrml-zsh-configはskelが含まれているのだが、Manjaroは含まれていない。 skelのほうは便利ツールがコメントアウトされているものなので、別になくても構わない。

なお、Zshの設定ファイルに日本語を使うとサーバーではトラブルのもとになるので注意してほしい。

オプション

だが、もう少し練ることにしよう。 まず、grmlの設定ではAUTO_CONTINUEが有効ではないので、間違ってフォアグラウンドで起動してdisownしたあとSIGCONTをわざわざ送る必要がある(実際はこのケースではbgしてからdisownするほうが良い)。

重複する部分が多いが、重要なオプションは設定しておこう。

私は次も設定しているが、多分いらない。(RC_EXPAND_PARAMはgrmlではオフかも)

シンタックスハイライト

プラグインの中では便利なもの。 ただし、いくつかのオプションが制限される。

% sudo pacman -S zsh-syntax-highlighting

履歴の機能を拡張

grmlの履歴機能はhistory-beginning-{for,back}ward-endを採用している。 これは、「コマンド部分は途中ならその位置、コマンド部分が入力されていればその部分を維持し、カーソル位置を末尾としてヒストリをたどる」というものだ。

だが、個人的にはオプションも含めてカーソル位置まで維持してくれるほうが好きだ。 全面的に書き換えるのではなく、PgUp/PgDown時はカーソル位置を維持してヒストリをたどるようにする。

本来は記述が足りていないが、この内容はgrmlを前提としている。

履歴を残す量も設定しておこう。 HISTSIZEは検索で辿れる量、SAVEHISTはファイルに残す量だ。

viモード

私はviモード使いなので、設定しておく。

なお、逆にEmacsキーバインドで使いたい人で、EDITORvivimnvimにしている人はちゃんと設定する必要がある。

ターミナルマルチプレクサ

SSHの場合は切れないとか、セッション増やしたいとかだいたい起きるので、使用させることにする。

なお、これでtmuxの設定で

set -g default-terminal "xterm-256color"

とかすると地獄をみるので絶対にしてはいけない。 必ず

set -g default-terminal "screen.xterm-256color"

または

set -g default-terminal "screen-256color"

とすること。

なお、私はGNU Screen使いなので、tmuxのキーバインドはscreen互換にしてある。

プロンプトとテーマモード

私は普段はgrmlプロンプトテーマを使っているが、SSHではPowerlevel9kを使っている。 これは、見やすく、わかりやすいため。普段から使わないのはプロンプトが戻るのがちょっと遅いからだ。

% sudo pacman -S zsh-theme-powerlevel9k awesome-terminal-fonts powerline-fonts

私はテーマ読み込みにこんなことをしている。

前述の$_DEFAULT_SHELLMODEはこのためのものだ。 だが、常にPowerlevel9kで良いのなら、別にロード部分を直接書いてもいい。

grmlと競合してしまうので、prompt offすること。

私の設定はこんな感じ。

このあたりは好みなのだが、実はPowerlevel9kの公式マニュアルにはあるが動かないものというのが結構合ったりする。 典型的には$POWERLEVEL9K_SHORTEN_STRATEGYは多くがうまく動かない。

ポイントになるのが、プロンプトにcontextを使わずuser hostと分けた上でホストのREMOTEのみ色を設定していること。

基本的には「ローカルの場合はどのマシンでも同じ色でいいが、リモートの場合はどのマシンか判別できたほうがよい」と思う。 別にこれ以外のプロンプトテーマでもホスト名は出しているのだが、現在作業中のホストを勘違いしてやっちまった、ということはしょっちゅうある。

まずホスト名に一貫性があってわかりやすい名前をつけることが大切だ。

% sudo hostnamectl set-hostname thinkpad-x1

私の場合は花の名前をつけることにしている。 実はこれは1993年の出来事に由来しており、運用は1998年から、と私としてはとても歴史がある。

さらにメリットとして花なので、色が連想できる。私は$POWERLEVEL9K_HOST_REMOTE_{FORE,BACK}GROUNDはその花の代表的な色をモチーフにした色使いにしている。 それぞれのマシンでイメージが離れた花の名前をつけているため、色被りも少ない。

簡単でわかりやすいのは、機種名とケースの色だろうか。VPSは難しい。

なお、

vi_modeを正しく表示するために必要な部分。

SSH

基本的なSSH

とりあえずroot鍵を登録してパスワード認証は閉じる。

まずはログインするほうでssh-keygen -f <file>によって生成した.pubのほうのファイルを ログインされるほうの~root/.ssh/authorized_keysにコピーする。

なお、.sshはパーミッション0600であること。

このroot鍵を登録するステップはサーバーに対するもので、直接ログインできるのであればスキップすべき作業である。

そして/etc/ssh/sshd_config (ssh_configではない!)を

PasswordAuthentication no

としておく。 この時点で一旦リロード

% sudo systemctl reload sshd

同じ要領でユーザー鍵を登録する。 鍵そのものも分けたほうがいい。

% ssh-keygen -f server-luser_rsa
% rsync -e "ssh -i server-root_rsa" server-luser_rsa.pub root@server:/home/luser/.ssh/authorized_keys
% ssh -i server-root_rsa root@server "chown luser:luser -R /home/luser

以降のために~/.ssh/configに設定しておく。

Host server-luser
  User luser
  Port 22
  HostName server.example.org
  IdentityFile ~/.ssh/server-luser_rsa

これでssh server-luserとして入れるようになる。

なお、HostNameだが、LANで同じセグメント内にいるのであればZeroconfによる.localを使えばいいだろう。 あるいは、各マシンを固定アドレスとして/etc/hostsに書いておくというのも手。 /etc/hosts上の名前は1マシン1つではなく、役割ごとに名前をつけておくと、その役割が他のマシンに移ったときにあまり苦労しなくて済む。dnsmasqで配るという方法もある。

SSHに関する話は以前にしたので、応用技としてはそのあたりを参考にしてくれると良い。

いざというときのための暗号化経路

なにかのときのため、ネットワークごとに1台は透過的にアクセスできると良いだろう。 これはいくつかの方法がある。

最も簡単なのは、Socksプロキシを使うことだ。

% ssh -TND 4711 -o ServerAliveInterval 10 -o ServerAliveCountMax 3 luser@server

これでlocalhost:4711をSOCKS5プロキシとして使用すればSSHサーバーを経由してアクセスすることが可能になる。 これは、ウェブブラウザやメールクライアントで有用である。これは公衆Wi-Fiからアクセスする程度の場合に有効だ。

もうひとつは、SSH経由の環境から利用できるようにしておくことだ。 w3mやMutt, Vim, Emacs, lvなど端末から利用できるアプリケーションを一通り揃えておけば、GUIは使えなくてもひととおりの作業が可能だろう。

本当にそのネットワークを通じてアクセスする必要が生じた場合はどうだろうか? 私はそんなサバイバルな経験を何度かしているが、普通の人はあまりない。 常時必要とするのであればVPNを用意しておけば良いのたでが、緊急避難的に使用できるようにしておくと何かと便利だ。

まずは双方にpppをインストールしておく。

% sudo pacman -S ppp

ログインするサーバーに対してはパスワードをかけたコマンド用rootキーを使うのが最も確実で安全。

command="/usr/sbin/pppd nodetach notty noauth",pty,no-X11-forwarding,no-port-forwarding,no-agent-forwarding ssh-rsa ...

さらに実際に使うときにログインした上でフォワーディングを許す。

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

そしてつなぐ。

% sudo pppd updetach noauth silent nodeflate pty "sudo -u luser ssh server-ssh-ppp" ipparam vpn 192.168.32.1:192.168.32.2

192.168.64.0/24に対してアクセスできるようにしたい場合:

% sudo ip route add 192.168.64.0/24 via 192.168.32.1

すべての未知のホストにこの経路でアクセスしたい場合。サーバーのアドレスは10.0.8.1、現在のデフォルトゲートウェイは192.168.1.1だとすると:

% sudo ip route add 10.0.8.1 via 192.168.1.1
% sudo ip route replace default via 192.168.32.1 proto static metric 101

一連のサーバー&SSH技 応用・実用編

このブログは多くが検索によって解決法を探してたどり着いた読者に支えられている。

このような場合、その人が向いている方向としては二種類ある。

ひとつは、なにをしようとしているかが(適切かはどうかはともかく)決まっている場合だ。 ポートフォワーディングしたい、とか、SSHでなんとかならないか、とか、自分の中で絞り込みができている場合である。

もうひとつは自分の現状だけを認識している場合だ。 例えば「ストレージがいっぱいなった」とか、「家のデータに外からアクセスできなくて不便だ」とか。 どのような解決方法があるのか、あるいは解決可能なのかどうかから探している状態だ。

このふたつは明確に異なる。

前者であればポイントを絞った答が欲しい一方、自分の中にある前提が間違っていると解決まで回り道をすることになる。 後者であれば何をどう考えて調べればいいのか絞り込んでいくほうが難しい。

しかし前者の問題は解決できるのだが、後者の問題は解決できない、という人が割と多い。 問題を定義し、設計し、手法を構築することは地力が求められ、知識の体系化が進んでいないために発想力が求められると難しい、というケースだ。

そこで、今回はそのあたりに踏み込んで解説していく。

個別ケースや個々の人の理解に合わせた内容は仕事としてやっているので、興味があればのぞいてみてほしい

Overview

Definition

親と同居しているごく普通のLinuxer少女が、日々を便利にするために奮闘する姿でも描けばよい。

…と思ったのだが、VPSを用意するにあたりクレジットカードが必要になるあたり、やはりペット同居のごく普通の乙女、もちろんLinuxerである、ぐらいにとどめておくのが無難か。

phase 1

ストレージの不足を解消するためのNAS導入と、監視カメラの設置を行う。

スマートフォンはきっと愛猫の写真と動画でいっぱいなのだろう。 これに愛猫が勝手にツナ缶を空けて食べてしまわないかチェックしておく必要がある。

phase 2

NASに写真を保存するようにしたはいいが、このままでは仕事中に愛猫の写真を堪能できない。

24時間愛猫とたわむれるためには家にあるデータにもアクセスできなくてはならない。

phase 3

もし愛猫がトラに進化しそうなときには急いで家にかえりこれを阻止しなくてはならない。

また、愛猫がNASからハードディスクを取り出そうとしたときにはデータ保護のためにNASを緊急停止する必要があるはずだ。

構成と発展

予めお断り

コピペでできるようにすることを目標としているわけではないので、詳しい手順などは各自学んでほしい。

難しい部分は過去の記事で解説している。

家用コンピュータを導入する

この手順において一番最初に、そして独立して効果を発揮するのはNASなのだが、設定なども面倒なので、とりあえずコンピュータを用意しよう。

この段階でラップトップがあるのであれば、NASがさき、デスクトップは後でも構わないし、 この場合必ずしもデスクトップである必要はない。 だが、総合的に考えてよりよいコンピュータ環境を構築するのが目標なので、このような余剰部分も今回は入れていく。

さて、やはりコストパフォーマンスを考えても、デスクトップPCは性能が高い。 そこでデスクトップを導入することにしたいが、おしゃれに気を使う乙女としては部屋にあまりに無骨な機械を導入するのは気が引ける。 かといってせっかくコンピュータを導入するならいろいろしてみたい。 悩みに悩んだ彼女は神に問うた。天の声(はるか)はこう答えた

「Pavilion Waveあたりにしとけば?」

まじめに答えて、まじめに構築する話はそのうちMimir Yokohamaでやることにしよう。

NASを導入する

NASの導入と構築もそのうち向こうでやることにする。 今回はLinuxでのテクニック中心なので、簡単に。

ReadyNASあたりが鉄板だろうし、WebDAV(HTTP)で共有すればスマートフォンのデータを転送するのも簡単だ。

もう少しスマートな話をすると、まずはReadyNASでストレージ環境を作り、共有の作成まで進める。 共有をSMBにして、

# mount -t cifs //nas-aa-bb-cc/shared1 /srv/nas

のようにマウントする。

次にスマートフォンをLinuxデスクトップに接続し、MTP経由でデータをコピーする。 あとは

$ rsync -rv ~/Pictures/20180602 /srv/nas/

のようにして(/の有無に注意)コピーすればバックアップが確保された状態になる。

監視カメラを導入する

これはどちらかといえばSocks Proxyの説明のためなので詳しくは省くけれども、ウェブカムとmotionを使うのが定番。動体検知もできる。

これについては結構設定が色々ややこしい。 興味がある人は“Linux motion カメラ”で検索すれば色々でてくるので参考にすれば良い。 設定ファイルを眺めるのも悪くない。

ネットワークに接続する

NASを導入する時点で有線でのネットワークは構築されているはずだが、無線LANルーターを含めて、さらに 有線での インターネット接続環境を構築する。

VPSを契約する

私はConoHaのとServerMan@VPSのユーザーだが、さくらのVPSも結構定番。

今回はゲートウェイとして使うだけなので、最低限でも大丈夫でSSH接続だけできるようにすればよいが、発展的にはあまりおすすめできない。

VPSを契約したらサーバーを設定し、SSHログイン可能な状態にしておく。

ラップトップを買う

外からアクセスできるコンピュータが必要である。 ラップトップを買おう。ネットカフェのような環境からアクセスすることを考えるべきではない。

SSHを設定する

ラップトップで2つのSSH鍵を作り、それぞれデスクトップとサーバーのauthorized keyとして登録する。

制限をかけてもいいが、今回の場合鍵のパスワード保護が可能なため、特にかけないほうが良いだろう。

ラップトップ側の~/.ssh/configは設定が必要。

Host vps
  User jrh
  Port 22
  HostName vps.example.com
  IdentityFile ~/.ssh/vpslogin_rsa

Host target-proxy
  User jrh
  Port 10000
  HostName localhost
  IdentityFile ~/.ssh/proxylogin_rsa
  ProxyCommand ssh -CW %h:%p vps

この場合、VPSのログインしてからリバースプロキシを介してデスクトップにログインする。

localhostはVPSから見たlocalhost(VPSのlo)だが、デスクトップにログインするためのSSHを実行するのはラップトップである。

単純にログインしたあとログインする場合、デスクトップにログインするSSHを実行するのはVPSなので、これがProxyCommandの特徴となる。

単純にSSHを張るだけであればデスクトップからVPSにログインできるようにして、

$ ssh -R 22:localhost:10000 vps

のようにすればよいのだが、経験ではそれはうまくいかないのでそれは記事にした

外から家のデータにアクセスする

これでSSH経由でアクセスできるようになったので、デスクトップでNASをマウントしておけばデータは利用可能な状態になる。 Nemo, Thunarならばアドレス欄にsftp://target-proxy/と入力すればアクセス可能。NautilusならConnect to Serverから。 Dolphin/Konquerorにも同等の機能はあるのだが、うまく動作しない場合がある。

VPSのコンソールやmotionのストリーミングにアクセスする

VPSのコンソールなどWebインターフェイスをもつものについてはインターネットに公開するべきではなくインターネットに閉じておくべきだが、これでは外出中にコントロールできない。

だが、SSHでアクセスできる状態であれば、簡単に解決できる。

$ ssh target-proxy -NCD 8888

Chromiumが簡単。

$ chromium --proxy-server="socks://localhost:8888"

Vivladiでも良い。

$ vivaldi-stable --incognito --proxy-server="socks://localhost:8888"

Firefoxなら専用プロファイルか

$ firefox -P proxylogin

SSHのリバースポートフォワーディングの強化

以前かなり入念に設定して外出中もSSHでログインできるようにしたはずだったのだが、実際に試してみるとうまくいかないケースがあった。

もちろん、前回の設定で、SSHが死ねば再度コネクションを貼り直すようにしたし、サーバーから一定時間応答がなければ死んだとみなすようになっていた。 これで万全のはずだった。

ところが、サーバーからPONGは届いているにもかかわらず、ポートフォワーディングは死んでいる…という事態に遭遇したのだ。

これでは困る。 なぜそんなことになるというのか。

しかし発生するものは仕方ない。 実際にログインできない場合には無理やり貼り直すことにしよう。

方法としては割と単純で、自分自身に対するものではあるが、一旦サーバーにSSHで接続し、そこからSSHで手元のコンピュータに対してログインしコマンドを実行する。 これに失敗すればコネクションが切れているとみなす。

ProxyCommandを使う必要はなく、単純にsshのコマンドとしてsshを含めればいい。

新しく鍵を作ってサーバーに登録する。

サーバーで実行するコマンドはsshである。

また、逆にサーバーでも新しい鍵を作って手元コンピュータに登録する。つまり、互いにコマンド実行用の鍵を登録することになる。

サーバー側で結びつけるコマンドはsshである。 このSSHで~/.ssh/configによってターゲットコンピュータに対してログインするホストを指定する。

Host target-pc-connection-check
    User jrh
    Port 2222
    Hostname localhost
    IdentityFile ~/.ssh/target-pc-connection-check_rsa

サーバー側で鍵に結びつけるコマンドはssh target-pc-connection-checkである。

ターゲット側では次のように登録する。

Host target-pc-connection-check-via-server
    User jrh
    Port 22
    Hostname serverhost.example.com
    IdentityFile ~/.ssh/target-pc-connection-check-via-server_rsa

これでターゲットコンピュータがこの鍵でサーバーにログインすると自動的にサーバーはSSHを実行しターゲットコンピュータにSSHポートフォワーディングを介して接続しようとする。 自動化のためそれぞれの鍵にはパスワードはかけない。

ターゲット側で鍵に結びつけるコマンドはtrueでも良いと思うが、echo OKあたりでも良いだろう。

これでターゲット側から

とすれば、コネクションが到達するかどうかをチェックできる。

Systemdユニットに組み込むと面倒なことになるので、システムトレイアプリに組み込む。

VPN(リバースフォワーディング)をアイコン操作にしてみる

先日の多段SSHによる外出時のログインだが、外出時にリバースフォワーディングをオンにし、帰ってきたらオフにするのはちょっと面倒だし、忘れそうだ。 そこで私は「システムトレイにアイコン出してもらって、クリックしたら閉じてくれるようにしたらいいじゃない」と考えた。

まず、「Linuxでシステムトレイにアイコン」と考えたらまずYadを考えて良い。 ZenityやKDialogはシステムトレイをサポートしていない。

yad --notification --image=<icon> --title=<title on hover>

の形式でシステムトレイにアイコンを表示できる。 --commandオプションをつかってクリック時の動作を指定することもできるし、--menuオプションで右クリックに対応させることもできる。 --commandオプションを指定した場合は終了するかわりにそのコマンドを実行する。

今回の場合クリックしたら終了を含む動作をさせたいので、特にコマンドは指定しない。 そこでyadプロセスが終了したらクリックした後の動作をさせていけばよいわけだ。

必ずしもこの操作をこのプログラムから行う、という制約はないこと、 そして「トンネルを解除しない」という選択がありえることから、ループとし、当該ユニットが動作中であればアイコンを表示する方式にした。

ひとつめのyadはシステムトレイにアイコンを表示し、クリックされるのを待つものだ。 これでクリックされるまではスクリプトはここでブロックされる。

ふたつ目のyadだが、yadの場合zenityと違い、タイプを指定しないで起動するとシンプルなダイアログになる。 アイコンとボタンのタイプはそれぞれ指定できる仕組みだ。 このため、ZenityやKDialogにあるいくつかの動作オプションがまとめられている。 ここではYes/Noダイアログを表示している。

なお、ボタンはボタンのあとに終了コードを書くようになっており、gtk-cancelも利用可能。それ以外は単にラベルとして使用される。

さらにランチャーで使用するため、.desktopファイルも作っておいた。 右クリックでの開始/停止もサポートしている。

これでわかりやすく、操作しやすくなった。

もちろん、SSHフォワーディングを行うスクリプトに含めるというのも手だが、そうすると他の手段が失われてしまう。 Systemdユニットにした上で追加機能は別のスクリプトにするというのは良いアイディアだと思う。

【Linux複合技】 SSHポートフォワーディングしてセッションを維持しつつ多段SSHでファイル転送

SSHでリモートからポートフォワーディング

例えばNAT内に存在するコンピュータに対してサーバーに代理応答してもらう方法になる。

この方法を使えばNAT内のコンピュータに対してサーバーを経由してアクセスすることが可能になる。

このポートフォワーディングは以下のように行う。

-Lと比べ-Rはその意味を見失いやすい。

5000はリモートホスト側のポートであり、リモートホストのこのポートにアクセスすることによりローカルホスト側にアクセスすることができるようになる。

hostはローカルホストからみたポートだ。 sshを実行しているコンピュータ自身に転送するのであればlocalhostだし、LANの他のコンピュータ、例えばbobにアクセスしたいのならbobになる。

10000はhostのポートである。 ここではSSHに対してログインさせたいので、変更していなければ22になるだろう。

リモート側ポートはそのポートを開くため、1024より小さい値を指定するには特権がいる。 逆にホスト側ポートは単にそのポートに転送するだけなので転送したいポートを指定する。

このままだとログインしてしまうのでバックグラウンドで実行するオプション-fと、何もコマンドを実行しない-Nを組み合わせるのが一般的だ。

なお、-gをつけない限りはリモートホストではループバックネットワークインターフェイスにのみバインドされるため、リモートホストに対して外部からアクセス可能になるわけではない。

セキュリティを考えれば、公開はせずにSSHでサーバーにログインし、そこから転送するようにしたほうがいいだろう。

接続を維持する

このままでは環境によっては入出力がないSSHセッションはすぐ切断されてしまう。 そこで、このSSHセッションは維持してもらいたい。

ピンポンのための双方向入出力

結局使わなかったアイディア。

通常のシェルスクリプトではあるプロセスに対して別のプロセスが読むことも書くこともする、ということはできない。 そういうことがしたい場合の方法は主にふたつ。

Procfs

/proc/<PID>/fd/0に対して書き込めば標準入力に入力が与えられる。

このとき注意すべきは、標準入力がつながっているのが端末だと端末に書いてしまうので、標準入力はパイプにつながっている必要がある。 特にパイプから何も入れる予定がないのであればsleepにつなぐと良いだろう。

出力はパイプで受け取れば良い。

FIFO

こっちのほうが普通。 FIFOを使えばそこに書かれた出力を一括して受け取れる。

複数のプロセスが書く場合はちゃんと排他制御すること。 また、後処理を忘れないこと。

リモートがぽん

こんな感じでよかった。

pong.sh

readの-tオプションでタイムアウトしている。Zshスクリプト。

30秒ごとにPINGしていて、45秒間PONGが返ってこなかったら、たぶんコネクションは死んでいる。 まぁ、多分ぴんぽんする必要はないけど。(片方が送り続けていればいいはず)

ただ、死活チェックのために返してほしい。 どちらかといえば向こう側に送り続けてもらう必要がある。

コネクションが切れたら確実に死んでもらおう

こんな感じ。

もしくはこんな感じ。

Systemdでrespawn

systemdで起動させることにして、死んだら復活させてもらう。

[Unit]
Description=Connect for SSH port forwarding

[Service]
ExecStart=/home/jrh/bin/sshforward.zsh
ExecStop=/bin/kill -TERM $MAINPID
Restart=always

enableする予定はないので、Installは省略。

プロセスが死んだらRestart=alwaysなので復活する。 停止するときはユニットをstopすること。

ちなみに、KillModeを省略しているので、停止時にはsshもkillされる。

SSHの設定

SSHログインできるようにする

ここらへんは基本手順。

まず鍵の生成

$ ssh-keygen -f ~/.ssh/server_rsa

これを何らかの方法でサーバーの~/.ssh/authorized_keysに追記する。 ない場合は作成。パーミッションは600であること。

続いて~/.ssh/configに設定

Host server
  Uesr jrh
  Port 22
  HostName server.example.com
  IdentityFile ~/.ssh/server_rsa

これで簡単にログインできるようになった。

$ ssh server

こちらはログインする側の端末の設定である。

コマンド専用鍵を作る

まずは前項と同じように鍵を作って登録する。

転送は許可しないといけないので、こんな感じ。

authorized_keysのコマンド用鍵の行の先頭に以下のようなフィールドを追加する。

command="/usr/local/bin/pong.sh",no-pty,no-X11-forwarding

今回はno-port-forwardingしてしまうと動作しなくなる。 ポートフォワーディングと、標準入出力を使ったやりとりを行うためだ。

なお、この時SSH鍵を使用してアクセスした場合 コマンドは入れなくて良い。 そのコマンドしか実行できないので、勝手にそのコマンドが実行される。

なお、configファイルにはRemoteForwardの項目を入れるようにすると良いだろう。 次のように。

Host proxy-server
  User jrh
  Port 22
  HostName server.example.com
  RemoteForward 10000 localhost:22
  IdentityFile ~/.ssh/server-proxy_rsa

こちらはログインされる側の端末の設定。

多段ログイン

ログインする端末はサーバーにログインしたあと、SSHポートフォワーディングを利用してログインされる端末にログインする。 ログインする端末から見るとSSHを二度行うことになる。

もちろん、このようなことはできないわけではないのだが、これだとSCPやSFTPなどは利用しづらい。 また、できればコマンド一発で簡単にログインしたいところだ。

そこで、まずはログインする側の鍵をログインされる側に登録する。 これでまず、サーバーを経由せず直接に鍵認証可能な状態になる。

その上で設定ファイル(~/.ssh/config)にProxyCommandとしてサーバーのSSHを経由して接続する設定を記述する。

Host target-proxy
  user jrh
  Port 10000
  HostName localhost
  IdentityFile ~/.ssh/proxylogin_rsa
  ProxyCommand ssh -CW %h:%p server
  • Port-Rによってサーバーに開かれているポート
  • HostNameはサーバーにログインしてから接続するものなので、localhost
  • IdentityFileは直接のログインにも使用できるログインされる側に登録されているもの
  • ProxyCommandとして先程の設定に記載したHostの値を利用する

これで外出中でもサーバーを経由して端末にログイン可能になった。

複雑なので手順のまとめ

本文は知識順に記述しているが、ここではミニマムな達成順で記述する。

ここではログインする側の端末をlaptop、ログインされる側の端末をdesktop、サーバーをserverと呼称する。

  1. desktopで鍵を生成し、serverauthorized_keysに登録する
  2. laptopで鍵を生成し、serverauthorized_keysに登録する
  3. laptopで鍵を生成し、desktopauthorized_keysに登録する
  4. serverで動作するPONGコマンドを作成する
  5. server上のdesktopの鍵をPONGコマンドに結びつける。
  6. desktop上でserverに接続するためのコマンドを作成する。このコマンドは基本的に <PING> | <SSH> | <READ>
  7. desktopで作成したコマンドを反復起動するためのsystemdユーザーユニットを作成する
  8. desktop~/.ssh/configにコマンドに結びつけられたserverにログインする設定を記述する。ポートフォワーディングも記述する
  9. laptop~/.ssh/configserverへのログイン、及びdesktopに対してProxyCommandserverを通じてログインする設定を記述する

これで準備は完了。あとはdesktopでユニットを起動し、laptopからserver経由desktopログインのsshを実行するだけ。

おわりに

SSHの応用, systemdユーザーユニット, シェルスクリプト, 入出力とファイルデスクリプタ, procfs, FIFO, プロセスとシグナルなど一般デスクトップユーザーは触れずにいるような基礎知識が詰まったものになり、計らずもさながら中級Linuxer認定試験のような内容になった。

基礎に関する知識と理解があればこのように便利に利用することもできるので、 この記事がmagicalに見える方はぜひがんばって取り組んでいただきたいと思う。

Btrfsのバックアップがうまくいかない

sshの問題

「sshdだとダメなのに、sshd -d(デバッグモード)では通る!!」 と言っていた問題は、yum update -yしたあとで再起動したら解決した。 意味不明だ。

send/receiveはよく止まる

2.79TiBに達した時に、send側コンピュータが停止してしまう。 なお、スナップショットの削除を行って再びためすと、さらに短く失敗するようになる。

最初はオーバーヒートかと思ったのだが、2.79TBで止まる、ということが共通しているため、問題があるように疑われる。

これで代替手段というと、スクリプトを組むしかないか。 それなりに複雑なものになりそうだ。もっとも、btrfsが集中的なwriteそのものを受け付けないのなら話は別だが、3TB近く書けるのだから、まさか。

ストレージワーク:btrfs+EncFS / dm-crypt+ZFSでのリモートミラー

Btrfs上にEncFSを構成したマスターから、dm-crypt上にZFSを構築したスレーブへとミラーする、しかもそれらのホストはシャットダウンされる。これはかなり厳しい条件だった。

やはりシャットダウンされるためにHA(高可用)システムは使えない。シャットダウンする時点で障害発生とみなされるし、切り離された状態で単独でスタートアップして動けない。

さらに、EncFSはrootであってもアクセスを許さないため、非常にセキュアではあるが、GlusterFS GeoReplicationも使えないなど障害になった。

やはり無理な要求である、というのは

LinuxQuestionで聞いてみても
明らかになるだけだった。だが、ここでrsyncが大規模システムに耐えるということが分かったため、rsync(1)at(1)でいこうと決意を固めることができた。

rsync+sshはごくごく単純だ。

rsync -e ssh fromdir user@host:destdir

でいける。だが、まずはZeroconfでアクセスしたい。

Manjaroで/etc/nsswitch.confmdns_minimalを指定しても解決できない。これでホスト名を解決しようと思うと、nss-mdnsパッケージをインストールし、avahi-daemonを動かさなくてはいけない。

さらに、CentOS側が受け入れてくれない。これは、NICがひとつだとそのNICをpublicなゾーンのインターフェイスとみなすが、Avahiはhomeインターフェイスにしか許されていない。そのため、firewall-cmd --add-service=avahi --zone=public --permanentとしてAvahi-daemonへのアクセスを透過する。

これでZeroconfでのアクセスに成功、.localのホスト名でsshアクセスできる。ssh-keygenでパスフレーズなしのキーを作り、アクセスしようとする。ところが、ssh-copy-idしようとした段階でToo many authentication failures for …となり、sshアクセスできない。これは、sshの管理下にある鍵が多すぎる場合に生じるようだ。その数はsshdが登録、管理している鍵とファイルとして~/.ssh以下にある鍵の総数。とりあえずの方法としては、鍵ファイルがあるものだけを鍵として扱うため、~/.ssh/config

IdentitiesOnly yes

と書くと改善される。ただし、ファイル自体が多くなるとこれでもダメだろう。

これで鍵によるアクセスまでできるようになった。

鍵による実際のアクセスの前に、atとrsyncについて確認する。rsyncについては前述の通りで大丈夫。atは

$ <kbd>at now + 1 minutes &lt;&lt;&lt; ‘zsh -c "notify-send \"$(id)\""'</kbd>

すると自身のuidになっているので、atを実行したユーザーで実行されることが分かる。EncFSに対してアクセスするためにはこれは絶対条件だ。

そしてこのままrsyncするとうまくいく。だが、パスフレーズなしで自由にアクセスできる鍵というのは危険だ。

コマンドで制限すべきなのだが、rsyncのコマンドを受ける側がどうなっているのか、というのは非常にわかりにくい。rsync -vvv -au --delete-after -e ssh from destして、パスワードの前に表示されたconnectionの中からrsyncより前を削り、互いにvを削って設定する。

ただし、このままでは外部からファイルを消されるリスクがあるため、ホストも限定したほうがいいかもしれない。ただし、鍵がなければできないのだから、その時はバックアップ側は仕方がない、とも見れる。

今回の成果物も

GitHub
にて公開。