Doa

サイトを Astro + k3s で作り直した話

Wed, 29 Jul 2026 00:00:00 GMT

このサイトは元々 HUGO で作り、その後 Next.js（tailwind-nextjs-starter-blog）で運用していましたが、このたび Astro 製のテーマ Fuwari に全面移行しました。

せっかくなので、現在の構成を最初から最後まで書いておきます。

::github{repo="saicaca/fuwari"}

全体像

記事 (Markdown)
  ↓ pnpm build
Astro → dist/ + Pagefind の検索インデックス
  ↓ docker build (multi-stage)
node:24-slim でビルド → caddy:2-alpine に dist/ だけ載せる
  ↓ GitHub Actions
ghcr.io へ push → k3s のマニフェストを自動で書き換えてコミット
  ↓ ArgoCD が Git を監視して同期
k3s + Traefik（Let's Encrypt / DNS-01）→ Cloudflare → 読者

サーバーサイドのアプリケーションは一切動いていません。配信されているのは完全に静的なファイルだけです。

ビルド

Astro なので出力は静的 HTML です。ページ遷移は Swup が担当していて、フルリロードなしで切り替わります。

全文検索には Pagefind を使っています。ビルド時に dist/ を走査してインデックスを作る方式で、検索用のサーバーが要りません。日本語もちゃんと引っかかります。

[!NOTE] Pagefind は日本語のステミングには対応していないので、語形変化をまたいだ一致はしません。とはいえ個人ブログの検索としては十分実用的です。

配信は Caddy

イメージは2段構成にしています。ビルド用に node:24-slim、配信用に caddy:2-alpine。最終的なイメージには dist/ と Caddyfile しか入っていません。

nginx ではなく Caddy を選んだのには理由があります。

Astro は trailingSlash: "always" なので、/posts/foo へのアクセスに対して /posts/foo/ へリダイレクトが常時発生します。nginx はこのリダイレクト URL を $scheme から組み立てるため、TLS を前段のプロキシで終端していると http:// へ 301 してしまうという古典的な罠があります。absolute_redirect off; を書けば回避できますが、知らないと必ず踏みます。

Caddy は相対リダイレクトを返すので、この問題が最初から存在しません。実際に確認するとこうなります。

$ curl -sI https://doany.io/posts/truck | grep -i location
location: https://doany.io/posts/truck/

ついでに encode zstd gzip の1行で zstd 圧縮まで効きます。nginx で zstd を使おうとするとモジュールのビルドが必要なので、この手軽さはかなり大きいです。トップページで 97,465 バイト → 16,264 バイトまで落ちています。

旧 URL からのリダイレクトも Caddy に集約しました。

@blogPost path_regexp blogPost ^/blog/(.+?)/?$
redir @blogPost /posts/{re.blogPost.1}/ permanent

