その昔(15年ぐらい前？)AKI-H8/3069FのLAN付きのものを買って持ってまして、その当時はGCC4.2とか、gdb6.8とかビルドして使ってました。H8300はまだメジャーな石で雑誌などにも色々取り上げられて需要があったようです。私の仕事でもH8Sを使ってましたし。portsにh8用のgccもあったような。野良ビルドする人は当時からあんまりいないですね。

時は過ぎ去り2024年、AVRやARM、RISCVが花盛りな今、すでにディスコンなH8ですよ。野良ビルドしたのは以下のものです。ちなみにFreeBSD-14.0R上です。

• binutils-2.42
• gcc-13.2.0
• gdb-14.2
• newlib.4.4.0-20231231

gccのビルドに必要なgmp, mpfr, mpc, texinfo, gnu makeはpkgで入れます。また、新し目のNative gccも入れといてください。私はgcc12を使いました。

すでに複数gccが入っている場合は名前でソートしたときに一番前に来るものを使ったほうが良いです。ビルドするgdbがlibstdc++.so.6を要求するのですが、それぞれのgccが自分のlibstdc++.so.6を入れてくれているので、使ったgccとリンクされるlibstdc++.so.6の組み合わせが壊れて動かない、という現象が発生します(ハマりポイント)。ld.soが共有ライブラリを探す順番に影響されるのでldconfig -r で一覧を見て、一番最初にlibstdc++.so.6を提供しているgccを使う、というのが正しいです。

binutilsのconfigureです。お作法として展開したフォルダ内にビルド用のフォルダを掘ってそこでconfigureを動かします。インストール先はhomeのdev/h8300になります。

../configure --disable-nls \
 --target=h8300-elf --prefix=$HOME/dev/h8300

次にgccのconfigure。対象の言語はCのみです。CCとCXXは自身の環境のgccを入れてください。

../configure \
 --target=h8300-elf --prefix=$HOME/dev/h8300 --with-newlib \
 --disable-nls --enable-languages=c \
 --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \
 --disable-gcov --disable-bootstrap --disable-libsanitizer --disable-libssp \
 --disable-libgomp --disable-libvtv \
 CC=gcc12 CXX=g++12

