netplanがapplyしても全然使い物にならなくてキレていたが拡張子が問題だった。
netplanの設定ファイルはYAMLで書くのだけれど
/etc/netplan/ccc.yml
だとだめで
/etc/netplan/ccc.yaml
じゃないとだめらしい。こういうので人生消費したくない........
netplanがapplyしても全然使い物にならなくてキレていたが拡張子が問題だった。
netplanの設定ファイルはYAMLで書くのだけれど
/etc/netplan/ccc.yml
だとだめで
/etc/netplan/ccc.yaml
じゃないとだめらしい。こういうので人生消費したくない........
ということで書きました。OSの課題で使ういつものやつです。
もともとは先輩が書いていたものですが、今年はシステム更新などでapacheを学科から追放したい気分があったのでnginxでリライトしました。といいつつ大体先輩のコードをそのまま使ってます。(ありがとうございます)
Fedora32で動くのを確認したので新鮮なFedoraでどうぞお試しください。
色々と改善していて、まずtasksに書いていたものをrolesにしたりとか、デーモンの再起動にnotifyを使っています。このあたりはisuconのansibleを参考にしました。
nginxでwordpressを動かしたいのでphp-fpmを入れていますが、本当にunix domain socketで通信をしているかが怪しい気がする。多分大丈夫だとは信じたいですが。
なにかツッコミがあればよろしくお願いします。(それを改善するのがB2の課題になる気がする)
歴史的な理由もあり学科のweb周りはapacheが元気に稼働しているケースが多い。
とはいえもうapacheの面倒を見るよりはnginxに移行したほうが何かと便利そうなので、現在apacheからnginxへの乗り換えを仕込んでいる。
先週の台風の際に学科システムへのダメージを減らすために、学科システムを一時的に停止させ、クラウドにおいてあるwebの予備サーバーを使うことになった。その時にタイミングを合わせて試しにnginxでwebを構築しようとしたところ、ちょっとSSL周りで詰まったのでそのメモ。
apache側では次のように証明書を指定している。
SSLCertificateChainFile
はいわゆる中間証明書。
SSLCertificateFile /etc/pki/tls/private/ie.u-ryukyu.ac.jp/ie.u-ryukyu.ac.jp.cer SSLCertificateKeyFile /etc/pki/tls/private/ie.u-ryukyu.ac.jp/ie.u-ryukyu.ac.jp.key SSLCertificateChainFile /etc/pki/tls/private/ie.u-ryukyu.ac.jp/nii-odca3sha2ct.cer
ググったところ SSLCertificateChainFile
に対応するnginxの設定項目は無いらしい。
どうもnginxの場合はSSL証明書と中間証明書を連結させたファイルを作る必要がある模様。
ということでこんな感じのコマンドを実行して連結させたpemファイルを生成する。
$cat ie.u-ryukyu.ac.jp.cer nii-odca3sha2ct.cer > ssl.pem
生成したpemファイルをnginxのserverコンテキスト内に指定する。
ssl_certificate /etc/pki/tls/private/ie.u-ryukyu.ac.jp/ssl.pem; ssl_certificate_key /etc/pki/tls/private/ie.u-ryukyu.ac.jp/ie.u-ryukyu.ac.jp.key;
こうするといい感じに動く。証明書周り難しいね...。
教えてもらったので。
ansibleでyum,dnf, apt を使っていくつかのpackageをまとめてインストールする際に、癖でloop(with_items
)を使っていたのだけど、これは非推奨らしい。
というのも
- name: install dnf packages become: yes dnf: name: - "{{ item }}" state: latest loop: - mariadb - mariadb-server - MySQL-python3 - python3-libselinux
みたいに書いてしまうと、これはこのコマンドを実行していることと等価になる。
sudo dnf install mariadb sudo dnf install mariadb-server sudo dnf install MySQL-python3 sudo dnf install python3-libselinux
そんな事しなくても sudo dnf install mariadb mariadb-server MySQL-python3 python3-libselinux
ってまとめられるよね。こっちのほうが効率いいよねということで、loop
を使うやり方は非推奨とのこと。
じゃあ実際にはどう書けばいいのかというと、usageを見たところ次のような世界観らしい。
- name: ensure a list of packages installed yum: name: "{{ packages }}" vars: packages: - httpd - httpd-tools - name: Install a list of packages yum: name: - nginx - postgresql - postgresql-server state: present - name: install the latest version of Apache and MariaDB dnf: name: - httpd - mariadb-server state: latest - name: Install a list of packages apt: pkg: - foo - foo-tools
ということでnames
の後ろに複数リストで与えるか、 {{ packages }}
を使えとのこと。
debug情報を見たところnames
で複数指定する方法とpackages
を使うやり方は内部的には同じみたいですね。-vvv
で見たところ両方次の様なjsonが表示されていました。好きな方を選べという感じっぽい。
ok: [test-fedora] => { "changed": false, "invocation": { "module_args": { "allow_downgrade": false, "autoremove": false, "bugfix": false, "conf_file": null, "disable_excludes": null, "disable_gpg_check": false, "disable_plugin": [], "disablerepo": [], "download_dir": null, "download_only": false, "enable_plugin": [], "enablerepo": [], "exclude": [], "install_repoquery": true, "install_weak_deps": true, "installroot": "/", "list": null, "lock_timeout": 30, "name": [ "mariadb", "mariadb-server", "MySQL-python3", "python3-libselinux" ], "releasever": null, "security": false, "skip_broken": false, "state": "latest", "update_cache": false, "update_only": false, "validate_certs": true } }, "msg": "Nothing to do", "rc": 0, "results": [] }
並行で学科のWordPressからコンテンツをダウンロードするくんを書いていた所、ミスでカレントディレクトリにhttp:/
みたいなディレクトリを生成してしまった。
$ ls http:/ $ tree . └── http: └── anatofuz.net └── test.html 2 directories, 1 file
こんな感じのディレクトリ構成になっている。
ここでtest.html
を開いてみようとmacのopenコマンドを利用した所おもしろい挙動になった。
$ open http://anatofuz.net/test.html http://anatofuz.net/test.html? [0] cancel [1] Open the file http://anatofuz.net/test.html [2] Open the URL http://anatofuz.net/test.html Which did you mean?
Which did you mean?
が表示されたあとは入力の待機状態になっていて、1と押すとファイルが、2と押すとwebのURLが開かれるようになっていた。
普段ならまず出てこないケースなので結構面白かったですね。ちなみにvimだと何も聞かれずにファイルを開きに行ってました。
ということで学科システムに障害が発生していました。具体的に言うと学科内から外に行けない、一部VMに学内からでもアクセスできないなどでした。
この障害は突然発生したものではなく琉大工学部で定期的に発生する計画停電によるものです。 原因としては3つあるL3スイッチのうち1つが故障。その結果としてネットワークが死んだという感じでした。 今回の計画停電はエレベーターも破壊したのでなにか良からぬ事をした可能性があります。
これはそのときの解決のログです(記憶力が無いので間違ってるかも...)
停電発生
id:anatofuzが学科サイトを静的にダウンロードするツールをテストしていたところ、突如ホストの応答が無くなる。 mattermostに「停電したわw」的な内容を書き込む。
id:unimarimoが悪い予感がしたらしく、停電対応でサーバー室に入る。 時既に遅しで既にサーバーは死んでいたらしい。この時に新規システムにつないでたケーブルを抜くのを忘れる。
mattermostにフラグを貼る
id:anatofuzが17時に復電しそうだなと思いサーバー室に到着。時既に遅しで既に復電しており、エアコンが付いていない30度の部屋の中サーバーが元気に稼働している。
基幹システムはa,b,c,dの4台あるが、bとcだけなぜか立ち上がっていた。新規システムはつないでいた2台が起動していた。
とりあえず新規システムを落としつつエアコンをいれる。このときサーバー室から変な音がする。
予備のエアコンも稼働して冷えたのでaとd起動する。起動した所livbirtdが立ち上がってないので一旦全員落とす。その後相変わらずlivbirtdが立ち上がってないのでsystemctlで立ち上げる。
立ち上げたが踏み台サーバーにssh出来ないなどの報告が出る。よくよく見ると学科のwebサイトも見れないわwifiが外に行けないわの症状が出ている。
8.8.8.8にpingを飛ばした所外に行けてなさそう。
id:unimarimoと合流。仲良くサーバーの調子を見る。 学内ネットからだと学科サイトが見れそう。内向きDNSは元気そう。
systemctlでstatusを確認していたらnetwrok
が一部立ち上がってない。startしても変化が見られない。
ぐむ〜と言いながら色々試したがダメそう。エレベーターが動いてなかったので「電気が完全に復旧してないのでは?」みたいな話になる。工学部周辺が停電という話だったので総情(琉大のネットワークの大本を管理している場所)が停電していたら外にいけないよね〜と話し、一旦帰宅することに。
階段を降り1Fにつくとエレベーターに「故障しました」のガムテープが。ひょっとしたら電気は完全に復旧している?などと思いながらおなか空いたので一旦家帰ってご飯。
ご飯食べながら色々考えていたが、そもそも総情のオンプレで配信している総情のページは見えているのだからやはり電気は復旧している。電気がだめじゃなくて我々が悪そう.......。
外に行けないサーバーのことを「内向的な性格」などと呼びつつ大学に戻る。
内向きが解決できるかと思っていたがなんかアクセスできなくなっている。 大学戻った所4Fのwifiが死んでいた。
先日UTMのアップグレードをしたこともありUTMを疑うが、UTMは見る限り元気に稼働している。 VMの状態を確認するなら有線持ってくるか〜と言いながらUTMの下に目を向けると、L3スイッチ3つのうちの1つが息をしていないことが発覚。
ラックの後ろに回ると動いていないL3スイッチのランプが赤色に光っている… しかも焦げたような匂いが漂っている。
型番からググってマニュアルを見ると、PS OKが赤色の場合は出力が停止しました
とのことらしい。障害じゃん…。
念のために電源を抜き差ししても変わらず。こいつが原因そうだったので電源を抜いて業者さんとの連絡用のMLに投稿。翌日の9時から作業をすることに。
業者さんから「火災防止でスイッチのケーブル抜いといて」と言われる。抜いたか覚えてなかったのでid:unimarimoに頼んで抜いてもらう。
実は既に抜いていたのでただサーバー室まで歩いて行かせたムーブをした。
業者さんとこんにちは。 コンソールケーブルは持ってきていただいた…。申し訳ない。
スイッチの電源を交換したりしたところ、相変わらず赤ランプだったので物理障害が確定。代替機の手配をしてもらいつつ今後の方針を決める。
L3スイッチ3つのうちに生き残った2つのスイッチに空いているポートがあったので、configを空いているポートに移す作業をすることになる。
その前に他のネットワーク機器が大丈夫かを調べた所、故障したスイッチに接続していた各研究室のフロアスイッチ及びEPS室に置いてあるスイッチがpingが通らないことが発覚。これらも治す必要がある。
またwifiアクセスポイントも赤色点灯しておりエラーが発生している。どうもwifiが全体的に調子が悪いらしい。
L3スイッチに接続していたフロアスイッチやルームスイッチの様子を見に行く。どうも自己防衛かなんかで落ちていたらしい。エレベーターやL3スイッチ、フロアスイッチまで障害が発生しているので計画停電で電気業者がなにかやらかした説が出てきた。一部スイッチの調子を見に行くためにid:unimarimoが脚立を借りに行く。ショムニっぽい。
各スイッチにはコンソール接続してconfigure terminal
したあとにshutdown
とno shutdown
をl3に接属していたport-channleで実行して解決して回る。
研究室はこのコロナ騒ぎで人がいないのでマスターキーを借りる。しばらくしたらエレベーターの修理で使うらしいので別のマスターキーを借りに行くなどをした。
wifiアクセスポイントは再起動時はよくなったがしばらくするとエラーがでる。つらい
スイッチの設定等は業者の方に頼みつつ、基幹システムの状況をリカバリしにいく。 radiusとかが立ち上がってないのを立ち上げていく。一部VMが立ちあがってもvirsh consoleでいけないので泣きながらshutdown。shutdownしても落ちないのでdestroy.........
wifiコンパネにアクセスしようとしたが相変わらずwifiが死んでいる。つらみ。
疲れたのでお昼休憩。家帰ってご飯を食べる。
鮭を3切れ焼いた。
頑張ってwifiアクセスポイントのwebコンパネにアクセスしようとする。 L3スイッチからVLANを切って有線でアクセスしようとしたが失敗する。
研究室のサーバーからアクセスしようとしたがこれも失敗。むむむ.....とか言ってたら突然wifiでアクセスできるようになった。webコンパネが表示しているスイッチなどの情報が少なすぎてウケるという感じ。まだどっかで障害が起きてそう。
基幹サーバー及びシステムともに、突然外部にいけるようになったりいけなくなったりする。 systemctlやnmcliなどを使っても原因が断定出来ない。基幹サーバーにtracerouteが入って無くて辛い気持ちになる
業者さんが原因を特定。生き残ったL3スイッチ2台がともにActiveになっていたらしい。 いわゆるダブルアクト状態というもの。
L3スイッチは冗長化としてActive/Standbyの状態を持つ手法があるらしいが、両方Activeだとゲートウェイが2つ存在することになりコンフリクトするらしい。 この設定を正常にした所、ネットワークが改善され外に行けるようになった。
業者さんがスイッチの設定を書き換え、及び取り外しを行っている間に、相変わらずダメそうな各フロア/ルームスイッチを再起動して回る。
すべてのスイッチの設定を生存していたスイッチに移しスイッチ側の復旧は完了。
僕とid:unimarimoも基幹システムのmountやデーモンの障害を一通り解決し終了。 ネットワークでトラブっていたためか微妙にNFSが調子悪そう。まぁ治るか....。 代替機がきたタイミングで交換作業をしましょうという話になり今日は終了。
ちょうど来月システム更新なんですが、システム更新前に障害が発生してウケるwという感じでした。 (今回代替機のL3スイッチは30日後に引き取られるスイッチになってしまった)
業者の方の対応力がすごくて、一緒にフロアスイッチを床から取り出す作業や、原因の特定、設定の書き換えまでしていただきました。ありがとうございます。
あとは一家に一台コンソールケーブルはあったほうがいいですね。シリアルケーブルも...。
ということで流れに乗ってみました。
毎週火曜日のペアプロ講習用に作成した問題を昨晩の #Perl入学式 オンラインミーティングで紹介したので Twitter でも紹介。情勢が収束したらまた懇親会でピザを食べつつお題に興じたい。 pic.twitter.com/n68luVPNEg
— OGATA Tetsuji (@xtetsuji) 2020年7月26日
アルゴリズムそんな自信ないのでどうなんだろう.....。競プロerからなんか突っ込まれそう