/blog/* /tags/* /projects /feed.xml あたりが旧構成の URL なので、全部 301 で新しい場所へ飛ばしています。

デプロイは GitOps

ここが個人的に一番気に入っているところです。手元から kubectl apply を叩くことは一切ありません。

main に push すると、まず GitHub Actions がイメージをビルドして ghcr.io へ push します。そのあと同じジョブが k3s/deployment.yaml のイメージタグをコミット SHA に書き換えて、リポジトリにコミットし返します。

- name: Update deployment image tag
  run: |
    sed -i "s#image: ${REGISTRY}/${IMAGE_NAME}:.*#image: ${REGISTRY}/${IMAGE_NAME}:${GITHUB_SHA}#" k3s/deployment.yaml

そして k3s 側には ArgoCD が常駐していて、このリポジトリを監視しています。マニフェストの変更を検知すると自動で同期し、新しいイメージの Pod に入れ替わります。

つまり Git がそのままクラスタの状態になっていて、リポジトリを見ればいま何が動いているか分かります。ロールバックしたければ git revert するだけです。

ArgoCD 自体も k3s の HelmChart CRD でマニフェストとして宣言してあるので、クラスタを作り直しても同じ手順で戻せます。ログインは Entra ID の OIDC に寄せて、ローカルの admin アカウントは無効化してあります。

証明書は Traefik が Let's Encrypt から DNS-01 チャレンジで取得しています。前段には Cloudflare を挟んでいます。

シークレットも Git に置いてある

コメントシステムの署名鍵や管理パスワードといった秘密情報も、Sealed Secrets で暗号化した状態で公開リポジトリにコミットしています。

$ ./bootstrap/kubeseal.sh /tmp/secret.yaml k3s/remark42-secret.yaml
wrote k3s/remark42-secret.yaml

クラスタ内のコントローラが持つ秘密鍵でしか復号できないので、公開リポジトリに置いても問題ありません。おかげで「Git に全部ある」という状態を崩さずに済んでいます。

コメントは remark42 をセルフホスト

移行の直後は giscus（GitHub Discussions を使うやつ）を入れていたのですが、コメントするのに GitHub アカウントが要るのがどうしても引っかかりました。

そこで remark42 に載せ替えました。Go の単一バイナリで、ストレージも BoltDB のファイルなので別途データベースが要りません。AUTH_ANON=true を入れるとアカウントなしで投稿できます。

- name: AUTH_ANON
  value: "true"

k3s に PVC を持たせることになるので、その分だけステートレスではなくなりました。そこは素直にトレードオフです。

読者は匿名のままでいい一方、荒らされたときに消す人間は要ります。そこで管理者だけ Entra ID でログインする構成にしました。ArgoCD や他の内部サービスと同じアプリ登録を使い回しています。

ここで少しハマりました。アプリ登録がシングルテナントだと、既定の /common エンドポイントは使えません。

AADSTS50194: Application is not configured as a multi-tenant application.
Usage of the /common endpoint is not supported for such applications.

テナントを明示するオプションが必要なのですが、これは remark42 v1.16 以降でしか使えませんでした。アプリ登録をマルチテナント化すれば通るものの、その登録は他のサービスも共有しているので、認証範囲を広げるのは避けたい。結局 remark42 を上げて解決しました。

購読と支援

サイドバーに置いてあるやつです。

Ko-fi は、公式ウィジェットが外部スクリプトを読み込むので、ただのリンクとして実装しました。表示速度に影響せず、テーマのライト/ダークにもそのまま追従します。

Newsletter は Buttondown を使っています。当初は RSS フィードを監視して自動配信してくれる機能を使うつもりだったのですが、これが月 $9 のアドオンでした。年に数本しか書かないブログには少し重い。

一方で API は無料プランでも叩けます。やりたいことは「記事が増えたらメールを作る」だけなので、それなら自分で書けます。

そこで記事を push したときに動くワークフローを足しました。

- name: Collect newly added posts
  run: |
    # 追加 (A) されたファイルのみ。既存記事の修正では配信しない。
    FILES=$(git diff --name-only --diff-filter=A "$BEFORE" "$SHA" \
      -- 'src/content/posts/**.md' | tr '\n' ' ')

--diff-filter=A で新規追加されたファイルだけに絞っているのが要点です。これがないと、誤字を直すたびに購読者へメールが飛びます。

作られるのは下書きまでで、送信は Buttondown 側で内容を確認してから手動で押しています。慣れたら自動送信に切り替えるつもりですが、メールは取り消しが効かないので当面はこのままにします。

上流への追従

Fuwari はテーマとして使わせてもらっているので、本家の更新を取り込みたい。とはいえ毎回手で確認するのは続きません。

そこで 月に一度、上流を自動でチェックして PR を出す ワークフローを入れました。マージが衝突なく通れば PR、衝突したら PR は作らず Issue で知らせる、という挙動にしてあります。

これを成立させるために、Git の履歴も細工しています。このリポジトリと Fuwari には元々共通の祖先が1つもなかったので、そのままでは git merge upstream/main が "refusing to merge unrelated histories" で弾かれます。そこで移行時に、Fuwari の全コミットの上に自分の変更を1コミット載せる形へ履歴を作り直しました。

$ git log --oneline -3
xxxxxxx feat: Next.js 版ブログの内容を Fuwari の上に移行
6d39b0d chore(deps): bump the patch-updates group ... (#681)
415fb97 chore(deps): bump the patch-updates group ... (#648)

GitHub 上のフォーク表示にはなりませんが、フォークにしたかった目的（上流追従）はこれで達成できています。

おわりに

静的サイトなので落ちる要素がほとんどなく、記事を書いて push するだけで公開されます。コメントだけは自前で面倒を見ることになりましたが、そのぶん読者はアカウントなしで書き込めるようになりました。

ソースコードは全部公開しています。

::github{repo="DAnything/blog"}

ステーションワゴンを貨物登録して税金を安くしてみた

Wed, 06 Aug 2025 00:00:00 GMT

久しぶりの投稿ですが、最近はウェブ関係とはうって変わって車ばかりに現を抜かしております。
その関係で先日スバルレガシィ(3ナンバー)を貨物登録(1ナンバー)してきましたので、その方法等を書いていこうと思います。

貨物登録とは

まず貨物登録とはなんぞやという話ですが、自動車検査証(車検証)に用途という項目があります。ここの項目を乗用から貨物に変更して適用される税区分を変更しようというものです。
詳細な税制度に関してはここでの説明は省きますが、今回貨物登録した車両では下記の通り税金が変わります。(旧の重量税, 自賠責は24ヶ月分を2で割っています。)

	旧	新
自動車税	51,750	8,800
重量税	22,800	8,200
自賠責	8,825	16,900
合計	83,375	33,900
差額	0	-49,475

上記の通りかなり安くなりますが、いくつかデメリットもあります。
大きなものだとETCの利用料金区分が普通から中型になり、料金があがります。ただこちらは年間差額5万円以上出るような使い方をしないかぎり問題はありません。もう一つが、車検が一年に一度になることです。こちらは年に一回検査手数料を払う費用が増えますが、たかだか2000円程度です。車検をディーラーやショップに預けている方もいるとおもいますが、日本車でしたらほとんどメンテナンスなんてしなくても車検はとおります。そもそもこの記事を読みに来ている時点で維持費を節約したい方だと思うので、維持費を抑えたいなら自分で整備道具を買ってネットで検索して車を維持するための最低限のメンテナンス方法ぐらいはぐぐりましょうそれができないならおとなしくディーラーの言いなりでお金を払いましょう。そのためのサービス料です。

貨物登録の流れ

車庫証明の取得

こちらは貨物登録には関係ないのですが、車両の名義を変更するのに必要です。
今回の場合下記書類を私が借りている駐車場の場所の管轄の警察署に提出しました。管轄警察署等は各県警によってホームページなどで公開されています。無い場合は直接電話して聞きましょう。

自働車保管場所証明申請書(2通(キャッシュレス等で印紙が無い場合は1通))
保管場所の所在図・配置図

上記2種類の書類は下記のページ内のXLSXファイルをパソコンで編集して提出しています。手書きである必要はありません。
保管場所証明申請手続

保管場所使用承諾証明書

こちらに関しては要件(貸主、借主、契約日、契約満了日など)を満たしていれば駐車場の賃貸契約書等で可能な場合があります。
自分はいつも駐車場の賃貸契約書のコピーで申請しています。自分の契約書が使えるかどうかの確認は警察署に問い合わせてみるといいでしょう。

参考: 保管場所（車庫）の要件と使用権原書面

仮ナンバーの取得

今回通した車ですが、購入時にすでに一時抹消されていたため仮ナンバーを借りにいきました。こちらがないと車両を車検や車検整備のために回送することができません。
仮ナンバーを借りるためには自賠責保険の加入が必要なのですが、今回購入した車がすでに自賠責が切れていたため商品自動車の契約で5日間だけ加入しました。
以前は抹消した状態の車種で1か月で自賠責が発行できたのですが、自賠責保険規制強化があったらしく現在は仮ナンバーを借りるという用途の場合商品自動車という形で5日間の契約しかできないようです。
また、自賠責代理店によっては商品自動車の契約の取り扱いが無い場合があります。陸運局事務所の敷地内や近くにある行政書士法人や、保険会社の支社などであれば確実に契約できます。カー用品店等では取り扱いがありませんでした。
自賠責に加入したら最寄りの市役所や仮ナンバーの貸し出しを行っている支所等に向かい仮ナンバーの貸し出し申請を行います。このとき最大貸し出し期間が5日なので上記の車庫証明の発行と後ほど記載する事前審査が完了してから借りに行くのをおすすめします。

貨物登録の為の改造

貨物として認定される基準

まず自動車等はどのようにして用途ごとの検査基準を設けているかというと、国土交通省からの政令によって決められています。
道路運送車両法で定められているんじゃないのという疑問を持つ方がいるかと思いますが、道路運送車両法には大まかな内容しか書かれておらず、その内容の解釈などを別途政令で定めています。
時代によって自動車の技術などの入れ替わりは激しいのでこのような形態を取っているというのが建前ですが、結局は関係各所とよろしくやるための制度だと思います。
貨物自動車として検査に通すための基準は下記の様な内容になります。政令から抜粋して平易な表現に書き換えています。

積載設備の床面積が1m2以上あること
乗車設備の床面積より積載設備の床面積が大きいこと
乗車設備の乗員重量より積載重量のほうが大きいこと
物品を積み下ろしする開口部が縦横800mm*800mm以上かつ投影面積が0.64m2以上であること
乗員と積載設備との保護仕切りがあること

※ 乗車設備とは2列目以降のことです運転席がある一列目は含みません

参考: 自動車の用途等の区分について（依命通達）

この政令に書かれていることの他NALTECが別途審査委事務規定というものを定めており、政令に書かれていない箇所に関してどう扱うかを明記しています。
国でも無い機関が勝手に法律、政令を解釈していいのかという疑問をいだきますが、節約のために飲み込みましょう。
下記が貨物登録するにあたって追加の条件となる規定です。不要な部分はカットしています。

第 4 章自動車の検査等に係る審査の実施方法
4-17 貨物自動車の審査
4-17-1 用途の判定
（2）乗用自動車（車体の形状が箱型、幌型又はステーションワゴンのものに限る。）として認証を受けた四輪以上の指定自動車等及びこれらの自動車に対し「指定自動車等と関連」に区分される並行輸入自動車の乗車人員の携帯品の積載箇所は、用途区分通達における物品積載設備とは判断しない。
ただし、車体の形状がステーションワゴンのもの（ステーションワゴン以外の自動車であるが別添 3「並行輸入自動車審査要領」6.2.7.を準用した場合にステーションワゴンと分類できるもの又は幌型の自動車であって座席後方の幌が車両の最後尾附近まであるものを含む。）に限り、後部座席等の取外し（座席定員の設定が複数ある状態で認証等を受けたものについて、後部座席等の取外しを行った状態のものと同様な状態で認証等を受けたものを含む。）又は床面への格納固定を行い、これによってできた床面及び当該床面と連続した乗車人員の携帯品の積載箇所については物品積載設備とするものとする。参照: 第4章自動車の検査等に係る審査の実施方法

上記を要約すると下記の様になります。

箱型、幌型、ステーションワゴンの最初からついてる荷物置き場は用途区分通達における物品積載設備とは判定しません。
ステーションワゴンもしくは並行輸入自動車審査要領6.2.7.を準用してステーションワゴンと分類できるものは座席の取り外しや収納などをしてできたスペースと最初からあった荷物置き場を合計して物品積載設備とみなす。

実際の改造箇所

上記要件を満たすために今回行った改造を書いていきます。

物品を積み下ろしする開口部が縦横800mm*800mm以上かつ投影面積が0.64m2以上であること

こちらに関してはメジャー等で計って800mm以上あれば概ね問題ありません。この時荷室の高さではなく開口部の高さなのに注意してください。

積載設備の床面積が1m2以上あること
乗車設備の床面積より積載設備の床面積が大きいこと
乗車設備の乗員重量より積載重量のほうが大きいこと

今回は2列目シートの右側を倒した状態で固定(NALTEC事務要領に格納固定とあるので固定が必要です)し荷室面積を増やすことにしました。
固定の方法ですが、ヘッドレスト用の穴にボルトをいれチェーンを繋ぎ座席の下にある座面を固定するストライカーとそのチェーンをつなげて固定しました。外すのが容易ですが、一般的にはこの状態でも固定と言えると思います。
また、検査員によっては平床であることを言ってくる検査員が居ますが法律、政令上平床である必要はありません。
先ほど参考にも記載した自動車の用途等の区分について（依命通達）の注2(2)にタイヤえぐり、蓄電池箱等の占める面積は、物品の積載に支障がない限り物品積載設備の床面積に含めるものとする。という記載があります。
こちらを読み解くとタイヤえぐり等の湾曲部が存在する箇所であっても物品の積載に支障が無い限り積載面積とするという風に書かれています。物品というのがここでは定義が記されていなく砂利などの可能性もあるため平床にしなくても問題ないと解するのが妥当だと思います。

乗員と積載設備との保護仕切りがあること

100均などで売っている棚に使うような金網を買ってきて90度曲げて倒した座席の下に差し込みました。
検査を通す際検査官にボルトなどで固定していないと指摘されたのですが、その際自分はボルトで固定されていてもボルトを回せば外れるので構造的に優位な差はありませんよね？と返したところその検査官はブツブツと言いながらどこかに消え検査が無事通りました。
またそもそも保護仕切りに具体的にどういった固定方法が必要かなどは指定されてないので一般的なバンなどに付いているつっかえ棒のようなものでもいいはずです。
このようにNALTECが行う保安基準適合検査とは、検査官の恣意的な判断が多く検査当日は、実際の政令や理論をしっかり理解し検査官を言い負かせる様になっておいた方が良いです。
そもそもNALTECの職員は道路運送車両法にある通り基準適合性審査結果を書面をもって国土交通省に通知することとなっています。つまり道路運送車両と国土交通省政令に沿って作成された事務要領などに反する内容を審査結果に記載した場合虚偽有印公文書作成に当たる可能性があります事実過去に起訴猶予になりましたが、摘発事例があります。
そういった話をしても埒が開かない場合、検査処分に関しては行政行為の一部だと思いますので、審査請求等も手だと思います。

最大積載量に関して

貨物登録するにあたって下記のような規定があります。また前記の部分で乗車設備の乗員重量より積載重量のほうが大きいこととあったと思います。
また、乗車設備とは前席を除く箇所と政令に規定がありさらには積載量は50kg単位での計算とするNALTECの規定があります。
総合すると100kg以上で同一類別区分中の最大の車両総重量を超えない範囲となります。
今回の場合座席を格納固定しただけなため同一類別区分中の最大の車両総重量(これはメーカーかNALTECに問い合わせればわかります)を超えてしまう場合があります。
そのためスペアタイヤなどの取り外しが必要になります。それでも足りなければ車載工具やラゲッジボード、カーナビ類内装等外してみてください。

オ指定自動車等のうち、車両総重量及び軸重の許容限度が明確でないものにあっては、同一型式の類別区分中の最大の車両総重量を超えない範囲内で指定する。カアからオまでに規定する自動車以外の自動車にあっては、取外した乗車設備分の定員数に55kgを乗じた重量を超えない範囲内で指定する。参照: 7-124、8-124 最大積載量

今度は下記規定を見てみてください産出される物品の積載量のうち最大のものとするこちらの記載を根拠に積載量を総重量のうち最大で取るようにNALTECから言われます。
ここで問題になるのは積載を最大に取った結果車両総重量が2トンを超えてしまうことがあるということです。2トンを超えると重量税が高くなるためなるべく軽くなるように収めたほうが良いと思います。
例として仕様上の最大車両総重量が2040kgで測定結果車両重量が1895kg+100kg=1995kgの場合と1890kg+150kg=2040kgの場合を例に出すとわかりやすいでしょうか。
この場合軽くしすぎてしまうと重量税が増えてしまうため微妙な調整が必要です対外はラゲッジボードの有無や内装部品の有無で調整できます。
まだ実現可能か未検証ですが、最大車両総重量が2090kg等どう頑張っても2トンを超えてしまう車両は一回2トン超えで登録し、座席の完全な撤去や内装部品の取り外しで重量を軽くした場合総重量2トン以下にできるのではないかと考えています。

（1）自動車の最大積載量は、本章の規定に適合して安全な運行を確保し、及び公害を防止できる範囲内において積載することができるものとして、（2）から（11）までの基準に基づき算出される物品の積載量のうち最大のものとする。

事前審査

2025年4月時点で規定が改正され、一部構造変更などで事前審査が不要になる旨が明確化されました。
今までの規定でも読み方によってはステーションワゴン->バンなどの場合は事前審査が不要な様に読めますが、おそらく各地域のNALTEC事務所ごとに解釈の違いがあり、問題になるのを避けるための改正だと思われます。
そのためこの章は不要になりますが、また今後書類審査が必要になる可能性も0ではないため残しておきます。
審査事務規程の一部改正について（第63次改正）

2024年10月28日より書類提出がオンラインでできるようになりました。ただし一部書類はこちらで用意してからアップロードする方式なので書類を一式用意してから申請を行うことになります。
審査の回答まで提出してから最大で15日かかります。ですので車庫証明などを発行してしまった場合早めに提出したほうがいいです。(車庫証明の有効期限は1か月程度)また自分の場合は書類提出した際に事前に車庫証明の有効期限が近いことを伝えると早く処理していただけました。

提出手順

こちらのサイトでアカウントを作るログイン->アカウント登録で作れる
アカウントを作りログインしたら新規検査届出をクリック
届出の作成をクリック
下記の通り選択、記入し次へをクリック
1. 届出方法選択: 個別届出
2. 附則: 技術基準等の審査を要する自動車、自動車予備検査証の交付を受けた自動車又は使用の過程にある自動車若しくは特定の大型特殊自動車
3. 区分: 3.2.（1）技術基準等の審査を要する自動車
4. 届出先: 検査を受ける検査事務所を選択してください
5. 車名、型式、車体番号: 車検証の通り記入してください
新規検査等届出書（第１号様式）（その１）は下記の通り記入する
1. 類別区分番号又は車両仕様記号: 類別区分番号を選択入力欄に車検証に記載のある類別区分番号を入れる
2. 当該型式・類別区分番号の指定自動車等に対して変更している自動車の構造・装置
  1. 構造・装置の変更有無: 有を選択
  2. オプション: （記入欄のとおり）を選択
  3. 記入欄: 下記の通り入力(現在の仕様に合わせて適宜書き換えてください)
```
乗車定員の変更（5人→3人）2列目右側座席固定  
用途変更（乗用→貨物）  
車体形状の変更（ステーションワゴン→バン）
```
  1. 騒音防止装置に係る構造・装置の変更有無: 無
  2. 騒音防止装置に係る過回転防止装置の有無: 無
新規検査等届出書（第１号様式）（その２）にアップロードする書類はNALTECが配布するwindowsアプリケーションで作成できます。下記リンクからzipファイルをダウンロードしbinフォルダ内のInitPreEntry.exeを実行すると起動します。
- 新規検査届出書第一号様式2
- 入力する内容は実際に車両を測定するかメーカーに問い合わせて諸元表をもらえばできます。
- 計算が要る部分に関しては、NALTECの事務所で重量分布計算書というものがもらえる場合がありますが、場所によって対応が異なる場合があるようです。ですので自動で計算するexcelを当方で作成いたしました。少しお値段すると思いますが、購入いただければ他の書類の記入方法に関してもお答えします。
- 重量分布計算書
自動車を特定する書面は登録識別情報等通知書のスキャンデータをアップロードする
諸元表又は車両諸元要目表はメーカーに問い合わせた諸元と外観四面図をアップロードする
技術基準等への適合性を証する書面は下記書類をアップロードしてください。内容は自分の車に合った計算をして記載してください。
- サンプル入力済みのwordファイル保安基準各条項の技術的要件の適合性に関する書面
その他書面には下記をアップロードしてください
- 横からの画像に車両全長を記載
- 前方からの画像に全幅を記載
- 後方からの画像に全高と荷室の全高と開口部の高さ
- 座面を固定および荷室との仕切り壁がわかる画像

キャッシュレスの登録

2023年1月より検査登録に必要な支払いをキャッシュレスで行えるようになりました。
下記より支払い情報の登録が行えます。
くるまの保有関係手続お支払い情報登録サービス

支払い情報登録の際手続きの種類を中古新規にしてください。そうしないと後で手続きの種類を変更することができないので、車検証発行の段階で現金で払うことになります。
車検が残っており一時抹消などで税の還付を受けない場合は構造変更を選択してください。
自賠責だけは別になるので自賠責分だけ現金を用意する必要があります。カー用品店等ではカードで自賠責が買えるためそちらで発行するのも手です。
また、ナンバーセンターでのナンバープレート発行費用及び記念所蔵時の穴あけ料についても現金になります。

検査当日

検査当日までに下記サイトから予約が必要です。予約時検査種別は一時抹消済みであっても構造等変更検査になります。
ただし、場所によっては予約が非常に取りにくいことがあります。
その理由として、一部の事業者が複数台分の予約枠を確保し、当日来なかった車両分だけをキャンセルするという運用をしているケースがあるためです。こうした行為には特にペナルティがないため、予約枠が埋まってしまうことがあります。
また、上記のような運用している事業者は当日予約をキャンセルすることが多いため当日に予約が空くこともあるので当日早朝及び第一ラウンド検査中などに見てみるのも手だと思います。
自動車検査インターネット予約システム

当日の流れですが、大まかには下記のようになります。細かいところは陸運局ごとに違うと思いますので、省略させていただきます。
またキャッシュレスの登録をしなかった場合当日書く書類が2,3枚増えますのでできるだけキャッシュレスでの手続きをおすすめします。下記手順では現金の場合の手続きを省いています。

検査受付書類を印刷するPCが登録事務所の検査受付窓口の近くに在るので、車検証のQRをスキャンして受付書類を出す
通常の継続検査レーンで検査を受ける
審査書類を提出した検査小屋で審査書類をうけとる※事前審査をしてない場合は不要
新規検査用のレーンで車重などを量る
普通貨物で自賠責を加入する
中古新規および構造変更どちらの場合でも一号様式に記入し登録窓口に提出する
税申告書を記入し税申告窓口に行き書類を提出する
ナンバプレート窓口でナンバープレートを受け取る(元々のナンバーが付いている場合は外してから)
ナンバープレートを取り付けし封印をしてもらう

まとめ

行政手続きや政治、法律のプロではないのでブログの内容や私の考えに間違いなどあるかもしれませんが、その辺りどしどしコメント頂けると助かります。今回節税するために貨物登録を行いましたが、そもそも現在の税制はあまり受益者負担になっていなのではないかと言うような疑問やNALTECや警察組織の思惑ばかりで本当に安全な交通社会に寄与できるような規制になっていないのではないかなどの疑問が私の場合は残りますが、その辺り皆さんはどう思われますでしょうか。

Mercedes NTG ATAロック解除メモ

Sat, 25 May 2024 00:00:00 GMT

下記で紹介されているxboxhdmを使う有名な方法があるがxboxhdm v1.9はsata接続に対応していないため4.5のsata接続以降では利用できない
NTG4.5 / 4.7 HDD imaging project
fujtoolを利用する方法等が紹介されているがそもそもwindows用のsmart編集ツールなどで解除できないか調べた
windowsで利用できるusb, sataなどに対応したsmart編集用ツールとしてsmartctlがある、またxboxhdmの最新版v.2.3においてはunlockhdコマンドにsmartctlが利用されている

ならば上記フォーラムに記載のパスワード生成手順と合わせ下記のようなコマンドでロックが解除できるのではないかと予想している

./smartctl.exe -s security-unlock,"longUserPasswordFromMelcoCalculator" /dev/sdb
./smartctl.exe -s security-disable,"longUserPasswordFromMelcoCalculator" /dev/sdb

OSSで移転登録してみた

Mon, 01 Jan 2024 00:00:00 GMT

前回に引き続き車ネタです。

OSSとは

OSSとはワンストップサービスの略で国土交通省が提供しているインターネット上で移転登録などの自動車に関する登録事務手続きができるサービスです。

通常の手続きとの違い

最近では自動車ディーラー等が手続きを簡素化したりするために導入しています。通常の手続きと下記のような違いがありますが、個人が使う範囲ではあまりメリットはありません。

車庫証明も同時申請できるため警察署に行く回数が少なく済む
手数料がPay-easy, クレジットカード等で納付可能なため手続きを管轄している陸運局がキャッシュレス決済に対応していなくても現金以外で支払いできる。
電子証明で申請する場合、自分の印鑑証明が不要なため印鑑証明代が節約できる
紙の書類を書かなくていい(譲渡証明書、委任状を除く)
電子車検証を用いて車両情報の記入時間を減らせる

実際の流れ

OSSを導入しているディーラーで購入した場合譲渡証明書等が電子登録されている場合がありますが、希有なケースな為今回は紙の委任状と譲渡証明書を受け取った場合で話をすすめます。

事前準備

OSSブラウザアドオン

OSSを使うためのブラウザアドオンのインストールが必要です。
下記からアドオンとchrome用の拡張機能をインストールしてください。
自分の場合microsoft edgeを使用しましたが、edgeでも変わりません。
OSSブラウザアドオン
 chrome用拡張機能

マイナンバー関連

一部の申請には、マイナンバーカードの電子署名機能が必要です。PCにカードリーダーを接続してマイナンバーカードを読み取る場合は利用者クライアントソフトをスマホで読み取る場合はマイナポータルアプリをインストールしてください。
今回はPCの場合で話を進めます。

利用者クライアントソフトは下記からインストールできます。利用者クライアントソフトのダウンロードからダウンロードしてください。ブラウザ利用版のインストールは不要です。
公的個人認証サービスポータルサイト

マイナポータルアプリは下記から。
android
iOS

キャッシュレス決済登録

クレジットカード等のキャッシュレス決済を利用したい場合、下記から登録を行う必要があります。
お支払い情報登録サービス

電子車検証読み取り

電子車検証を利用して入力を省略できます。
車検証閲覧アプリ

受任者情報ファイルの作成

電子で委任状を作成するのですが、その前に受任者情報ファイルという自分の情報を作成する必要があります。

受任者情報ファイル作成
上記ページの申請開始をクリック
ICカードを選択
カードリーダーを利用を選択
電子署名用パスワードを入力してマイナンバーカードを読み取る
自動車の車台番号をご存知ですか。の項目でいいえを選択(ここでいいえを選択すると申請する車に制限なく申請に使えるようになります)
受任者情報ファイルの保存

委任状の作成

紙の委任状を受け取っていると思いますが、電子でも作成する必要があります。
下記リンクから作成できます。
委任状作成

相手方電話番号がわからない際自分の電話番号を入れましたが、問題ありませんでした。
受任者情報ファイルのところには先ほど作成したファイルを指定してください。
こちらでは車体番号を入れる必要があります。
所有者・使用者の別は旧所有者を選択してください。(ここを正しく選択しないと申請できません。)

移転登録

下記から移転登録の申請をします。
移転登録

譲渡証明書の種類は紙を選択してください。
すでに取得済みの保管場所証明書を利用した申請ですか。の欄でいいえを選択すれば車庫証明も同時に申請できます。
委任状のところでは先ほど作成したものを選択してください。

書類の提出

電子で申請すると言っても委任状と譲渡証明書は紙の原本の提出が必要です。
OSSでの申請完了後陸運局に行って提出する必要があります。
陸運局によって違うと思いますが、自分の行った習志野の場合はOSS専用の受付窓口がありそちらで提出しました。

手数料の納付

ステータスが更新されるたびにメールが来ます。メールが来たらすぐ確認しましょう。
書類の提出後申請のステータスが更新され保管場所証明手数料納付待ちになりますので、メールに記載のURLから申請が面にログインできるので申請時に決めたパスワードでログインしてPay-easyか対応している金融機関から支払いを行います。
納付後警察内管理番号が発行されますが、そちらを管轄の警察署に電話で伝え保管場所標章を郵送でお願いすることもできるようです。

その後2,3日経つと保管場所標章手数料納付待ちになりますので、同じように納付します。
納付した翌日、検査登録手数料納付待ちになりますので、こちらも同じように納付しますが、納付先が違う関係で対応している金融機関が異なります。Pay-easyはこちらも使えます。

保管場所標章と自動車検査証の受け取り

検査登録手数料を納付した段階で保管場所標章の発行は完了しているので管轄の警察署に受け取りに行きます。
その後、陸運局に行き自動車検査証を受け取りに行きます。移転登録の際管轄する陸運局が変更になる場合ナンバープレートの変更が必要なので、車を持って行ってください。
上記の順番はどちらでもいいです先に自動車検査証を受け取りに行っても大丈夫です。

まとめ

上記が大まかな流れです。紙の書類に関しては陸運局に提出しなければならないため、あまりインターネットを用いてるメリットはないです。更には申請画面の選択項目も煩雑なため手続きにある程度詳しくないと使用するのは難しいと思います。既存の方法をそのままデジタル化しているためこのような仕様なのだと思いますが、個人的には辞めてほしいです。

アウディコーディングメモ

Wed, 08 Jul 2020 00:00:00 GMT

※以下内容を実行した際車両の破損や車検不適合が発生した際当方は一切の責任を負いません

↑あくまでも自己責任でお願いいたします。

アウディにてVCDSを用いて電装系の動作のカスタマイズ(俗にコーディングというらしい)を行ったので、手順やカスタマイズできる内容などを紹介していく。

1. VCDSケーブルの準備

ヤフオクや楽天などでVCDSと検索すればケーブルが出てきますのでそちらを購入すれば問題ありません。

バージョンなどが記載されていますが商品詳細ページに対応車種、年代などが書かれています大体新しめのものを買っておけば問題ありません。

2. PCの準備

大体ディスクが付属していますのでディスク内にある内容など読んで適宜セットアップしてください。

VCDSのアプリケーションが起動できたら先にAuto-Scanからマップデータを取得して保存しておきます。復元用に利用できます。

3. 設定リスト

各種カスタマイズするには、車両側OBD2とPC側にケーブルを指してSelect Control ModuleのSelectをクリックします。下記メニュー内での番号になります。車種によっては該当の項目が存在しない場合がありますその場合は別の項目にあるか対応していない可能性があります。
A5B8用です

- MMI再起動方法
前期 SETUP+ジョイコンの真ん中+右上のボタン同時押し
後期 MENU+ジョイコンの真ん中+右上のボタン同時押し
長押しはいらないです同時押しがちゃんと認識されてれば話した瞬間再起動します。
- グリーンメニュー有効化
MMI 2gの場合
[07-Bed.Paneel/Display]
[Aanpassen-10]
[Kanaal 08]  '1'を入力
前期: SETUP+CAR同時押し
後期: CAR+MENU同時押し
MMI 3gの場合
[5F-Informatie Electr.]
[Aanpassen-10]
[Kanaal 06]  '1'を入力
メニュー起動方法は同一
- クルコンの距離調整画面表示
[13-Afstandsregeling]
[Aanpassen-10]
[Kanaal 07]  値を'1'に
MMIにてCAR->ACC内に表示されると思います。
- パーキングアシスト解除速度設定
[10-Parkeerhulp]
[Aanpassen-10]
前期  [Kanaal 23]  最大20km/h
後期  [Kanaal 233]  最大20km/h
- 停車中に内気循環切り替え(外付けではないがパーキングエアコンというらしい)
[08-Airco/Verwarming]
[Hercoderen-07] longcoding
[Byte 01]  [Bit 4]  有効化
グリーンメニュー表示->'Car'->'cardevicelist'->'Auxillary heating' 有効化
グリーンメニュー表示->'Car'->'carmenuoperations'->'Auxillary heating'この項目を5に
- キーアンサーバック有効化&MMI設定表示有効化(盗難防止装置付き車両のみ)
[46-Comfortsysteem]
[Hercoderen-07] longcoding
[Byte 01]  [Bit 2]  有効化
[46-Comfortsysteem]
[Aanpassen-10]
[Kanaal 63]  初期値 40; 44で有効化
- 内部監視機能付き警報装置有効化(日本版だと標準装備ではないが後付けした場合)
[46-Comfortsysteem]
[Hercoderen-07] longcoding
[Byte 01]  [Bit 1]  盗難防止装置有効化
[Byte 01]  [Bit 2]  ホーンでのアラーム有効化
[Byte 01]  [Bit 3]  傾斜計有効化
[Byte 01]  [Bit 4]  内部モニタ有効化
[Byte 01]  [Bit 5]  リアウィンドウセンサ有効化
[Byte 01]  [Bit 6]  アンチロッドモニタリング無線接点有効化
- アウトバーンライト有効化
130km/hで点灯します日本での車検適合未確認
[09-Boordnet]
[Hercoderen-07] longcoding
上のプルダウンから下記の様な表示のやつを選ぶ
'2 -- xxx -- RLS' (Rain and Light Sensor)
[Byte 00]  [Bit 0]  有効化

RDS+ECSで定期的にダンプをS3に保存してみる

Thu, 31 Oct 2019 00:00:00 GMT

概要

AWS にて RDS の定期ダンプを取得したかったので ECS にある cron 的な機能を使ってダンプを定期取得する設定をしてみた
ECS で動かす定期実行用のコンテナのイメージやタスクも管理を自動化してみた
今回 postgres が対象です mysql 等は適宜 dockerfile を変更してください

前提条件

AWS のアカウント取得済み
RDS 構築済み
bitbucket のアカウント取得済み

準備

IAM ユーザーの作成

今回 bitbucket pipeline からのデプロイとダンプデータ S3 へのアップロード用にユーザーを作成する。
通常はデプロイと S3 でユーザーを分けた方がいいのだが今回は管理コストの面で一つで作成します。

IAM を開き左メニューにあるユーザーを開くその後ユーザーの追加を開くと下記の様な画面になる
ユーザー名を適宜入力,アクセスの種類をプログラムによるアクセスに制限

AmazonECS_FullAccess, AmazonEC2ContainerRegistryFullAccess, AmazonS3FullAccessを選択(今回 CLI で同一ユーザーを使いたかったので広に権限取ってあります。わかる人は適宜絞ってください。)

その後特に設定項目はないのでユーザーの作成まで進む
最後にこのような画面が表示されるのでアクセスキー ID とシークレットアクセスキーをメモしておいてください。シークレットアクセスキーに関しては追加発行できますが二度と再表示できないので絶対にメモしておいてください。

IAM ロールの作成

タスクを実行するためのロールだが自動で作られるものではあるのだが ECS を全く使っていない場合は作成されていないので手動で作成する。
(ecsTaskExecutionRoleと最後に付くロールが既にある場合はその ARN をメモしておいてください)
IAM を開き左メニューにあるロールを開くその後ロールの作成を開くと下記の様な画面になる
Elastic Container Serviceを選択次にElastic Container Service Taskを選択次へ

AmazonECSTaskExecutionRolePolicyを選択その後特に設定項目はないのでロールの作成まで進む

作成が完了したら元の画面に戻ってくるので先ほど作成したロールを開く下記画面のロール ARNをメモしておいてください。

バケットの作成

特別設定する項目はありません。適宜設定の上作成しておいてください。
その際作成した名前をメモしておいてください。

ECR リポジトリの作成

こちらも特別設定する項目はありませんが、パイプラインでタグを上書きする関係上タグのイミュータビリティは無効化しておいてください(デフォルトで無効)
作成した後 URI のカラムにある URL みたいなものをメモしておいてください。

bitbucket でリポジトリの作成

いつも通りリポジトリを作成してください。
ローカルで下記の通りファイルを作成してください。

~/
 ├ .pgpass
 ├ bitbucket-pipelines.yml
 ├ Dockerfile
 └ docker-entrypoint.sh

.pgpass は postgres にパスワードを省略してアクセスするためのパスワードファイルですダ下記の通り記述してください。

hostname:port:database:username:password

bitbucket-pipelines.yml は bitbucket のパイプラインの定義を記述するファイルです下記の通り記述してください。
execution-role-arn のところに先ほどメモしたロール ARNを記入してください。

# enable Docker for your repository
options:
  docker: true

pipelines:
  default:
    - step:
        name: build-push
        image: atlassian/pipelines-awscli:latest
        deployment: test
        caches:
          - docker
        script:
          # aws login
          - eval $(aws ecr get-login --no-include-email --region ${AWS_DEFAULT_REGION})
          # docker
          - export BUILD_ID=$BITBUCKET_BRANCH_$BITBUCKET_COMMIT_$BITBUCKET_BUILD_NUMBER
          - docker build -t ${AWS_REGISTRY_URL}:$BUILD_ID -t ${AWS_REGISTRY_URL}:development .
          - docker push ${AWS_REGISTRY_URL}

    - step:
        name: deploy
        image: atlassian/pipelines-awscli:latest
        deployment: production
        script:
          - export BUILD_ID=$BITBUCKET_BRANCH_$BITBUCKET_COMMIT_$BITBUCKET_BUILD_NUMBER
          - export IMAGE_NAME="${AWS_REGISTRY_URL}:$BUILD_ID"
          # ECS variables
          - export ECS_CLUSTER_NAME="${BITBUCKET_REPO_OWNER}"
          - export ECS_SERVICE_NAME="${BITBUCKET_REPO_SLUG}"
          - export ECS_TASK_NAME="${BITBUCKET_REPO_SLUG}"
          # Create ECS cluster, task, service
          - aws ecs list-clusters | grep "${ECS_CLUSTER_NAME}" || aws ecs create-cluster --cluster-name "${ECS_CLUSTER_NAME}"
          # Updating the existing cluster, task, service
          - export TASK_VERSION=$(aws ecs register-task-definition
            --family "${ECS_TASK_NAME}"
            --execution-role-arn ""
            --network-mode "awsvpc"
            --requires-compatibilities "FARGATE"
            --cpu "256"
            --memory "512"
            --container-definitions "[{\"name\":\"${ECS_TASK_NAME}\",\"image\":\"${IMAGE_NAME}\",\"logConfiguration\":{\"logDriver\":\"awslogs\",\"options\":{\"awslogs-group\":\"/ecs\",\"awslogs-region\":\"${AWS_DEFAULT_REGION}\",\"awslogs-stream-prefix\":\"${ECS_TASK_NAME}\"}}}]"
            | jq --raw-output '.taskDefinition.revision')
          - echo "Registered ECS Task Definition:" "${TASK_VERSION}"

Dockerfile は ECS でデプロイする用のコンテナ定義です下記の通り記述してください。
補足がある箇所は先ほどメモしたものから適宜いれてください。

FROM alpine

RUN apk --no-cache add postgresql-client python3
RUN pip3 install awscli
ENV AWS_DEFAULT_REGION ap-northeast-1
ENV AWS_ACCESS_KEY_ID {アクセスキーID}
ENV AWS_SECRET_ACCESS_KEY {シークレットアクセスキー}
RUN mkdir dump
WORKDIR /root/dump
ADD .pgpass /root/.pgpass
RUN chmod 0600 /root/.pgpass
ADD docker-entrypoint.sh /root/docker-entrypoint.sh
RUN chmod +x /root/docker-entrypoint.sh

CMD ["/root/docker-entrypoint.sh"]

docker-entrypoint.sh は docker 起動時に実行するコマンド群ですいわゆる cron の中身です。
補足がある箇所は先ほどメモしたものから適宜いれてください。
保存構成的には最初のプレフィックスが削除周期次に DB 名最後にファイルの接頭辞が今回はダンプの周期を入れています。

#!/bin/sh

mkdir -p yearly/{DB名}
pg_dump -Fc -h {DBのホスト} -U {ユーザー} {DB名} > yearly/{DB名}/weekly-`date "+%Y%m%d_%H%M%S"`.custom
aws s3 sync . s3://{S3のバケット}

準備が完了したらいつもの通り先ほど作成したリポジトリにプッシュしてください。

bitbucket での pipeline の準備

先ほどプッシュしたリポジトリを bitbucket で開く
設定->PIPELINES->Settings に進みEnable Pipelinesを有効にする

次にRepository variablesを開く
下記の通り先ほどメモしたものから設定をする。

デプロイと cron の設定

デプロイの実行

引き続き bitbucket の画面で再度メニューからPipelinesを開く次にRun pipelineをクリックし下記の通り選択してRunをクリック

完了すると下記の様になるのでパイプラインが完了するのを待つ

次回以降ブランチに変更が入る度自動で実行されます。

AWS でスケジュールの作成

AWS ECS 上でリポジトリオーナー名でクラスタが作成されているのでそのクラスタを開く(クラスタ名が書かれているところをクリックすると開きます)。

タスクのスケジューリングのタブを開き作成をクリック

実行間隔等を設定しターゲットの部分は今回FARGATE用にタスクを作成したので起動タイプをFARGATEを選択タスク定義のファミリーはリポジトリ名と同名のタスクがあるのでそれを選択する。VPC とセキュリティグループは適宜設定してください。

補足:Cron 式を選択したときに躓いたのだが busybox cron 等の cron 式とは違う模様下記を参考にいたしました。
AWS_Cron 式のワイルドカード

DooDでcronをコンテナで分離してみる&swarm対応

Tue, 24 Sep 2019 00:00:00 GMT

概要

dockerで複数サービスを1サービス1コンテナで管理している際1コンテナ内それぞれにcronを常駐させるもしくはホスト側cronで動かすのは個人的に好ましくない(どう好ましくないかは長くなるし大体の人はわかると思うのでここでは割愛します)と思ったのでDooDを使ってcron用コンテナを作成して管理できるようにしてみた

構成

下記の様にファイルを配置すれば動く ssmtpに関してはcron実行結果をメール送信する際sendmailコマンドを内部的に利用するのだがalpineではそもそもsmtpサーバーが内蔵されていないため外部のsmtpサーバーを指定できるようにするためのものです。例ではgmailのsmtpサーバーを利用します。 ※cronファイルの権限をrootユーザーにしないと動きません

~/
 ├ cron/
 │ ├ root
 │ ├ ssmtp.conf
 │ └ Dockerfile
 └ docker-compose.yml

# docker-compose.yml
version: '3.7'
services:
  cron:
    build: cron
    restart: always # docker起動時に毎回自動起動
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock # ホストのdockerソケットをマウントすることでDooDを可能に
      - ./cron/root:/var/spool/cron/crontabs/root # busybox cronの初期設定ディレクトリ

# cron/Dockerfile
FROM alpine
# cronの実行時間が初期設定だと9hずれてしまうのでtimezoneを設定
RUN apk add --update --no-cache tzdata && \
    cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime && \
    apk del tzdata
# dockerのクライアントとssmtpをインストール
RUN apk add ssmtp docker-cli
# ssmtpのコンフィグを追加
ADD ssmtp.conf /etc/ssmtp/ssmtp.conf
# crondをフォアグラウンドで標準出力を使用して起動
CMD crond -f -d 8

# cron/root
# cron実行完了時に実行結果をメールするメアド
MAILTO=メアド
# docker execでコンテナ内でバッチを走らせる
00  10  *  *  3 docker exec -w /var/www/api/m docker_lb_1 php cu.php

# docker swarm用inspectコマンド等を使ってコンテナIDを特定してる
00  10  *  *  3 docker exec -w /var/www/api/m $(docker inspect --format '{{ .Status.ContainerStatus.ContainerID }}' $(docker service ps --filter 'desired-state=running' main_lb -q)) php cu.php

# smtpサーバーホスト
mailhub=smtp.gmail.com:587
# gmailログイン用ユーザー名(大体メアド)
AuthUser=hoge@gmail.com
# gmailパスワード
AuthPass=password
# smtpサブミッション認証時にSTARTTLSを利用する(gmail等のSTARTLSサーバーでは必須)
UseSTARTTLS=YES
# メール送信時の送信元ホストを下記で書き換えるイメージ(dockerデフォルトだとコンテナIDが入ってしまうため大体迷惑メールとしてブロックされます)
hostname=gmail.com

ubuntuのlxdが仮想ブリッジからネットワークにつながらない

Fri, 20 Sep 2019 00:00:00 GMT

概要

ubuntuでlxdの環境を構築した際ネットワークにつながらないという事象が発生した。

構成情報

ubuntu18.04.3
lxc,lxd3.17(snapバージョン)
netplanにて仮想ブリッジを作成
lxcコンテナにnetplanで作成したブリッジをアタッチした状態

解決策

どういった条件で引き起こされるかは不明だがubuntuのlxdがufwの書き換えでnatを設定しているためufwが無効化されているとコンテナ内部から適切にnat forwardされずに外部と疎通できなくなる。つまり下記コマンドで解消する

sudo ufw enable

これでもつながらない場合は本来は個別にroutedを作成しなければいけないがめんどくさい場合は下記を実行してすべてのroutingを許可

sudo ufw default allow routed

ZabbixのアラートをIFTTTで通知する

Tue, 17 Sep 2019 00:00:00 GMT

概要

ちまたではPushbulletを使う方法やSlackを使う方法等が紹介されているがそもそもIFTTTアプリをスマホに入れており。履歴を記録する必要もなかったためIFTTTのプッシュ通知機能でアラートを受け取れるよう設定した。

前提条件

Zabbixのバージョンは4
- 基本的には下記記事で構築した通りの環境
- dockerでzabbixを導入してみる
- 設定を日本語に変更済み今回は日本語でのUIを使って解説する
iOSもしくはandroid端末にIFTTTアプリを導入しプッシュ通知を許可済み

設定手順

メディアの作成

管理->メディアタイプを開く
メディアタイプの作成を開く
下記の通り設定(SUBJECTは二個要らないですミスで入れてしまいました。)

(画像では登録済みのため更新と出ているが)追加をクリック

メディアの紐づけ

右上のユーザーアイコンをクリック
メディア->追加をクリック
タイプでpushを選択
送信先は今回使わないのでダミーで何か入れておいてください
追加をクリック
更新をクリック(ここを忘れて別ページ移ると設定が消えます)

IFTTTレシピの作成

レシピの作成を開く
thisにwebhooksを設定(途中でEvent Nameを聞かれますが後で使うので覚えておいてください)
thatにNotificationのSend a rich notification from the IFTTT appを設定
下記の通り設定

プッシュ通知のテストとURLの取得

webhooksを開く
右上のDocumentaitionを開く
イベントの箇所に先ほど作成したwebhookのイベント名value1に適当な文言value2に適当なURLを入れる
Test Itをクリック
IFTTTアプリが入ってる端末にプッシュ通知が届きプッシュ通知を開いた際にvalue2に入れたURLが開かれることを確認
この時のテスト画面にあったURLをコピーしておいてください

scriptの設定

Monitoring Artistのdockbixのalertスクリプトのパスはこの公式資料のZS_AlertScriptsPathにあるとおり/usr/local/share/zabbix/alertscriptsにあるzabbixの環境によってこのパスはことなると思うが、基本的にzabbixで設定されているalertscriptsディレクトリにスクリプトファイルを設置しないと呼び出されません。(永続化は別途設定必要)

alertscriptsディレクトリにpush.shを作成下記の通り記述

※何故STDINを使って改行しているかというと$1の中身が改行されていたため最初通知の発砲に失敗しており個の箇所を現在の様に修正したら治りました。よりよい解決放があればご教示願います。

#!/bin/sh
curl -X POST {先ほどのURL} -H "Content-Type: application/json"
-d @- << EOF
{
  "value1":"${1}",
  "value2":"${2}"
}
EOF

2.最後におまじないをして終わりchmod +x push.sh(大体意味は分かると思うので説明は割愛)

プッシュ通知用にアクションをカスタマイズ(テスト中動かないかも)

IFTTTでURL用のパラメーターを設定したがそれをアクションの件名を使って引用しているので件名の欄をイベントURLに書き換えれば通知を開いた際アラートのイベント画面が開く(はず)

設定->アクションを開く
デフォルトのアクションを開き複製をクリック
実行内容,復旧時の実行内容,更新時の実行内容のデフォルト件名を下記の様な形式に書き換え
http://{zabbixホスト}/tr_events.php?triggerid={TRIGGER.ID}&eventid={EVENT.ID}
実行内容,復旧時の実行内容,更新時の実行内容の実行内容のステップ1の変更をクリック
次のメディアのみ使用の箇所をpushを選択
作成をクリック

dockerでzabbixを導入してみる

Wed, 24 Apr 2019 00:00:00 GMT

概要

前回の記事で紹介したウェブアプリデプロイ環境だが今回はここにzabbixを導入してみる。最近ではdockerの死活環境を監視するにはdatadogやprometheus+etc.等での監視環境があるがdatadogはコンテナ監視機能が有料なのとprometheusはalertとalertのgrafanaへの反映等にとても作業手順が多いため最初からalertやdashboardの設定がされているzabbixを採用した。基本的に前回の続きからとなるためパッケージの導入やディレクトリ構成等は上記記事を参照してください。

zabbixの導入

まず手元の環境がlxcなのでコンテナ内特権を許可するために以下を実行。コンテナ内特権はzabbix-agentコンテナで使用します。

lxc config set {コンテナ名} security.privileged true
cat <<EOT | lxc config set {コンテナ名} raw.lxc -
lxc.cgroup.devices.allow = a
lxc.cap.drop =
EOT
lxc restart {コンテナ名}

次にzabbix関連のコンテナを用意していきます今回はzabbix公式イメージではなくmonitoringartistのdocker向けのzabbixイメージを利用しますこちらを利用することでテンプレートの設定の手間等がほぼなしでセットアップができます。それでは前回作成したdocker-compose.ymlを下記の様に編集します。データベースのユーザ,パスワード等は適宜設定を変更してください。

version: '3'
services:
  db:
    image: mysql
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: '0000'

  laravel:
    image: yuim/laravel

  zabbixdb:
    image: monitoringartist/zabbix-db-mariadb
    restart: always
    environment:
      MARIADB_USER: "zabbix"
      MARIADB_PASS: "zabbix"
    volumes:
      - zabbixdb:/var/lib/mysql

  zabbixs:
    image: monitoringartist/dockbix-xxl
    restart: always
    environment:
      ZS_DBHost: "zabbixdb"
      ZS_DBUser: "zabbix"
      ZS_DBPassword: "zabbix"
      PHP_date_timezone: "Asia/Tokyo"

  zabbixa:
    image: monitoringartist/dockbix-agent-xxl-limited
    privileged: true
    restart: unless-stopped
    volumes:
      - /:/rootfs
      - /var/run:/var/run

volumes:
  zabbixdb:
    driver: local

次にzabbixのコンソールにアクセスできるようにvhosts.confを下記のように追記

server{
  listen 80;
  server_name {fqdn};
  location / {
    proxy_set_header Host $proxy_host;
    proxy_pass http://laravel;
  }
}
server{
  listen 80;
  server_name {fqdn};
  location / {
    proxy_set_header Host $proxy_host;
    proxy_pass http://zabbixs;
  }
}

最後に下記コマンドを実行するとzabbixが立ち上がります。コマンド実行完了後30秒程度でアクセスできるようになります。

docker-compose up -d

agentの設定

起動が完了したら早速コンソールにアクセスしてログインします初期ID/PWはAdmin/zabbixですログインしたらメニューのConfigration->Hostsの順番でクリックし右上のCreate hostをクリックします。下記の通り設定してください。

次にTemplatesタブに移動してSelectをクリックしTemplate App Docker - www.monitoringartist.comとTemplate OS Linuxを選択しSelectをクリックその後下のAddをクリックしさらにその下にあるAddで登録します。初期設定で10分程度でコンテナが認識されるはずですコンテナの状況はMonitoring->Latset dataで確認できます。

alertの設定

そのままではdockerがstopした際等にalertをしてくれないのでプロトタイプにtriggerを設定していく。webの疎通確認のトリガーに関してはdockerだからといって特段変わった設定は要らないので今回は割愛します。プロトタイプのtrigger設定は先程のHostsの画面で先程作成したホストのDiscoveryをクリック次にRunning containersと記載がある行のTrigger prototypesをクリックその次に右上のCreate trigger prototypeをクリックそうするとtrigger作成画面になるので下記のように入力しAddをクリックし作成します。こちらも10分程度で反映されます。

mail通知の設定

dockerの監視に関する設定は以上になるが、zabbixにはメール通知機能がついておりそちらも設定したので設定方法を紹介する。まずAdministration->Media typesをクリック次にEmailをクリックgmailのsmtpsを利用する際は下記の様に設定します。

次にメール送信先ユーザーを設定していきます。今回は初期アカウントであるAdminに設定します。まずAdministration->Usersをクリック次にAdminをクリックMediaタブを選択しAddをクリックTypeでEmailを選択しSend toに送信先を入力しAddをクリック最後にその下のUpdateをクリックして保存します。最後にConfiguration->ActionsをクリックしDisabledになっている箇所をクリックしてEnabledにします。以上でメール送信の設定は完了です。

docker-hubを利用して簡易的なウェブアプリデプロイ環境を構築する

Wed, 17 Apr 2019 00:00:00 GMT

docker-compose version3でのlinksの取り扱いが変更になっており今回の場合不要だったため削除(全然知りませんでした…)

概要

bitbucketとdocker-hubを用いて自動ビルド&デプロイ環境を構築した

docker用インスタンスの作成

手元の環境ではlxcでサーバを管理していたため下記コマンドでlxcを立ち上げ&ip固定を行った。

lxc launch ubuntu:18.04 docker
lxc network attach lxdbr0 docker eth0 eth0
lxc config device set docker eth0 ipv4.address <IPアドレス>
lxc stop docker
lxc config set docker security.nesting true #コンテナ内コンテナのセキュリティ許可
lxc start docker

またlxcデフォルトテンプレートだとsshでkey認証が必須なので下記コマンドでgithubに保存してあるpublic keyを設定した。

curl https://github.com/{githubのアカウントid}.keys >> ~/.ssh/authorized_keys

docker用インスタンスの準備

下記コマンドでdocker-composeごとインストールします。

sudo apt update
sudo apt install docker-compose
sudo gpasswd -a $USER docker    #aptで入れると実行する現在のアカウントが権限不足で実行エラーやroot権限が必要となってしまうためインストール後にグループ設定を行う。
sudo systemctl restart docker
exit    #一旦セッションを消す

bitbucketリポジトリの作成

docker-hubで自動ビルドさせるリポジトリを作成していきます。今回はlaravelをデプロイする想定です。まず適当なディレクトリを作り下記の様なDockerfileとvhost.confを作成します。

FROM centos

RUN yum install -y yum-utils epel-release
RUN yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional
RUN rpm -Uvh http://rpms.remirepo.net/enterprise/remi-release-7.rpm
RUN yum install -y --enablerepo=remi --enablerepo=remi-php72 php-cli php-zts php-intl php-mbstring php-dom php-pdo php-mysql php-pgsql php-devel php-gd php-zip
RUN php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" \
 && php -r "if (hash_file('sha384', 'composer-setup.php') === '48e3236262b34d30969dca3c37281b3b4bbe3221bda826ac6a9a62d6444cdb0dcd0615698a5cbe587c3f0fe57a54d8f5') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" \
 && php composer-setup.php \
 && php -r "unlink('composer-setup.php');" \
  && mv composer.phar /usr/local/bin/composer
RUN yum install -y python2-certbot-apache git httpd unzip
ADD ./vhost.conf /etc/httpd/conf.d/vhost.conf
ADD ./laravel /var/www/html
RUN chmod -R 777 /var/www/html

EXPOSE 80
EXPOSE 443

CMD httpd -DFOREGROUND

DocumentRoot /var/www/html/public
ServerName localhost
<Directory "/var/www/html">
AllowOverride All
</Directory>

次にdockerfileを作成したディレクトリでlaravelプロジェクトを立ち上げます。下記の様なコマンドで立ち上げます。

cd {dockerfileを作成してディレクトリ}
sudo apt install composer php-zip
composer global require "laravel/installer"
PATH=$PATH:~/.config/composer/vendor/bin
export PATH #パスは必要に応じて永続化(.bashrcに記述)等してください
laravel new laravel
rm laravel/.gitignore #開発もdocker前提なのでignoreを消してしまいます。開発用サーバーを分離したい等あれば別途設定してください

これをdockerfileごとbitbucketにpushします。(bitbucketのリポジトリ作成方法は割愛します)

git init
git add .
git commit -m "first commit"
git remote add origin {bitbucketリポジトリ}
git push -u origin HEAD

docker-hubの自動ビルド設定

次にdocker-hubでリポジトリを作成します。アカウント設定で先ほどbitbucketにpushしたアカウントをconnectしておきます。そうするとリポジトリ作成時に下記の様にリポジトリが出てくるので先ほどpushしたリポジトリを選択しcreate&buildをクリックします。

docker-composeでの運用

docker-hubのbuild画面にてsuccessが出ていたらbuild完了です。build完了を確認したらdockerを動かしたいインスタンスにて適当なディレクトリを作成し下記の様なdocker-compose.ymlとvhosts.confファイルを作成します。一様dbもdockerで用意していますが今回は設定方法や管理方法等は一旦割愛します。

version: '3'
services:
  db:
    image: mysql
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: '0000'

  proxy:
    image: nginx
    ports:
      - "80:80"
      - "443:443"

  laravel:
    image: {先ほど作成したdocker-hubのリポジトリ}

server{
  listen 80;
  server_name {FQDN};
  location / {
    proxy_set_header Host $proxy_host;
    proxy_pass http://laravel;
  }
}

ファイルの作成が完了したらdocker-compose.ymlがあるディレクトリで下記コマンドでコンテナを追加。

docker-compose up -d

サイトの開発

docker-composeを用いて本番環境とほぼ同一の環境の開発環境を構築する。先ほどのdocker-compose.ymlとvhosts.confをベースにローカル開発環境用にディレクトリを作成し下記ファイルを作成する。

version: '3'
services:
  db:
    image: mysql
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: '0000'

  proxy:
    image: nginx
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./vhosts.conf:/etc/nginx/conf.d/default.conf

  laravel:
    build: ./laravel
    volumes:
      - ./laravel/laravel:/var/www/html

server{
  listen 80;
  server_name laravel.localhost;
  location / {
    proxy_set_header Host $proxy_host;
    proxy_pass http://laravel;
  }
}

次にlaravelリポジトリをサブモジュールとして追加し新規リポジトリを作成しpush。

git init
git submodule add {先ほど作成したlaravelのリポジトリ} laravel
git add .
git commit -m "first"
git add remote origin {bitbucketの新規リポジトリ}
git push origin HEAD

開発環境の起動を行う基本的には本番インスタンスと同じで下記コマンドを実行しlaravel.localhostにアクセス

docker-compose up -d

バージョンの更新

基本的にdocker-hubで設定したブランチに変更が入ると自動でビルドが開始されるのでブランチに変更を行いdocker-hub上でビルドが完了したら下記コマンドを本番インスタンスでdocker-compose.ymlがある場所で実行するだけで本番環境へのデプロイが完了する。

docker-compose pull
docker-compose up -d

まとめ

以上が個人的に利用しているごく簡単なデプロイ環境の一例です間違っている箇所やもっと効率的にCI/CD等と連携できる方法等あればご教授いただけると助かります。

GUIを入れたubuntuでネットワークが繋がらない

Fri, 11 Jan 2019 00:00:00 GMT

ubuntu等のlinuxにnetplanでipを固定設定をしていてその後にubuntu-desktopやnetworkmanager等のGUIを入れた際NetworkManagerの管理外となりネットワークが繋がらなかったりGUIから設定できなくなることがあるその際は/etc/netplan/にyamlファイルを作成しNetworkManagerがnetplanを利用できるように設定を書き足せば良い下記の通り設定すれば動くと思われる。

network:
  version: 2
  renderer: NetworkManager

hls.jsのレベル変更で躓いた件

Tue, 18 Dec 2018 00:00:00 GMT

概要

すごく稚拙の理由だがhls.jsでレベル変更機能(m3u8ファイルの切り替え)で躓いた。

躓いたとこ

hls.jsにはhls.currentLevelというapiが用意されていてこちらの値を変更することでレベルの変更ができるようになっているのだがこちらにslectを変更した際にoptionの値を導入するという仕様で作成を試みたのだが-1を与えてると再生が止まる状況に陥ってしまった。

$('.res>select').on('change', function() {
    hls.currentLevel = $(this).val();
});

解決方法

optionのvalueをNumberでキャストすれば治ります。

$('.res>select').on('change', function() {
    hls.currentLevel = Number($(this).val());
});

原因

val()で取得した値は非明示的に文字になったり数字になったりする-がついた際に文字にキャストされさらにはhls.jsが内部で値チェック等を行っていなかったためエラーなどもでず再生できなくなったと思われる。

まとめ

かなりレベルの低い内容だったが筆者のレベルが低いのか解決になかなか時間がかかったりする。日本語でこういった情報が溢れていてくれるとありがたい。

EC-CUBE3系に簡単なAjax用エンドポイントを作成してみる

Mon, 03 Dec 2018 00:00:00 GMT

仕事の方でEC-CUBE3系を触る機会がありその際EC-CUBE3系にAjax用のエンドポイントを実装したので備忘録としてまとめてみた。

概要

EC-CUBE3系では標準でwebAPIが用意されているのだがそちらをSymfony内で有効化する方法や利用方法のドキュメントが皆無でありSymfony内で開発したほうが早いと思われたため自前で実装をした。

How to

routeの設定

まずはじめにAPI用のrouteを定義する。今回は特にCRUIDを意識した実装内容でないためmatchで下記の通りとした。routeの定義場所についてはPlugin内が推奨Pluginの構築方法等はこちらを参考にさせていただいた。

$app->match('/api', 'Plugin\Custom\Controller\ApiController::index')->bind('api');

コントローラの実装

次にエンドポイントとなるコントローラの実装だがroute定義でおわかりの通りSymfonyのform builderは使用せずにCSRF対策を行うEC-CUBEの公式ドキュメント等に記載はないが$app内にcsrf_providerがあるのでそちらを利用する。今回はajaxで実装するため下記の通り実装した。動作自体は商品IDを受け取ったらをれをお気に入りに追加するというものだ簡易的なものなのでお気に入り追加済み等のチャックやtry等は実装していない。

<?php
    namespace Plugin\Custom\Controller;

    use Eccube\Application;
    use Symfony\Component\HttpFoundation\Request;
    use Symfony\Component\Security\Csrf\CsrfToken;
    use Symfony\Component\HttpFoundation\Response;

    class ApiController {
        public function index(Application $app, Request $request) {
            if($app['form.csrf_provider']->isTokenValid(new CsrfToken('csrf', $request->get('csrf')))) {
                $Customer = $app->user();
                $Product = $app['eccube.repository.product']->get($request->get('id'));
                $res = $app['eccube.repository.customer_favorite_product']->addFavorite($Customer, $Product);
                return '{"success": "success"}';
            }
            return Response::create('', 400);
        }
    }

フロントの実装

次にフロントの実装だが今回はAjaxにjQueryを使用した。まずdefault_frame.twig等に下記の用にcsrf用のトークンを入れる。じつはcsrf_tokenが定義済みでtwig内で使用可能となっている()内のcsrfの部分はハッシュとなるためこちらの値が先程のコントローラのCsrfTokenインスタンス化時に指定した値と一致していなければならない本来はフォームを特定するためのものなのだがそこまでの対策でセキュリティの懸念には対して影響しないと思われたため今回はこのような実装とした。

var csrf = "{{ csrf_token('csrf') }}";

ajax実行部分については下記の通り実装したidの箇所には商品IDが入る。

$.ajax({
    type: 'POST',
    url: '/index_dev.php/api',
    data: 'csrf='+csrf+'&id='+id,
    dataType: 'json'
}).then(function(data) {
    console.log(data);
}, function(data) {
    console.log(data);
});

まとめ

かなり早足で簡単な実装方法を紹介したがあくまでこれは旧バージョンで半ば強制的に対応する方法なので特段理由がないのであればそうそうに3系のサポートを切り旧バージョンのFWを採用するようなEC-CUBEの利用はやめましょう。(筆者のおすすめはWooCommerceのほうがおすすめです)

hhvm環境でlaravel5.7のプロジェクトを作成しようとしたら苦労した話

Thu, 27 Sep 2018 00:00:00 GMT

hhvmでのphpのサポートが終了していますhhvmでのphpの利用は非推奨です。

初めに

当方がhhvm環境でlaravel5.7を導入しようとした際の備忘録として導入の際に発生した問題、解決策を書いていく

composerの導入

自分は簡単なLaravelインストーラーを使用したのでまずLaravelインストーラーを導入するためにcomposerを導入しようとしたのだがその際下記の様なコマンドで導入しようとしたのだがインストール自体は完了するがapt自体がcomposerに必要なphp-commonやphp-cliを自動で同時にインストールされるためその際hhvmとphp-cliが競合してしまいcomposerコマンドが使い物にならなくなるなので解決策としては下記を参照

sudo apt install composer

公式ページにもあるがセットアップ用のスクリプトをダウンロードしてきてpharを作成しパスを通すこれでhhvm環境でも問題なく動くはずだこの際注意なのだが誤ってaptでcomposerを導入してしまった場合composerだけでなくphp-*等で特に理由がない限りはphp環境を削除しておくこと

php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('SHA384', 'composer-setup.php') === '93b54496392c062774670ac18b134c3b3a95e5a5e5c8f1a9f115f203b75bf9a129d5daa8ba6a13e2cc8a1da0806388a8') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
mv composer.phar /usr/local/bin/composer

laravelインストーラーの導入

次にlaravelインストーラーを導入していくといっても下記のコマンドを実行してパスを通すだけどこちらでは特に問題は発生しなかった

composer global require "laravel/installer=~1.1"

上記コマンドを実行して~/.composer/vendor/binこちらにパスを通せば完了

phpenvの導入

ここでやっとプロジェクトの作成ができると思ったのだが何やらエラーが出てきて進めなくなりました。この時点では知らなかったのですlaravel5.7がphp7.1からサポートなのですがhhvmは最新安定板がphp7.0ベースなため動かないことが判明しました。解決策としてはphpenvを導入してcliのphpバージョンを切り替えるという方法です。下記コマンドを実行していきます。

git clone https://github.com/CHH/phpenv.git
cd phpenv/bin
./phpenv-install.sh

上記が完了したら下記を.bashrcなりに記述します

export PATH="$HOME/.phpenv/bin:$PATH"
eval "$(phpenv init -)"

そうしたらsource ~/.bashrcなりで.bashrcを読み込みなおしてphpenvコマンドが通っていればphpenvの導入は完了です。

phpenvでphpのビルド

次はphp7.1以上の環境をphpenvで導入していきます。下記コマンドでインストール可能リストがみれますので7.1以上のものをえらびます。

phpenv install --list
phpenv install {インストールするバージョン、エディション}

当方の環境ではライブラリが足りずビルドができなかったphpのビルドには様々なライブラリが必要なのだがaptでのパッケージ名で必要なライブラリの一覧等が見つけられなかったのでエラーに出てきたライブラリをインストールしてビルドしなおすという作業を繰り返しました。(ライブラリ一覧やもっと効率の良い方法があったら教えていただけると助かります)そしてビルドが完了したら下記コマンドでphpenvのバージョンを切り替えます。

phpenv global {インストールしたバージョン、エディション}

laravelプロジェクトの作成

laravelのプロジェクト自体はコマンドで作成できる。これで環境が構築できたと思うがphpenvの仮想環境はcliのみの設定となっているのでロードバランサー側のphp設定はhhvmのままだとエラーが出る可能性があるので別途設定がひつようだ。

laravel new {プロジェクト名}

まとめ

単純に当方の技術、能力不足な面が大きいが環境構築だけでかなりてこずってしまったこの記事が何かの解決につながれば幸いだ。

PayPalのClient Integrationの簡易的な実装方法

Wed, 26 Sep 2018 00:00:00 GMT

PayPal Tech Meetupに行ってきてPayPalのClient Integrationについて色々お話が聞くことができたので決済後処理、決済フローのカスタマイズを除いて簡易的にボタンを作成する方法を紹介していく

1.スタイルの決定

Checkout Integration PatternsこちらでCheckoutボタンのテストができるのでこちらで確認しながらきめるとよいだろう下記がstyle関連で使用できるオプションです。

locale: 'ja_JP'

ボタン等に使用する言語使用可能な言語はこちらを参照

style: {
    size: 'small',
    color: 'gold',
    shape: 'pill',
    label: 'checkout',
    tagline: 'true',
    layout: 'vertical',
    fundingicons: 'true'
}

ボタンのデザインに関するオプションこちらから使用できるオプションを確認できます。
またfundingだが日本だったら特にカスタマイズは要らないはずですチェックアウトボタンでのクレジットカード決済は有効になっているのでfundingiconsをtrueにしていただくか、layoutをverticalにしていただければアクセプタンスマークが表示されるはずですのでそちらからクレジットカード決済が可能になります。

2.ボタンの実装

こちらでREST API appsのCreate Appフロー通り情報を入力してAppを作成してください、作成が完了したらappのページを開きClient IDをどこかにメモしておいてくださいこれがSandbox(テスト)のIDになります次に右上のLiveをクリックしてください違うClient IDが表示されるのでこちらもメモしておいてくださいこれがLive(本番)のIDになります

<script src="https://www.paypalobjects.com/api/checkout.js"></script><!--checkout.min.jsにするとminify版になります-->
<div id="paypal-button-container"></div><!--DOMで操作したいエレメント簡単に言うとボタンの設置場所-->
<script>
    paypal.Button.render({
        env: 'sandbox', //snadbox(テスト)かproduction(本番)か
        locale: 'ja_JP' //言語設定
        style: {
            //ここに先ほど決定したデザインを入れる
        },
        client: {
            sandbox: '', //先ほどメモしたsandboxのClient IDを入れる
            production: '' //先ほどメモしたLiveのClient IDを入れる
        },
        payment: function(data, actions) {
            return actions.payment.create({
                payment: {
                    transactions: [
                        {
                            amount: {total: '1000', currency: 'JPY'}
                        }
                    ]
                }
            });
        }, //商品内容や買い手へのメッセージ等の設定ができるこちらを参照https://developer.paypal.com/docs/checkout/integrate/#2-set-up-a-payment
            //また配送情報の削除等も可能こちらを参照https://developer.paypal.com/docs/checkout/how-to/customize-flow/#pass-web-experience-profile-options
        onAuthorize: function(data, actions) {
            return actions.payment.execute().then(function() {
                window.alert('Payment Complete!');
            });
        } //決済時のhookアクション等の設定ができる見本は決済完了時こちらを参照https://developer.paypal.com/docs/checkout/how-to/customize-flow/#show-a-confirmation-page
    }, '#paypal-button-container');//ボタンをレンダリングするエレメントのセレクタが引数
</script>

3.決済テスト

テスト用アカウントをログインできるようにする必要があるこちらを開きアカウントをクリックしたらprofileをクリックそうするとモーダルが開くのでChange passwordをクリック任意のパスワード入力後saveをクリックこれを2アカウントあるはずなので両方行う次にチェックアウトボタンをテスト用のページなりで使用できるようにするコードが問題なければボタンが表示されるはずなのでクリックするenvの値がsandboxの場合sandboxの決済画面が開くので先ほどのアカウント一覧の画面のPERSONALと書かれている方でログインする、そうすれば決済ができるはずです。次にテスト用のアカウントで決済の受け取りが完了しているかの確認ですがこちらから先ほどのアカウント一覧の画面のBUSINESSと書かれている方でログインすると先ほどテストで決済した分が反映されていれば成功していることになりますが、反映まで時間がかかるので注意が必要です。

まとめ

速足で簡単な実装について説明して感じたことだが公式のqiitaの情報の少なさ英語版リファレンスの非フロー的な機能説明(主に情報が分散しすぎてる)が多いと感じました。その辺りなんとかなればもっと利用者が増えるのではないだろうか。

磁気ストライプの検証

Sun, 26 Aug 2018 00:00:00 GMT

磁気ストライプカードとは

磁気ストライプカードとはwikipediaによると磁気ストライプカード（じきストライプカード、英: magnetic stripe card）は、磁性体の帯があるカードで、その中の鉄をベースとした小さな磁性粒子の磁性を変化させることでデータを格納できるもの。とありますが簡単に説明するとみなさんが持っているポイントカードやクレジットカードなどの磁性体を持ったカードのことを言います。

概要

今回は磁気ストライプの基本的な仕様等の説明、簡単に仕様特定等に行った検証を掲載していく。

仕様

磁気ストライプ内データ

まず磁気ストライプ内のデータだがMSR705と付属のソフトウェアを使用し内部データを読み取りネット上の情報等を参考にまとめた。ネット上の情報に関してはこちらを参考にした。

上記が読み取ったデータであるサンプルにはアクティベートを行っていないおさいふポンタを使用した。クレジットカードはTrack1, Track2, Track3がありそれが縦に並ぶような形で配置されています。(※国内で発行されている殆どのクレジットカードはTrack3はありません)磁気ストライプ内の番号に関して上記を例に簡単に解説をつけると下記の通りです。
Track1
B(開始符号)3574001005472095(カード番号)^(区切り符号)MEMBER/OSAIFUPONTA(氏名)
^(区切り符号)2110(有効期限)121(サービスコード)679(cvc1)

Track2
3574001005472095(カード番号)=(区切り符号)2110(有効期限)121(サービスコード)679(cvc1)

サービスコードについて

先ほどの磁気ストライプ内のデータにあったサービスコードについて解説していくこのサービスコードとは決済端末側に要求しうる動作を決める為のもので数字によって下記の様な意味を持つ。
1桁目
1:国際ブランド
2:国際ブランド&ICチップ搭載
5:国内ブランド
6:国内ブランド&ICチップ搭載
7:プライベート用
9:テスト用

2桁目
0:決済機側で判断
2:イシュアーに問い合わせる
4:二国間協定を除いてイシュアーに問い合わせる

3桁目 0:制限なし&PIN入力要求
1:制限なし
2:物品とサービスのみ
3:ATMのみ&PIN入力要求
4:キャッシングのみ
5:商品とサービスのみ&PIN入力要求
6:制限なし&可能な場合はPIN入力要求
7:物品とサービスのみ&可能な場合はPIN入力要求

検証

カードの偽造可否や偽造カードの使用可否等の検証を行った。

カードの偽造

まず結論から言うと偽造は可能であるしかしカード番号や有効期限、CVC2を知っていても偽造は不可能である理由として先ほど説明したCVC1が不明であるためである実はクレジットカードは通常裏面等に記載があるものはCVC2でありこちらはEC決済等に用いられるが磁気ストライプ内のものは店頭決済用のCVC1となっておりこちらは乱数で推測が不可能であるため偽造は不可能である。ではどうやって偽造が可能かと言うと有名な手口ではあるが決済機等に付けるスキミング装置を用いる方法やまた悪意のある加盟店に直接磁気ストライプ内データが盗まれたりした際に偽造カードの作成は可能になってしまう磁気ストライプには書き換え不能な固有データ等が存在しないため磁気ストライプ内のデータを直接抑えられたら終わりなのである。
対策等は近年日本でも増えてきているが決済操作のセルフ化と決済端末等を目視確認することだ。

偽造カードの使用

こちらも結論から言うと使用可能であるしかし近年のIC対応で使用が難しくなっているのも事実であり理由としては先ほど説明したサービスコードだがこちらの1桁目が2か6である場合ICが要求されてしまい(要求しない決済機もあり)決済ができないまたこちらのサービスコードを書き換えて検証を行ったところ現在のクレジットカードインフラではイシュア側で少しでも違う番号等があると決済できない仕様となっており決済が不能だった。ここで余談だが本検証で分かったことなのだがTrack1にデータがない場合(磁気等を取り去った状態)決済できないがTrack1になんらかのカード情報があった場合決済できたのだがTrack1に如何なるカード情報を入れてもTrack2のカード情報により決済が行われた、また先ほどのサービスコードもTrack2のものが使用される仕様となっていた。
対策としてはカードのIC搭載、決済機のIC対応だ。

まとめ

以上の通り割と簡単に不正利用ができてしまうことが判明した特に日本国内の決済事情的にはかなり早急な対応が必要な状態だと思われる。

ubuntuで超簡単にmastodonインスタンスを作成する方法(docker)

Fri, 17 Aug 2018 00:00:00 GMT

概要

qiita等に上がっている既存の情報ですと情報が少し古かったりしまたtootsuiteによる公式ドキュメントも現在は存在する為公式ドキュメントに沿って無駄な構成要素を省いて構築していく。

2018-12-25:対話形式のものを使用するように修正タイトルを修正
2018-12-25:公式ドキュメントが移動dockerページがなくなるサポート状況不明

環境

OS:Ubuntu server 18.04 AMI HW:aws c5.large

nginxの構築

nginxのインストール

sudo apt update
sudo apt install nginx

インストールが完了したら下記の通りconfファイルを作成しexample.comを今回インスタンスを作成するドメインに修正する(serverとssl証明書の4箇所)

map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

server {
  listen 80;
  listen [::]:80;
  server_name example.com;
  root /home/mastodon/live/public;
  # Useful for Let's Encrypt
  location /.well-known/acme-challenge/ { allow all; }
  location / { return 301 https://$host$request_uri; }
}

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name example.com;

  ssl_protocols TLSv1.2;
  ssl_ciphers HIGH:!MEDIUM:!LOW:!aNULL:!NULL:!SHA;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  keepalive_timeout    70;
  sendfile             on;
  client_max_body_size 8m;

  root /home/mastodon/live/public;

  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  add_header Strict-Transport-Security "max-age=31536000";

  location / {
    try_files $uri @proxy;
  }

  location ~ ^/(emoji|packs|system/accounts/avatars|system/media_attachments/files) {
    add_header Cache-Control "public, max-age=31536000, immutable";
    try_files $uri @proxy;
  }
  
  location /sw.js {
    add_header Cache-Control "public, max-age=0";
    try_files $uri @proxy;
  }

  location @proxy {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";
    proxy_pass_header Server;

    proxy_pass http://127.0.0.1:3000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  location /api/v1/streaming {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";

    proxy_pass http://127.0.0.1:4000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  error_page 500 501 502 503 504 /500.html;
}

sslの取得

sudo apt install certbot
sudo systemctl stop nginx
sudo certbot certonly --standalone -d {ドメイン}

この後は対話型で情報入力していきます。

dockerの構築

dockerのインストール

sudo apt-get -y remove docker docker-engine docker.io containerd runc
sudo apt-get update
sudo apt-get -y install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo apt-get -y install docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo adduser $USER docker
exit    #一旦セッションを消す

dockerのビルド

cd
git clone https://github.com/tootsuite/mastodon
cd mastodon
cp .env.production.sample .env.production
docker-compose run --rm web bundle exec rake mastodon:setup

ビルドが完了すると対話形式で情報を入力していきます。途中This configuration will be written to .env.productionと聞かれた際にYesを選択その後下記のような設定ファイルが出力されるのでメモっておき処理が完了したら.env.productionにコピペして保存する。 ※このとき別のセッション等で保存後に続きの質問を続行する

# Generated with mastodon:setup on 2018-12-25 10:12:56 UTC

LOCAL_DOMAIN=m.do-a.co
SINGLE_USER_MODE=false
SECRET_KEY_BASE=xxxxxxx
OTP_SECRET=xxxxxx
VAPID_PRIVATE_KEY=xxxx=
VAPID_PUBLIC_KEY=xxxx=
DB_HOST=db
DB_PORT=5432
DB_NAME=postgres
DB_USER=postgres
DB_PASS=
REDIS_HOST=redis
REDIS_PORT=6379
REDIS_PASSWORD=
SMTP_SERVER=mail.so-net.ne.jp
SMTP_PORT=587
SMTP_LOGIN=xx
MTP_PASSWORD=xxx
SMTP_AUTH_METHOD=plain
SMTP_OPENSSL_VERIFY_MODE=none
SMTP_FROM_ADDRESS=Mastodon <notifications@m.do-a.co>

最後に下記コマンドを実行して起動

docker-compose up -d
sudo systemctl restart nginx

以上で管理者アカウントの設定まで他保守に関する設定は一切省いた構成となっているので実際に複数人数で利用する際は別途設定が必要です。

WordPressをマルチサイト化してgitを導入してみた

Thu, 02 Aug 2018 00:00:00 GMT

経緯

日頃から WordPress の改修等やっているが理想的な管理方法はないかと思い自分なりに管理環境を構築してみた。

概要

大まかな概要としては以下の通り。

WordPress をマルチサイト化
ステージング用テーマを作成
テーマディレクトリを branch ごとに管理

環境は以下の通り

Ubuntu server 18.04.1
nginx
hhvm
mysql
WordPress 4.9.7

nginx の設定

まず nginx の設定をしていく nginx で virtual host と basic 認証の設定をしていく

.htpasswd の生成

.htpasswd を生成するため下記を実行

sudo htpasswd -c -b {生成する.htpasswdのパスファイル名も含めて} {ユーザ名} {パスワード}
#例
sudo htpasswd -c -b /etc/nginx/conf.d/.htasswd hogehoge hugahuga

basic 認証と virtual host の設定

basic 認証と virtual host を設定していく下記に例を示す。

server{
    listen 443 ssl;#今回は443で待ち受けてsslを有効
    server_name stg.doany.io;#マルチサイトに使用するドメイン
    index index.php;#インデックスを有効にするファイル
    root /var/www/html;#ルートディレクトリ
    location / {
           try_files $uri $uri/ /index.php?$args;#WordPresのリライトを有効
        auth_basic "Restricted";#basic認証を有効
        auth_basic_user_file /etc/nginx/conf.d/.htpasswd;#.htpasswdのディレクトリを指定
    }
    location ~ \.php$ {#fast cgiの設定
        include fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
    }
}

nginx を下記コマンドで再起動して起動すれば OK 起動しなければ文法ミス等が考えられるので修正。

sudo systemctl restart nginx

WordPress のマルチサイト化

次に WordPress をマルチサイト化してステージング環境を作成していく。

WordPress のマルチサイトを有効化

まずマルチサイトの有効かだが wp-config.php に以下の一行を追加/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */の上あたりに追加します。

