オタク日記
(Mac と Linux, 2016Q4)

---

2016-12-31 (Sat): SSH と EmacsMac/Tramp

SSH の disconnect を防ぐ

OSX の Terminal.app から、Ubuntu-16.04LTS や Raspbian (Debian) に ssh login するのは自分にとっては「ごくあたりまえ」の作業で、 最近まで何も問題が無かった。(どちらの側も OpenSSH。) だのに、何が引き金になったのかわからないが、このところ、 数分？放置すると接続が切れるようになってしまっていた。 普段はそれでも然程の問題にはならないが、このごろのように、 宅外サーバで長々と作業をするようになるとこれは結構煩わしい。

対策は簡単……な筈だったのだが、 最初にやった対策が「効いていない」と判断してしまい、 結構右往左往してしまった。(Ubuntu の ssh/sshd と MacPorts の ssh/sshd が随分違うという事もその「右往左往」を長びかせた原因。)

しかし、結論は最初にやった対策を「もう一押しする」が正解だったようで、クライアント側 (つまり OSX 側) の設定ファイル (~/.ssh/config) で

Host otacky.jp otacky.us
  ServerAliveInterval 10 

とやるだけ。 最初、これを

Host *
  ServerAliveInterval 10 

とやったら、% ssh otacky.us で接続が確立できなくなって、 ダメだと思ってしまったようだ。

Tramp

Ssh でログインして、そこで nano を使うというのもなかなか便利で、 それで用が足りてしまう場合も多いが、ちょっと込み入った事をしようとすると、 かなり制限が多い (なかなか使い方を憶えられないだけ、という噂も :-)

なので、このごろは大抵、EmacsMac の tramp を使って、remote host のファイルを弄る事にしている。 これは凄く強力で、しかもかつては安定して動いていた。が、 これも、上の SSH の不調と前後してかなり悩ましい事になっていた。

• DDSKK と干渉する？ trump だけでもそうなるのか、もしくは sudo を併用した場合にそうなるのか定かではないが、DDSKK で変換がうまく行かない。
• ファイルは読み込んでいるんだが、その buffer が自動では表示されない…… ([C-x b] で明示的に表示させる必要がある)
• 最悪の場合 EmacsMac がフリーズする—— 本当にフリーズしているのか、極端にレスポンスが遅くなっているのかは未詳。

上の「Server からの自動切断」も関与しているのだろうけど、 それを直すだけでは問題は解消しなかった。

半日右往左往してたどりついた解決策は、~/.emacs.d/init.el を編集して、次にようにする事。

