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

目次

2016-12-31 (Sat): SSH と EmacsMac/Tramp
2016-12-24 (Sat): DigitalOcean 讃
2016-11-26 (Sat): Raspberry Pi で自宅サーバ (その 2)
2016-11-19 (Sat): Raspberry Pi で自宅サーバ (その 1)
2016-11-05 (Sat): Jupyter Notebook (その 3)
2016-10-01 (Sat): 宅外サーバのメンテナンス

古い日記:
2016Q3   2016Q2   2016Q1  
2015Q4   2015Q3   2015Q2   2015Q1   2014Q4   2014Q3  
2014Q2   2014Q1   2013Q4   2013Q3   2013Q2   2013Q1  
2012 年   2011 年   2010 年   2009 年   2008 年   2007 年  
2006 年   2005 年   2004 年   2003 年   2002 年   2001 年


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

2017-01-05 (Thu) 改訂: Tramp の問題を完全に克服するには、 config を少し削り過ぎたようだ……一部元に戻した

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 の不調と前後してかなり悩ましい事になっていた。

上の「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" とした時よりもこっちの方が「上等」らしい。(sshscp を使い分けるんだとか。)
  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 君達の来訪が増えたせい(おかげ?)だろう。
Page View Graph
Crawler 達のおかげで、百万 Page View 突破
しかし、何故そんな「集中攻撃」が起きて、しかもそれが続くのかよく分らない。 が、まあ、すなおに「タナボタ」を喜んでおく事にする——実は、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 が立ち上がる。

Page View Graph
BackUp Image から、Droplet を立ち上げる
素晴しい。 (但し 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. 新サーバをリブート
して最終チェック。と言っても大した事はしてなくて、 等を確認。

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

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

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

2017-02-16 (Thu): 追記
dd コマンドを使う前に、unmount しておかないといけません。

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

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。

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) を構築した。

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

UI も「なせばなる!」

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

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

Jupyter Attribute Complement
Jupyter の "Attribute Complement"
実は、クリックしただけではだめで、 カーソルキーでグレーの部分を移動して選択してから 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 が完成してみると、 エラーになる……。随分思い悩んだが、長い話を思いっきり短くすると

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

PDF — Print + Print Preview

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

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

HTML — Download as HTML

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

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 のみが更新されるようになった。
2016-10-06 (Thu) 補遺: Postifx の ssl に関する設定を少し弄ったので、ちょっと心配だったが、 MxToolbox によると、まだ Black List には上がってないようだ。一安心。

Mailman ML

Mailman は毎月朔日に「リマインダ」を出してくれる。 それを眺めていて、今更ながら気がついたのだが、lark.otacky.jp というホストからもリマインダが出ている……本来は lists.otacky.jplark.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
「幽霊の正体見たり枯尾花」というか「ゾンビらの正体見たらわがチョンボ」のお粗末でした。
121/1,729,020 Valid CSS! Valid HTML 5.0
Taka Fukuda
Last modified: 2017-03-01 (Wed) 12:00:55 JST