define('WP_ALLOW_MULTISITE', true);
/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */

次にマルチサイト導入の為一旦プラグインを全て無効かしてから管理画面で左メニューのツール → ネットワークの設置クリックします。そして今回はサブディレクトリを選択サイトネットワーク名等を入力してインストールをクリック画面が変わったら案内通り下記を参考に wp-config を編集※下記の htaccess は今回は nginx の為無視してください。

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'doany.io');#お使いのサイトのドメインによってかわります
define('PATH_CURRENT_SITE', '/');#こちらもWordPressの構成によってかわります
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
/* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */

再度ログインしていただいてプラグインを有効かして既存のサイトが表示されていれば OK ですまたカスタム投稿タイプ等を使用していて記事が表示できなくなった場合フロントでのリライトを無効かすると治ることがあります。

ステージング用サイトの構築

今回はプラグインを使用して構築しました。Clonerこちらをインストール後左メニューのサイトを開きステージング環境を作成したいサイトの下の Clone をクリック Create a new Site を選択その下にサブドメイン(※フルドメインは不要です)を入力 Clone Site を実行。しばらくすると処理が始まり管理画面が表示されたら完了です。
次に ftp なりで本番サイトで使用しているテーマを同じ themes ディレクトリ内に複製します。(※この時サイトネットワークから有効化しないと使用できない場合があります)そしたらそのテーマをステージングサイトで有効化します。