.....
;; tramp
(require 'tramp)
;; (setq tramp-default-method "ssh") 
(setq tramp-default-method "scp") ;; #1)
(add-to-list 'tramp-default-proxies-alist ;; #2)
               '(nil "\\`root\\'" "/ssh:%h:"))
;; (setq shell-file-name "/opt/local/bin/zsh") 
(setq shell-file-name "bash")  ;; #3) 
(setenv "SHELL" shell-file-name) ;; #4)
(setq explicit-shell-file-name shell-file-name) ;; #4)
    

ここに

1. #1) 何故か毛嫌いしていたが、どうも、"ssh" とした時よりもこっちの方が「上等」らしい。(ssh と scp を使い分けるんだとか。)
2. #2) remote host に対して、root privilege でアクセスするためのトリックだが、ここでは /ssh:%h: のままでないとダメ。
3. #3) zsh へのフルパスで定義したのでは、remote host にそれが無くてはマズいだろうと……
4. #4) これらの規定がないと、上記の「バッファが自動で表示されない」 が時々起きる。

必要十分条件になっているかどうかは未詳だけど、とにかくこれで、

[C-x C-f] /otacky.us:~/.zshrc’

は勿論の事、

[C-x C-f] /sudo:root@otacky.jp:/etc/ssh/sshd_config’

等もちゃんと働くようになった。副作用も (今のところ) 出ていない。

---

2016-12-24 (Sat): DigitalOcean 讃

この十日程、やたらアクセスが増えて、気が付かないうちに 100万 PV を超えてしまった。こういう急な繁盛は 5 ヶ月前にも一度有ったが、 その時も今回も Crawler Robot 君達の来訪が増えたせい（おかげ？）だろう。 しかし、何故そんな「集中攻撃」が起きて、しかもそれが続くのかよく分らない。 が、まあ、すなおに「タナボタ」を喜んでおく事にする——実は、robot の IP を推測して PV count から外すべくスクリプトを書き始めたが、 意外に面倒な事が解ってすぐ諦めたのだった。

が、一昨日だったか、digoc02.otacky.jp の crontab から、 sitemap_gen.py の実行に失敗しているとのメールが届いた。何でも、 sitemap/config.xml が見つからないんだとか。 ひょっとしたら、これが「タナボタ」の原因かな？ (sitemap_gen.py が、Google 他への Notification をしなくなったら、Robot がよく来るようになるってのも、ちょっとおかしい気もするが。)

まあそれでも、Notification はともかく、sitemap は登録しておいた方が良いだろうから、なんとか sitemap/config を見つけなくては……

しかし、当初の予測に反して、これが結構難航した。

DigitalOcean

まず、digoc02.otacky.jp 内を根気よく捜したが、 sitemap/config.xml は見付からない。 元の自宅サーバには「止めを刺して」しまったので、そちらも捜せない。 残っている、/var/www/html/sitemap.xml の日付が Dec 1 なので、その頃までは有った筈なので、DigitalOcean の BackUp の中を試してみる事にした。

幸い、一番古いのは一月前 (4 週間前) のものなので、かろうじて ~/sitemap/config.xml は残っているはず。 DigitalOcean のサイトへ行って、 Droplets → images → backup と辿って、そこから "create droplet" とやると、backup イメージから、Ubuntu が立ち上がる。

素晴しい。 (但し 6-7 分かかる。) あとは、そこへ ssh login して、 config.xml を捜すだけ。何なく ~/sitemap の下に見付かった。 要は、自分がうっかり ~/sitemap を消してしまった、という事のようだ。

ssh login にはちと「ひねり」が……新たな droplet を作ったという事で、例によって、root の password をメールで知らせてくれるのだが

fukuda@falcon:~% ssh root@128.199.xxx.205 

とやって、そのパスワードを何度入れてもダメ。 「おっかしいなぁ」とかいいながら、ダメモトで

fukuda@falcon:~% ssh 128.199.xxx.205 

とやったら、password も聞かれずにログインできた……つまり、 ~/.ssh/ 以下も新 droplet ではそのまま再現されているので、Falcon からなら、password 無しで fukuda アカウントにログインできる訣。 但し、逆にこのせいで、otacky.jp には ssh でログインできない……

fukuda@digoc02otackyjp20161126-2gb-sgp1-01:~% ssh-keygen 
    -f "/home/fukuda/.ssh/known_hosts" -R otacky.jp
# Host otacky.jp found: line 1
/home/fukuda/.ssh/known_hosts updated.
Original contents retained as /home/fukuda/.ssh/known_hosts.old
fukuda@digoc02otackyjp20161126-2gb-sgp1-01:~% rsync -Cuav sitemap otacky.jp:
fukuda@digoc02otackyjp20161126-2gb-sgp1-01:~% ssh otacky.jp
    .....    
fukuda@digoc02:~% python ~/scripts/sitemap_gen.py \
   --config=sitemap/config.xml  --testing 
   
Reading configuration file: sitemap/config.xml 
The Sitemap type is WEB Sitemap.
Walking DIRECTORY "/var/www/html/"
Sorting and normalizing collected URLs.
Writing Sitemap file "/var/www/html/sitemap.xml.gz" with 98 URLs
Search engine notification is suppressed.
Count of file extensions on URLs:
      98  .html
Number of errors: 0
Number of warnings: 0

これでできた sitemap.xml.gz を展開してみると、 既存のものと同じようにできているようなので、これでよしとする。

ただし、今回は試しに「二日置き（三日に一度）」で notifiy させる事にする。 すなわち、crontab の該当する行を

40 4 */3 * * python ~/scripts/sitemap_gen.py --config=sitemap/config.xml 

と書換えた。

またもや自分の「錯和（チョンボ）」の尻拭いをしたわけだが、しかし、 ここは DigitalOcean の Backups がちゃんと使える事を確認できたのが嬉しい。 ほんとに DigitalOcean VPS は「お値打ちモノ」だと思う。

---

2016-11-26 (Sat): Raspberry Pi で自宅サーバ (その 2)

RasPi 自宅サーバで DNS/DHCP を運用中であるが、 問題なく動いてくれていて、これは中々快適。 が、しかし本来の目的は「瀕死の旧サーバから全ての機能を移す事」だから、 ここで気を抜いてはいけない……

「Rsync 簡易データベース」は、RasPi (otacky.us) サーバではなくて、 DigitalOcean (digos02.otacky.jp) に移す事にした。考えてみれば、mobile device からの Sync は、こちらの方が断然速いし、しかも RasPi (sparrow.otacky.us) サーバの ssh ポートをグローバルに公開する必要もない……。 何より嬉しいのは重要なファイルのバックアップを、VPS のところ (シンガポール) にもう一揃い持てる事。(VPS のストレージ全体を 1 週間毎にバックアップしてもらっている。)

SSH サーバ

ここまでなら、新自宅サーバを DMZ に置く必要はないし、sshd のポートを外部に開く必要さえ無くなる……が、外部から ssh login する必要は無いだろうか……。ちょっと悩んだが、 「やっぱり要るだろう」という結論になり、しかも ssh port forwarding ではなくて、 RasPi サーバを DMZ に置くというオタクっぽい構成にする事になった (やっぱりな :-)

Sshd 自体 (openssh-server) は極最初からインストールされている。 なので、新たにやるべきは

1. 'No passphrase' の rsd key を作る

   fukuda@sparrow:~% ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/fukuda/.ssh/id_rsa): 
   Created directory '/home/fukuda/.ssh'.
   Enter passphrase (empty for no passphrase): 
   Enter same passphrase again: 
   Your identification has been saved in /home/fukuda/.ssh/id_rsa.
   Your public key has been saved in /home/fukuda/.ssh/id_rsa.pub.
   The key fingerprint is:
       .....

2. client から id_rsa.key をコピーしてきて、

   fukuda@sparrow:~% cat id_rsa.pub >> ~/.ssh/authorized_keys 

3. password login を禁止する

   # /etc/ssh/sshd_conf
       #PasswordAuthentication yes
       PasswordAuthentication no

[NB] これ以降、id_rsa.pub を登録していないホストからは一切ログインできなくなる。

UFW

DMZ に置くからには、firewall が必須。これはもう UFW しかないだろう。

fukuda@sparrow:~% sudo ufw enable
fukuda@sparrow:~% sudo ufw limit OpenSSH                     
fukuda@sparrow:~% sudo ufw allow from 192.168.0.0/16 to any app Bind9
fukuda@sparrow:~% sudo ufw status verbose 
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)              #1
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           LIMIT IN    Anywhere         #2
22/tcp (OpenSSH (v6))      LIMIT IN    Anywhere (v6)    #3
53 (Bind9)                 ALLOW IN    192.168.0.0/16   #4

