Error Establishing a Database Connection
びびった。
この WordPress で、特に何もしていないのに、「データベース接続の確立エラー」(Error Establishing a Database Connection)
が表示された。コレが出ると、データベースファイルが壊れたとかの場合が多くて、復旧に手間取る可能性が高い。
今回は、サーバに login して、MySQL の Restart だけで復帰した。
Teams 説明会のトラヒック
fukuikousen-bot の更新周期を短く
福井高専のホームページの最新情報を、つぶやく bot ( https://twitter.com/FukuiKousen )を動かしているけど、この連日、コロナウィルスのため重要な公式情報の流れる機会が増えている。
通常は、5時,9時,11時,15時,19時 としていたが、当面頻度を高めておこう。8時から22時まで2時間刻みとしておく。
払い下げ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の環境では無理っぽいな。インストール作業を授業時間内にやるか…
Thunderbirdの送信時エンコーディングがJISじゃなかった
とある先生から、メールが文字化けで読めないとの連絡があった。古いメールソフトを使っているとのことだったけど、私はThunderbirdで極力プレインテキストで送っているからJISコードだろうし古いメールソフトでも読めるはず…と思っていたけど、確かめると @kosen-ac.jp が BASE64 で送られていたり、@gmail.com が quoted-printable だったり。
設定を再確認したら、設定のフォントと文字エンコーディングで、デフォルトエンコーディングがUTF-8になってた。古い人間なので、送受信もデフォルトエンコーディングが「JIS(iso-2022-jp)」、「可能な限り返信でもデフォルトエンコーディングを使用」に設定を行った。
うーむ、ちゃんとJISに設定したのに、@gmail.com のメールのタイトルが、”=?UTF-8?B?…”になってら。