Git の導入

次に本番テーマを master、ステージングテーマを stg としてブランチを作り git を構築していきます。

git の導入と github への push

先に GitHub でリポジトリを作成しておいてください。作成したら ssh で入り本番用テーマのディレクトリ以下を git 管理します GitHub の案内通り git を導入していきます下記に例を示す。

git init
git add .
git commit -m "first commit"
git remote add origin https://github.com/16dyui/mywordpress.git #作成したリポジトリのurl
git push -u origin master

ステージングブランチの作成

次にステージングブランチを作成していきます。ssh で stg サイトで有効にしたテーマディレクトリに移動してくださいそこで下記のようなコマンドを実行してください。

git init
git add .
git commit -m "my first stg"
git remote add origin https://github.com/16dyui/mywordpress.git #作成したリポジトリのurl
git branch -m stg #現在のブランチをstgにリネーム
git push origin stg #stgをリモートにpush

まとめ

問題発生を防ぐ為サーバーを分けたりする場合が多いですが今回は簡易的に WordPress を git 管理する方法を紹介させていただきました。このようにマルチサイトを利用することでより簡易的に WordPress を Git 管理することができます。

postfixの導入とOP25Bの回避

Wed, 01 Aug 2018 00:00:00 GMT

概要

ubuntu server 18.04.1にてpostfixを導入しOP25Bの回避設定をしたので備忘録としてこちらに書いていく。

