Dockerfileの中で永続化が必要なディレクトリ（ボリューム）としてVOLUMEを指定すると、-vまたはvolume:で明示的にマウントしないと匿名ボリューム（名前なしのボリューム）が作られます。匿名ボリュームが起動する度に新しく作成されるので放っておくとどんどん溜まります。
どのコンテナが匿名ボリュームを作っているのかはdocker inspectで判別出来るのですが、何度も、何度も、手動でやっているので今動作しているコンテナ全てのボリュームのマウント状態をダンプするスクリプトを作りました。（コンテナとDockerfileを見つけて明示的にマウントする方法もあるがこの方法は他人が書いたDockerfileだと探すのが面倒すぎる）
(さらに…)なんだかやけに長い説明ばかり検索に引っかかったので書きました。
Linuxのローカル環境でDockerコンテナ内のXアプリ（GUIアプリ）を利用するには
$ xhost localhost +
を実行した後に
$ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path
とすれば良いです。
(さらに…)SSHなどよく知られたサービスポートで何も対策せずにいると数えきらないくらいの攻撃リクエストが来ます。不必要なログを増やしてリソースを無駄にし、もし不用意なユーザーやシステムがあると攻撃に成功する場合もあります。
SshguardはC作られており、flex/bisonのパーサールールを足せば拡張できますがカスタム版をメンテナンスするのも面倒です。必要なルールを足してプルリクエストを送ってもマージされる可能性の低いです。
Fail2banはPythonで作られていてメンテナンスも比較的容易です。しかし、削除された機能を使用しておりメンテナンス状態も良くないです。今のPythonで動くようにしても良いのですが、Fail2banは無駄に大きいです。そしてPythonはあまり速くもないです。
Webアプリも放置していれば攻撃できるか試し放題です。OWASP TOP 10 A09:2021-Security Logging and Monitoring Failures に準拠するにも「ほぼリアルタイム」のIPアドレスブロッカーが欠かせません。 A9:2021に対応するにはブロックツール以前に、Webアプリ攻撃ツールなどが生成するリクエスト（入力）を検知し記録しなければなりません。このためWebアプリの入力を厳格にバリデーションする必要があります。
参考：
（注意： A9:2021はWAFを導入するという基準ではないです。Webアプリが攻撃（≒無効な入力）を検知・記録・対応する機能がないと脆弱なWebアプリだとする基準です、念の為）
という事で簡単に拡張（どんなログでもパースしてブロック）できて、300行ほどの一つのスクリプトでそこそこ速く、簡単にカスタマイズできるIPアドレスブロッカーを書いたのでgithubに入れておきました。
https://github.com/yohgaki/ssblocker
(さらに…)Alpine Linuxは軽量Linuxディストリビューションの一つでカスタムDockerコンテナのベースイメージに使っている人も多いと思います。Dockerコンテナで複数サービスを起動したい場合、プロセススーパーバイザーを使うのが常道です。DJBのdaemontoolsなら小さく軽量で良いのですが、Pythonで実装されたSupervisordは軽量コンテナにする意味を台無しにするくらいに色々インストールする必要があります。
インストールするパッケージ／プログラム数と管理項目を最小限にしたいミニマリストなら、Alpine Linuxの起動プロセス管理ツールのOpenRC（昔ながらのSysV Initスタイル）を使いたいと思うハズです。私もその一人でしたが、検索してもどう構成すれば良いのかズバリ説明しているページを見つけられませんでした。
ということで、Alpine Linuxなどに付属するOpenRCを使ったDockerの起動プロセス管理の基本を紹介します。
(さらに…)大抵のシェルスクリプトはセキュリティ対策を考慮する必要がないので与えられたパラメーターはそのまま利用されています。シェルスクリプトを利用して権限の無いユーザーが勝手なコマンドを実行できないようにするにはエスケープが必要になります。
このようなスクリプトで
この場合はエスケープ（やバリデーション）が必要になります。
(さらに…)Fedora34になりGnome40になった事により、今まで縦スライドで仮想画面がスライドしていたの横スライドする仕様（WindowsやMacOSと同じ）になりました。
これがどうにも使いづらい。今の横長モニターなら「これでしょ？！」と思います。
Fedora 33にアップグレードした時にも直したのですが、Fedora 34でも同じように今まで使えていたネットワークプリンタがアップグレード後使えなくなりました。
デフォルトのnsswitch.conf設定だとmDNSを参照しないで名前解決する事が原因。
(さらに…)VMwareゲストのFedora 33が起動しなくってしまい直す事にしました。原因は今一つ判っていないのですが、ホストのFeodra 33のカーネルに外れがありシステムが連続してフリーズしたりことがあります。恐らくこれが原因でしょう。
どうせテスト用なので再インストールでも良かったのですが、直せる物は直すということで直しました。
(さらに…)gmailの仕様が変更され自己署名証明書が使えなくなりgmail設定の「アカウントとインポート」で設定したメールアドレスからの送信が使えなくなったようです。結構困っている人が多いようですが判ってしまえば直す方法はそれ程難しくありません。
エラーメッセージで検索するとどうもこの4月くらいから仕様変更されているようです。qmailを使っているのでqmailでの修正方法です。postfixなどでもやる事はあまり変わりません。
(さらに…)FedoraでGnomeを使っているのですが、幾つか前のFedoraメジャーバージョンアップ後からスクリーンロック後にGnome Shellがクラッシュするようになってしまいました。放っておけばそのうち直るだろう、と放置していたのですが直る気配がないので調べてみました。
(さらに…)
手っ取り早くリモートのLinuxマシン（私の場合はVMwareの仮想マシン）からDockerイメージを作りたくなったのでその手順です。
最低限の手順なのでサービス（nginxやhttpd）を動かしたい場合はカスタマイズが必要です。不必要なファイルもコンテナに入るので、サイズを小さくする場合は適当にファイルを削除してください。
きっちり作るにはベースOSに必要最低限のパッケージだけ入れたコンテナを作り、そのコンテナに必要なパッケージを入れて作ります。しかし、コンテナが大きくても構わない、アップデートをベースのコンテナとDockerfileのビルドで行わなくても構わない、といった際にサクっと作るには便利です。
PostgreSQLを使うならZFSで決まりです。数値で明らかです。ZFS以外を使うのは論外なくらいの性能差があります。
Fedora（Linux）でボリューム管理、スナップショット、圧縮、RAID5以上の性能と可能性を持つファイルシステムで”安定しているファイルシステム”となるとZFSしかありません。
機能的にはBtrfsも同等の機能を持っています。しかし、少なくともこのブログを書いている時点では、RAID56はカーネルがクラッシュした場合などにファイルシステムが壊れてしまう問題があります。2017年8月に修正パッチが提案されていますが、12月現在でも運用環境では使用しないように、と注意書きがあります。
ZFS, Btrfsは両方ともデータの整合性のチェックが可能です。一般にログファイルシステムと呼ばれているファイルシステム（NTFS, XFS2, Ext4など）はディレクトリ情報などのメタデータの整合性をログで維持しています。ZFS、Btrfsはメタデータの整合性に加え、データ自体の整合性もハッシュでチェックしています。冗長性を持たせていない場合でも、HDDのセクタ不良でどのファイルが壊れたのか確実に判ります。
HDDは普通一気に使えない状態になりません。RAID1で冗長性を持たせていても、どちらかのHDDのセクタ不良の場合はどちらのデータが正しいのか？判断できません。ZFSやBtrfsなら、どちらのデータが正しいのか判断できます。
データ整合性の保証はZFS、Btrfsの大きなメリットです。
※ Fedora用に記載していますが、UbuntuやCentOSなど、他のLinuxでZFSを使う場合も基本は同じです。
(さらに…)ファイアーウォールで守っている、プロキシも使っている、だからインターネットからローカルネットワークは守られている！
半分あたりですが、半分はずれです。よくあるネットワークシステムではローカルネットワークはインターネットから半分くらいしか守っていません。
まだ対策をしていない場合は実施することを強くお勧めします。
クロスサイト攻撃からローカルネットワークを守ることは簡単です。簡単なので会社、特にシステム開発／運用部門は必ずローカルネットワークへのクロスサイトアクセスを禁止＆検出すべきです。クロスサイト攻撃とはクロスサイトスクリプティング（XSS）やクロスサイトリクエストフォージェリ（CSRF）の事です。基本的な対策ですが、意外に実施されていることが少ないようです。
クロスサイト攻撃はWebシステムに対するよくある攻撃手法です。少しの手間でインターネットからローカルネットワークに対するクロスサイト攻撃を完全に防止することが可能です。