個人的なお気に入りの場所・ツボにはまった場所を紹介
計算機とか
このところ、どうもFTPの調子がうまくない。ローカルのくせに(汗)。
brute-force対策のためにiptablesで制限をかけているせいかと思って、試しにACCEPTに戻したところ、調子を取り戻したが、しかし油断すると、複数ファイルのうち1個が詰まったりする。要調査だ。
おまけに今晩はWebまで応答しなくなってしまった。sshもDNSもメール転送もちゃんと動いているし、CPU負荷も全然だし、いつぞやみたいにスワップアウトしているわけでもない。とりあえずhttpdをリスタートしてみる。ファイルシステムにエラーがあるのは関係ないと思うけど、こちらも要調査。
WordPressの「ギャラリー」は、画像投稿の手間を極限まで省いてくれる悪魔の機能(笑)だが、ほっとくと投稿単位でアップロードした全画像が表示されてしまうため、各所で少しずつギャラリーを表示するという使い方が、GUIだけではできない。
実は半分諦めて、手作業でテーブル組んで1枚ずつ貼り付けようとしていたところ、GUIでは設定できないオプションがたくさんあることを発見。考えたら後発の私が不便だと思うぐらいだから、とっくに対処されていたとしても不思議ではない。
投稿にアップした画像の一部だけをギャラリーに出すには、include="mm,nn,…"オプションを使う(数字は画像のID)。
これを使えば、同じ投稿上に複数のギャラリーを分散配置することも当然できる。
ギャラリーの挿入は、テキスト編集のフォームでを書くだけなので、こりゃ慣れたらGUIの方は使う必要ないな。もちろんメディアファイルのアップロードには必要だけど。
参考までに、他のオプションを含めた一覧を記す(バージョン3.0.1現在)。
columns="n"
|
横方向の列数(GUI設定可) |
id="nn"
|
投稿ID指定(指定がない場合は現在の投稿でアップロードされたメディアが対象) |
size="{thumbnail|medium|large|full}"
|
記事内に表示する画像サイズ(実際のサイズは設定による) |
orderby="[menu_order][ID][title][rand]"
|
画像の表示順序を決める要素 |
order="{asc|desc}"
|
画像の表示順序(昇順/降順) |
link="file"
|
画像をクリックした時に画像表示(指定しない場合はパーマリンク表示)(GUI設定可) |
include="mm,nn,…"
|
表示画像のIDを指定 |
exclude="mm,nn,…"
|
表示しない画像のIDを指定 |
ソースコードのバックアップに長いことxcopyを使っているけど、.asmがバックアップされてないことにいまごろ気づいた。
もっとも滅多に変更せんコードなので、相当前の丸ごとzipから助けることができて、まあヒヤリハットレベル止まり。
原因は、除外リストに".a"を登録していたこと。部分一致ってそういうことだったのね(汗)。
さて現実問題として、*.aを避けながら*.asmをxcopyするにはどうするか?
…従来のxcopyに続いて、*.asmだけのxcopyを実行するのが正解、かも。よりスマートな方法としては、二次生成ファイルは全部workとかのディレクトリ下にまとめて一網打尽、でもいいかもしれない。
他にもバックアップすべきファイルが漏れてないかどうかWinMergeしたが、それでも開発環境を変えたり、除外リストを修正したりする可能性を考えると、本質的な解決にはならんのがつらい。
前記事の『マウントしたままチェックのみ』を大マインさんサーバでも試してみたら、果たして"/"にエラーがあると言われた(汗)。
修復を試みるには、どのような手段であれサーバを停めるしかない。/rootに逃げて"/"をアンマウント、ってできるかもしれんけど、どうせサーバ機能が停まるんなら単純にリブートして自動でfsckを走らせる方が楽であろう。
ただ、リブートして修復に失敗して起動しなくなるのが怖い。コンテンツとログは別ドライブなので、ディスクイメージをリストアすればいいところだが、clamdとかyumでインストールしていた時期のものだからなぁ(汗)。最悪数時間単位で停まるかもと思えば、サーバがヒマな時間帯といえどもおいそれとはリブートしづらい。タイミング見極め中。
…は、いろんなことが起こる。
といっても、別に感傷的な話でも何でもなく、cron.monthlyのことである(笑)。
先日、3つあるボリュームを順繰りにアンマウント→fsck -f→マウントする、っていう内容のスクリプトをcrom.monthlyに放り込んだところ、本日の管理者宛メールにて
e2fsck: need terminal for interactive repairs
と怒られた。修復が全自動でできないだけで、チェックはやってくれたのかなと期待したが、dumpext2fsしても最終チェック日時は変わっていなかった。
というわけで、fsck -fnに変更。でよく考えたら、チェックのみで危険を冒して一時的にアンマウントする必要はないので、アンマウント→マウントの処理は取り消した。
…これなら、cron.weeklyで全ボリュームやってもいいかもしれん。というかマウントしたままなら営業時間中にでもできるということで、コンソールから手入力でfsck -fnをやってみたがdumpext2fsのチェック日時が変わらない。はて?
