Error Establishing a Database Connection
びびった。
この WordPress で、特に何もしていないのに、「データベース接続の確立エラー」（Error Establishing a Database Connection）
が表示された。コレが出ると、データベースファイルが壊れたとかの場合が多くて、復旧に手間取る可能性が高い。
今回は、サーバに login して、MySQL の Restart だけで復帰した。
払い下げPCへのddを使ったディスクイメージコピー
総合情報処理センターのパソコンの入れ替えにより、払い下げとなったパソコンのセットアップ中。
1台をWindows10などの環境を整えて、あとは、USBブートのUbuntuを使って、HDDを全コピー。
最初、SATA のケーブルを、コピー元=SATA0 と、コピー先=SATA1 につないでコピーをしたら、同一バスを使うからかな!?やたらと時間がかかり、1台あたり 290分かかった。
$ time sudo dd if=/dev/sda of=/dev/sdb 289min...
2度目からは、コピー元=SATA0で、コピー先=SATA1を、コピー先=SATA3に変更して、ついでにコピー単位を256kB に変更して行う。
$ time sudo dd if=/dev/sda of=/dev/sdb bs=256k 78min...
バッファーサイズが効果的だったのか、SATA3 にしたのが良かったのか…はよく判らないけど、コピー時間を1/3に短縮できた。
でも、残りあと10台以上セットアップは続く。卒業式が始まる前に、1ローテーション回してから、式に向かう。まだまだあるし、もう1つUbuntuのUSBを準備し、2台並行作業を開始。
ネットワークセキュリティのためのTips
- デーモン(ネットワークサービス)の起動
- rc.d(古い方法)
- systemd(新しい方法)
- スーパーサーバによる起動
- ファイアウォール
- 検査手法
- Linuxで開いているポートを確認する方法(netstat)
- ポートスキャン
- パケットキャプチャ
- Webサーバへの攻撃方法
- 一般的な知識
- バックドアの確認方法
- 仕掛けられたバックドアの検出と対処
- maldetect
- ルートキット検出ツールの比較(rkhunter,chkrootkit)
usacloud
さくらのクラウド上のサーバを、実験・演習用に使っているけど、未使用時に起動していると課金も増えるので、極力電源を落としたい。調べると、さくらのクラウドであれば usacloud という CLI により操作ができるみたい。
同じネタを「機構管理の Azure のサーバでも極力電源を落とせ」と言われているけど、利用者のいるWebサーバなので困難。
APIキーの取得
usacloud の説明を見ているけど、API キーの取得画面の出し方が変更になっているみたい。さくらのクラウドホームにて、APIキーを発行
usacloud のインストール
usacloud のドキュメントには、
curl -fsSL https://releases.usacloud.jp/usacloud/repos/install.sh | bash
と書かれていたけど、debian の apt の GPG エラーでインストールに失敗したので、usacloud_0.31.1-1_all.deb をダウンロードし、dpkg -i *.deb でインストール。
先の手順で作ったAPIキーを登録
[root]# usacloud config Setting SakuraCloud API Token => Enter token: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Setting SakuraCloud API Secret => Enter secret: xxx...xxx Setting SakuraCloud Zone => Enter zone[is1a/is1b/tk1a/tk1v]: is1b Setting Default Output Type => Enter default-output-type[table/json/yaml/csv/tsv]: json Written your settings to /root/.usacloud/default/config.json
サーバの操作コマンド
設定が終われば、サーバの起動や停止もコマンド一発
((( サーバの起動 ))) $ sudo usacloud server boot 名前 $ sudo usacloud server wait-for-boot 名前 ((( シャットダウン ))) $ sudo usacloud server shutdown 名前 $ sudo usacloud server wait-for-down 名前 ((( サーバ一覧 ))) $ sudo usacloud server list $ sudo usacloud server list -q 11xxxxxxxxxx $ sudo usacloud server list --output-type table +--------------+---------+-----+--------+------------+--------------------+--------+----------------+ | ID | Name | CPU | Memory | Commitment | IPAddress | Status | Host | +--------------+---------+-----+--------+------------+--------------------+--------+----------------+ | 11xxxxxxxxxx | nitfcei | 2 | 2048MB | standard | xxx.xxx.xxx.xxx/24 | up | sac-xxxx-xxxxx | +--------------+---------+-----+--------+------------+--------------------+--------+----------------+ $
VMware PlayerでLinux
授業の中で unix 環境を体験してもらうために、vmware player を使う準備
VMware Workstation Playerのインストール
- VMware Workstation Playerのページ より、Windows(無償版)をダウンロードし、インストールを行う。
Ubuntu 18 Desktop 版の起動イメージ
起動した状態のイメージを作っておきたかったが、Freeの環境では無理っぽいな。インストール作業を授業時間内にやるか…
nfsのソフトマウント
自室の Linux サーバでは、自分が管理している Azure 上のサーバのデータバックアップを取っているが、ハードディスク容量が巨大な訳でもないので、iMac に接続された Drobo (複数ディスクの改良RAID?) に保存させている。
このネットワーク越しのバックアップでのディスクアクセスになるが、iMac を時々再起動させると、その間に icinga のディスクチェック処理が走った際に、アクセスできないために df プロセスが大量に残るトラブルが発生していた。リトライするため CPU 負荷も高い状態で、一番簡単なのは サーバの再起動。(iMacを再起動したら、その後にLinuxサーバを再起動….無駄や…)
最初は、check_disk 処理で余計なところを見させないために、特定マウント先を無視するオプションを加えていたが、df がマウント先をしつこくアクセスをリトライするのが原因。
よく考えたら、ネットワーク越しのマウントだから、ハードマウント(ディスクアクセスに失敗したら何度もリトライ)ではなく、ソフトマウント(複数回リトライしたら諦める)にする必要がある。
ということで、automount オプションに、”soft” オプションを加えて解決。
MySQLでトラブル対応
仕事で動かしているサーバが動いていないとの連絡が入り、システムが動いていない。
他の方との共同のネタなので、サーバーの更新は慎重に行っているけど、今回は MySQL が落ちているのが原因。サーバーの定期的な更新作業後あたりから動かなくなっているので、最近更新されたパッケージを確認し、MySQL が含まれていたのでパッケージを一つ前のバージョンに落とそうと対応を行った。
しかしダウングレードでパッケージの不整合が出る中、無理やりダウングレードをおこなって MySQL を起動させようとするが、”mysqld got signal 11 ; This could be because you hit a bug.” といったメッセージで起動しない。
四苦八苦するも原因がつかめず、以前の状態に戻そうとバックアップ時に作成しておいたパッケージのバージョン情報を確認すると、パッケージが更新されて動かなくなったのではなく、パッケージが消されていたことが判明。原因を誤解していた。
OSの更新作業の中で、MySQL のメジャー更新で使っていたバージョンが標準パッケージから外されたみたい。メジャー更新すればいいのだろうけど、運用不安もあるので、MySQL の本家で公開しているパッケージを入れて、無事復旧。
長期運用とはいえ、更新は慎重に作業せねば。
gcj (GNU Compiler for Java) の使い方
いつもは Java を使わないけど、久々に java のプログラムの動作実験と思い、サーバ機に gcj (GNU Compiler for Java)を入れて使おうとしたら、コンパイラ javac とバイトコードインタプリタ java のつもりでコマンドを探すけど、見つからない。
gcj を見つけて “gcj HelloWorld.java” ってやってみたけど動かない。あらためて確認したら、バイトコード生成もできるし、直接機械語も生成できるけど、色々とオプション指定がいるみたい。なるほど。
// HelloWorld.java
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
# 機械語を直接生成する場合 $ gcj -o HelloWorld --main=HelloWorld HelloWorld.java $ ls HelloWorld HelloWorld.java $ ./HelloWorld Hello World! # バイトコードを生成して動かす場合 $ gcj -C HelloWorld.java $ ls HelloWorld.class HelloWorld.java $ gij HelloWorld Hello World!
プロセス状態 I (Idle Kernel Thread)
自宅のサーバの状態を見ていたら、青:sleep 灰:total の間の差が大きい。
変なプロセス走っていないかと心配したら、ps ax の出力でのステータスがIとかI< となっている項目。日本語のマニュアルを見ても意味不明。
英語のマニュアルを見たら、”Idle Kernel Thread”らしい。
緊急連絡システムのOS更新など
緊急連絡システムのOSが、Ubuntu/trusty でそろそろ、サポート期間に近づいているので、OS の更新を行った。
Ubuntu 更新
更新自体は、do-release-upgrade コマンドで、xenial に更新が進む。
$ sudo do-release-upgrade
しかしながら、openssh-server が、更新でエラーがでて、かなり悩んだ。解ってみれば、単純なミスで、自作の /etc/init.d/script を書いてあったけど、その insserv ヘッダで、ssh をコピーしてヘッダ部の # Provides: sshd の行を書き換えてなかった。
このおかげで、insserv が、ssh はすでに登録されている…と勘違いしていた。
緊急連絡システムの文字コードUTF-8 に変更
Ubuntu の更新をかけたら、php5 が使えなくなったため、php7.0 に更新を行うが、これに合わせ、取り扱い文字コードを EUC-JP から UTF-8 に変更を行った。
緊急連絡システムは、内部でデータベースを利用せず、テキストファイルですべてを管理しているが、最初は利用組織毎の設定ファイルや、データファイルをエディタでチマチマと修正を始めたけど、大量の組織のため、途中で断念。perl でファイル名や記載時のエンコーディングを修正するスクリプトを書いて一発変換。
あとは、プログラム中のエンコーディング依存の部分を修正し、送信できることを確認してひとまず移行作業完了。