postfixの導入

下記コマンドを実行。

sudo apt install postfix

postfixの設定

OP25Bの回避

まずOP25Bとは簡単に説明すると25番ポートを用いて直接メールを送信するのをブロックし迷惑メールを減らすためのもので今ではほとんどのISPが導入している、その為ISPのメールサーバー等を経由(ここに関してはお使いの環境によって異なります)してメールを送信するように設定する必要がある、方法は簡単で/etc/postfix/main.cf内を下記の様に編集していく。

relayhost = [mail.so-net.ne.jp]:587 #ISPのmailサーバー
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = plain
smtp_sasl_password_maps = hash:/etc/postfix/mailpass
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_use_tls = yes
smtp_tls_CApath = /etc/ssl/certs/ca-certificates.crt #ca証明書(お使いの環境によって違います)

次に/etc/postfix/mailpassを作成下記の様に記述していく。

[{ISPのメールサーバー}]:587 {ID}:{パスワード}

次にID、パスワードをハッシュ化しpostfixを再起動して送信テストするため以下を実行。

sudo postmap hash:/etc/postfix/mailpass
sudo systemctl restart postfix
echo "Hello post" | sendmail {メールアドレス}

まとめ

以上でOP25Bの回避ができます。自宅サーバーでメールが送信できないなんてときは試してみてください。