そのココロは

1. #1) 基本、外向き接続は全部通すが、内向きは全部ブロック。
2. #2) Port:22 (ssh) へは、どこからの接続要求でも通すが、 あまり頻繁な接続要求 (過去 30 sec の間に 6 回以上のアクセス) は拒否。
3. #3) IPv6 のアドレスも通す。これまでこれが必要だった事はないが、 Raspbian の # apt update コマンドは、IPv6 アドレスからファイルを取って来ようとするので、これは必須。
4. #4) DNS への名前解決の要求は、local network からのもののみ通す。

Logwatch + Postfix

SSH ポートを外部に開くとなると、なんだか logwatch がないと心配になる。 で、それを常用のアカウントへ Mail でレポートして欲しい——どんどんオタク趣味になっていくなぁ。

fukuda@sparrow:~% sudo apt install postfix    
# edit /etc/postfix/main.cf to change myhostname
fukuda@sparrow:~% diff /etc/postfix/main.cf{,~}
31c31
< myhostname = sparrow.otacky.us
---
> myhostname = sparrow
fukuda@sparrow:~% /usr/sbin/sendmail fukuda@otacky.jp
To: fukuda@otacky.jp
Subject: Test from Sparrow via Postfix-sendmai

test line 1
test line 2
.    

驚いた事に、これでしっかりメールが送られる。ちょっとまごついたのは、 ディフォルトの PATH に /usr/sbin が入ってないので、 /usr/sbin/sendmail とする必要が有った事くらいかな。 宛先の IMAP4 サーバに

To: fukuda@otacky.jp
Subject: Test from Sparrow via Postfix-sendmai
From: fukuda@sparrow.otacky.us (Taka Fukuda)
Date: Sat, 26 Nov 2016 06:31:45 +0900 (JST)
X-Spambayes-Classification: ham; 0.02

test line 1
test line 2  

が届いていた。 (そう、かつては、Postfix ってこれくらい簡単だったんだよなぁ——というか、 メールを送り出すだけなら今でも簡単というべきか。)

続いて、logwatch をインストール、設定、確認。

fukuda@sparrow:~% sudo apt install logwatch
# edit /usr/share/logwatch/default.conf 
fukuda@sparrow:/usr/share/logwatch/default.conf% diff logwatch.conf logwatch.conf.orig
35c35
< Output = mail
---
> Output = stdout
44c44
< MailTo = fukuda@otacky.jp
---
> MailTo = root
77c77
< Detail = Med
---
> Detail = Low 

fukuda@sparrow:~% sudo logwatch --range today --output stdout 
[sudo] password for fukuda: 
 
 ################### Logwatch 7.4.0 (03/01/11) #################### 
        Processing Initiated: Sat Nov 26 07:21:42 2016
        Date Range Processed: today
                              ( 2016-Nov-26 )
                              Period is day.
        Detail Level of Output: 5
        Type of Output/Format: stdout / text
        Logfiles for Host: sparrow
 ################################################################## 
 
 --------------------- Cron Begin ------------------------ 

 Commands Run:
    User root:
          cd / && run-parts --report /etc/cron.hourly: 8 Time(s)
       test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ): 1 Time(s)
 
 ---------------------- Cron End ------------------------- 
    .....

ここまでできていれば、logwatch がインストールされた時点で、 /etc/cron.daily/00logwatch ができているので、 時間 (6:25 a.m.) になれば、メールアカウントに一日分のログのサマリーが送 られてくる筈。

完全移行確認

上の移行の途中、旧サーバ (lark.otacky.us) の daemon を止めてきたが、 この時点で

1. 旧サーバの Ethernet ケーブルを抜いて、
2. WiFi Router (WZR-HP-AG300H) の DMZ を新サーバに向け
3. 新サーバをリブート

して最終チェック。と言っても大した事はしてなくて、

• Tethering を使って、外部 (global network) から、SSH で login できる事 (id_rsa.key を登録してあるホストからのみ)。
• 外部からは、DNS (named) にアクセスできない事、
• iPhone から WiFi の 2.4G と 5 G に交互に接続してみて、ちゃんと登 録されている事

等を確認。

旧サーバを殺す (ホントに)

さて御役御免となった旧サーバをどうしようか……。とにかくファンを交換して、 CPU のグリスを塗り替える事が必須なんだけども、それまで dhcp-client を動かせて、普通の Linux ホストに……とやっているうちに、まさかの # rm -rf /etc/ をやってしまった……。 （チョンボは色々やってきたけど、これほど「凄い」のは初めて。 高熱が出て虫の息になってる人に「止め」を刺してしまったような気がする。）

---

2016-11-19 (Sat): Raspberry Pi で自宅サーバ (その 1)

旧自宅サーバがついにダウン

HTTP, SMTP, IMAP4, MailMan サーバ等、 旧サーバ（Lark: ThinkPad X200, Ubuntu-14.04LTS) の機能の殆んどは既に 宅外サーバ (DigitalOcean VPS, Ubuntu-16.04LTS) は移してしまっており、自宅サーバは今や、DHCP や SSH のサーバ、 簡易データベース (rsync でモバイルクライアントとのデータ同期専用) くらいしか担っていない……。

