OpenSSLのコマンドで有効な暗号スイートを確認。 [Linux]
SSL/TLSのどの暗号スイートが有効か調べたかったんだけど、社内のシステムにつき
https://www.ssllabs.com/ssltest/index.html
のような外部サイトがつなげない。
そういう時にopensslコマンドを使えばいいんだけど、網羅的に使おうとすると面倒で…
https://qiita.com/ionis_h/items/277430a8807ee09c8b46
ここではRubyスクリプトを提示しているんだけど、Ruby入れるのがしんどいのでシェルスクリプトでやってみた。全然opensslコマンドを編集していないので冗長すぎるけど、必要ならばGrepとかしてほしい。
https://github.com/miffy/ssl_ciphers.sh/blob/main/ssl_ciphers.sh
どこから取ってきたのか忘れたけど、ワンライナーでもそこそこできる。
こんな感じなんだけど、つなげない暗号スイートの名前が出てこないので一覧にはできない。ただgrepしているところがピンポイントなので、かなり簡潔な物にはなる。使える暗号スイートを調べるだけならこれでOK。
というかTLS使うのまんどう臭い。でも、最近はGoogleのページ評価の関係でHTTPSを使うのがデフォルトになっているので、使わないわけにはいかなくなってきてはいる。
https://www.ssllabs.com/ssltest/index.html
のような外部サイトがつなげない。
そういう時にopensslコマンドを使えばいいんだけど、網羅的に使おうとすると面倒で…
https://qiita.com/ionis_h/items/277430a8807ee09c8b46
ここではRubyスクリプトを提示しているんだけど、Ruby入れるのがしんどいのでシェルスクリプトでやってみた。全然opensslコマンドを編集していないので冗長すぎるけど、必要ならばGrepとかしてほしい。
https://github.com/miffy/ssl_ciphers.sh/blob/main/ssl_ciphers.sh
#!/bin/bash
HOST="localhost:443"
echo $HOST
LF=$'\n'
# 暗号スイートを列挙し配列の中に入れる
OLD_IFS=$IFS
IFS=:
CIPHER_ARR=(`openssl ciphers`)
IFS=$OLD_IFS
# openssl s_clientコマンドで各暗号スイートの確認
for (( i=0; i < ${#CIPHER_ARR[@]}; i++ ))
do
echo "<<< "${CIPHER_ARR[i]}" >>>"$LF
openssl s_client -connect ${HOST} -cipher ${CIPHER_ARR[i]} < /dev/null
echo $LF
done
どこから取ってきたのか忘れたけど、ワンライナーでもそこそこできる。
$ openssl ciphers -v | awk '{print "s_client -connect localhost:443 -cipher " $1}' | xargs -L 1 openssl 2> /dev/null | grep "Cipher is" | grep -v "NONE"
こんな感じなんだけど、つなげない暗号スイートの名前が出てこないので一覧にはできない。ただgrepしているところがピンポイントなので、かなり簡潔な物にはなる。使える暗号スイートを調べるだけならこれでOK。
というかTLS使うのまんどう臭い。でも、最近はGoogleのページ評価の関係でHTTPSを使うのがデフォルトになっているので、使わないわけにはいかなくなってきてはいる。
RHELのsubscription-managerでエラーが出た時の話 [Linux]
RedHatEnterpriseLinuxを使っている時に、subscription-managerで下記のエラーが出た。
エラーメッセージでググってもそのものずばりのエラーが出てこない上に、解決方法もよくわからない。UTF-8が何とかだから文字コードの問題だとは思うんだけど…。
https://bugzilla.redhat.com/show_bug.cgi?id=1449839
ここを見るとロケールによって問題が発生していることがあるようで。
普通にやると上記のようにエラーが出るので、上のリンクのをまねして文字コードを指定した。
そうするとエラーが出ず問題なくサブスクリプションの確認ができる。
というか、今更Linuxをeuc-jpで使うなよなって話だが、今は普通に入れるとUTF-8でOSが入ると思うので、レガシーを引きずる企業ユーザーにしか必要のない情報でした。
# subscription-manager list
+-------------------------------------------+
インストール済み製品のステータス
+-------------------------------------------+
'utf8' codec can't decode byte 0xb7 in position 8: invalid start byte
エラーメッセージでググってもそのものずばりのエラーが出てこない上に、解決方法もよくわからない。UTF-8が何とかだから文字コードの問題だとは思うんだけど…。
https://bugzilla.redhat.com/show_bug.cgi?id=1449839
ここを見るとロケールによって問題が発生していることがあるようで。
普通にやると上記のようにエラーが出るので、上のリンクのをまねして文字コードを指定した。
# LANG=euc-jp subscription-manager list
+-------------------------------------------+
Installed Product Status
+-------------------------------------------+
Product Name: Red Hat Developer Toolset (for RHEL Server)
以下略
そうするとエラーが出ず問題なくサブスクリプションの確認ができる。
というか、今更Linuxをeuc-jpで使うなよなって話だが、今は普通に入れるとUTF-8でOSが入ると思うので、レガシーを引きずる企業ユーザーにしか必要のない情報でした。
yum updateかけるときの個別の上がるバージョンを調べるの。 [Linux]
RedHat系好きじゃないんだけど、仕事だから仕方なく使っている。あんなもの企業のサポートしなかったら大して便利な物じゃないのにね。
今回はyum updateをする時に、個別のパッケージがどんだけバージョンが上がるのかを知りたかった。ググっても素直に出てこないので大したことじゃないけど書いておく。
yum check-updateでyum updateをかけた時にアップデートされるパッケージは列挙できる。だけど（たぶん）新しくなるパッケージのバージョンはわからない。というか、そこで分かるようにしておけよｗ
面倒だけどyum update 「パッケージ名」で個別アップデートする直前まで行ってしまう。そうすれば、どのパッケージにアップデートされるのかは個別に出てくる。今回はOpenSSLがどこまで対応してくれるのかを知りたかったので、yum update opensslで見たのだけれど、直前でNを入力しないといけないので気持ち悪いんだよね。参照モードみたいな形でやってほしいので、そういうところ行き届いてないなと思う。
yum updateで痛い目見た系のページがよく検索にヒットするのだけれど、たぶんコンソールのメッセージにyum updateしましょう、みたいなのが出てくるから、初心者が安易にやって実行環境を崩すんだろうね。そういうどうでもいいお節介みたいなものはやめてほしんだけど。
今回はyum updateをする時に、個別のパッケージがどんだけバージョンが上がるのかを知りたかった。ググっても素直に出てこないので大したことじゃないけど書いておく。
yum check-updateでyum updateをかけた時にアップデートされるパッケージは列挙できる。だけど（たぶん）新しくなるパッケージのバージョンはわからない。というか、そこで分かるようにしておけよｗ
面倒だけどyum update 「パッケージ名」で個別アップデートする直前まで行ってしまう。そうすれば、どのパッケージにアップデートされるのかは個別に出てくる。今回はOpenSSLがどこまで対応してくれるのかを知りたかったので、yum update opensslで見たのだけれど、直前でNを入力しないといけないので気持ち悪いんだよね。参照モードみたいな形でやってほしいので、そういうところ行き届いてないなと思う。
yum updateで痛い目見た系のページがよく検索にヒットするのだけれど、たぶんコンソールのメッセージにyum updateしましょう、みたいなのが出てくるから、初心者が安易にやって実行環境を崩すんだろうね。そういうどうでもいいお節介みたいなものはやめてほしんだけど。
cronでメールを送るシェルスクリプトが動かなかった件。 [Linux]
crontabで設定して、tail -f /var/log/cron を見ていて実行されていても、実際には動かないシェルスクリプトとかありますか？ 自分は休日を入れて4日間もハマりましたｗ。
「cron シェルスクリプト 実行されない」
とかでググってみると
https://i-think-it.net/linux-cron-not-be-execute/
・cronの記載方法に間違いないか
・cronサービスは起動しているか
・スクリプトに実行権は付与されているか
・シェルスクリプトのパス指定に間違いないか
・SSH接続が可能か
・expectコマンド入りのスクリプト
があってどれも当てはまらない。きちんとコマンドラインではシェルスクリプトは実行されていて、処理のメールがきちんと届く。でもcronでは動かない。
結局、どこでコケているのか分からないので、下記のようにログに出力を出してみることにしました。
https://qiita.com/ekusuy/items/2d87f5542e2287028634
10 * * * * /home/myuser/mailsend.sh >> /tmp/cron.log 2>&1
10分が近かったのでcrontabに指定してみるとcronのログには同様に動いていたのが見えたが、やはり実行されない。/tmp/cron.logを見るとがっつりエラーが出ていました。やっとエラーの理由がわかりました。
sendmailコマンドでメールを出していたんだけど、そのsendmailコマンドが見つからないときた。
なぜか？ シェルスクリプトを手動で動かしていた時は、シェルが呼び出す実行ファイルまでのパスが通っていて、恐らくcronの時はその実行パスが分からない状態になっていたようです。
確かにcronでbashを動かしていても、環境変数はどこから取ってきていいのか分からないし、cronで使われるユーザーの.bashrcなどの設定ファイルを読み込んでくれるほどのサービスはしてくれないという事ですね。なので、シェルスクリプト内の実行ファイルはフルパスにしないといけないみたい。
なので、which sendmailで調べて
/usr/sbin/sendmail
に変えて動かしたら問題がなくなりました。他のファイルのパスはどこで実行してもいいようにフルパスにしていたんだけど、コマンドまでしなくてはいけないとは気づきませんでした。コマンドラインからはカッチリ動くだけに厄介な感じです。
あとがきですが、
それまでは、
command > /dev/null 2>&1
って後ろにつけないといけないのかもなと、おまじないをしようとしていたんですが、それは余計に悪いことだったりしました。
https://qiita.com/ritukiii/items/b3d91e97b71ecd41d4ea
http://dqn.sakusakutto.jp/2012/06/shell_dev_null_2_1_crontab.html
動かないうちは少なくとも/dev/nullに捨てない方がいいですよね。
さらに後書き。
cronで実行中、エラーが出たりすると勝手にメールを出したりする。余計なお世話なんだけど、エラーが前提のシェルスクリプトだと困る。
そのための > /dev/null 2>&1 なんだろうけど、自分の場合、cron内でこれをつけてもメールが発信された。crontabの時に行頭にMAILTO=""をすると送られないとの情報もダメだった。結局エラーメールは出てしまっていたのですよね。
根本的にシェルスクリプトからエラーが出ないようにすればいいと思い、エラーが出ている三段ぐらいパイプしているところの最後に > /dev/null 2>&1 をしたら結果も闇に消し去られてしまった。エラーだけを消すには 2>/dev/null をパイプで繋げている途中でも入れないといけないみたい。結局エラー処理がそのコマンド単体で出ているから、パイプをいくつも通した後でまるっとエラー処理みたいなことはできないみたい。だからコマンド単体でエラーを殺しておく必要がある。
そんなわけでcrontabで >/dev/null 2>&1 をしようが、MAILTO=""をしようが、元のシャルスクリプトのコマンドでエラーが出てしまうと、エラーメールが容赦なく出てしまうという話でした。どうでもいいが、自分の使う環境って例外なのか、ググって出てくる情報がエアプなのかはわからないけど、実際やってみるとダメな場合が多いんだよな。んで、結局自分で解決するんだけど、他の人も本当にそれで解決しているのかなと思いました。
できなかった事を書いてある所にリンクを張ろうとしたけど、そうすると余計誘引することになるのでやめた。まぁそれでできるようになる環境ならいいけど、できないものはできないから。というか、環境が違うからか、情報が古いからなのか、どう考えてもエアプだろうという情報がかなり多いのだけれど、すぐに解決できないのはイライラするものです。まぁ嘘を書いているわけじゃないんだろうけど、当てはまらないと一体なんなん？って思うよね。
「cron シェルスクリプト 実行されない」
とかでググってみると
https://i-think-it.net/linux-cron-not-be-execute/
・cronの記載方法に間違いないか
・cronサービスは起動しているか
・スクリプトに実行権は付与されているか
・シェルスクリプトのパス指定に間違いないか
・SSH接続が可能か
・expectコマンド入りのスクリプト
があってどれも当てはまらない。きちんとコマンドラインではシェルスクリプトは実行されていて、処理のメールがきちんと届く。でもcronでは動かない。
結局、どこでコケているのか分からないので、下記のようにログに出力を出してみることにしました。
https://qiita.com/ekusuy/items/2d87f5542e2287028634
10 * * * * /home/myuser/mailsend.sh >> /tmp/cron.log 2>&1
10分が近かったのでcrontabに指定してみるとcronのログには同様に動いていたのが見えたが、やはり実行されない。/tmp/cron.logを見るとがっつりエラーが出ていました。やっとエラーの理由がわかりました。
sendmail: コマンドが見つかりません
sendmailコマンドでメールを出していたんだけど、そのsendmailコマンドが見つからないときた。
なぜか？ シェルスクリプトを手動で動かしていた時は、シェルが呼び出す実行ファイルまでのパスが通っていて、恐らくcronの時はその実行パスが分からない状態になっていたようです。
確かにcronでbashを動かしていても、環境変数はどこから取ってきていいのか分からないし、cronで使われるユーザーの.bashrcなどの設定ファイルを読み込んでくれるほどのサービスはしてくれないという事ですね。なので、シェルスクリプト内の実行ファイルはフルパスにしないといけないみたい。
なので、which sendmailで調べて
/usr/sbin/sendmail
に変えて動かしたら問題がなくなりました。他のファイルのパスはどこで実行してもいいようにフルパスにしていたんだけど、コマンドまでしなくてはいけないとは気づきませんでした。コマンドラインからはカッチリ動くだけに厄介な感じです。
あとがきですが、
それまでは、
command > /dev/null 2>&1
って後ろにつけないといけないのかもなと、おまじないをしようとしていたんですが、それは余計に悪いことだったりしました。
https://qiita.com/ritukiii/items/b3d91e97b71ecd41d4ea
http://dqn.sakusakutto.jp/2012/06/shell_dev_null_2_1_crontab.html
動かないうちは少なくとも/dev/nullに捨てない方がいいですよね。
さらに後書き。
cronで実行中、エラーが出たりすると勝手にメールを出したりする。余計なお世話なんだけど、エラーが前提のシェルスクリプトだと困る。
そのための > /dev/null 2>&1 なんだろうけど、自分の場合、cron内でこれをつけてもメールが発信された。crontabの時に行頭にMAILTO=""をすると送られないとの情報もダメだった。結局エラーメールは出てしまっていたのですよね。
根本的にシェルスクリプトからエラーが出ないようにすればいいと思い、エラーが出ている三段ぐらいパイプしているところの最後に > /dev/null 2>&1 をしたら結果も闇に消し去られてしまった。エラーだけを消すには 2>/dev/null をパイプで繋げている途中でも入れないといけないみたい。結局エラー処理がそのコマンド単体で出ているから、パイプをいくつも通した後でまるっとエラー処理みたいなことはできないみたい。だからコマンド単体でエラーを殺しておく必要がある。
そんなわけでcrontabで >/dev/null 2>&1 をしようが、MAILTO=""をしようが、元のシャルスクリプトのコマンドでエラーが出てしまうと、エラーメールが容赦なく出てしまうという話でした。どうでもいいが、自分の使う環境って例外なのか、ググって出てくる情報がエアプなのかはわからないけど、実際やってみるとダメな場合が多いんだよな。んで、結局自分で解決するんだけど、他の人も本当にそれで解決しているのかなと思いました。
できなかった事を書いてある所にリンクを張ろうとしたけど、そうすると余計誘引することになるのでやめた。まぁそれでできるようになる環境ならいいけど、できないものはできないから。というか、環境が違うからか、情報が古いからなのか、どう考えてもエアプだろうという情報がかなり多いのだけれど、すぐに解決できないのはイライラするものです。まぁ嘘を書いているわけじゃないんだろうけど、当てはまらないと一体なんなん？って思うよね。
2022-01-27 09:11
コメント(0)
前にWSL2を入れてVirtualBoxが動かなくなって戻して、再度WSL2を入れた [Linux]
前にWSL2を実行しようとしたら、VirtualBoxが動かなくなって、設定でWSL2用の仮想化をオフにした覚えがあった。そのためWSL2は動かなくなってたのはなんとなくわかっていたけれど、そのためにやった設定とかは全然忘れていた。
WSL2を使おうとすると、Ubuntu 20.04LTSが動かなかった。
って出てきてUEFIだかBIOSだかの設定で、ググったら仮想化がオフにされているんじゃね？と書いてあったので、再起動してみたけれど軒並み設定は有効になっていた。
[Windowsの機能の有効化または無効化]からWindowsハイパーバイザープラットフォームにチェックを入れてはいて、その点で問題が出ているわけではない。
https://daysput.com/blogs/environment/2020/0811.html
何が悪いのか。前にやったことはやっぱり思い出さない。
https://teratail.com/questions/342263
が足りないんじゃないかと書いてあったので、管理者権限で実行して再起動。
とか出てきて、ちょっと状況が変わった（エラー値が違う）。
https://minus9d.hatenablog.com/entry/2018/12/29/105151
bashコマンドを打ったらUbuntuが立ち上がったので、何だろうと思った。元から立ち上がっていたとは思えんのだが…。その流れでアプリのUbuntu 20.04 LTSを立ち上げたら、ユーザー名とパスワードを聞いてきた。問題ないようだ。
もちろんVirtualBoxが立ち上がらなくなるわけだが、新しくすれば両立はできるらしい。最新のver.6を入れると使えるようになった。前は対応していなかったのだが、VirtualBoxもやっと対応できた模様。WSLもVirtualBoxもこれで問題はないようだ。
WSL2を使おうとすると、Ubuntu 20.04LTSが動かなかった。
WslRegisterDistribution failed with error: 0x80370102
って出てきてUEFIだかBIOSだかの設定で、ググったら仮想化がオフにされているんじゃね？と書いてあったので、再起動してみたけれど軒並み設定は有効になっていた。
[Windowsの機能の有効化または無効化]からWindowsハイパーバイザープラットフォームにチェックを入れてはいて、その点で問題が出ているわけではない。
https://daysput.com/blogs/environment/2020/0811.html
何が悪いのか。前にやったことはやっぱり思い出さない。
https://teratail.com/questions/342263
bcdedit /set hypervisorlaunchtype auto
が足りないんじゃないかと書いてあったので、管理者権限で実行して再起動。
WslRegisterDistribution failed with error: 0x80370110
とか出てきて、ちょっと状況が変わった（エラー値が違う）。
https://minus9d.hatenablog.com/entry/2018/12/29/105151
bashコマンドを打ったらUbuntuが立ち上がったので、何だろうと思った。元から立ち上がっていたとは思えんのだが…。その流れでアプリのUbuntu 20.04 LTSを立ち上げたら、ユーザー名とパスワードを聞いてきた。問題ないようだ。
もちろんVirtualBoxが立ち上がらなくなるわけだが、新しくすれば両立はできるらしい。最新のver.6を入れると使えるようになった。前は対応していなかったのだが、VirtualBoxもやっと対応できた模様。WSLもVirtualBoxもこれで問題はないようだ。
そろそろCentOS8のサポート期限が切れますね。 [Linux]
CentOS8のサポート期限の切り詰めがあって、一部からは非難轟々でしたけど、結局サブスクリプションを買っている企業には、普通のRHELがタダで開発用にも使えるということで収まった感はあります。
それまでタダ乗りしていた人達は、CentOS以外のRHELクローンに乗り換えないといけないわけですが、どれが生き残るのかよくわかりません。それまでも生まれては消えていったので、正直何を選んだらいいかなんてわからないっすよね。
脆弱な資本基盤のプロジェクトだとダメになりやすいし、かと言ってでかい資本の会社でもいつ止めるかなんてわからないし、Oracleみたいな会社を政治的に嫌って使わないとかも普通にあるでしょう。今はいくつか新しいの出てきたんですよね。下を見ると
https://ja.wikipedia.org/wiki/Red_Hat_Enterprise_Linux%E6%B4%BE%E7%94%9F%E3%83%87%E3%82%A3%E3%82%B9%E3%83%88%E3%83%AA%E3%83%93%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3
あからさまにCentOS8打ち切り対応なのは
Rocky Linux
AlmaLinux
くらいなのかな。最近はMIRACLE LINUXっていうのもあるのか〜。これは日本だけのディストロということになるんだろうが、金かかるならいらねーっていう人もいると思うので、金がかからない方法があるにしても、RedHat本体を使わないところは使わない気はするよね。メリットがよくわからん。そんならまだこなれてそうなOracle Linuxを使った方が良さそうだ。
なんにしてもCentOSの良いところは商用Linuxをサポートはないけどタダで使えるというところにあって、所謂揶揄されるフリーライドが問題なわけです。お金を払わずに安心を得ようとする企業は滅びろとか思うんですが、そういうところに限ってUbuntuとかSuseとかのディストロを使おうとも思わないんだよな。まぁ日本人は保守的だから商用のRedHatに寄り添うしかないのかもしれません。
会社でも上の人がRedHatの人と交渉をして11月ごろから、タダの開発サブスクリプションを使えるようになったっぽいですね。これは動き始めた会社の時期によるとは思うんですが、最初は会社一法人に対して一つの開発サブスクリプションとか言っていたような気がするんで、RedHat本社の方でもそこそこ混乱していたんじゃないかと思われます。今までそういうサービスがないところで、新しく分け与えなくてはならないので、基本的に最初から対応みたいな感じにはなっていたんでしょうから。
CentOS8のサポート期限の切り詰めで、RHELがタダで使えるみたいよという話が出ていた当時は、個人向けのサポートしか大々的にやっていなかったんだけど、Linuxの雑誌に商用サブスクリプションを買っている法人には開発サブスクリプション無料みたいなことも書いてあったので、上司に報告してふむふむと言っていたけれど、結局今まで時間がかかってしまったみたいですね。基本サーバベンダからRHELを買っていたので、間に入った分揉めていたっぽいですが、結局RedHatと直でやっていたみたいです。
CentOSからのRHELへのマイグレーションは、自分のところでも書いたのでそちらをどうぞ。
https://miff.blog.ss-blog.jp/2021-07-04
ミソはGitHubの最新のrpmを使うところかな？ 現行で上手くいくかどうかは知らんけど。
それまでタダ乗りしていた人達は、CentOS以外のRHELクローンに乗り換えないといけないわけですが、どれが生き残るのかよくわかりません。それまでも生まれては消えていったので、正直何を選んだらいいかなんてわからないっすよね。
脆弱な資本基盤のプロジェクトだとダメになりやすいし、かと言ってでかい資本の会社でもいつ止めるかなんてわからないし、Oracleみたいな会社を政治的に嫌って使わないとかも普通にあるでしょう。今はいくつか新しいの出てきたんですよね。下を見ると
https://ja.wikipedia.org/wiki/Red_Hat_Enterprise_Linux%E6%B4%BE%E7%94%9F%E3%83%87%E3%82%A3%E3%82%B9%E3%83%88%E3%83%AA%E3%83%93%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3
あからさまにCentOS8打ち切り対応なのは
Rocky Linux
AlmaLinux
くらいなのかな。最近はMIRACLE LINUXっていうのもあるのか〜。これは日本だけのディストロということになるんだろうが、金かかるならいらねーっていう人もいると思うので、金がかからない方法があるにしても、RedHat本体を使わないところは使わない気はするよね。メリットがよくわからん。そんならまだこなれてそうなOracle Linuxを使った方が良さそうだ。
なんにしてもCentOSの良いところは商用Linuxをサポートはないけどタダで使えるというところにあって、所謂揶揄されるフリーライドが問題なわけです。お金を払わずに安心を得ようとする企業は滅びろとか思うんですが、そういうところに限ってUbuntuとかSuseとかのディストロを使おうとも思わないんだよな。まぁ日本人は保守的だから商用のRedHatに寄り添うしかないのかもしれません。
会社でも上の人がRedHatの人と交渉をして11月ごろから、タダの開発サブスクリプションを使えるようになったっぽいですね。これは動き始めた会社の時期によるとは思うんですが、最初は会社一法人に対して一つの開発サブスクリプションとか言っていたような気がするんで、RedHat本社の方でもそこそこ混乱していたんじゃないかと思われます。今までそういうサービスがないところで、新しく分け与えなくてはならないので、基本的に最初から対応みたいな感じにはなっていたんでしょうから。
CentOS8のサポート期限の切り詰めで、RHELがタダで使えるみたいよという話が出ていた当時は、個人向けのサポートしか大々的にやっていなかったんだけど、Linuxの雑誌に商用サブスクリプションを買っている法人には開発サブスクリプション無料みたいなことも書いてあったので、上司に報告してふむふむと言っていたけれど、結局今まで時間がかかってしまったみたいですね。基本サーバベンダからRHELを買っていたので、間に入った分揉めていたっぽいですが、結局RedHatと直でやっていたみたいです。
CentOSからのRHELへのマイグレーションは、自分のところでも書いたのでそちらをどうぞ。
https://miff.blog.ss-blog.jp/2021-07-04
ミソはGitHubの最新のrpmを使うところかな？ 現行で上手くいくかどうかは知らんけど。
半自動的にLinuxのコマンドライン作業をしたい。 [Linux]
定型作業があって、たくさんのサーバで行わないといけない。SSHクライアントやLinuxのコマンドでなんとかならないかなぁと思っています。なんかどこかで見かけた覚えがあるんだけど、本気になってやろうと思っていなかったんだよね。
重い腰を上げてやろうと思ったのは、同じことを数十のサーバでやらないといけなくなったからで、毎回やるのはしんどいのである程度作り込んでも問題ないかなと思ったからです。とは言え、普通にコマンドラインを打つ以上のプログラミングはあまりしたくない、とかなりやる気なしなんですが。
そもそもパスワードも違うサーバ同士を一つのメソッドでやろうとするんだから、そこのところは別途どうにかしないといけない。パスワードを間違えた時のリカバリとか考えると途端に憂鬱なるんだけど、なんとか方法はないだろうか。
http://www.math.kobe-u.ac.jp/HOME/kodama/tips-expect.html
expectというのを入れると良さそうだが、各サーバに入れなきゃいけないようなので、その作業を考えるとしんどいかな。やはりクライアント側でごにょごにょやって済むならそうしたい。
とりあえずWindowsのSSHクライアントのRLoginにスクリプトなるものがあるから、それを使ってみた。スクリプトというからただ単に内容を標準入力に流す程度のものかと思っていたら、そこそこ色々できるマクロのようなものであった。
https://colo-ri.jp/develop/2014/02/rloginroot.html
sputs()を単独で実行させてみたけど、上のようにログイン作業を定型化しなくても使えるので、入ったサーバにそれぞれ任意の時に実行させることができる。そのため、Linuxにシェルスクリプトをアップして実行する手間が省ける。少し、サーバごとに変わっていても、ちょこちょこWindowsのエディタで書き換えて対応できるので、ちょっとした違いを考えてスクリプトに仕掛けを作らなくてもいい。
全部が全部自動化すると大変なので、ある程度は手作業を交えて作業をすることにした。10行あまりの実行にしても、ファイルを選んで一発で終わるので、省力という点では同じことをするんだったら、使わない手はない。
ただ残念なのがスクリプトファイルを他で開いていると実行できないという仕様になっていて、実行の度にエディタなどでファイルを閉じないといけない。あとコメントアウトは//でできるっぽいんだけど、公式サイトには出ていないっぽい。この二つはあまりよろしくないので、後で直した方がいいよと忠告しておこうと思っている。編集のためにファイルを開いているから実行できない処理系ってほとんどないので。
https://kmiya-culti.github.io/RLogin/script.html
RLoginとかが特殊なのかなと思っていたら、TeraTermにもマクロはあるらしい。でもTeraTermはいろいろ面倒なので、RLoginから戻ることはないかなと思ったり。
最後にSSH公開鍵登録のサンプルを上げておきますね。これは一部書き換えないとそのままでは使えないのはもちろんだけど、実行時にrootユーザーになっていないといけなかったりします。あと特定の場所にSSH鍵を置かないといけなかったりするので（"id_rsa.pub.ユーザー名"のファイルを置く）、手動の部分は多いです。だけど、そこは自動化できるようなところではないので仕方ないですね。
本当はログインから自動化したかったんだけど、サーバによってパスワードが違う環境だったりしたのでできませんでした。他のサイトでそこのところはやっていたりするので、やりたい人は別のところを見てください。というか、コンテナとかでぽんぽん環境を作る場合はいろいろ方法はあるんだろうけど、そういう仕組みが使えない場合ってことで…。
重い腰を上げてやろうと思ったのは、同じことを数十のサーバでやらないといけなくなったからで、毎回やるのはしんどいのである程度作り込んでも問題ないかなと思ったからです。とは言え、普通にコマンドラインを打つ以上のプログラミングはあまりしたくない、とかなりやる気なしなんですが。
そもそもパスワードも違うサーバ同士を一つのメソッドでやろうとするんだから、そこのところは別途どうにかしないといけない。パスワードを間違えた時のリカバリとか考えると途端に憂鬱なるんだけど、なんとか方法はないだろうか。
http://www.math.kobe-u.ac.jp/HOME/kodama/tips-expect.html
expectというのを入れると良さそうだが、各サーバに入れなきゃいけないようなので、その作業を考えるとしんどいかな。やはりクライアント側でごにょごにょやって済むならそうしたい。
とりあえずWindowsのSSHクライアントのRLoginにスクリプトなるものがあるから、それを使ってみた。スクリプトというからただ単に内容を標準入力に流す程度のものかと思っていたら、そこそこ色々できるマクロのようなものであった。
https://colo-ri.jp/develop/2014/02/rloginroot.html
sputs()を単独で実行させてみたけど、上のようにログイン作業を定型化しなくても使えるので、入ったサーバにそれぞれ任意の時に実行させることができる。そのため、Linuxにシェルスクリプトをアップして実行する手間が省ける。少し、サーバごとに変わっていても、ちょこちょこWindowsのエディタで書き換えて対応できるので、ちょっとした違いを考えてスクリプトに仕掛けを作らなくてもいい。
全部が全部自動化すると大変なので、ある程度は手作業を交えて作業をすることにした。10行あまりの実行にしても、ファイルを選んで一発で終わるので、省力という点では同じことをするんだったら、使わない手はない。
ただ残念なのがスクリプトファイルを他で開いていると実行できないという仕様になっていて、実行の度にエディタなどでファイルを閉じないといけない。あとコメントアウトは//でできるっぽいんだけど、公式サイトには出ていないっぽい。この二つはあまりよろしくないので、後で直した方がいいよと忠告しておこうと思っている。編集のためにファイルを開いているから実行できない処理系ってほとんどないので。
https://kmiya-culti.github.io/RLogin/script.html
RLoginとかが特殊なのかなと思っていたら、TeraTermにもマクロはあるらしい。でもTeraTermはいろいろ面倒なので、RLoginから戻ることはないかなと思ったり。
最後にSSH公開鍵登録のサンプルを上げておきますね。これは一部書き換えないとそのままでは使えないのはもちろんだけど、実行時にrootユーザーになっていないといけなかったりします。あと特定の場所にSSH鍵を置かないといけなかったりするので（"id_rsa.pub.ユーザー名"のファイルを置く）、手動の部分は多いです。だけど、そこは自動化できるようなところではないので仕方ないですね。
user_name = "ユーザー名";
//ユーザーと.sshディレクトリを作る
sputs(sprintf("adduser %s\n", user_name));
sputs(sprintf("mkdir /home/%s/.ssh\n", user_name));
sputs(sprintf("chown %s:%s /home/%s/.ssh\n", user_name, user_name, user_name));
sputs(sprintf("chmod 700 /home/%s/.ssh\n", user_name));
//.sshに鍵を置く
sputs(sprintf("mv /home/ファイルを上げられるユーザ/id_rsa.pub.%s /home/%s/.ssh/authorized_keys\n", user_name, user_name));
sputs(sprintf("chown %s:%s /home/%s/.ssh/authorized_keys\n", user_name, user_name, user_name));
sputs(sprintf("chmod 600 /home/%s/.ssh/authorized_keys\n", user_name));
sputs(sprintf("ls -la /home/%s/.ssh/\n", user_name));
本当はログインから自動化したかったんだけど、サーバによってパスワードが違う環境だったりしたのでできませんでした。他のサイトでそこのところはやっていたりするので、やりたい人は別のところを見てください。というか、コンテナとかでぽんぽん環境を作る場合はいろいろ方法はあるんだろうけど、そういう仕組みが使えない場合ってことで…。
john the ripperとssh-privkey-crack.cを使ってみた。 [Linux]
この二つを使うと、SSHの秘密鍵からパスフレーズを取れるので悪用厳禁なのだが、ペネトレーションテストなので仕方がないと自分に言い聞かせる。というか仕事なんだけどねｗ。仕事でクラッキングするとは思っていなかったが、危険性がどこまであるのかは知っておいた方がいい。
ググるとCentOS6のころの古い情報が結構たくさんあって、それだとyumとかでJohn the ripperとかはお手軽に入れられたんだけど、コンパイルしたところでそれほど面倒くさいことにはなっていないので、ソフトウェアリポジトリになかったら、ソースからコンパイルしたほうが早い。というか、今はもうないに等しいので、自分でコンパイルしましょう。ソフトなんてyumとかのソフトウェアリポジトリからしか入れたことないよ、という方も多いかとは思うけど、そこまで難しいわけではないのでチャレンジしてみてほしい。
まず、ここのサイトを見てみたりしたが、
https://kaworu.jpn.org/security/ssh%E7%A7%98%E5%AF%86%E9%8D%B5%E3%82%92%E3%82%AF%E3%83%A9%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95
最初のssh_privkey_crack.cがlusas.googlecode.comの場所にない。
ググったらGithubにあった。
https://github.com/Boran/lusas/blob/master/ssh-key-crack/ssh-privkey-crack.c
同じモノっぽい。これをコンパイルにかける。OpenSSLに依存しているからCentOSとかだと
で依存性を解消してからコンパイルしないといけない。というか、CentOS8も今年いっぱいなんだっけ？ Ubuntuとかに変えちゃった方がいいよね、ふつう。
ソースに
でコンパイルしろと書いてあるので、そのままコピペで実行。ssh-privkey-crackという実行ファイルができる。パス張ったりが面倒なのであとでJohn the ripperと同じディレクトリに持っていって使う。
次にJohn the ripperを入れる。これも以前はyumとかで簡単に入れられたみたいだけど、最近はそうでもないみたい。あるにはあったけど逆に手足を縛られそうなので、ソースを持ってきて使った方がいい気はする。
http://www.openwall.com/john/
ここからソースは手に入れることはできるようだ。
これは特に依存性はないみたいなので、コンパイル作業は面倒じゃない。あ、OpenSSLがないといけないみたいだけど、さっきssh-privkey-crackで入れたので気にしない。
https://kaworu.jpn.org/security/John_the_Ripper#john_.E3.82.92.E3.83.93.E3.83.AB.E3.83.89.E3.81.99.E3.82.8B
解凍してmakeファイル動かして終わり、ですね。makeは少し違って
にしました。とりあえず仮想マシンだったので良く分からなかったので、一般的と言われるものにしました。
パスが通ったところまでインストールしてくれなくてrunディレクトリに実行ファイルができるだけですね。まぁシステムにガッツリ入れる方法もあるかもしれないですが、そこまで頻繁にやるわけじゃないからいいか…。
runディレクトリに、先ほどのssh-privkey-crackの実行ファイルと、クラックしたい秘密鍵を入れます。めんどうなので同じところに全部入れちゃいます。実行は
四文字の”test”なパスフレーズだったので、4秒で開けちゃってますね。
ちなみに英数字8文字のパスフレーズだと12時間以上かけても開けませんでした（夜中じゅうやっていても無理だったので途中で止めた）。これはきちんとしたハードでやれば一日かからず開けてしまうはず。仮想マシンでCPUの設定も控えめにしたので、そこそこ遅いはずです。
コマンドを見た感じ、john the ripperからざらざらパスワードを流して、パイプでssh-privkey-crackが受け取って処理している感じ？ ソースを読めば細かいことはわかるけど、面倒くさくて読みませんｗ。結局秘密鍵をブルートフォースでクラックするという方法であることに違いはないと思う。
とにかく、そんなに苦労しなくてもSSHの秘密鍵のパスフレーズを解読するにはそこまで手間はかからないので、秘密鍵は漏らさないようにしないとあかんねという事でした。というか、余程のことがない限りは、秘密鍵を手にすることなんてないと思うので、そういう立場にならない限りはまず使うことなんてないのかもしれないけど、実際に使えるのかどうか知っているということと、たぶんできるんだろうと思っているだけのとは全然違うので、実際にやってみること自体で怖さを知る事は大切だとは思うけどね。
ググるとCentOS6のころの古い情報が結構たくさんあって、それだとyumとかでJohn the ripperとかはお手軽に入れられたんだけど、コンパイルしたところでそれほど面倒くさいことにはなっていないので、ソフトウェアリポジトリになかったら、ソースからコンパイルしたほうが早い。というか、今はもうないに等しいので、自分でコンパイルしましょう。ソフトなんてyumとかのソフトウェアリポジトリからしか入れたことないよ、という方も多いかとは思うけど、そこまで難しいわけではないのでチャレンジしてみてほしい。
まず、ここのサイトを見てみたりしたが、
https://kaworu.jpn.org/security/ssh%E7%A7%98%E5%AF%86%E9%8D%B5%E3%82%92%E3%82%AF%E3%83%A9%E3%83%83%E3%82%AD%E3%83%B3%E3%82%B0%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95
最初のssh_privkey_crack.cがlusas.googlecode.comの場所にない。
ググったらGithubにあった。
https://github.com/Boran/lusas/blob/master/ssh-key-crack/ssh-privkey-crack.c
同じモノっぽい。これをコンパイルにかける。OpenSSLに依存しているからCentOSとかだと
sudo yum install -y openssl-devel
で依存性を解消してからコンパイルしないといけない。というか、CentOS8も今年いっぱいなんだっけ？ Ubuntuとかに変えちゃった方がいいよね、ふつう。
ソースに
$ gcc -Wall -O2 -o ssh-privkey-crack ssh-privkey-crack.c -lssl -lcrypto
でコンパイルしろと書いてあるので、そのままコピペで実行。ssh-privkey-crackという実行ファイルができる。パス張ったりが面倒なのであとでJohn the ripperと同じディレクトリに持っていって使う。
次にJohn the ripperを入れる。これも以前はyumとかで簡単に入れられたみたいだけど、最近はそうでもないみたい。あるにはあったけど逆に手足を縛られそうなので、ソースを持ってきて使った方がいい気はする。
http://www.openwall.com/john/
ここからソースは手に入れることはできるようだ。
これは特に依存性はないみたいなので、コンパイル作業は面倒じゃない。あ、OpenSSLがないといけないみたいだけど、さっきssh-privkey-crackで入れたので気にしない。
https://kaworu.jpn.org/security/John_the_Ripper#john_.E3.82.92.E3.83.93.E3.83.AB.E3.83.89.E3.81.99.E3.82.8B
解凍してmakeファイル動かして終わり、ですね。makeは少し違って
$ make clean linux-x86-64
にしました。とりあえず仮想マシンだったので良く分からなかったので、一般的と言われるものにしました。
パスが通ったところまでインストールしてくれなくてrunディレクトリに実行ファイルができるだけですね。まぁシステムにガッツリ入れる方法もあるかもしれないですが、そこまで頻繁にやるわけじゃないからいいか…。
runディレクトリに、先ほどのssh-privkey-crackの実行ファイルと、クラックしたい秘密鍵を入れます。めんどうなので同じところに全部入れちゃいます。実行は
$ ./john -stdout -incremental | ./ssh-privkey-crack ./id_rsa ssh-privkey-crack v0.3 made by anonymous@echo.or.id, enhanced by michu@neophob.com keyheader: Proc-Type: 4,ENCRYPTED DEK-Info: AES-128-CBC,ほにゃほにゃなんとか Press 'q' or Ctrl-C to abort, almost any other key for status trying 467250 keys/s, # of tested keys: 1869001. ------------------------------------------------------------------------ -- - Passphrase match:. Found password after 4 seconds and 1869158 tries. -------------------------------------------------------------------------- -- -
四文字の”test”なパスフレーズだったので、4秒で開けちゃってますね。
ちなみに英数字8文字のパスフレーズだと12時間以上かけても開けませんでした（夜中じゅうやっていても無理だったので途中で止めた）。これはきちんとしたハードでやれば一日かからず開けてしまうはず。仮想マシンでCPUの設定も控えめにしたので、そこそこ遅いはずです。
コマンドを見た感じ、john the ripperからざらざらパスワードを流して、パイプでssh-privkey-crackが受け取って処理している感じ？ ソースを読めば細かいことはわかるけど、面倒くさくて読みませんｗ。結局秘密鍵をブルートフォースでクラックするという方法であることに違いはないと思う。
とにかく、そんなに苦労しなくてもSSHの秘密鍵のパスフレーズを解読するにはそこまで手間はかからないので、秘密鍵は漏らさないようにしないとあかんねという事でした。というか、余程のことがない限りは、秘密鍵を手にすることなんてないと思うので、そういう立場にならない限りはまず使うことなんてないのかもしれないけど、実際に使えるのかどうか知っているということと、たぶんできるんだろうと思っているだけのとは全然違うので、実際にやってみること自体で怖さを知る事は大切だとは思うけどね。
pam_tally2とfaillockでパスワードロックした話 [Linux]
セキュリティを上げるため、Linuxでパスワードを何回か間違うと、ログインできなくなるということをやった。基本SSHでログインするので、SSHだけやっておけばOKってことで。というか、直のコンソールでもそれをやると逆に困りそうなので考えない。
基本的にPAMという仕組みを使ってやることになるのだけれど、現状pam_tally2とfaillockが使える（CentOS7とか？）。なんでダブスタなんだという話なんだけど、まぁそこはまだこなれていなかったということなんでしょうね。最初、faillockがうまく動かなかったので、pam_tally2でやってみた。faillockを使えて分かったのだけれど、pam_tally2の方が融通が効くというか、簡略的な書き方で設定できるので、使い心地としてはpam_tally2の方が良かった。どっちも入っているときはどっちも使えるんで、よくコンフリクトしないなぁと思ったり。
pam_tally2でsshを設定するのですが、/etc/pam.d/sshd に以下の二行を適切なところに入れれば問題なく動きました（入れ込む場所とかはググって適当なところを見つけてください）。denyは回数で、unlock_timeはロックする時間です。これはpam_tally2もfaillockも同じなはず。その他のパラメータは知らんけど。
分かりやすい。faillockでも/etc/pam.d/sshd に設定を行ったんだけど、間違う前の最初からロックしてしまって上手くいきませんでした。設定が悪かっただけかもしれないんですが、faillockで/etc/pam.d/sshd に設定をするという例が見つからなかったので、そもそもできない可能性はあります。
同様にpam_tally2で/etc/pam.d/password-auth にも設定できて動作もするんですが、Faillockだと/etc/pam.d/system-authにも同じように設定しないと動かないので、注意が必要。ググったらpassword-authしか設定していないところとか普通にあるので、どちらもやらないとダメです。pam_tally2のつもりでやっていたら動きません。
RedHat系はここに書いてある通りやればいいんですけど、
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/security_guide/chap-hardening_your_system_with_tools_and_services
を適宜入れ込めばいいんですけど、なぜ二つのファイルに同じことを書かないといけないのかが冗長すぎて気持ち悪いです。まぁPAMの仕組みがそうであるということなんでしょうけど、pam_tally2はそうではないのでやっぱ気持ち悪いですね。それとこのやり方だとコンソールだろうと何だろうと間違うとロックしちゃうんじゃないかな？ たぶんsshでも直接コンソールを使っても同じになっちゃうんだと思う。手持ちの仮想化サーバではそういう挙動であった気がした。
faillockがsshだけをターゲットにできないなら、pam_tally2からデグッていることにもなろうとは思いますが、Linux標準になったからと言っていいものが残るというわけでもないのがキツいですね。そういうところは変な政治圧力とか他の本来どうでもいいところで足枷になって消えていってしまうものも結構あったりする。
あと他にPermitRootLoginでrootで入れないようにもしたんだけど、yes, no以外でいろいろ設定できるのも初耳でした。色々する奴がいると言うことで。
https://qiita.com/ine1127/items/b50b9a8f831736cf14ea
それとIPでアクセス制御もできたりするんだけど、盛り過ぎなので機会があったらまた書きます。これは会社の環境でファイル名が独自で、それでググって全然出てこなくて一時途方に暮れていました。というか、設定ファイルで独自ファイル名とかやめてよねｗ。/etcでgrepかけるときはrootにならないといけないし。まぁ設定ファイルを変更するにはルートにならないといけないから別にいいけど…。
基本的にPAMという仕組みを使ってやることになるのだけれど、現状pam_tally2とfaillockが使える（CentOS7とか？）。なんでダブスタなんだという話なんだけど、まぁそこはまだこなれていなかったということなんでしょうね。最初、faillockがうまく動かなかったので、pam_tally2でやってみた。faillockを使えて分かったのだけれど、pam_tally2の方が融通が効くというか、簡略的な書き方で設定できるので、使い心地としてはpam_tally2の方が良かった。どっちも入っているときはどっちも使えるんで、よくコンフリクトしないなぁと思ったり。
pam_tally2でsshを設定するのですが、/etc/pam.d/sshd に以下の二行を適切なところに入れれば問題なく動きました（入れ込む場所とかはググって適当なところを見つけてください）。denyは回数で、unlock_timeはロックする時間です。これはpam_tally2もfaillockも同じなはず。その他のパラメータは知らんけど。
auth required pam_tally2.so deny=2 unlock_time=3600 account required pam_tally2.so
分かりやすい。faillockでも/etc/pam.d/sshd に設定を行ったんだけど、間違う前の最初からロックしてしまって上手くいきませんでした。設定が悪かっただけかもしれないんですが、faillockで/etc/pam.d/sshd に設定をするという例が見つからなかったので、そもそもできない可能性はあります。
同様にpam_tally2で/etc/pam.d/password-auth にも設定できて動作もするんですが、Faillockだと/etc/pam.d/system-authにも同じように設定しないと動かないので、注意が必要。ググったらpassword-authしか設定していないところとか普通にあるので、どちらもやらないとダメです。pam_tally2のつもりでやっていたら動きません。
RedHat系はここに書いてある通りやればいいんですけど、
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/security_guide/chap-hardening_your_system_with_tools_and_services
auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=600 account required pam_faillock.so
を適宜入れ込めばいいんですけど、なぜ二つのファイルに同じことを書かないといけないのかが冗長すぎて気持ち悪いです。まぁPAMの仕組みがそうであるということなんでしょうけど、pam_tally2はそうではないのでやっぱ気持ち悪いですね。それとこのやり方だとコンソールだろうと何だろうと間違うとロックしちゃうんじゃないかな？ たぶんsshでも直接コンソールを使っても同じになっちゃうんだと思う。手持ちの仮想化サーバではそういう挙動であった気がした。
faillockがsshだけをターゲットにできないなら、pam_tally2からデグッていることにもなろうとは思いますが、Linux標準になったからと言っていいものが残るというわけでもないのがキツいですね。そういうところは変な政治圧力とか他の本来どうでもいいところで足枷になって消えていってしまうものも結構あったりする。
あと他にPermitRootLoginでrootで入れないようにもしたんだけど、yes, no以外でいろいろ設定できるのも初耳でした。色々する奴がいると言うことで。
https://qiita.com/ine1127/items/b50b9a8f831736cf14ea
それとIPでアクセス制御もできたりするんだけど、盛り過ぎなので機会があったらまた書きます。これは会社の環境でファイル名が独自で、それでググって全然出てこなくて一時途方に暮れていました。というか、設定ファイルで独自ファイル名とかやめてよねｗ。/etcでgrepかけるときはrootにならないといけないし。まぁ設定ファイルを変更するにはルートにならないといけないから別にいいけど…。
最近、開発から保守に回ってる。 [Linux]
歳からか実力からか、ただ単に仕事があったからか、開発から保守系の仕事ができたのかサーバの設定をしている。元々、開発というか保守の方の仕事で入る予定だったから、元に戻っただけなのかもしれないけど、それまで保守は仕事でそんなにやっていない。
ちょっと前、DevOpsとかいうのが流行っていたけど、結局デプロイやったついでに保守もしようよ的な感じになっているのだと思うが、開発をしていたら正直アプリケーションをリリースするのだけで一杯一杯だろう。保守まで手を回せっていうのは厳しい感じではある。
インフラエンジニアというほどでもないのだが、サーバいじりを生業とすることになったので、改めてシス管系女子とか買って読もうかなぁ…。日経Linuxでまとめが出ているときに、ちょこちょこ買ったんだけど、一通り読んでおくのもいいかなとは思っている。
紙のがいいんだけど、今時じゃないのかな…。
結局、ソースを読んで設定とかしているので、開発している時と同じぐらいソースを見ている。主にgrepなのだけれど、パラメーターとか読まないといけないので、結局ソースをなめて読まないとダメだったりする。面倒だな…。開発だとピンポイントにやればよかったけど、保守系だと全体を見ないといけないことが多いような気がする。おいら基本的にリベラル派なんですけど、保守系をしていていいんですかね？ｗ
ちょっと前、DevOpsとかいうのが流行っていたけど、結局デプロイやったついでに保守もしようよ的な感じになっているのだと思うが、開発をしていたら正直アプリケーションをリリースするのだけで一杯一杯だろう。保守まで手を回せっていうのは厳しい感じではある。
インフラエンジニアというほどでもないのだが、サーバいじりを生業とすることになったので、改めてシス管系女子とか買って読もうかなぁ…。日経Linuxでまとめが出ているときに、ちょこちょこ買ったんだけど、一通り読んでおくのもいいかなとは思っている。
まんがでわかるLinux シス管系女子（日経BP Next ICT選書）
- 出版社/メーカー: 日経BP
- 発売日: 2015/02/19
- メディア: Kindle版
まんがでわかるLinux シス管系女子2(日経BPパソコンベストムック)
- 出版社/メーカー: 日経BP
- 発売日: 2015/12/09
- メディア: 単行本
- 出版社/メーカー: 日経BP
- 発売日: 2018/04/24
- メディア: Kindle版
- 作者: 日経Linux
- 出版社/メーカー: 日経BP
- 発売日: 2017/06/27
- メディア: Kindle版
紙のがいいんだけど、今時じゃないのかな…。
結局、ソースを読んで設定とかしているので、開発している時と同じぐらいソースを見ている。主にgrepなのだけれど、パラメーターとか読まないといけないので、結局ソースをなめて読まないとダメだったりする。面倒だな…。開発だとピンポイントにやればよかったけど、保守系だと全体を見ないといけないことが多いような気がする。おいら基本的にリベラル派なんですけど、保守系をしていていいんですかね？ｗ