ubuntuでhhvm+nginx+mysqlでwordpress環境の構築

Sat, 28 Jul 2018 00:00:00 GMT

経緯

環境構築の経緯だが大変間抜けな話だがubuntuのpythonコアをあろうことかpurgeしてしまい修復するにも手が付けられずまたguiからcuiに乗り換える目的から1から環境構築しなおしたので備忘録としてこちらに書いていこうと思う。

バックアップ

以下の順番でバックアップしていった

mysql
その他設定等のファイル群

mysqlのダンプ

まずmysqlだが幸いシリアルコンソールは起動したので下記コマンドにてダンプファイルを生成した。

mysqldump -u root -p {データベース名} > dump.sql

ファイルのバックアップ

live cdより起動して先ほどのmysqlのダンプファイルと自己ビルドしたnginxを使用していたため/usr/local/nginx内を全て外部メモリに保存した。この際設定ファイル等には隠しファイルや権限が必要なファイルがある可能性もあるのできおつけること。

ubuntuのインストール

次にUbuntuをインストールしていく内容はさほど凝ったものではないので飛ばし飛ばし書いていく。

Ubuntuイメージディスクの作成

今回はUbuntu server 18.04.1を使用した。下記よりダウンロードしwindows7以降ならWindowsディスクイメージ書き込みツールが搭載されているはずなのでそちらで焼いた。 Ubuntu server