なので、どうしてもその管理がないがしろになる……夏場、CPU 温度が上がり過ぎてフリーズ——いつものように、 屏風のように立て掛けてしのいだ。 少し前には、何かの都合でリブートしようとしたら "Fan Error" と表示さいたまま立ち上がらなくなりちょっと焦った。 が、再起動したら治ったので、 またまた喉元過ぎたら……という体たらく。

先週だったか、それがまた起きた……今度は、何回起動しても、 "Fan Error" で勝手にシャットダウンしてしまう。 パニック！ 4 回目くらいだったかで、ようやく起動できたので、 今のうちにと、大急ぎで新サーバに移行する事を試みた。

実は、しばらく前に一度試みた——実際 Bind9 が動くところまで行った——のだが、市販の RasPi 用の UPS が高価な上に「不細工」なので、なんとなく沙汰止みになっていた。 という事で、 RasPi 3 (raspi08) にその時の痕跡が残っているが、 こちらは WiFi や BT が載っているので、そっちむけに残しておこう、 というケチな料簡が起きて、RasPi 2 (raspi06?) に、 Raspbian-2016-09-23 のインストールから始める事にした。

OS インストール

1. Raspbian のサイトから、lite を選んでダウンロード。 （たかが、290 MB のファイルのダウンロードに、3 時間もかかった…… 前からこのサイトは遅いけど、なんだかますます酷くなる。）
2. 買い置きの 32 GB の mini SD カードに、 Mac から焼く。

   fukuda@falcon:~% sudo diskutil list
   fukuda@falcon:~% sudo diskutil unmountDisk /dev/disk6
   fukuda@falcon:~% sudo dd bs=1M of=/dev/rdisk6 \
       if=Downloads/2016-09-23-raspbian-jessie-lite.img 

   これ自体は 62 秒で完了した。ひとつ前の版の書き込みに 4 分かっかていたから、凄い改善。 OS のサイズが半分になっている上に、 SD ドライブの書き込み速度が向上しているに違いない。
3. 同 SD を、Raspberry Pi 2 に差して、 モニタとキーボードを継ぎ起動。 Lite のためか、CUI 画面で立ち上がる。
4. raspi-config で、
   • SSH: enable
   • hostname: sparrow
   • LOCALE: en_US.UTF-8
   • Time Zone: Asia/Tokyo
   あたりを設定しておけば十分？ Keyboard Layout はどうしてもうまく設定できないけど、すぐに ssh login するので、まあ良しとする。 (Locale や Time Zone も後回しにしても可？)
5. reboot

環境設定

少々の不便なら我慢する、という方は、adduser とか zsh 云々のあたりは飛ばしても OK。

• まずは login

  (pve35) fukuda@falcon:~% ssh pi@sparrow 
  pi@sparrow:~ $

• user account を作って、zsh に変更

  pi@sparrow:~ $ sudo apt update
  pi@sparrow:~ $ sudo apt upgrade
  pi@sparrow:~ $ sudo adduser fukuda
  pi@sparrow:~ $ sudo adduser fukuda sudo
  pi@sparrow:~ $ su fukuda
  fukuda@sparrow:~ $ sudo apt install zsh lv 
  fukuda@sparrow:~ $ chsh -s /bin/zsh    
  fukuda@sparrow:~ $ zsh
  # .zshrc 設定のためのプロンプトが出るので、2 を選ぶ
  # 次いで、.zshrc の中の PROMPT を変更
  fukuda@sparrow:~% 

• 自身の static なネットワーク関連の設定（何と、dhcpcd.config でやる！！）

  # /etc/dhcpcd.conf
      ....
  # Custom static IP address for eth0
  interface eth0
  static ip_address=192.168.0.13/24
  static routers=192.168.0.1
  static domain_name_servers=192.168.0.13
  static domain_search=otacky.us 

  この設定が、/etc/resolv.conf に反映される。 （逆に、/etc/hosts, /etc/resolv.conf を手で編集しても、 すぐに dhcpcd に？上書きされる。)

Bind9 のインストールと設定

fukuda@sparrow:~% sudo apt install bind9
fukuda@sparrow:~% sudo systemctl status bind9
fukuda@sparrow:~% sudo systemctl stop bind9

/etc/bind/named.conf は、/etc/bind/named.conf.local と /etc/bind/named.conf.options, /etc/bind/named.conf.default-zones を呼んでいるだけなので、前者二つを編集する（実は旧自宅サーバからコピペ）

// /etc/bind/named.conf.local
// organization
include "/etc/bind/rndc.key";
zone "otacky.us" {
     type master;
     file "otacky.us.zone";
     allow-update { key rndc-key; };
};
zone "0.168.192.in-addr.arpa" {
     type master;
     file "0.168.192.in-addr.arpa.rev";
     allow-update { key rndc-key; };
};

