オタク日記
(Mac と Linux, 2016Q4)
目次
2016-12-31 (Sat): SSH と EmacsMac/Tramp2016-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
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 がフリーズする—— 本当にフリーズしているのか、極端にレスポンスが遅くなっているのかは未詳。
半日右往左往してたどりついた解決策は、~/.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) 何故か毛嫌いしていたが、どうも、"ssh"
とした時よりもこっちの方が「上等」らしい。(
ssh
とscp
を使い分けるんだとか。) - #2) remote host に対して、root privilege
でアクセスするためのトリックだが、ここでは
/ssh:%h:
のままでないとダメ。 - #3) zsh へのフルパスで定義したのでは、remote host にそれが無くてはマズいだろうと……
- #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 が立ち上がる。
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) は極最初からインストールされている。 なので、新たにやるべきは
- '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: .....
- client から id_rsa.key をコピーしてきて、
fukuda@sparrow:~% cat id_rsa.pub >> ~/.ssh/authorized_keys
- password login を禁止する
# /etc/ssh/sshd_conf #PasswordAuthentication yes PasswordAuthentication no
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) 基本、外向き接続は全部通すが、内向きは全部ブロック。
- #2) Port:22 (ssh) へは、どこからの接続要求でも通すが、 あまり頻繁な接続要求 (過去 30 sec の間に 6 回以上のアクセス) は拒否。
- #3) IPv6 のアドレスも通す。これまでこれが必要だった事はないが、
Raspbian の
# apt update
コマンドは、IPv6 アドレスからファイルを取って来ようとするので、これは必須。 - #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 を止めてきたが、 この時点で- 旧サーバの Ethernet ケーブルを抜いて、
- WiFi Router (WZR-HP-AG300H) の DMZ を新サーバに向け
- 新サーバをリブート
- 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)
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 インストール
- Raspbian のサイトから、lite を選んでダウンロード。 (たかが、290 MB のファイルのダウンロードに、3 時間もかかった…… 前からこのサイトは遅いけど、なんだかますます酷くなる。)
- 買い置きの 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 ドライブの書き込み速度が向上しているに違いない。 - 同 SD を、Raspberry Pi 2 に差して、 モニタとキーボードを継ぎ起動。 Lite のためか、CUI 画面で立ち上がる。
- raspi-config で、
- SSH: enable
- hostname: sparrow
- LOCALE: en_US.UTF-8
- Time Zone: Asia/Tokyo
- 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) このように外部のサーバを指定しないでおくと、
***.otacky.us
へのアクセスをローカルドメインからは、 ローカルアドレス、外部からは、global address を示すようにできる。 - #2)
/etc/bind/rndc.key
の中身をコピー。 (直接ファイルを指定する方法が有るんだろうけど……。) - #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 が消えてしまう
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 界隈の事は私にもよく解らないのだった。
- ページに分けてくれない
Jupyter のおかげで、折角なにやかやが簡便になった (手抜きができるようになった) のに、これではツライが、pLatex のテンプレートを弄る知識も根気も無いので、 とりあえず、
- 「Print → Preview で PDF 化」を試し、それでうまく行かなかったら
- [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「幽霊の正体見たり枯尾花」というか「ゾンビらの正体見たらわがチョンボ」のお粗末でした。
356/1,781,601 Taka Fukuda Last modified: 2017-03-01 (Wed) 12:00:55 JST