Ubuntuのインストール

まずUbuntu serverを起動するこの時点では知らなかったのだが今のUbuntu serverはEFIブートするらしいのでわざわざ書き込みツール使う必要もなかったのですがまあいいでしょうインストールを進めていきます。EFIで起動したら黒い画面に白字で選択画面がでるのでInstallなんちゃらを選択する。今は便利でCUIながらグラフィカルなインストールのマネージャーが上がるので以下に手順を簡単に示す。

Englishを選択。
キーボードレイアウトを選択
Install Ubuntuを選択
セットアップに使用するネットワークI/Fを選択(今回は優先でオンボードのドライバが当たっていたので特に何も設定せず進めた)
仕様するプロキシーの設定(今回は特別に設定はしてない)
ミラーアドレスの設定(こちらも今回特別に設定はしていない)
ディスクの構成(今回は得に考えずUse An Entire Diskを選択)
インストールするディスクを選択
ディスクの構成(今回は特に考えず自動設定のまま進めた)
ユーザー等の設定
サーバーパッケージ(?)詳しくないのでよくはわかっていないが代表的なサーバーのパッケージを自動セットアップできる(今回は特に選択無し)
インストールが完了したら再起動します

Ubuntuの設定

ubuntuが起動したらユーザー名とパスワードを打ってログインします。