Dynamic DNS にするにはこの記述が重要。Local domain の正引き、逆引きゾーンファイルの名前（/var/cache/bind/ 下にある）と、どのようにして更新するか (rndc-key という key で認証してアクセスする——nsupdate コマンドによる、はたまた dhcp サーバから、にかかわらず。）

// /etc/bind/named.conf.options

options {
        directory "/var/cache/bind";
        forwarders {
                   8.8.8.8;
        };
//      allow-query {lan;};
        dnssec-validation auto;
//      dnssec-enable no;
        auth-nxdomain no;    # conform to RFC1035
//      listen-on-v6 { any; };
};

ゾーンファイルの位置と、forwarder の指定だけ。(ISP の DNS を加えていた事もあったけど、今は 8.8.8.8 のみ。 これだけで十分みたい。）

上のゾーンファイルディレクトリに、上で指定したファイル名 (otacky.us.zone, 0.168.192.in-addr.arpa.rev) のスケルトンを置き、owner を bind:bind にする。

ここで、ファイルの正当性確認

fukuda@sparrow:/etc/bind% sudo named-checkconf /etc/bind/named.conf.local
fukuda@sparrow:/etc/bind% sudo named-checkconf /etc/bind/named.conf.options
fukuda@sparrow:/var/cache/bind% sudo named-checkzone otacky.us otacky.us.zone
fukuda@sparrow:/var/cache/bind% sudo named-checkzone 0.168.192.in-addr.arpa 0.168.192.in-addr.arpa.rev 

これで問題が無ければ、動作確認ができるはず。

まずは、daemon をスタートして、ステータスチェック。

fukuda@sparrow:~% sudo systemctl restart bind9
[sudo] password for fukuda: 
fukuda@sparrow:~% sudo systemctl status bind9 
● bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled)
  Drop-In: /run/systemd/generator/bind9.service.d
           └─50-insserv.conf-$named.conf
    .....
   CGroup: /system.slice/bind9.service
           └─3945 /usr/sbin/named -f -u bind

Nov 21 20:10:36 sparrow named[3945]: managed-keys-zone: loaded serial 5
    .....
Nov 21 20:10:36 sparrow named[3945]: zone 0.168.192.in-addr.arpa/IN: loaded serial 16006  #1)
    ..... 
Nov 21 20:10:36 sparrow named[3945]: zone otacky.us/IN: loaded serial 23861 #2)
    .....
Nov 21 20:10:36 sparrow named[3945]: all zones loaded
Nov 21 20:10:36 sparrow named[3945]: running 

次に、dynamic update を試みる。

fukuda@sparrow:~% sudo nsupdate -d -k /etc/bind/rndc.key
Creating key...
Creating key...
namefromtext
keycreate
> update add xenial3.otacky.us 600 IN A 192.168.0.202
> show
Outgoing update query:
    .....
;; UPDATE SECTION:
xenial3.otacky.us.	600	IN	A	192.168.0.202

> send
Reply from SOA query:
   .....
Found zone name: otacky.us
The master is: ns.otacky.us
Sending update to 192.168.0.13#53
Outgoing update query:
    .....
;; UPDATE SECTION:
xenial3.otacky.us.	600	IN	A	192.168.0.202

どうやら、dummy host の xenial3 が無事付け加えられたようだ。

このエントリを確認してみる。

fukuda@sparrow:~% dig xenial3.otacky.us
; <<>> DiG 9.9.5-9+deb8u8-Raspbian <<>> xenial3.otacky.us
    .....
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;xenial3.otacky.us.		IN	A

;; ANSWER SECTION:
xenial3.otacky.us.	600	IN	A	192.168.0.202
    .....
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 21 20:08:47 JST 2016
;; MSG SIZE  rcvd: 95

DHCP サーバ

Static なネットワークパラメータを実現するには、 dhcpcd (DHCP client) が必要というあたりには大いに面喰らったが、本来の DHCP サーバも（変更箇所は多くないが）意外なファイルを弄る必要があって、 ちょっといやらしい。(そもそも、dhcpcd は isc- ではないのに、 dhcpd は isc- 版だし。)

まず /etc/dhcp/dhcpd.conf を編集。結構長いので、 original との差だけ示すと

fukuda@sparrow:~% diff /etc/dhcp/dhcpd.conf{,.orig} 
4,6d3
< # Attention: If /etc/ltsp/dhcpd.conf exists, that will be used as
< # configuration file instead of this file.
< #
13,15c10
< # ddns-update-style none;
< ddns-update-style interim;  # 11/1/13
< 
---
> ddns-update-style none;
18,20c13,14
< option domain-name "otacky.us";
< #option domain-name-servers ns1.example.org, ns2.example.org;
< option domain-name-servers 192.168.0.13;  #1
---
> option domain-name "example.org";
> option domain-name-servers ns1.example.org, ns2.example.org;
45,60d38
< subnet 192.168.0.0 netmask 255.255.255.0 {
<   range 192.168.0.100 192.168.0.150;
<   option routers 192.168.0.1;
< }
< key rndc-key {
< 	algorithm hmac-md5;
< 	secret "iCgFcCVXsxxxxxx5ePYY9g==";  #2
< };
< zone otacky.us. {  #3
<   primary ns.otacky.us;
<   key rndc-key;
< }
< zone 0.168.192.in-addr.arpa. {  #4
<   primary ns.otacky.us;
<   key rndc-key;
< }

ここに、

1. #1) このように外部のサーバを指定しないでおくと、 ***.otacky.usへのアクセスをローカルドメインからは、 ローカルアドレス、外部からは、global address を示すようにできる。
2. #2) /etc/bind/rndc.key の中身をコピー。 (直接ファイルを指定する方法が有るんだろうけど……。)
3. #3, #4) ダイナミックに正引き、逆引きファイルを更新するための必須の設定。

次に、 /etc/default/isc-dhcp-server で、

# INTERFACES=
INTERFACES="eth0" 

これは、そもそも isc-dhcp-server を動かし始めるためには必須。

旧自宅サーバをネットワークから離して (早い話が、Ether cable を外して) daemon を起動

fukuda@sparrow:~% sudo systemctl restart isc-dhcp-server
fukuda@sparrow:~% sudo systemctl status isc-dhcp-server
● isc-dhcp-server.service - LSB: DHCP server
   Loaded: loaded (/etc/init.d/isc-dhcp-server)
   Active: active (running) since Tue 2016-11-22 06:27:21 JST; 6s ago
  Process: 8714 ExecStop=/etc/init.d/isc-dhcp-server stop (code=exited, status=0/SUCCESS)
  Process: 8720 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/isc-dhcp-server.service
           └─8726 /usr/sbin/dhcpd -q -cf /etc/dhcp/dhcpd.conf -pf /var/run/dhcpd.pid eth0

Nov 22 06:27:19 sparrow dhcpd[8725]: Internet Systems Consortium DHCP Server 4.3.1
Nov 22 06:27:19 sparrow dhcpd[8725]: Copyright 2004-2014 Internet Systems Consortium.
Nov 22 06:27:19 sparrow dhcpd[8725]: All rights reserved.
Nov 22 06:27:19 sparrow dhcpd[8725]: For info, please visit https://www.isc.org/software/dhcp/
Nov 22 06:27:19 sparrow dhcpd[8725]: Wrote 17 leases to leases file.
Nov 22 06:27:19 sparrow dhcpd[8726]: Server starting service.
Nov 22 06:27:21 sparrow isc-dhcp-server[8720]: Starting ISC DHCP server: dhcpd.
Nov 22 06:27:21 sparrow systemd[1]: Started LSB: DHCP server.

として起動…… (実は isc-dhcp-server パッケージをインストールした時点で、server は働き始めていた模様)

Fusion の xenial (Ubuntu-16.04.1 LTS) を起動して、 うまく lease されているか確認。

fukuda@sparrow:~% tail -20 /var/lib/dhcp/dhcpd.leases
  hardware ethernet 40:b8:9a:43:4c:8a;
  uid "\001@\270\232CL\212";
  set ddns-rev-name = "104.0.168.192.in-addr.arpa.";
  set ddns-txt = "316a1fe55a8c188a2d752886f598660aeb";
  set ddns-fwd-name = "TakasPrinter.otacky.us";
  client-hostname "TakasPrinter";
}
lease 192.168.0.119 {
  starts 1 2016/11/18 21:41:05;
  ends 1 2016/11/18 21:51:05;
  cltt 1 2016/11/18 21:41:05;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 00:0c:29:fb:88:a7;
  set ddns-rev-name = "119.0.168.192.in-addr.arpa.";
  set ddns-txt = "00c44191ef988540db2f5fdf01e87ba743";
  set ddns-fwd-name = "xenial.otacky.us";
  client-hostname "xenial";
}