次にnewlibのconfigure。ここ( https://blueeyes.sakura.ne.jp/2019/05/22/2363/ )を参考にしました。非常にためになりました。

../configure \
 --target=h8300-elf --prefix=$HOME/dev/h8300 \      
 --disable-nls --disable-werror --disable-bootstrap \
 --disable-newlib-supplied-syscalls \  
 --enable-newlib-reent-small --disable-newlib-wide-orient \
 --enable-newlib-nano-malloc --enable-lite-exit \
 --enable-newlib-global-atexit  --enable-target-optspace

次にgdbの configure。MONIX用にgdb/h8300-tdep.c内にある h8300_break_insn[] をSleep命令からTRAPA #3 { 0x57, 0x30 } に書き換えてます。

../configure --disable-nls \
 --target=h8300-elf --prefix=$HOME/dev/h8300 \
 --disable-werror --disable-bootstrap \
 CC=gcc12 CXX=g++12 

無事にgmake; gmake installが完了すると自分のhomeの下、dev/h8300/bin/h8300-elf-gccが動くと思います。あ、gdbのsimはうまく動きませんでした。

動かしてる環境ですが、MONIX ( http://kuwa.s256.xrea.com/monix/index.html )のgdb-stub(udp)でデバッグ出来てます。break張って止めるだけですが。MMCカードからの読み込み、書き込みにも成功しました。AKI-H8/3069F LAN付きは16MbitのDRAMが乗ってて、書き込み回数を気にせず Try & Errorが出来るのでお試しには重宝します。

ただ、当初の目的であるところのAVRでSDカードの読み書きが、まだできてない…

The post 2024年のGCCでH8300-elfの開発環境を整える on FreeBSD appeared first on dogmap.jp.

前回の記事から既に二か月も経過してしまっておりますが、今回の処理自体は翌日には行っていますのでご安心を。
さすがに何も処理していない生肉を冷蔵庫とはいえ二か月も放置する度胸はありません。

そんなわけで、1/31。
正直面倒くさいけど、2,000 円なんていう大枚を費やして入手した肉を無駄にするわけにはいきません。
本日は血抜きをしようと思います。
ネットを調べると、血管に沿って絞り出せとか……
生ハムの味を決める重要な工程なので、何回も行えとか色々書かれていますが、よく分からないので塩に頼ろうと思います。
きっと浸透圧様が良い感じにしてくれる筈（まあ、お肉も小さいですし……）。

そんなわけで、これが買ってきたお肉です。

どうです？　色気すら感じてしまうようなこの外見。




あーーー！　もう焼いて喰いたい。

そんな気持ちをグッと堪えて熱々のフライパンお塩を用意します。
あ、その前にアルコールスプレー様にも大活躍いただきます。
まな板やら何やら、あらゆる接触部にひと掛け。どの程度効果あるか不明ですけどね……

塩の量は結構適当。血を抜くだけですし。
そいつを全体に擦りこむ！　揉みこむ！
あーもぅ、ムラムラする。


その後はもう一回袋に戻して……


冷蔵庫にシュート！
二日目しゅう～りょ～！

……本当に完成するんかね？　これ。

The post 生ハム戦線異常事態　2日目 appeared first on dogmap.jp.

と思ったら、もうすっかり過ぎていました。
おかしい？　やるなら12月中には始めたいと思っていたのに、気が付けばもう1月。しかも……末（1/30 の出来事を記事にしております）。
ちゃんとした設備のない環境における生ハム作りは、低温時における乾燥が命！
それに失敗すると腐敗まっしぐら後悔まっしぐら……
正しくやれば発酵で美味しくなるのに、失敗すると腐敗でマズくなる。おんなじ現象なのにな～。
何はともあれ、正直乾くかどうかわからない。
でも、作りたい。
うん、作ろう。

というわけで、今回は暇な年には思わず作っちゃう生ハムの記事です。

作ると決めたら準備開始です。
皆さん、生ハム作りに必須なものって何だかわかりますか？
調味料だ何だと色々と思いつくものはあるかもしれませんが、やはり一番必要なのはやる気肉です。
しかし、肉といっても様々。鳥・豚・牛・馬……単純に干支で考えても十二種類もの候補が！
皆さん、干支ってどのくらいまで食べたことあります？
まあ、種類は流石に豚と概ねわかるところですが、豚といっても様々な部位があります。
どの部位をどのくらいどう使えばいいのか？
結論は簡単。肉屋に聞く、これに限ります。

「おっちゃん、生ハム作りたいから良いとこ分けて」

大体こんな感じで聞いていけば、物事は上手く進んでいきます。

「腿か？　やっぱ腿だろ？　良いのあるぞ、良いの」

とまあ、ノリの良いおっちゃんの店に来たので、こんな返事が返ってきました。
肉の相談をすると、実に嬉しそうに答えてくれるおっちゃん、信用できます。

さて、ここで購入者の立場は大事な事を伝えなければなりません。
それは、重さ。
いつかは骨付きの腿一本まるまる生ハムにしてみたいと夢見るものはありますが、今回はやめておくかな～。予算もあるし、そもそも仕掛が遅すぎて乾かなそうだし。
そんなこんなで今回は１キロを注文。
嬉しそうに冷凍庫に入っていったおっちゃんは、巨大な肉塊をぶら下げて戻ってきて、慣れた手つきでカットしていきます。

「見ろ！　この断面。良いだろ？　絶対美味いぞ！」

途中わざわざ肉塊を持ち上げて見せつけてくるおっちゃんに「いいですねー」と相槌。
でも、すまんおっちゃん。断面見ても全然わからん……というか、肉ってだけでどれも美味そうにしか見えん。
でも、おっちゃんのオススメなら信用してるで。
何年か前に買った時も、『これは○○農業高校で飼育されたやつだ。見ろ！　この脂身。やっぱり脂が……』云々といっぱい語ってくれたもんなー。あれも美味かったで。

とまあ、そんな感じで話を聞いたり聞かなかったり理解できなかったりしてからお会計。
１キロ概ね 2,000 円。
普段の食事に使う肉に比べるとだいぶいい肉です（ほくほく）。
……えっ？　世間的にはそうでもないのかな？

何はともあれ、お家に帰って早速……お肉を冷蔵庫にシュート！
初日しゅ～りょ～！

いや、早めに下拵えした方が良いとは思いますよ。
でも、疲れたのです。根気が続かんのです。歳なんです。

つづく（と思う）。

The post 生ハム戦線異常事態　1日目 appeared first on dogmap.jp.

買いました〜。

おかえり！　ハルヒ！

久しぶりです。

……えっ？　一月経ってない？
いや、今回は作品が久しぶりです。

いったい何年経った？
そう思わずにはいられない「涼宮ハルヒシリーズ」の最新刊、『涼宮ハルヒの直観』をご紹介したいと思います。
前回の投稿で書いた「久しぶりのもの」とはこいつのこと。でも、ホント何年だ？
最後の「涼宮ハルヒの驚愕」が 2011/06/15 とかなってますね。

いや～……意外と経ってないなぁ？　何かもっとすごーい待っているようなイメージでした。
よく考えると、そのくらい待たされている作品って結構あるような気がするし、作者生死不明みたいなのもあったりしますもんね（『マージナル・マスターズ』はどうなった！　『龍盤七朝 DRAGON BUSTER』はどうなった！！　……うん、あげたらキリがないね）。
そう考えると、まずは頑張って書いてくださった作者様に感謝！　ですね。

さてさて、褒めるだけ褒めたから後は貶すぞ（ぉぃ）。

とはいえ今回の話、個人的には結構好きですね。
何というか……戻ってきた日常感？
今までのシリーズ後半は結構話も大きくなってきて、登場人物も増え。まあ、だから良いという人も多いかとは思いますが、私は何となく付いていけないものを感じておりました。実際、シリーズは全部読んできた筈なのに、覚えているのは最初の巻と初期の頃の印象深いエピソードだけですしね。（キャラの設定考えると、話が大きくなるのは仕方と解っているのですが……）

その点、今回の巻は登場キャラもいつものメンバー＋１くらいですし、舞台もいつもの部室メインです。
怪異異常現象もほぼほぼ無くてミステリー色が大変強い感じになっています。
こういうのが意外に「このミステリーがすごい」とかの候補とかになるんじゃないでしょうか？　『古典部シリーズ』みたいに。

そんなわけで、このシリーズを読んできた方には懐かしさも込めてオススメですし。そうじゃな人も……やっぱりキャラが解ってないと全然楽しめないと思いますので、昔からの読者の方にはオススメですかね。
あぁ、薦める意味ねぇ。

The post 涼宮ハルヒの直観 appeared first on dogmap.jp.

買いました〜。

押入れ生活をやめて
学校に行ってみた。

相変わらずの終末感

アニメ化もされた『少女終末旅行』の作者「つくみず」先生の最新作『シメジ シミュレーション』をご紹介致します。

まー何と言いますか、久しぶりです。
久しぶりなので、久しぶりのものを投稿しようと思っていたのですが、急遽これを投稿します。
何故か？
本日郵便ポストを覗いたら、2巻が届いていたからなのです。
よく見りゃ半年くらい前に書いたこの記事。何やってたんだ？？？
まあ、深くは考えずにいきましょう。

主人公月島しじまは、中学一年の時に色々あって学校がいやになり、二年間押し入れに引きこもった少女。気が付けば頭からしめじが二本生えていたという、なかなかに奇抜な設定を持っています。
何？　その変な設定。と思われるかもしれませんが、相方の山下まじめは生まれつき頭に目玉焼きをのせているので、それに比べると幾分マシな気がします。まあ、慣れろってことですね、多分……

そんな主人公の周囲には役所と戦う姉や、サスマタみたいな棒を持って間違いを直すべく彷徨うオッドアイの少女。学校には、酒ばっかり飲んでいる穴掘り部の顧問の「もがわ」先生や、天才のあやかとまあ、紹介文のどこを太字にすればいいのか迷うくらいの奇想天外な方々が居ります。

何というか……帯に書かれている通り『詩的でシュールなほのぼの日常４コマ！』というのが確かに的確な……と、言いたいところですが、それだけだと何処か何かおかしい感じ。
・何処ともつながっていない完結している電線。
・あちこちにある謎のオブジェ。
・増えるシメジと、夢（？）の世界。
・そして、なま魚製造機。
とまあ、色々と不安感を煽るような要素も散りばめられています。
どことなく、『少女終末旅行』に通じるような終末感。
何かあるのかもしれない。
何もないのかもしれない。
だって、絶対雰囲気漫画ですもん～これ。
でもまあ、『少女終末旅行』の雰囲気が好きだった方々ならば、とりあえず読んでみるくらいの価値はありそうに思います。

−　おまけ　−

つか、あれはチトとユーリだったりするのん？

それでは、2巻を読み終わったらまた～。

The post シメジ シミュレーション 1 巻 appeared first on dogmap.jp.

さて Shifter Static で WordPress を起動すると、プラグインの Must-Use って所にいくつかすでにプラグインが入っていることに気づいている方もいるかと思われます。
この Must-Use というのは、/wp-content/mu-plugins/ ディレクトリ以下に入ってるプラグインは必ず有効化されるという WordPress の機能を利用しています。
詳細については Must Use Plugins を参照してください。
Shifter Static で Must Use Plugins としてインストールされているプラグインは以下の9つです。

• EVA
• Redis Object Cache
• S3 Uploads
• Shifter
• Shifter – Incompatible Plugins
• Shifter GitHub Plugin/Theme Installer
• Shifter tips
• Shifter WP Webhook
• Shifter – Artifact Helper

これらについて解説した公式文書がなかった気がするので、解説しますね。

Redis Object Cache

Redis Object Cache

WordPress が発行するクエリの結果や、Transient API の保存先として Redis を使用することができるようになるプラグインです。
Shifter Static の docker コンテナ内では Redis が動作していますので、そこに Object Cache を溜め込みます。

Shifter Static で起動した WordPress では、デフォルトでこちらが有効になっており、特に意識しなくても Redis Object Cache の恩恵を受けることができます。

S3 Uploads

S3-Uploads

Shifter Static の Tier 1 以上のプランでは、Media CDN という機能が利用できます。
これは WordPress からアップロードされるファイルを S3 バケットに直接アップロードし、Generate 時にメディアファイルを Artifact に含めないことで Generate の処理時間の短縮を行うための機能です。
また、S3 にアップロードされた画像ファイルは S3 に設定された Lambda によって自動的に WebP 形式の画像が用意され、WebP に対応しているブラウザに対しては WebP 形式で転送されるようになります。

この Media CDN 機能を実現するために、WordPress の管理画面から S3 バケットにメディアファイルをアップロードするために、この S3 Uploads プラグインが利用されています。
なお、Tier 1 以上で Media CDN オプションを ON にしている Shifter Static 以外では、このプラグインは動作しないため、メディアファイルは S3 バケットにはアップロードされません。

EVA

Shifter のための環境設定( テーマ、プラグイン、MUプラグインディレクトリの移動 )や、Media CDN オプションの有無による S3 Uploads の有効化・設定などを行います。
このプラグインは公開されていませんが、Shifter Local で配布しているコンテナ内にはありますので、ソースが気になる方はそちらを参照してみましょう。

Shifter

shifter-wp-mu

Shifter Static が動作するために必要なヘルパー関数を詰め込んだプラグインです。
動作し始めてから一定時間経った時に WordPress の管理画面に「Notice: Shifter will power down WordPress in a few minutes…」とかってメッセージ出したり、WordPress が送信するメールの From メールアドレスを変えたり、Algoria とのインテグレーションや、Redis Object Cache 用の Fix、拡張された WP JSON Rest API のエンドポイントの提供なども行なっています。

Shifter – Incompatible Plugins

shifter-incompatible-plugins

導入されたプラグインが Shifter Static での動作が保証されないプラグインリストに掲載されている場合に WordPress 管理画面に警告を出すためのプラグインです。
実際の Incompatible Plugin list は https://download.getshifter.io/incompatible-plugins.json から取得しています。

Shifter GitHub Plugin/Theme Installer

shifter-github

Shifter Static に GitHub のリポジトリから直接プラグイン・テーマをインストールするためのプラグインです。
Shifter Github Plugin/Theme Installer プラグインを公開しました

ちょっと前まで、プライベートリポジトリにあるテーマやプラグインをインストールすると、インストールはできたが、更新するとディレクトリ名がランダムな英数に変わってしまうという不具合がありましたが、ようやく直しました。
現在は、プライベートリポジトリ・パブリックリポジトリどちらでも正常に動作するはずです。

Shifter tips

shifter-wp-tips

WordPress の管理画面に Shifter のサポートドキュメントへのリンクなどを表示するためのプラグインです。

Shifter WP Webhook

shifter-wp-webhook

Shifter Static のコンテナが起動された時に指定された URL に対して POST するためのプラグインです。
以下の FAQ で説明している機能を実装しています。
[Shifter Outgoing Webhook at WordPress start] Send POST request on booting WordPress

設定によっては Shifter Static のコンテナが起動したら、パスワードレスログイン用の URL を Slack に流したりもできるので、なんかうまい使い道を考えてみてください。

Shifter – Artifact Helper

shifter-artifact-helper

Generate 対象の URL のリストを Generator に渡すための REST API を提供するためのプラグインです。
/wp-json/shifter/v1/urls にリクエストすることで、対象の URL を100件ずつ、JSON で返します。
初期からあるプラグインで Artifact 生成のヘルパーだけでなく、Shifter Static のダッシュボードから WordPress の管理画面へのパスワードレスログインやマジックリンク、メディアファイルへのリンクの相対 URL 化なども、このプラグインで実装しています。

"Redis Object Cache", "S3 Uploads" 以外の Digitalcube として GitHub で公開しているものについては、プルリクや Issue へのご意見をいつでも募集してますので、何か問題見つけたら気軽にご連絡くださいまし。

それでは、良い Shifter ライフを！

The post Shifter Static に標準で同梱されているプラグインについて ( Shifter Advent Calendar 2020 23日目 ) appeared first on dogmap.jp.

さて Shifter では、昨年末からユーザーミートアップを行なっております。
東京では、Stripe さんのオフィスを借りて２ヶ月に1度くらいのペースで実施しているのですが、このときにビールを持っていくのが通例となっております。
Advent Calendar には AWS re:Invent 参加中にラスベガスのホテルでどん兵衛食べながら、Shifter ダッシュボードに組み込むための Stripe API を叩く Lambda を描いてた話でも書こうかと思ってたんですが、そういえば愛すべきビール達のフォローアップをしてなかったなーと思いまして、今回はそんな話など。
なお、アイキャッチ画像は今年私の地元で行われた初の WordCamp "WordCamp Niigata 2019" でビールスポンサーとして参加した Shifter がビールを提供していた際の写真になります。

今まで開催された Shifter meetup には様々なボトルビールを持ち込ませていただきました。
また、アイキャッチにもある WordCamp Niigata のビールスポンサーとしてはケグとサーバを持ち込んで提供しています。
（サーバレスの Shifter がサーバでビールを提供とか面白くね？っていう発想から）
それらのビールについて、フォローアップの意味を込めてご紹介をば

志賀高原ビール (玉村本店)

志賀高原ビールは、長野県の志賀高原スキー場の麓にある玉村本店で醸されているビールです。
IPAを得意としますが、ベルジャンスタイルの山伏や、木樽熟成したビール、自家栽培の生ホップを使用したフレッシュホップシリーズなど多様なスタイルのビールを醸造しています。
Shifter Meetup での提供回数は多いかも。個人的にも一番多く飲んでると思います。
毎年３月に志賀高原スキー場で行われる Snow Monkey Beer Live は、とても良いイベントなので参加しましょう。

スワンレイクビール

スワンレイクビールは、新潟県が誇るブリュワリーです。
ただ僕の近所でボトル売ってないので、あまり Shifter meetup に持っていけてません…残念。
WordCamp Niigata では、ケグで提供しました。
最近、ケトルサワーリングのサワーエールを立て続けに出してくれててもう好きってなります。
季節限定の #B-IPA とか、クリスタルエールとか、その季節になると出してくれる美味しいビールが多いのでとても良いです。
毎年、8月始めくらいに行われるスワンレイクの周年祭は、欠かさず参加しましょう。
僕も15周年くらいから毎年行ってますが、暑い日本庭園で飲むビールが最高にうまいです。

Anglo Japanese Brewing

Anglo Japanese Brewing は、長野県野沢温泉にあるマイクロブリュワリーです。
野沢温泉内にタップルーム里武士があるので、そちらでビールを飲むことができます。
Shifter meetup には Joy Juice ver.3 などをボトルで持っていました。
こちらが去年からやっている、サワー・セゾン・バレルエイジド・ブレットビールに特化したイベント SSBB は、北竜湖湖畔で行われるイベントでちょうどいい規模感です。
時期的に高アルコールのバレルエイジドはとても良いのですが、サワーやセゾンをいただくには少し肌寒いかも。
このイベントに初めて行きましたが、ロシアのブリュワー Zagover のゴーゼと、北京のGreat Leap が最強でした。
また、飲みたいなー

京都醸造

京都醸造は、京都にあるブリュワーです。本社が神戸にある関係で関西方面に時折行くのですが、そちらにいった時は必ず醸造所に併設されているタップルームに行くほど好きです。
タップルームに行けばボトルは買えるけど、通販してないので Shifter meetup に持っていけてません。残念

うちゅうブルーイング

うちゅうブルーイングは山梨にあるブリュワーです。宇宙農民が自家栽培したホップを使ってかもす Hazy IPA は五次元フェスです。
なんだかんだで、Shifter meetup には何本か持っていってます。
ホームページで通販もやってますが、だいたい発売と同時に売り切れて切ないことになりますので、最近は千葉のちょうせいやさんか、新潟の清水酒店で買ってます。

koti brewery

koti brewery は、岡山にある空気中から採取した自然酵母で発酵しているブリュワリーです。
ホワイトエールが優しい酸味で、ランビック初心者にもオススメ。
ヘッドブリュワーがランビック好きらしいので、ゴリゴリの奴が出てくるのを楽しみにしています。
Shifter meetup でも一度持っていきました。
ちょうせいやさんとか、仙台の佐藤商店さんで時々通販で買えます。

来年も Shifter meetup では、多様なビールを紹介していきます。
お楽しみに！

The post Shifter meetup とビール ( Shifter Advent Calendar 2019 21日目 ) appeared first on dogmap.jp.

CloudFront の「Compress Objects Automatically」ってオプションを有効にすると、対応しているブラウザに対しては圧縮転送をしてくれるはずなんですが、オリジンサーバが WordPress の場合、これが有効になりません。
css とか js なんかの静的ファイルはちゃんと圧縮してくれてるんですが…

調べたところ、CloudFront で compress オプションが有効になるには、以下の条件があるようです。

• The file must be of a type that CloudFront compresses.
• The file size must be between 1,000 and 10,000,000 bytes.
• The response must include a Content-Length header so CloudFront can determine whether the size of the file is in the range that CloudFront compresses. If the Content-Length header is missing, CloudFront won't compress the file.
• The response must not include a Content-Encoding header.

Serving Compressed Files – Amazon CloudFront

これの「The response must include a Content-Length header so CloudFront can determine…」が引っかかってるんですね…

そんなわけで、Content-Length ヘッダを創出してやればちゃんと CloudFront で圧縮転送オプションが有効になります。
ob_start() と ob_end_flush() にお出まししてもらいましょうか。

このサイトは TwentyTwelve の子テーマとして作成されてるので、テーマの index.php を以下のようにしました。

View the code on Gist.

普通のテーマなら、index.php の最初で <?php ob_start();> して、最後で <?php header('Content-Length: '.ob_get_length()); ob_end_flush(); ?> すればいいかな。
まぁ、子テーマにしてテーマディレクトリに上記のような index.php を置いておく方が後々のテーマのアップデート時とか楽なので、その方がいいでしょう。

ちゃんと gzip されるようになりましたね。
[text]$ curl –head -H "Accept-Encoding: gzip" https://dogmap.jp/
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Content-Encoding: gzip
Date: Fri, 26 May 2017 07:50:25 GMT
Server: nginx
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Vary: Accept-Encoding
X-Cache-Status: HIT
X-Cached: Fri, 26 May 2017 07:50:09 GMT
X-Cache: Miss from cloudfront
Via: 1.1 2bb00e225b1b6c3d82913e7c9db706c5.cloudfront.net (CloudFront)
X-Amz-Cf-Id: cFG5SBIQJjYYWwuMHX6RV-WOt77-pTKtqoI-UwLz9c2cU1O0I6nSaA==
[/text]

現場からは以上です。

The post WordPress サイトを CloudFront で配信すると compress オプションを設定していても圧縮転送されない… appeared first on dogmap.jp.

そんなわけで、ひさ～しぶりのブログはバックドア仕掛けられないようにする防衛策とソースが改変された時の対応策です。

バックドアを仕掛けられる前の防衛策

不要な php ファイルにアクセスさせない

WordPress のバックドア仕掛けてくるやつの手順として多いのが、メディアアップロード機能の脆弱性とかを利用して wp-conten/uploads/ 以下に php ファイルを置いていき、そのファイルに対してリクエストすることで色々悪さをする手口です。
また、そのファイルが発見されて駆除されたとしても良いように wp-includes/、wp-admin/includes/ とかにファイルを置いておくやつもいます。
なので、Nginx を使ってる場合は以下の様な設定でこれらのディレクトリに置かれたファイルに対して直接アクセスできないようにしてあげると良いです。
View the code on Gist.
こうすることで、仮にバックドアを仕掛けられたとしてもある程度は防げるでしょう。

プラグイン・テーマの編集機能を殺す

あと、多いのはブルートフォースでパスワードをクラックして WordPress のダッシュボードからプラグインやテーマを編集・アップロードする機能を使用してバックドアを仕掛ける手口です。
これに関しては、define( 'DISALLOW_FILE_EDIT', true ); や、define( 'DISALLOW_FILE_MODS', true ); を wp-config.php に追加しておいてダッシュボードから作業できなくするようにすることです。
※一番の対策はクラックされないようにパスワードを単純なものにしないことなのは言うまでもありませんが….
Editing wp-config.php « WordPress Codex

ただ、これをやっちゃうと WordPress の利点であるダッシュボードからのプラグインアップデートとかもできなくなっちゃうので、運用形態にあわせて考える必要がありますね。

特定のPHP関数を無効にする

バックドアとして仕掛けられた php やマルウェアを含む php では、往々にしてソースを難読化するために eval() 関数を使っていることが多いです。
また、exec()、shell_exec()、system() などの PHP から外部コマンドを実行する関数を使用して悪さをすることもあります。
これらは、特に使用していないのなら php.ini の disable-functions 設定で無効にしておくと良いでしょう。
少なくとも、WordPress のコアソースではこれらの PHP 関数は使用していませんが、一部のプラグイン等で使用している可能性がありますので、これらを無効にする場合は自分が使っているプラグイン・テーマのソースを精査してから行ってください。
※追記: eval() は無効にできないそうです。
php.iniで関数を無効化できる。言語構造は無効化できない。ユーザー定義関数は無効化できない。

自分のサーバが SPAM 送信の配信元にされてないか確認しとく

mailq コマンドでメールキューに溜まったメッセージ数を確認できます。

# mailq | grep 'Total requests'

ただ、こんなん毎回手で叩いてもいられないので AWS 使ってる場合は、CloudWach のカスタムメトリクスを使って定期的にメールキューのメッセージ数を監視して、ある程度大きい数になったらアラート上げるようにしてあげると良いです。
カスタムメトリクスにメールキュー数をあげるためのシェルスクリプトはこんな感じ。
View the code on Gist.

これを crontab で定期的(5分に一度程度)まわしてあげれば、ある程度の監視が可能ですね。
バックドア仕掛けられて SPAM の踏み台にされてる場合には、ありえない数の mailq が溜まるはずですので。

AWS 使ってない場合は、閾値以上のメールキューが溜まってたらメールするなり Slack 通知するなりするようにしてあげればいいと思うよ。

コアソースが改変されていないかを確認する方法

コアソースが改変されていないか確認するには、wp-cli を使用するのが便利です。
wp core verify-checksums を使用することでチェック可能です。
wp core verify-checksums

$ wp core verify-checksums
Success: WordPress install verifies against checksums.

なんか改変がある時は以下のように教えてくれます。

$ wp core verify-checksums
Warning: File doesn't verify against checksum: wp-load.php
Error: WordPress install doesn't verify against checksums.

マルウェアファイルが無いか確認する方法

一番良いのはアンチウィルスソフトを使って検索することですが、手っ取り早く行うには eval() を使ってるところが無いかをざっと確認することです。

$ cd /path/to/wordpress
$ find . -type f -name '*.php' | xargs grep 'eval(' | grep -v 'doubleval('
$ find . -type f -name '*.php' | xargs grep 'eval\/'

これで、あきらかにおかしいとことが無いかがざっと確認できます。
ただ、これだけだと特定のパターンにしか対応できないので、やはりアンチウィルスソフトなどを使用するようにした方がいいです。

不幸にも改変されていたことがわかった場合に復旧させるための作業

不幸にも改変が見つかった場合は、WordPress のコアソースに関しては wp-cli を使用すれば以下の手順で正規のモノに戻すことが可能です。
View the code on Gist.
※ 1行目の /path/to/wordpress は WordPress がインストールされているディレクトリに読み替えてください。
※ 7行目の wp core download コマンドのパラメータ --version と --locale は、適宜読み替えてください。

ただし、これだけだとコアソースに仕掛けられた改変しか戻すことはできません。
プラグインやテーマについては別途作業が必要になります。

※追記
もちろん、これだけやっときゃ大丈夫って話ではないです。
セキュリティ対策には銀の弾丸はありません。あくまでも一例ということで、ご理解ください。
記事中に間違ってる記述があるとか気づかれた方は、コメント欄等で指摘していただければ幸いです。

The post WordPress にバックドア仕掛けられないように… appeared first on dogmap.jp.

あと、各種グラフは簡単な設定でログインしていないユーザにも公開することが可能です。
このサイトが動いているインスタンスの CPU Usage は、以下のURLで公開してます。
CPU Usage | dogmap.jp

AMIMOTO AMI HTTP/2版のデモサイトでも公開してますので、見てみてください。
Server Overview | HTTP2 AMIMOTO Demo

今日は、この New Relic を AMIMOTO AMI にインストールする手順を紹介します。

New Relic には Free Trial もありますが、AWS ユーザーなら以下の隠しキャンペーンページから登録することで無料で Standard プランが利用できますので、まずはここから登録しちゃいましょう。
AWS and Free New Relic SaaS Application Performance Monitoring | New Relic Partner
登録するときのメールアドレスは、たぶん AWS アカウントに登録してるメールアドレスを入れればいいんでないかな。

無事 NewRelic にログインできるようになったら、ライセンスキーを取得します。
画面右上のメニューから「Accout settings」を選択すればおっけ。
英数字40字の「License key」が記入されてますので、コピペしてください。

で、あとはサイトに書いてある手順にしたがって NewRelic System monitor とか NewRelic PHP とかをサーバにインストールすれば、NewRelic の管理画面にサーバの情報が表示されるようになるんですが、一連の手順がめんどくさいというあなたのために AMIMOTO AMI 用のワンライナー用意しておきました。
[text]$ LICENSE_KEY={YOUR_NEWRELIC_LICENCE_KEY_HERE} sudo -E -H bash -c "$(curl -sSL https://raw.githubusercontent.com/amimoto-ami/install-newrelic-client/master/newrelic_install.sh)"[/text]
{YOUR_NEWRELIC_LICENCE_KEY_HERE} ってところを、あなたの Licence Key に書き換えて実行してください。

このワンライナーは、対話式とかダサいこと言わないので EC2 をローンチするときにユーザーデータに記入しておけば、自動的に NewRelic で監視開始されまっせ。
EC2 ローンチ時にユーザーデータでシェルスクリプトを実行させる方法は、以下のURLを参考にしましょう。
Linux インスタンスでの起動時のコマンドの実行

それでは、良い監視ライフを！

The post New Relic で AMIMOTO を監視する ( AMIMOTO Advent Calendar 2015 23日目 ) appeared first on dogmap.jp.