標準エラー出力をパイプラインで次に渡す

表題を一部知らなかったのでメモ。

■ 環境

  • Linux
  • Mac OSX El Capitan

■ パイプライン

標準エラー出力をパイプラインで後続のコマンドの標準入力に渡すときはいつも下記のように実行していた。

$ command1 2>&1 | command2

上記のように実行すれば、標準出力と標準エラー出力がともにパイプラインで後続のコマンドに引き渡される。これを下記のようにも書けるようだ。

$ command1 |& command2

|&“は”2>&1 |“の短縮表記だそうである。是非覚えておこう。

以上。

適当なfaviconの設定

nginxにおいて表題の通り。

■ 環境

  • Nginx 1.12.2
  • Amazon Linux

■ favicon

faviconへのアクセスログが大量に出ているので制御したい。設定ファイルに下記を記載する。

location = /favicon.ico {
    access_log off;
    return 200;
}

これでアクセスログが平和になった。

ブラウザに適当な画像をキャッシュさせ、アクセス自体を減らしたければ先日の”empty_gif“を用いて下記のようにすることもできる。

location = /favicon.ico {
    access_log off;
    empty_gif;
    return 200;
}

ただしこれを設定すると、ブラウザのタブ上でも何もアイコンがなくなるので少々わかりづらい。気にならないのであれば構わないが。

以上。

■ 関連

empty_gif

ELBのヘルスチェックログを出力しない

Chrony on Amazon Linux

表題の通り。先日の”Amazon Time Sync Service“の続き。

■ 環境

  • Chrony 3.2
  • Amazon Linux
  • AWS EC2

■ Amazon Time Sync Service

先日は”Chrony“をUbuntuで入れた。今回はAmazonLinuxでやってみる。

$ ps -ef | grep ntp
ntp       2571     1  0 Nov18 ?        00:00:01 ntpd -u ntp:ntp -p /var/run/ntpd.pid -g
$

`ntp`が動いているのでこれを停止する。

$ sudo service ntpd stop

chronyをインストール。

$ sudo yum install chrony
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main                                                                                                       | 2.1 kB  00:00:00
amzn-updates                                                                                                    | 2.5 kB  00:00:00
Resolving Dependencies
--> Running transaction check
---> Package chrony.x86_64 0:3.2-1.22.amzn1 will be installed
--> Processing Dependency: libseccomp.so.2()(64bit) for package: chrony-3.2-1.22.amzn1.x86_64
--> Running transaction check
---> Package libseccomp.x86_64 0:2.3.1-2.4.amzn1 will be installed
--> Processing Conflict: chrony-3.2-1.22.amzn1.x86_64 conflicts ntp
--> Finished Dependency Resolution
Error: chrony conflicts with ntp-4.2.6p5-44.34.amzn1.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
$

`ntp`とconflictしていると怒られた。というわけで`ntp`の削除を実施してから再度実行する。

$ sudo yum remove ntp
 :
$ sudo yum install chrony

あとは前回と同じように設定を入れ込む。

server 169.254.169.123 prefer iburst

設定ファイルはUbuntuの時とは違い、下記にあった。

/etc/chrony.conf

またサービス名もUbuntuの時は”chrony“であったが、こちらでは”chronyd“であった。ansibleのplaybookにする時等はいつものように注意が必要だ。

$ sudo service chronyd start

以上。

■ 関連

Amazon Time Sync Service

logrotate: ALERT exited abnormally with [1]

表題のメッセージが”/var/log/messages“に出力されていた。

■ 環境

  • CentOS 6.9

■ logrotate

最近変更はしたが、変更時には下記コマンドで確認していた。

$ logrotate -d [変更したファイル]

上記でエラーが出ていないことは確認していたのだが、今回このメッセージが出ているのは何故であろう…。いつから出力されているのかまでは追っていないがとりあえず現状で問題が無いかを確認する。

まずは直近で変更したファイルを元にlogrotateされる対象のファイルが、現在正しくlogrotateされているかを確認してみると問題なくされていた。続いてコマンドで確認する。

$ logrotate -vd /etc/logrotate.conf

上記にて、直近で変更したファイルだけでなく全てを対象として確認したのだが、目で見る限りエラーのような箇所はない。下記コマンドでも確認したが何も見つからない。

$ logrotate -vd /etc/logrotate.conf |& grep ^error
$

しばらく様子を見ることにする。

以上。

sshdが起動しない

AWS EC2において表題の件に陥った。

■ 環境

  • AWS EC2
  • Amazon Linux

■ 接続できない

「SSHで接続できなくなった」

と相談を受けた。話を聞いてみると「/var を全て削除した」という事をやったらしい。状況がおかしいのでManagementConsoleからインスタンスを再起動してみたりもした。とのこと。

該当のインスタンスを停止し、EBSをデタッチ。別途復旧用のインスタンスを起動し、デタッチしたEBSを復旧用のインスタンスにアタッチ。復旧用インスタンスにSSHでアクセスし、アタッチしたEBSを`mount`する。そして中を確認した。

ログファイル等を見ているとsshdが起動した形跡がない。”/var/log/secure“が空っぽのままであったので”/etc/init.d/sshd“にログを仕込む。先ほどの手順を逆に行い、該当のインスタンスを起動してみるも、やはり`ssh`での接続はできなかった。

再度復旧用のインスタンスでEBSを`mount`して仕込んだログを見ると下記のメッセージが出力されていた。

failed to run commands: exit status 255
Missing privilege separation directory: /var/empty/sshd

とりあえず該当のディレクトリを作成し、再度インスタンスを起動したところ`ssh`での接続ができるようになった。

念のため、”openssh-server“を入れ直すことにしたのだが、”/var“を削除したことによって`yum`のデータベースも削除されてしまったのだろうエラーとなる。ので見た目だけではあるがインストールした。

$ sudo yum install openssh-server

他にもエラーが残っている気がするが、とりあえずの復旧としては終了。

以上。