さらにこれが、DNS に反映されているかどうかも確認。

fukuda@sparrow:~% dig xenial.otacky.us
    .....
;; ANSWER SECTION:
xenial.otacky.us.	300	IN	A	192.168.0.119

fukuda@sparrow:~% dig -x 192.168.0.119
    .....
;; ANSWER SECTION:
119.0.168.192.in-addr.arpa. 300	IN	PTR	xenial.otacky.us.

どうやら、うまく行ってるようだ。 実稼働を始める……

まとめ

Raspberry Pi 2 と、2016-09-23-raspbian-jessie-lite の上に、 DDNS (dhcpd + dns) を構築した。

• 内向き名前解決専用、かつ chroot は使わず、また security も最低限 (dnssec は off)。
• にもかかわらず、設定は結構面倒だった。(dhcpcd と dhcpd が originator がそれぞれ違う事による？)
• それ以前に、サーバ自身を Static IP にするのに戸惑った。
• しかし、設定後のデバッグで悩む事は少なかった。 多分 systemd を使う事で、# systemctl status xxxx で起動後すぐにエラーメッセージやログが見える事が大きいだろう。
• あと named-checkconf や named-checkzoneで、config file や zone file を作った直後に確認できたのも「後で悩む」事を減らすのに貢献したものと思われる。
• 性能は十分。global address の名前解決は、140-180 ms, local は 1-2 ms. また、一旦キャッシュされれば、いずれも 1 ms となる。(dnssec が off とは言え、ThinkPad Unbutu-14.04 の DDNS より速いくらい。)

---

2016-11-05 (Sat): Jupyter Notebook (その 3)

UI も「なせばなる！」

Jupyter Notebook は順調で、もう何をやるにもこれしか使わない……というの はちょっと言い過ぎで、まあ時々は iPython のごやっかいになっている。 Jupyter の使い始めの頃の 「iPython でできるのに、Jupyter ではできない事が有る」との不満は、 例えば、アトリビュート (メソッド) の拡張について、 iPython では、np.fft. までタイプインして、Ctrl-I と打つと、Ctrl-n/p でリストの中から選択でき、その状態で Return キーを打てば、コマンドラインに fft2 が挿入される。 素晴らしい！ (Python のディフォルトシェル？から iPython に移ったのは、主にこれと <object>? や %timeit のためだったかも知れない :-p )

しかし、Jupyter ではこれができない、と思っていたのは、私の早とちりで、 勿論可能。但し、上の Ctrl-I ではなく、TAB キーを押さないと、 窓が表われない……これは比較的早く気がついたが、しかし窓が表われても、 そのエントリの一つをクリックしても、選択した文字列は挿入されない……。

実は、クリックしただけではだめで、 カーソルキーでグレーの部分を移動して選択してから Return キーを押すのだった。

てな具合で大抵の事は Jupyter でもできるようになった、 というか、できる事がようやく解った。 しかし、Input cell 内でのコマンド他の使い勝手は、iPython にまだ一歩及ばない。という事で、少なくとも暫くは「併用」が続きそう。

