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?…”になってら。
nfsのソフトマウント
自室の Linux サーバでは、自分が管理している Azure 上のサーバのデータバックアップを取っているが、ハードディスク容量が巨大な訳でもないので、iMac に接続された Drobo (複数ディスクの改良RAID?) に保存させている。
このネットワーク越しのバックアップでのディスクアクセスになるが、iMac を時々再起動させると、その間に icinga のディスクチェック処理が走った際に、アクセスできないために df プロセスが大量に残るトラブルが発生していた。リトライするため CPU 負荷も高い状態で、一番簡単なのは サーバの再起動。(iMacを再起動したら、その後にLinuxサーバを再起動….無駄や…)
最初は、check_disk 処理で余計なところを見させないために、特定マウント先を無視するオプションを加えていたが、df がマウント先をしつこくアクセスをリトライするのが原因。
よく考えたら、ネットワーク越しのマウントだから、ハードマウント(ディスクアクセスに失敗したら何度もリトライ)ではなく、ソフトマウント(複数回リトライしたら諦める)にする必要がある。
ということで、automount オプションに、”soft” オプションを加えて解決。
福井高専のドメイン名
そろそろ前期期末の成績締め切り。学生さんがレポート課題提出で先生にメールを送ることも多いが、メールアドレスの書き間違いでメールがエラーになって届かないトラブルがちらほら。
メールアドレスをどう書き間違えているのか確認すると、hoge@fukui-nct–ac.jp と書いていたりする。高専機構のドメイン名は、hoge@fukui.kosen-ac.jp で、ac の前がハイフンに間違えてるんだろうな。
まずは結論
高専機構(福井)のメールアドレスは、hoge@fukui.kosen–ac.jp です。
福井高専のメールアドレスは、hoge@fukui–nct.ac.jp です。
ということで、以下解説。
ドメイン名の一般ルール
ちなみに、日本のドメイン名は古くは、組織ドメイン.種別ドメイン.国ドメイン の形式。
組織ドメイン=fukui-nct , 種別ドメイン=ac(教育機関) , 国ドメイン=jp(日本)
種別ドメインには、.co.jp(会社) , .ne.jp(ネットワークサービス) , .or.jp(団体) , .go.jp(政府機関) といったものがあるが、企業のサービスだと、.co.jp なのか .ne.jp なのか曖昧だったりするので、最近は省略したものを申請できるようになっている。
国ドメインは、アメリカはネットを作った所なので、国ドメインは省略され、.us(アメリカ) を使うことはめったに無い。一方、国ドメインも、.jp(日本) , .uk(イギリス) , .ch(中国) とかあっても、世界中に拠点を持つ企業では、.jp なのかよくわからないので、国ドメインを持たない種別ドメイン .com (企業) を取得することも多い。
高専機構のドメイン名
日本では最近様々な形式の学校が出てきたため、.ac.jp のドメインを取る時の審査は厳しくなっている。
このため、高専機構では、kosen.ac.jp を取得したいが審査が通らず、しかたがないので kosen–ac.jp を取得している。
組織ドメイン=kosen-ac , 種別ドメイン=なし , 国ドメイン=jp(日本)
ちなみに、”-ac.jp” といった変則的なドメイン名は、教育機関を偽装したドメイン名と勘違いされやすく、kosen-ac.jp のドメイン名を見て「怪しい…」と思う人も多い。
福井高専のドメイン名
一方、高専機構ができた後の福井高専の英語の正式名称は、“National Institute of Technology, Fukui College” であり、福井高専のドメイン名としては、本来 “nit-fukui.ac.jp” を取得したい。
組織ドメインの綴りのルールは無いので、大学でも 大学名-u.ac.jp だったり u-大学名.ac.jp など色々あるが、最近は後者が主流となっている。(福井大学も以前は、fukui-u.ac.jp だったが、最近は u-fukui.ac.jp に変更されている)
しかし、.ac.jp の審査が厳しく、高専機構の1組織っぽい nit-fukui.ac.jp は審査が通らない可能性が非常に高く、どの高専も以前のドメイン名をそのまま使用しているのが現状である。