ifupdown2 のトラブル
ソフトの更新とかかけていて、久々に reboot をかけたら、 パソコンなどが、ネットワークにつながらずトラブル。
確認すると、dhcpd サーバが動いていない。設定ファイルなどを みるけど、特に問題もない。 おかしいおかしいと改めて 確認していると、上流ルータへの ping が通らないことも判明。
理由が分からず、色々動かしていると、eth0 が起動していない(link upしていない)。 ifup eth0 を手作業で実行して、設定をさらに調べていると、 ping 127.0.0.1 さえも通らず、localhost さえ link up していない。
こうなると、/etc/init.d/networking がおかしい…と思うけど、 このご時世は、systemd になっている。なんだかよくわかんないけど、 systemctl -a とかを実行したら、 networking が inactive dead って 表示されている。 そういえば、ひと月ほど前、 ifupdown2 なんていう パッケージに更新した記憶があるし、 どうもこれが原因。
# aptitude install ifupdown
を実行して、再起動したら、すべてがようやく元通り。
Windows10のSNMP監視が止まってる
自宅では、パソコンの稼働状況をモニタリングするために、 WindowsのSNMP機能を ON にして、サーバ側から munin を 使って、ディスク容量やネットワーク通信の監視をさせていた。
しかし、最近モニタリングのグラフが表示されていないことに 気づいた。どうも 2015/10月中旬あたりから。
Windows10 のパッチが影響したと思うのだが、なんだろう。
munin の snmp のチェックをかけるけど、返答がない。
nagios3からicingaに移行
自宅サーバは Debian/testing で運用しているけど、 "aptitude safe-upgrade"しても、大量の保留。
試しに"aptitude full-upgrade"を実行すると、nagios3 が perl-5.20 に 依存していて、 perl 関連のライブラリがこぞって保留となっている。
icingaに切り替え
nagios4 とかがあるかと思って、"aptitude search nagios"を実行すると、 pnp4nagios なるものがひっかかり、インストールをしようとすると、 "icinga" を入れようとする。モニタリングは icinga が担当しているようで、 設定ファイルもほとんど nagios と同じ。 pnp4nagios は、表示を担当するようだけど、 内部で使う mysql とかの設定が悪いのか、 動かない。 ひとまず、icinga でも状況は確認できるので、pnp4nagios はやめておく。
自宅では、室内の温度センサーが一定気温を越えたらメールさせるとか、 アホなルータが間違ってDHCPを起動させていないとか、独自チェックも させているので、 手間取るかとおもったが、無事移行ができた。
external commandが実行できない
nagios3をセッティングした時とまるっきり同じ症状だけど、監視の一時停止などを行う、 インタフェースが動かない。 設定がオフになっているのと、 処理を起動するためのパイプが入っているディレクトリの アクセス権限の問題なので、設定を変更。 この手の設定は、nagios3 を icinga に読み替えるだけなのは、nagios の fork だから、そのまんま。
(( /etc/icinga/icinga.cfg )) check_external_commands=1 $ sudo dpkg-statoverride --update --add nagios www-data 2710 /var/lib/icinga/rw $ sudo dpkg-statoverride --update --add nagios nagios 751 /var/lib/icinga
sambaで書き込み不可
Debianを使っていると長年稼働させるから、古い設定ファイルで トラブルが起こることが多い。samba でもその傾向があるのか、 /etc/samba/smb.conf.ucf-dist が反映されず残ってる。
ということで、古い設定ファイルをバックアップして、 smb.conf.ucf-dist を極力触らずに設定ファイルを更新していた。
でも、いざ共有フォルダに書き込もうとしたら、書き込み失敗。 確認したら、"[homes] read only = yes"になってた。
バルス祭りに合わせて RainbowStream
日テレで、恒例のラピュタが始まった。 NTTさんも本腰をあげてのバルス祭り対策に燃えている。
んで、ふと「Linux環境で制御して、つぶやきたいな…」
RainbowStream をインストール
調べてみると、Linux環境のコマンドラインで呟くには、RainbowStream なる ソフトが高機能。Python で作られているので、必要なライブラリを 入れてから、python installer の pip コマンドでインストール。
$ sudo aptitude install install python-dev libjpeg libjpeg-dev libfreetype6 libfreetype6-dev zlib1g-dev $ sudo pip3 install rainbowstream
RainbowStream の設定。
コマンドラインで rainbowstream を起動すると、初回は認証
$ rainbowstream
すると、認証を行うための URL が表示されるので、Twitter を使っている ブラウザで URL をコピペして、連携許可すると PIN 番号が表示された。 その番号をコマンドラインにコピペして認証完了。
あと、Tweet したければ、"t テキスト" で OK 。
バルス…
締めは当然…。やらないけどね。
$ for((i=0;i<100;i++)) > do > echo -e "t #バルス by RainbowStream\nq" | rainbowstream > sleep 1 > done
pop3-login PLAINだめだこりゃ
メール録画予約で、予約メールの確認方法が pop3 で、apop か PLAIN しか使えないので、 自宅サーバ上に、pop3 / PLAIN 接続ができるようにした。 しかし、半日ほど運用していると、プロセス数がなんか多い。
"ps ax"で確認すると、"dovecot/auth -w"の量が定常的に30件ほど出てくるようになった。 何らかのプロセスがブロックしているのかと思ったら、プロセス数は増えたり減ったり。 ブロックしているなら、時間と共に増加傾向があるはず。そこで syslog を見ると、
Oct 17 16:15:05 hostname dovecot: pop3-login: Aborted login (auth failed, 1 attempts in 20 secs): user=, method=PLAIN, rip=37.49.224.10, lip=192.168.xx.xx, session=<bg+4qkciNAAlMeAK>
みたいなのが、続々と表示される。攻撃相手のアカウント探しみたい。 ファイアウォールで dovecot 関連は、pop3s に限っていたとはいえ、 こういう攻撃をうけるのね。
早々に、dovecotでPLAINを禁止し、FireWallのpop3sを閉じ、メール録画予約も取りやめ。 確認のために、前述の dovecot のLOGを確認すると、どうも中国人が利用しているサーバを想定したパスワード探索をしている。
145 user=liu, 145 user=lee, 145 user=huang, 145 user=chen, 116 user=yu, 116 user=yang, 116 user=wu, 116 user=wang, 116 user=lu, 116 user=lin, 116 user=li, 116 user=cheng,
番組のメール録画のフォーム
我が家のテレビやレコーダーは、 東芝に統一してあり、どちらもメールを使った 録画予約ができる。
今回改めて、下記資料を見ながら、録画予約のメールを作る Web フォームを作ってみた。
ただ、我が家では、 朝のテレビ自動On&曜日に応じた チャンネル設定とかしてるけど、 メール録画機能をOnにすると、 テレビがつけっぱなしか、 ping で確認できなくなった。
nmapでポートスキャンかけたけど、 常に全拒否で、電源状態を確認できそうな ネタがない。
メール録画のためのアカウント作成
メール録画機能は、指定した自分のメールアドレスにPOP3でアクセスして、 特定フォームの本文を探す方式。 しかし、最新テレビじゃないし、POP3Sとか使えず平文で読もうとするし、 認証もAPOPに対応しているけど、我が家の設定の都合上APOPは….
どうせ自宅内のメールサーバあるし、regza/テレビ用、vardia/レコーダ用の アカウントを作る。
bluetooth接続を改めて
bluetoothドングルの余っているのを、再活用しようとチャレンジ。 ただ、管理用のソフトが日進月歩なのか、CUIで操作する方法は、 参考にならない記事ばかり。(この記事もいつまで使えるやら…)
サーバで活用したいので、gnomeやkdeを使った設定も使いたくないので、 調べると、bluetooth-agent(bluez) を使ってという記事があるけど、 jessie では入っていない。
bluetoothなんちゃら…だろうと、shellの補完させると、 bluetoothctl なんていうコマンドがある。
インストールとbluetoothドングルの確認
((bluetooth関連のインストール)) $ sudo aptitude install bluetooth $ sudo /etc/init.d/bluetooth start
次にbluetoothの認識されている状態を確認。 buffaloのメジャーなbluetoothドングルなのか、普通に認識している。
((bluetoothの認識状態)) $ sudo /etc/init.d/bluetooth status ● bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Active: active (running) since 木 2015-10-15 18:12:51 JST; 17min ago Docs: man:bluetoothd(8) Main PID: 9999 (bluetoothd) Status: "Running" CGroup: /system.slice/bluetooth.service └─9999 /usr/lib/bluetooth/bluetoothd
bluetoothctlコマンドでペアリング
bluetooth-agent の変わりに、bluetoothctlを使う。 “[bluetooth]#” のプロンプトが出たら、様々なコマンドが対話的に使える。 “help”で命令も見れるので、見ながら適当にやってみる。
((bluetoothctl)) $ sudo bluetoothctl [NEW] Controller 00:1B:DC:xx:xx:xx host [default] [bluetooth]# list Controller 00:1B:DC:xx:xx:xx host [default] [bluetooth]# show Controller 00:1B:DC:xx:xx:xx Name: host Alias: host Class: 0x000104 Powered: yes Discoverable: no Pairable: yes UUID: Generic Attribute Profile...
肝心のペアリングだけど、”pair”なんてコマンドがあるし、試してみる。 BT番号を入力したら簡単に成功。ろくにマニュアル見ていないけど、 ここまではスムーズ。
((bluetoothのペアリング)) [bluetooth]# power on ←ドングルを使えるように [bluetooth]# scan on ←デバイスを探す Discovery started [CHG] Controller 00:1B:DC:xx:xx:xx Discovering: yes [NEW] Device 70:3E:AC:xx:xx:xx iphone6-user デバイスを見つけるたびに情報が表示される [bluetooth]# scan off ←デバイス探しを止める [bluetooth]# pair 70:3E:AC:xx:xx:xx ←見つけたデバイスのアドレス : ((ここでペアリング相手にメッセージが出るのでOKを押す)) [CHG] Device 70:3E:AC:94:73:34 Paired: yes Pairing successful ←ペアリング成功 ((ペアリングで信用登録が必要な場合)) [bluetooth]# trust 70:3E:AC:xx:xx:xx ←デバイスを信用 [bluetooth]# connect 70:3E:AC:xx:xx:xx ←デバイスを接続
再起動後にも接続するための設定
この記事によると、udev で対応をとるらしい。
(( /etc/udev/rules.d/10-local-bluetooth.rules )) $ sudo vi /etc/udev/rules.d/10-local-bluetooth.rules # Set bluetooth power up ACTION=="add", KERNEL=="hci0″, RUN+="/usr/bin/hciconfig hci0 up"
rloginの更新
最近Windows環境から、自宅サーバに rlogin.exe で ssh 接続しようとすると 「get msg global request hotkeys 00@openssh.com」みたいな 警告メッセージが表示されるようになった。
調べてみると、rlogin のバージョン(2.17.x)の問題っぽい。 早々に、最新の(2.19.1) に入れ替えたら問題解決。
http://nanno.dip.jp/softlib/man/rlogin/
定期的にfull-upgrade
自宅サーバ及び職場の自分用Debianサーバは、testingにて運用し、 定期的に "aptitude update ; aptitude safe-upgrade" を行っている。 でも、safe-upgrade だと、新しいパッケージが入らないままになることも多い。 このため、"aptitude full-upgrade" を行っているが、 今回は、競合パッケージがちょっと多くて、競合チェックに失敗する。
(( 定番の更新 )) # aptitude update ; aptitude safe-upgrade (( 不要パッケージの消去 )) # aptitude purge `deborphan` # aptitude install gcc-5-base libstdc++6 libgcc1 gimp gimp-data # aptitude install aptitude kdelibs-bin libopencv-core2.4v5 # aptitude install libtag1v5-vanilla libmagick++-6.q16-5v5 libtag1v5 (( ようやくfull-upgradeでの競合チェックに成功 )) # aptitude full-upgrade (( 競合でtexliveが消えちゃったので再インストール )) # aptitude install texlive-full