この「使い勝手」云々は、まあしかし、自分が GNU readline に慣れているから、 というだけの事かも知れない。あまり責める気になれないし、 これから Jupyter を使ってみようという人の熱意に水を差す気もないけど、 しかし、次の (PDF) の問題はどうも「なんだかなぁ」である。

PDF — Download as PDF

Jupyter の環境を作るのが以前程難しくなくなったとは言え、 作った Notebook の .ipynb ファイルを誰彼無しにそのまま送りつける訣には行かない、 できれば .pdf ファイルにして送りたい。

使い始めの頃、Jupyter 画面の [File] → [Download as] → [PDF via LaTeX (.pdf)] で、あっさり .pdf ファイルができて、 また、仕上がりもそこそこだったのに、いざ Notes が完成してみると、 エラーになる……。随分思い悩んだが、長い話を思いっきり短くすると

• 後になってエラーになるのは、当初疑った pandoc のバージョンアップのせいではなくて、Notebook に日本語が含まれるようになったから。
• nbconvert の ディフォルトは

  (pve35) fukuda@falcon:~/pve35% cat ./lib/python3.5/site-packages/nbconvert/templates/latex/article.tplx
      .....
  ((* block docclass *))
  \documentclass[11pt]{article}
  ((* endblock docclass *))    

  となっているから、

  (pve35) fukuda@falcon:~/pve35% cat article.tplx
      .....
  ((* block docclass *))
  %\documentclass[11pt]{jsarticle}
  \documentclass[a4paper,dvipdfmx]{jsarticle}
  ((* endblock docclass *))    

  と書き直す。これで、「"multi-byte" code に対応できない」 というエラーメッセージは出なくなる。 が、代りに、「'LaTeX2e ではなくて、'pLaTeX2e' が要る」と言われる。