ipの固定

ローカルipを固定してポートフォワードを設定していたのでipを固定します。インストール時に実は設定できたのですが知らなかったので後から設定します。/etc/netplan/50-cloud-init.yaml以下を編集します。

network:
    ethernets:
        {デバイス}:
            addresses: [{ipアドレス}]
            dhcp4: true
    version: 2

設定の適用は

sudo netplan apply

sshポートの変更

デフォルトのポート(22)で使用していた際海外からのアクセスが集中し認証できなくなるという事態が発生したのでポートは絶対に変えておきましょう。/etc/ssh/sshd_configの記述を変更。念のためテストしようと思ったのですが、以前のキーが残っていると接続できないので厳密にはそれぞれキーを再生成すべきなのですがめんどくさいので~/.ssh/known_hostsを削除しました(非推奨)

Port {ポート番号}

sslの取得

通常だとnginxのインストールが先な気がしますが今回はssl化が前提なので先にsslを取得していきます。

certbotの導入

下記コマンドを実行。

sudo apt update
sudo apt install software-properties-common
sudo add-apt-repository universe
sudo add-apt-repository ppa:certbot/certbot
sudo apt update
sudo apt install certbot

証明書の取得

今回は複数ドメイン+サブドメインを同時に証明書取得したいと思います。下記既にcertbot-auto導入済みなので下記コマンドを実行-dの後ろはドメイン(今回は二つ指定)-mの後ろはメールアドレスに適宜書き換えてください。

sudo certbot certonly --agree-tos --no-eff-email --manual-public-ip-logging-ok --manual -m {メールアドレス} -d {ドメイン} -d {ドメイン}

次に下記の様な案内がでますのでネームサーバーのtxtレコードに案内の通り設定していきます。もし-dを2つ以上設定していた場合下記の様な案内が出た後エンターを押す度指定したドメインの数だけ案内がでますので全てtxtレコード設定してください。※最後の案内が出た後エンターを押さないでそのままにしてください。

Please deploy a DNS TXT record under the name
_acme-challenge.siteyui.site with the following value:

lb0hNdyPwXpftFbkZcIVsXIyQFxd5bzmTKrKQJlGqMs

Before continuing, verify the record is deployed.

設定が終わりtxtレコードが反映完了したらエンターを押してください。反映されていない段階でエンターを押したりエラーが出た際には上のコマンドを再度実行して1から設定しなおしてください。また下記コマンドでtxtレコードの状態を確認できます。ドメイン名のところはサブドメイン無しのドメインを入れればすべてのレコードが見れるはずです。

dig -t txt {ドメイン名}

mysqlのインストール

先にmysqlをインストール設定していきます。下記コマンドを実行。

sudo apt install mysql-server

mysqlの初期パスワード設定

本来は非推奨らしいのだがセキュリティプラグイン周りは詳しくない為平文で直接テーブルを書き換える。

sudo mysql

mysql>ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '{パスワード}';

mysqlでのインポート

テーブルを作ってエクスポートの逆をやるだけ。

mysql -u root -p

mysql>CREATE DATABASE {データベース名};
mysql>exit;

mysql -u root -p {データベース名} < {ダンプファイル}

hhvmのインストール

今回はphpの代わりに速度改善の為にhhvmを入れていきます。下記コマンドを順次実行。

sudo apt update
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xB4112585D386EB94
sudo add-apt-repository https://dl.hhvm.com/ubuntu
sudo apt update
sudo apt install hhvm

nginxのインストールとセットアップ

他記事等ではaptでのインストールだとバージョンが古いと書かれているものもありますが2018/07/28現在1.15.2がインストールされるので問題ないです。下記コマンドを実行

sudo apt install nginx

nginxの設定

nginxの設定をしていくaptでインストールした場合は/etc/nginx/conf.d以下に拡張子.confでファイルを作成すれば自動的に読み込まれる今回は下記の様な設定を行ったので簡単に説明していく。

server{
    listen 80;#80番ポートで待ち受け
    server_name .siteyui.site;#.でスタートするとドメイン+サブドメイン全てが対象
    return 301 https://$host$request_uri;#httpsに全て301リダイレクト
}
client_max_body_size 100m;#自分の環境ではwordpressのメディアアップロード時エラーが出ていたため明示的にリクエストサイズを指定
ssl_certificate /etc/letsencrypt/live/siteyui.site/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/siteyui.site/privkey.pem;#先ほどcertbotで取得した証明書の設定
server{
    listen 443 ssl;#443で待ち受け&SSLを有効
    server_name tv.siteyui.site;
    location / {
        auth_basic "Restricted";#ベーシック認証を使用
        auth_basic_user_file /etc/nginx/conf.d/.htpasswd;#id,pwファイルの指定
        proxy_pass http://192.168.0.2;#プロキシの設定
    }
}
server{
    listen 443 ssl;
    server_name siteyui.site;
    index index.php;#indes.phpにインデックスを有効
    root /var/www/html;
    location / {
           try_files $uri $uri/ /index.php?$args;#スラッグでのアクセスをクエリに変換(wordpress用)
    }
    location ~ \.php$ {#hhvmの設定
        include fastcgi_params;
        fastcgi_pass 127.0.0.1:9000;
    }
}

最後に

以上となりますがセキュリティ的におすすめできるような内容ではないので後学の為にも指摘等頂けると大変助かります。

クレジットカード番号の検証

Fri, 27 Jul 2018 00:00:00 GMT

はじめに

普段目にしているクレジットカードの番号ですがこれにも様々なルールやセキュリティ対策がなされています。今回はそれについて説明していきます。

番号の概要

まずクレジットカード番号がどのように構成されているかですがクレジットカード番号はISO/IEC 7812にて策定されており、6桁のBIN（Bank Identification Number, 銀行識別番号）もしくはIIN（Issuer Identification Number, 発行者識別番号）+残りの番号はイシュアによって決定されます。

BIN、IINについて

BIN、IINもまた複数要素で構成されており最初の1桁はMII（Major industry identifier, 主要産業識別子）と呼ばれており、カードを使用する業界を示し対応表を下記のとおりです。

MII値	産業
0	ISO予約値
1	航空
2	航空 / その他将来発生する産業
3	旅行・娯楽/銀行・金融
4	銀行・金融
5	銀行・金融
6	運送 / 銀行・金融
7	石油 / その他将来発生する産業
8	ヘルスケア / 医療 / 通信 / その他将来発生する産業
9	国毎に割り当て可能

また以下は主な過去に存在していた若しくは現在存在するBINのリストです。

カードの種別	プレフィックス	番号長	検証
American Express	34, 37	15	Luhnアルゴリズム
中国銀聯 (China UnionPay)	622126-622925, 624-626, 6282-6288	16	なし
Diners Club International	300-303574, 3095, 36, 38-39	14	Luhnアルゴリズム
Discover Card	60110, 60112-60114, 601174-601179, 601186-601199, 644-649, 65	16	Luhnアルゴリズム
JCB	3528-3589	16	Luhnアルゴリズム
MasterCard	510000 - 559999, 222100 - 272099	16	Luhnアルゴリズム
UATP	1	15	不明
Visa	4	13, 16	Luhnアルゴリズム

チェックディジットに関して

クレジットカード番号にはLuhnアルゴリズムが使用されており、主な目的として連番での発行をさせず、入力ミス等で他人のカードが決済されるのを防ぐためだと推測される。但しこれは計算可能な為悪意のある決済を防ぐ為のものではない。

セキュリティ面での検証

以上のルールを踏まえ当方が検証した内容を記述する。

検証概要

近年ではApple Pay等でクレジットカード番号の下4桁が管理用に表示され尚且つApple Payの場合クレジットカードデザインからある程度イシュアが特定可能な為そこからクレジットカード番号が推測できないか検証してみた。

BIN,IINの特定

まずカードデザインよりBINを特定してみる、BIN等は公にはされていないが以下サイト等で調べることができるがカード会社によっては途方もないBINの登録がありこの時点でカード番号を特定できるイシュアーが限られてくるが続きはBINが特定されたものとして進めていくBIN search

カード番号の特定

BINが特定されたものとして話を進めていきます。この時点で6桁のBIN+下4桁が判明していることになります。ここで全てのLuhnアルゴリズムに当てはまる数字を算出してみました(今回は16桁で)下記サイトでチェックしましたがゆうに100件を超えており特定が不可能でした。credit card number generator

まとめ

以上の通りスクリーンショットやレシート画像等から番号特定は現実的にはほぼ不可能という結果になりましたまた近年ではセキュリティコードの必須化や3D secure導入等が進んでおり仮に割れたところで現実的には決済できる加盟店は存在しないでしょう。