• platex を呼びさえすれば良いように聞こえるので、

  (pve35) fukuda@falcon:~/pve35% jupyter nbconvert --to latex Untitled7.ipynb
  (pve35) fukuda@falcon:~/pve35% extractbb Untitled7_files/*.png
  (pve35) fukuda@falcon:~/pve35% platex Untitled7.tex
  (pve35) fukuda@falcon:~/pve35% dvipdfmx Untitled7.dvi 

  とやってみたら、実際 Untitled7.pdf ができた！
• しかし、これ、全く嬉しくない……
  • 確かに、日本語はちゃんと表示されるが、
  • 図の配置がデタラメになり、
  • heading の番号が勝手に付け加えられ、
  • コードの highlighting が消えてしまう
  という事でかなりがっかり。

なので、nbconvert が platex を呼ぶようにする、というのは放棄した。

PDF — Print + Print Preview

で、弥縫策としてやっていた、Firefox の menu から、[File] → [Print...] でポップアップする、Print タイルで、左下の方にある [PDF] → [Open PDF in Preview] として、Preview で開き、 そこで出来栄えを確認してから、PDF ファイルとして出力する、 という方法に戻る事にした。

図のように、関連ありそうな項目が一杯あるが、弄り回して得た結論は、 「In[] cell と Out[] cell の組が長くなるとどうしてもグラフやパラグラフが ページの最後で切れてしまう」 という事。LaTeX -> pdf のところで、この組をうまく分割する事ができないのが根本原因なんだろう。

HTML — Download as HTML

要は、PDF にするのにページ分けがうまく行かない、って事だろうから、 どうしても、「操作できないが完璧な」 Notebook が欲しければ、 Jupyter の [File] → [Download as] → [HTML (.html)] として、HTML ファイルに落すしか無さそう……。 こちらは (当然ながら) .ipynb を表示させたのと略同じにできるが、一方で、

• 読んでもらうのに、ブラウザが必要。 ブラウザを持ってない人はいないだろうけど、どうやって、その HTML ファイルをブラウザに読み込ませればよいのか、Windose 界隈の事は私にもよく解らないのだった。
• ページに分けてくれない

つまりは、PDF に変換したら、いずれにしても、 おかしな事になってないか、よく確かめる必要が有るという事。

Jupyter のおかげで、折角なにやかやが簡便になった (手抜きができるようになった) のに、これではツライが、pLatex のテンプレートを弄る知識も根気も無いので、 とりあえず、

1. 「Print → Preview で PDF 化」を試し、それでうまく行かなかったら
2. [Download as] → HTML (.html) で HTML 化

をやる事にする。

---

2016-10-01 (Sat): 宅外サーバのメンテナンス

「宅外サーバ」というのは、DigitalOcean の VPS を使ったサーバ (otacky.jp) の事。至極順調に稼働してくれている。先月は、「新しい droplet を作って弄り回す」等という事をまったくやらなかったので、料金の請求は 24 ドルだった。(その内の 4 ドルはバックアップ・オプションの料金。)

Let's Encrypt の Certificates

Let's Encrypt さんの Certificates は、その後も問題なく動いていて、 それを crontab で更新するのも問題無さそう——実はまだ、直近の更新から 一月半しか経ってないので「--force-renew 無し」での自動更新は確認できていないが。

という事で、実際上はなにも問題ないのだが、 オタク的にはちょっと気になる点が……。それは、 前回の更新の際にも書いたが、 certs のセットが二通りある事： www.otacky.jp と www.otacky.jp-0001。 後者は、certbot-auto で certificates を再度作った時にできたもので、 どうも強制的にこういう名前になるらしい。この名前は気に入らないが、 どちらかを残すとしたら、こちらしかない——前者はその Alternative Subject Name が必要な名前を全部カバーしていないから。

例によって、とっても解り難い certbot-auto のヘルプを渡り歩いて、結局

fukuda@digoc02:~/certbot% sudo ./certbot-auto revoke --cert-path
    /etc/letsencrypt/live/www.otacky.jp/cert.pem  

とやるのが正解だったようだ。 （ちなみに、このコマンドは Let's Encrypt のサイトに作用するだけで、 こちら側には何の影響も与えない。--cert-path は、その際に使う認証 key を指定しているだけと思われる。）

certs を使用しているサーバが、それぞれちゃんと www.otacky.jp-0001 を指しているかどうかを確認する。

• Apache: (/etc/apache2/site-enabled/*.conf)

    SSLCertificateFile	/etc/letsencrypt/live/www.otacky.jp-0001/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/www.otacky.jp-0001/privkey.pem
    SSLCACertificateFile /etc/letsencrypt/live/www.otacky.jp-0001/chain.pem

  >>> https://www.otacky.jp, https://www.waremo.com に問題無くアク セスできた。
• Dovecot:
  /etc/dovecot/conf.d/10-auth.conf

  disable_plaintext_auth = no

  /etc/dovecot/conf.d/10-ssl.conf

  ssl = yes 
  ssl_cert = </etc/letsencrypt/live/www.otacky.jp-0001/fullchain.pem
  ssl_key = </etc/letsencrypt/live/www.otacky.jp-0001/privkey.pem
  # ssl_ca = </etc/letsencrypt/live/www.otacky.jp-0001/chain.pem

  >>> Wanderlust から

  (setq elmo-imap4-default-authenticate-type 'clear ;; 2016-09-16 (Fri): 
         elmo-imap4-default-stream-type 'ssl
         elmo-imap4-default-port '993)

  の設定でアクセスを確認。また、Mail.app でも OK。
• Postfix:
  /etc/postfix/main.cf

  smtpd_tls_cert_file = /etc/letsencrypt/live/www.otacky.jp-0001/cert.pem
  smtpd_tls_key_file = /etc/letsencrypt/live/www.otacky.jp-0001/privkey.pem
  smtpd_tls_CAfile = /etc/letsencrypt/live/www.otacky.jp-0001/chain.pem
  smtp_tls_security_level = may
  smtp_use_tls = yes

  >>> Wanderlust と Mail.app から smtp.otacky.jp が posting server として使える事、 また、Gmail の Web Mail から xxxx@otacky.jp へメールが送れる事を確認。

fukuda@digoc02:~/certbot% sudo mkdir /etc/letsencrypt/hide    
fukuda@digoc02:~/certbot% sudo mv /etc/letsencrypt/renewal/www.otacky.jp.conf /etc/letsencrypt/hide/ 
fukuda@digoc02:~/certbot% sudo ./certbot-auto renew

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/www.otacky.jp-0001.conf
-------------------------------------------------------------------------------

The following certs are not due for renewal yet:
  /etc/letsencrypt/live/www.otacky.jp-0001/fullchain.pem (skipped)
No renewals were attempted.

最初の二つのコマンドが必須かどうかは未詳。ともあれ、これで、...-0001 のみが更新されるようになった。

Mailman ML

Mailman は毎月朔日に「リマインダ」を出してくれる。 それを眺めていて、今更ながら気がついたのだが、lark.otacky.jp というホストからもリマインダが出ている……本来は lists.otacky.jp。 lark.otacky.jp は、旧自宅サーバの URL (現在は lark.otacky.us) なので、「まだ生きていたのか」と思ったが、そうではなかった—— そもそも、そのホストでは qrunner は走っていない。

考えてみれば、lark.otacky.jp は宅外サーバにマップされているし、http://lark.otacky.jp/mailman/admin で、Mailman のサマリーページまでちゃんと出るのだから、Mailman のプロセス (qrunner) がそこで走っているのは間違いない。 が、どういうメカニズムでそんなものが生きて動いているのか、なかなか解らない。 散々右往左往したが、どうやら、自宅サーバから宅外サーバに Mailman を移行する際に錯和をやらかしたという事らしい。つまり、 宅外サーバに ML を移した時、古い mailman アカウントで、新規にできていた mailman を上書きしてしまった……

実際、その時の操作を参考にして、mailman の中身を覗いてみたら、まさに、その URL になっている。

fukuda@digoc02:/var/lib/mailman% sudo bin/withlist -l mailman
Loading list mailman (locked)
The variable `m' is the mailman MailList instance
>>> m.web_page_url
'http://lark.otacky.jp/mailman/'
>>> m.web_page_url = 'http://lists.otacky.jp/cgi-bin/mailman'
>>> m.Save()

早速、本来の URL に変更したら、(mailman を reload するまでもなく) lists.otacky.jp にリストが表われた。ミステリーは解消。

ついでに、不要となっているリストを消去。

fukuda@digoc02:/var/lib/mailman% sudo bin/rmlist sor-core
[sudo] password for fukuda: 
Not removing archives.  Reinvoke with -a to remove them.
Removing list info
fukuda@digoc02:/var/lib/mailman% sudo bin/rmlist mmtest3 
Not removing archives.  Reinvoke with -a to remove them.
Removing list info

「幽霊の正体見たり枯尾花」というか「ゾンビらの正体見たらわがチョンボ」のお粗末でした。

---

243/1,788,173

Taka Fukuda

Last modified: 2017-03-01 (Wed) 12:00:55 JST