それマグで!

知識はカップより、マグでゆっくり頂きます。 takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。

systemd で引数で分割を使う(@:アットマーク)ユニットのテンプレート化で似たような複数サービスをまとめる。

systemd で引数を使う

@:アットマークを使えば、ユニットのテンプレート化で似たようなサービスをまとめることができる。

systemd の list-units をすると、user@1001.service のように、ユニット名@値 でいくつも起動しているので、自分でもそれを作って使えるようにしてみる。

テンプレート化された systemd ユニットの例

一番手軽に確認できるのは、 ユーザー毎の systemd だと思います。

 systemctl  --user status

これで確認すると、ユーザーの id ごとのジョブになっていることがわかります。

user@1001.service の設定元は、次のようなファイルです。ユニットのファイル名に@アットマークを入れることでテンプレートを明示しているみたいです。

user@.service

f:id:takuya_1st:20200924174028p:plain

実際に作ってみる。

今回は、システム全体ではなく、ユーザー毎のsystemd で試してみたいと思います。

ユーザーごとの systemd ユニットは、過去の記事に書きました。 → ユーザー毎の systemd を使ってシステム全体設定と個人用設定を分ける

ファイルの作成をします。

ユーザー空間に、ユニットファイルを作成します。

mkdir -p ~/.config/systemd/user/
touch ~/.config/systemd/user/my-loop-template@.service

このときに、名前に@ アットマーク を入れるのがポイントです。

my-loop-template@.serviceを編集します。

%i が引数として処理されます。

[Unit]
Description=テンプレートなサービスを作成する練習。 %i 秒スリープします

[Service]
ExecStart=bash -c 'while : ; do echo loop ; sleep %i ;done '

[Install]
WantedBy=default.target

テンプレートを実際のユニットとして登録します。

 systemctl  --user enable my-loop-template@10.service

すると、次のようなリンクが作られて、systemd ユニットが作成されたメッセージが出てきます。

Created symlink /home/takuya/.config/systemd/user/default.target.wants/my-loop-template@10.service
 → /home/takuya/.config/systemd/user/my-loop-template@.service.

サービスを開始します。

 systemctl  --user start my-loop-template@10.service

状態を確認します。

 systemctl  --user start my-loop-template@10.service

無事に、引数を決めたサービスが起動しているのがわかりす。これで引数つ変えるようになりました。

似たようなサービスをまとめて管理できることがわかります。

f:id:takuya_1st:20200924174836p:plain

もうひとつ起動してみます。

テンプレートとして動作しているのを確認するために、もう一つのサービスを作りながら、手順をおさらいします。

takuya@vps:~$ systemctl  --user start my-loop-template@100.service
takuya@vps:~$ systemctl  --user status my-loop-template@100.service
● my-loop-template@100.service - テンプレートなサービスを作成する練習。 100 秒スリープします
     Loaded: loaded (/home/takuya/.config/systemd/user/my-loop-template@.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-09-24 17:50:57 JST; 4s ago
   Main PID: 224128 (bash)
     CGroup: /user.slice/user-1001.slice/user@1001.service/my\x2dloop\x2dtemplate.slice/my-loop-template@100.service
             ├─224128 /usr/bin/bash -c while : ; do echo loop ; sleep 100 ;done
             └─224129 sleep 100

Sep 24 17:50:57 vps systemd[223671]: Started テンプレートなサービスを作成する練習。 100 秒スリープします.
Sep 24 17:50:57 vps bash[224128]: %

アットマークを複数入れてた場合

複数の@マークをいれれば、2つ使えるとかそんなこともないようです。 f:id:takuya_1st:20200924180235p:plain

タイマーで使う場合。

timer ユニットで使う場合は、どうなるでしょうか。試してみたいと思います。

結論を先に言えば、timer ユニットで使う場合は、一つずつサービスを起動は不要でした。

タイマーユニットを作成します。

@を名前に入れてテンプレートで作成しますします。

~/.config/systemd/user/my-loop-template@.timer

[Unit]
Description=My %i timer Sample

[Timer]
OnCalendar=minutely
RandomizedDelaySec=20
Unit=my-loop-template@%i.service

[Install]
WantedBy=default.target

タイマーユニットを有効にします。

タイマーユニットを引数付きで開始します。

 systemctl --user start my-loop-template@100.timer

すると、サービス側も有効になっていることがわかります。

f:id:takuya_1st:20200924183727p:plain

参考資料

redj.hatenablog.com

コマンドが存在するか調査するコマンド、その名もcommand

コマンド存在スルか調査するコマンドに command が使えます。

$ command -v ls ; echo $?
alias ls='ls --color=auto'
0

シェルの実行結果は 1/0 で戻されています。

echo $? は直前のシェルの実行結果$? を出力しています。正常終了なら0 異常終了なら $? > 0 が返されます。

あるとき

$ command -v ls ; echo $?
alias ls='ls --color=auto'
0

ないとき

command -v lsaaa > /dev/null  ; echo $?
1

command コマンドとは?

commandコマンド はその名前の通りコマンドを実行するプログラムでもあります。

$ command php -v
PHP 7.4.9 (cli) (built: Aug  7 2020 14:55:48) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.9, Copyright (c), by Zend Technologies

マニュアルにもある通り、通常は type を使います。

ヘルプには、次のように書いてあります。

-v コマンドの詳細をプリントする、これは 組み込みの type コマンドと同じ機能です。

なので、通常は type を使えばいいと思います。

type と command の違い

type は STDERRに出力されます。

$ type lsaaa
-bash: type: lsaaa: not found

command コマンドは、何も出ません

$ command -v  lsaaa
$

bashrc などに書くときに、シェルのリダイレクトの書き方に差が出ます。

type では stderr を消さなくちゃいけないのに対し、command コマンドを使うなら、リダイレクトは1つで済みます。

command -v  lsaaa > /dev/null    && echo exists
type lsaaa > /dev/null  2>/dev/null  && echo exists

マニュアル

help command
command: command [-pVv] command [arg ...]
    Execute a simple command or display information about commands.

    Runs COMMAND with ARGS suppressing  shell function lookup, or display
    information about the specified COMMANDs.  Can be used to invoke commands
    on disk when a function with the same name exists.

    Options:
      -p    use a default value for PATH that is guaranteed to find all of
            the standard utilities
      -v    print a description of COMMAND similar to the `type' builtin
      -V    print a more verbose description of each COMMAND

    Exit Status:
    Returns exit status of COMMAND, or failure if COMMAND is not found.

検索エンジンの最適化による 困った問題

commandコマンド はその名前の通りコマンドを実行するプログラムでもあります。 しかし、その名前が「あまりに汎用的」な名前であるために、検索でキーワード無視されたり、インデックスの結果をうまく取り扱ってもらえません。

つまり、とっても検索をしにくい名前なんですね。

WEB口座振替とかいう、インターネットバンキングとはまた別の機能について。

WEB口座振替という闇

インターネットバンキングと口座振替は、別の機能です。そのことがわかる画像をキャプチャしたので共有します。

4桁暗証番号と銀行口座の番号で口座振替が完結するのでは?という銀行がいくつか有ることが判明しています。

つまり、インターネットバンキングのログインとは「別機能」で、口座振替のWEB申し込みを提供している都市銀行があるのではという話にもなります。

なので、クレジットカードを新規作成して、口座振替を申し込みしてみました。

口座振替を申し込んでみた。

楽天カードを作って、口座振替を依頼してみしてみました。

楽天カードで申し込み画面を完了し、口座振替の登録画面に移行したところです。楽天カードからのWEB口座振替、やってみた。

この申込は生年月日を入力するだけ完結しました。

口座振替の申込みを開始する画面

最初の画面では口座振替の申込みを開始する画面です。画面が大きく分け、2つの機能があります。

インターネットバンキングのログイン、「口座番号+4桁暗証番号」でログイン、この2つの機能があることが画面から見て取れます。*1

2つの機能が並列している。

口座番号と暗証番号が上方にあるので、「口座番号+4桁暗証番号」がメインの機能と想像できます。

f:id:takuya_1st:20200915133943p:plain:w300

口座番号と暗証番号でログインしてみます。

すると、口座振替の申し込みの画面に遷移します。

「本サービスにより、書類を提出することなく口座振替契約の受付が完了します」と書かれています。

f:id:takuya_1st:20200915133309p:plain:w600

本人確認は、生年月日

生年月日で本人確認します。生年月日。。。ですか。

f:id:takuya_1st:20200915134505p:plain

この銀行は「ワンタイムパスワードが必要」と書いてありますが、口座振替は生年月日だけで完結しました。

4桁暗証番号をインターネットで入力するという暴挙

銀行のキャッシュカードを、「多要素認証」のスキームで展開すると、カードを持っている(所有)と暗証番号を知っている(知識)の2要素認証になっています。

キャッシュカードの4桁暗証番号は、銀行ATMではネットワーク経由で暗証番号のチェックをしているとはいえ、WEBのような開かれたネットワークで入力するものではないですよね。そもそもこの設計がおかしいと言えます。

インターネットで、カードを持たずに4桁の暗証番号を入力する行為、これは認証として褒められたものではないのです。「銀行はSMSやメールなどを追加認証で求め、暗証番号と併せて入力する」でセキュリティを確保すると報道発表をしていますが、本気なのだとしたら、セキュリティの基本である「認証」を理解していないと言っても過言じゃないのでしょうか。

WEB口座振替とインターネットバンキングのログインは別もの

ログイン画面からわかるように、インターネットバンキングとWEB口座振替は「別物」として機能していると考えても大丈夫でしょう、内部的にいくつかモジュールを共有しているとしても、画面設定から読み解く限りにおいて、インターネットバンキングを申し込んでいない人でも「口座振替」は使えるように開放していると考えられます。

その際に、本人確認で求めるものが、生年月日と口座番号と4桁暗証番号というのは、恐ろしい限りです。

危ないWEB口座振替 

「口座番号+暗証番号+生年月日」で本人確認とするのは、インターネットのシステムとしては、危ない。本当に危ない危機的状況にある。そもそも。「口座番号+暗証番号+生年月日」は認証と呼べるのでしょうか。銀行によっては「口座番号+暗証番号」だけで申し込みが完結することもあります。ドコモ口座が問題というより、銀行が根本的に誤っているとおもいませんか?ウェブから口座引き落としの申込みが「口座番号+暗証番号+生年月日」で完結ですよ?口座振替なので金額に上限がないんですよ?危なっかしいどころの話じゃないですよね?

ATMではカードの所有を確認している。

ATMで暗証番号を入れますが、そのままシステムに送られます。銀行システム視点でみるとATMからは「口座番号+暗証番号」が送られてきます。この点だけを見て、WEB機能をインターネットに展開しているのでしょう。

ATMでは「所有」を確認しています。この所有確認があるからこそATMに「カメラ」を設置して抑止力の効果もあるのです。

銀行から見た通信が「口座番号+暗証番号」とはいえ、インターネットでは所有確認がないので「パスワードの強度」で勝負するしか有りません。銀行さん警察さん金融庁さんは、そのことをまるでわかってないのではと、いつも首を傾げます。

口座番号は公開情報

そもそも、口座番号は「住所」や「電話番号」と同じく、公開して使う個人情報です。公開しているので振込を受けることができます。口座番号はフォーマットが定められており、店番号+7桁で、古い口座ほど番号が若いことから考えるとある程度連番になっていると想像できます。

生年月日はほぼ公開情報

生年月日は、名簿屋などの個人情報で入することもできる程度のものです。パスワードのように「当人以外知り得ない」という「知識」の認証に使えるような、強固な秘匿情報では有りません。例えば結婚式準備で結婚式場に見学にいく、結婚指輪を買いに行く、ユニクロに会員登録するような場面で、生年月日を記入するように、生年月日はとてもカジュアルにやり取りされる個人情報です。生年月日は気軽に入手できます。

また、特定の手続きをふめば、生年月日が記載された住民票をお役所で閲覧さえも不可能では有りません。生年月日は公開している情報だと思っても過言ではないかと思います。

生年月日のうち誕生日を見つけるには

仮に生年月日を知らなくても、4桁の暗証番号を誕生日にしている人を探すことができます。ブルートフォースアタックですね。総当りすればいいのです。

ただし、4桁暗証番号は3回の間違いでロックされます。そこで、先程の口座番号が規定フォーマットでほぼ連番になっている前提が使えるのです。

暗証番号を誕生日の1203にしている口座をさがすために、暗証番号に1203を入力し、口座番号を順番に変えていけばいいのです。

パスワードの部分ではなく、口座番号を変えるような一般的なブルートフォースアタックとは入力が逆になるのでリバースブルートフォースアタックと呼ばれます。リバースブルートフォースアタックで「口座番号+暗証番号+生年月日」のうち、口座と暗証番号と月日までが特定されてしまいます。

暗証番号から生年を憶測する

生年月日をたとえ知り得なくとも、暗証が1203の口座をいくつか先に見つけておき、生年のところをランダム変えていけば、100通りくらいですよね。

銀行口座にたくさんお金をいれていて、なおかつ生年月日を暗証番号にしているような年代のひとは、インターネットへのセキュリティへ意識が全く低いのでこっそり口座振替しても気づかない可能性が高いです。 そういうひとは、2000年以降生まれではないでしょう。また1990年以降生まれでもないでしょう。1970以前で十分だと思われます。また90歳以上のひとも死んでいる可能性が高いので除外します。また日本の人口分布を考えると、団塊世代団塊ジュニア世代(氷河期とバブル世代)がおもなターゲットに据えられるでしょう。したがって生年は1930-1970のおおよそ40通りです。

つまり、暗証番号が「誕生日」の愚か者の口座番号で、かつ、1930-1970生まれを探せば、かんたんにカモれそうです。

40回に一回あたるガチャと考えれば、暗証番号が誕生日の口座を1000件くらい調べ上げておけば、1つくらいは生年も当たりそうですよね。

40回1回でも当たる確率は、外れる確率の余事象 1-(39/40)40 = 0.634 なので、1000件くらいも誕生日が暗証番号の口座番号を調べ上げて入手しておけば、一つくらい当たりそうです。

一つの口座で3回間違えたらアウトとして、2回まで試せるとかんがえれば、もうすこし確率を上げられそうですよね。

ミドリのイタチの銀行は。。。誕生日入力の失敗ではロックされない。

今回画面キャプチャを撮っているときに、うっかり、生年月日を間違えて画面が終了してしまいましたが、10分経てば、再度生年月日を入力することができました、いちど暗証番号で通るとアカウントはロックされるわけじゃなく取引が中断されるっぽいですね。

f:id:takuya_1st:20200915142048p:plain

というとは、リバースブルートフォースアタックで暗証番号と口座番号を割り出されると生年月日を果てしなく調べ上げることも可能なのかもしれない。ログが残るから何度も試行すると攻撃扱いされるでしょうが、ロックされるわけじゃなく取引が停止なので、3回位の総当りはできちゃうということでしょうかね。

WEB口座振替の機能はほんとうやばい

ここまでで、WEB口座振替というインターネットバンキングとはまた別の機能があることがわかりました、また暗証番号4桁と誕生日で十分だと銀行が考えているとわかります。本気なのでしょうか。WEB口座振替は暗証番号が生年月日のような単純な口座だと、第3者が引き落としの口座登録が出来てしまうこともわかりました。WEB口座振替の認証機能は、ほんとうに危険ですね。そしてそれはインターネットバンキングを使ってない人にも提供されるために停止する手段がありません。

インターネットバンキングは、「フィッシング詐欺」にご注意くださいと盛んに注意喚起していて、「ドコモ口座」の不正な口座振替についてもフィッシング詐欺のサイトURLを踏んだんでしょと警察はたいおうするでしょうが、そもそも「暗証番号」をWEBで入力させる行為そのものが「危険行為」なわけで。銀行さんは「当行自慢のセキュリティ」と「誤安心」させるようなWEBページを作っている暇があれば、とっとWEB口座振替を暗証番号+口座番号ではなく、インターネットログインID+十分に長いパスワードに変えるべきだと思うんですよね。

インターネットバンキングと、WEB口座振替は別機能で提供されるゆえに、インターネットバンキングで有効なセキュリティ対策をいくらやっても全く効果が上がらないんですね。

SMSの2段階認証とかもあまり褒められたものではなく、まず口座番号でログインをやめるべきだと思うんですよね。

どこが落とし所だったか。

婚姻届による姓名の改姓や、LGBTの通称通名なども斟酌すれば、「名義人名」で本人確認するというものちょっと時代遅れ感もあるし、婚姻の形態も様々あります。家族や同居人名義で口座振替することもあると思います。そうなると、WEB口座振替で名義人の一致をみるというもの窮屈な感じがします。

とすると、マイナンバーのような一意のIDによる紐付けでしょうが、紐付けは強烈すぎて、流出による無秩序な紐付けの懸念があります。濫用ですね。また誤用も怖いです。マイナンバーのような一意IDを入力すれば本人とみなすような誤用が起こりかねません。マイナンバーを知ってるのは本人だけという謎の暗黙の前提のシステムが出来上がってしまう懸念もあります。

とかんがえれば、WEBによる口座振替のドコモ口座登録での落とし所は、「本サービスにより、書類を提出することなく口座振替契約の受付が完了します」ではなく、「申込みが完了します、詳細は書類を郵送します」というアナログ手法に頼ることだったと思います。書類を返送するか、書類が郵送完了した時点で本人確認完了と見做す、ような「受付」に限定した方が良かったのかもしれません。

または、本人確認と口座登録を分ける必要があったかもしれません。

ドコモ口座の何が問題だったのか。

そしてWEB口座振替による「口座登録」ができれば本人確認としてドコモ口座やペイペイなど決済サービスが使えるようになります。やばいですよね。ドコモ口座事件の問題は銀行が提供しているWEB口座振替にあるわけです。

ドコモ口座は「口座登録」によるアカウント有効化と、「口座登録」によるチャージを有効化をWEB口座振替で1度に済ませていました。問題があるとしたらこの点です。でも、口座登録で本人確認を済ませるのでいいと決済サービスのガイドラインで定めらています。銀行がちゃんとWEB口座振替で本人確認をしている前提に立っています。銀行のWEB口座振替がザルなのです。ドコモ口座は、むしろ被害者と言えませんか。

ドコモ口座がわるい、ドコモが補償すべきという、私のようなドコモ株主からすると、許せない事態になっています。どうかんがえてもWEB口座振替で4桁暗証番号を入力させるという暴挙をおこなっている銀行側に問題があるんです。補償するならドコモから100%ではなく、銀行が9割位の責任割合じゃないのかなと個人的には考えます。ドコモが自社で補償するなら株主利益の毀損だと思います。

そもそもドコモはなぜdアカウントを一般開放したのか。

これは、私が数日前に登録した dアカウントなのですが、ドコモ回線の紐付きdアカウントでは有りません。 登録完了メールの問い合わせ先が 「151」となってるところが、実に「ドコモ回線に限定したdアカウント」の名残だと思われます。

f:id:takuya_1st:20200915144034p:plain:w300

このような回線保持者に向けたアカウントサービスだったdアカウントですが、ドコモではdTVやdアニメなどサービスは徐々ではありますが、一般に開放されつつありました。

しかし、決済まで一気に開放する必要が生じた事件があります。それが消費税還元キャンペーンです。

消費税還元キャンペーンが諸悪の根源

消費税還元キャンペーンがはじまり各社がこぞってアカウントを開放し、ポイントカードを決済サービスに昇格させたあたりから世の中がおかしくなっていませんか。

QRコード決済サービスと還元キャンペーンは本当に必要だったんでしょうか。わたしは消費税を減税すべきだったのではないかと今でも思います。

7pay の事件もコーナンpay の事故も今回のドコモも元をたどれば、消費税還元キャンペーンです。消費税還元キャンペーンでばら撒きに各社と人々が躍らされた結果なのでしょう。しかもデジタル庁が存在しなく、高市早苗総務大臣と菅官房長官と西村経済再生大臣という、IT音痴がトップで内閣政策が現実のITや法制度とそぐわない設計だったのに、無理にやりすぎた結果かなぁと、未来に漠然とした不安を覚えるのです。

そう考えると、責任は銀行と内閣のキャンペーンにも数割あると思うのですが、ドコモだけが一方的に悪いドコモコウザが悪いみたいな言い方、各報道のされ方はコロナ禍における報道禍と同じようにNHKとマスコミの弊害なのかなと思います。

ドコモは消費税還元キャンペーンに躍らされ、菅官房長官にキャリアは高すぎると締め上げられた結果、他サービスに活路を見出す他なく、アカウントサービスと決済サービスに進出したら、その決済サービス関連で銀行がありえない認証だったわけで、むしろ政権のデジタル化遅れの被害者にすら思えてくるわけです。

*1:例として出しているキャプチャは、2020/09/15日ではまだ問題が起きていないとされるミドリの銀行です

LXC 内部で docker を動かす。 ( docker in LXC container )

LXC 内部で docker を動かす。

既知の問題点 lxc 内部で docker は動かない ことがある

調べた結果、次の条件で動かない。

  • docker のoverlay2 が lxc デフォルトzfs で動かない
  • docker のoverlayがありlxc 内部でsnapcraft-docker を使うと動かない。
  • docker の権限管理がLXC のデフォルトで動かない。

今の処分っている問題点は、overlay2 の関するものなので、zfs を避けると動く

ただし、snapcraft で docker を入れると動かない。 snap でインストールされる docker のバージョンの問題なのか、 snap が管理するストレージがネストしててやばいのか。

そのへんはまだよくわかってない

ということで docker in LXC のポイント

  • snapcraft の docker は動かない
  • lxc の特権コンテナが必要
  • LXCストレージでZFSでDockerは動かない

このポイントをクリアすると動作しました。

こうすればひとまず動く

btrfs のストレージを作る。

lxc storage create bt01 btrfs

docker を動かすLXCコンテナを ubuntu のLTSから作る

lxc launch ubuntu:20.04 docker-host --storage bt01

LXCのコンテナに対していくつかの権限設定をする。

lxc config set docker-host security.privileged true
lxc config set docker-host security.nesting true

新しい権限で、LXC コンテナを起動し直す。

lxc restart docker-host

Ubuntu LTS のコンテナに対して apt 更新を掛ける。

lxc exec docker-host apt update 
lxc exec docker-host apt upgrade  

これでbtrfs で作ったストレージにコンテナを立ち上げたので、その内部で docker をインストールしてみる

lxc exec docker-host apt install docker.io

インストールした docker で hello-world をしてみる。

lxc exec docker-host docker run hello-world

やったね、無事にrun docker in LXC container ができたよ。

docker run hello-world を試す。

lxc exec 経由で docker run を試す。

lxc exec docker-host docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
0e03bdcc26d7: Pull complete
Digest: sha256:d58e752213a51785838f9eed2b7a498ffa1cb3aa7f946dda11af39286c3db9a9
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/

For more examples and ideas, visit:
https://docs.docker.com/get-started/

無事に動いたときの設定などをメモっておく

LXC ホスト

takuya@:~$ lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 20.04 LTS
Release:    20.04
Codename:    focal

LXD バージョン

takuya@:~$ lxc version
Client version: 4.3
Server version: 4.3

LXC コンテナ

takuya@:~$ lxc exec docker-host -- lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 20.04 LTS
Release:    20.04
Codename:    focal

Docker バージョン

takuya@:~$ lxc exec docker-host docker version
Client:
Version:           19.03.8
API version:       1.40
Go version:        go1.13.8
Git commit:        afacb8b7f0
Built:             Tue Jun 23 22:26:12 2020
OS/Arch:           linux/amd64
Experimental:      false

Server:
Engine:
  Version:          19.03.8
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.8
  Git commit:       afacb8b7f0
  Built:            Thu Jun 18 08:26:54 2020
  OS/Arch:          linux/amd64
  Experimental:     false
containerd:
  Version:          1.3.3-0ubuntu2
  GitCommit:
runc:
  Version:          spec: 1.0.1-dev
  GitCommit:
docker-init:
  Version:          0.18.0
  GitCommit:

2023-10-06 追記

docker compose で mailcow を上記の状態で up down したら

などとなり、OS起動時は動くのに、docker 側で down -> up するとエラーになった。

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: failed to write "a *:* rwm": write /sys/fs/cgroup/devices/docker/3cf0487fa80fd2a06f4a61b7c5ae58231db463e2a922bd28ca4a7abb00247b18/devices.allow: operation not permitted: unknown

なんとなく、以前のdocker on lxc で使っていた raw.lxc を書き直したらエラーが出なくなった。

  raw.lxc: |-
    lxc.mount.auto=proc:rw sys:rw cgroup:rw
    lxc.cgroup.devices.allow=a
    lxc.cap.drop=

ailed to write "a : rwm": write /sys/fs/cgroup/devices/docker

devices.allow … operation not permitted` in privileged container

Cannot start hello-world in LXC conatiner

なんでLXCコンテナの中でDockerを動かすのか。

特に理由はない。なんか面白そうだから。

強いてあげるなら、docker / docker-compose したコンテナを長期間動かすと、メンテがめんどくさいから。

docker/docker-compose を使ってると、コンテナが増えすぎてどのコンテナがどのサービス用なのかゴチャゴチャになってわからなくなる。巷ではdocker の管理UIをdocker run すとかもあるみたいだけど、それもなんか違う気がするし、docker のコンテナとボリュームが稼働しているマシンを別のマシンに移動させたり、バックアップを取得したり、そういう管理が本当にめんどくさい。

docker ってパパっとインスタンスを立ち上げて使い捨てるには本当に便利なんだけど、長期間動かすのには向いてない気がする。ちょっとパフォーマンスが足りないからCPUやメモリを潤沢にした新サーバーに移動しようとか、さくらのVPSの別の契約に移動しようとか、そういうことをやろうとして本当に苦労した。なのでdocker を、LXCとかlibvirt+kvm に閉じ込めておくほうがライブマイグレーションができて便利だと思った次第。

docker は開発用に実験環境を作るのは本当にすばらしい。docker でインスタンスをサクッと立ち上げるのもスラバシイし、デプロイ時にデータボリュームとソースコードの領域を分けられるのも素晴らしいと思うんだけど、データボリュームをいちいち移動するのとか、デプロイ設定を書き換えるのが面倒じゃないですかね。まぁGoogleAmazonを使えばいいんだろうけど。

LXC/LXDとかsystemd-nspawn とか名前空間を使った実行に docker が対応すべきだと思います。はい。個人的な意見ですけど。

個人的な意見ですけど、docker はソフトウェア開発の環境にすごく向いている。LXC はサーバーの実験環境をつくるのにすごく向いている。と思います。

そもそも docker run したインスタンスを長期間運用するとなると、バージョンアップとかコンテナのベースになってるイメージの更新とかあるので、dockerfile だとか docker-compose をよーく読んでvolume をよく考えないといけない。その作業がもうめんどくさい。

nextcloud や mattermost や gitlab をdocker で起動して痛い目にあった

LXC のコマンドで基本操作 / lxc でイメージ検索とインストール / centosとubuntu

LXC のイメージについて。

LXDは仮想マシンの「統合管理」的なものなので 、docker のようなコンテナ、vbox のような仮想マシン、この2つを管理できる。コンテナは lxc のコンテナ、インスタンスqemu仮想マシンを扱えるようですね。

docker と違って lxc で起動すると、systemd がはじめから起動しているので、docker より扱いやすいです。

docker のようにストレージをレイヤ管理しないし、より「普通の仮想マシン」にちかいので、長期間運用するようなホストに向いていると思います。

「systemd が動いてる docker 」がほしいと思った方は lxc を選ぶと幸せになれるでしょう。

LXC のコマンド

LXC / lxd のコマンドは、現在は、lxc のコマンドとサブコマンドに統合されています。

lxc list 仮想マシン・コンテナの一覧

lxc list 

LXCで新規作成と終了と削除

新規作成

lxc launch ubuntu:18.04 myFirstContainer

このコマンドは、次のようになってる

lxc launch イメージ名 自分で決めるホスト名

停止・再起動・開始

lxc stop myFirstContainer
lxc restart myFirstContainer
lxc stop myFirstContainer

削除

削除は、停止後に出来ます。

lxc delete  myFirst

コンテナ環境内に入る

コンテナの中に入るには docker と変わりません。

lxc exec myFirst bash 

exec で任意のコマンドを実行できる。

lxc exec myFirst sh
lxc exec myFirst login
lxc exec myFirst systemctl status  sshd
lxc exec myFirst systemctl status nginx

イメージの検索について

LXDにビルトインされているイメージ用リモートサーバーの名前空間は、ubuntu のlxc では、次の3つです。

ubuntu:
ubunt-daily:
images:

取得済みのイメージ

lxc image list 

公式イメージ

取得済みのイメージと引数が違うだけなのでちょっと覚えづらい

lxc image list images:
lxc image list ubuntu:

イメージの一覧を見る時に使うコマンドの例

lxc image list images: 'debian'
lxc image list images: 'debian/11/amd64'
lxc image list images: 'centos'

検索イメージは多くなると 見づらいので grep するといい

lxc image  list  ubuntu: | grep 20.04
lxc image  list  images: | grep debian

さらに詳細を見たいときは次のようなオプションを使う

lxc image list images: 'debian/11/amd64' -c Lfpdatsu

イメージサーバーはどこにあるのかというと https://images.linuxcontainers.org/ をみると、全部見ることができるけど多すぎて見ることはないんじゃないかと。

debian を起動する場合

lxc image list images: debian

新規で起動するなら次のようにする

lxc launch images:debian/10

デフォルトで、最新版とCPUアーキテクチャ(amd64)と、コンテナが選ばれて起動します。

centos を起動する場合

CentOS を起動するときは次のようにする。

images:XXX の images:を付けるのが重要

lxc launch images:centos/8 

ubuntu 以外は名前空間が違うので注意

ubuntu 以外のイメージを使うときは、images:XXX の images:を付けるのが重要

lxc launch ubuntu:18.04 ubuntu1804
lxc launch images:debian/10
lxc launch images:centos/8 --storage bt01

ubuntu だけは、ubuntu を先頭につけるのですが、ubuntu:18.04 でインストールできるからといって debian:10 でインストールできるわけではありません。最初のうちはよく間違うので注意。

ubuntus: と images:という : セミコロンが配布サーバを指定する名前空間だと思って置くとベター。

centos を検索するといっぱいあります

grep すると長いので、ある程度わかっていたら、名前を入れたほうが速い。

takuya@:~$ lxc image list images:centos
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
|              ALIAS               | FINGERPRINT  | PUBLIC |               DESCRIPTION                | ARCHITECTURE |      TYPE       |   SIZE   |          UPLOAD DATE          |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/6 (3 more)                | 047d1e4bbd22 | yes    | Centos 6 amd64 (20200714_07:08)          | x86_64       | CONTAINER       | 75.83MB  | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/6/cloud (1 more)          | 1f2c57f63c95 | yes    | Centos 6 amd64 (20200714_07:08)          | x86_64       | CONTAINER       | 84.13MB  | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/6/cloud/i386              | 50fb77c012f1 | yes    | Centos 6 i386 (20200714_07:08)           | i686         | CONTAINER       | 84.26MB  | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/6/i386 (1 more)           | dd5ca34a8695 | yes    | Centos 6 i386 (20200714_07:08)           | i686         | CONTAINER       | 75.96MB  | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/7 (3 more)                | a007f18afb7c | yes    | Centos 7 amd64 (20200714_07:08)          | x86_64       | VIRTUAL-MACHINE | 417.25MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/7 (3 more)                | eeecaeac13c8 | yes    | Centos 7 amd64 (20200714_07:08)          | x86_64       | CONTAINER       | 83.16MB  | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/7/armhf (1 more)          | b8a283e1740c | yes    | Centos 7 armhf (20200714_07:08)          | armv7l       | CONTAINER       | 78.95MB  | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/7/cloud (1 more)          | 89fee0193ddd | yes    | Centos 7 amd64 (20200714_07:08)          | x86_64       | VIRTUAL-MACHINE | 420.13MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/7/cloud (1 more)          | b3b9407c1839 | yes    | Centos 7 amd64 (20200714_07:08)          | x86_64       | CONTAINER       | 89.75MB  | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/7/cloud/armhf             | 483310afd026 | yes    | Centos 7 armhf (20200714_08:11)          | armv7l       | CONTAINER       | 85.35MB  | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/7/cloud/i386              | 3b176216218d | yes    | Centos 7 i386 (20200714_07:08)           | i686         | CONTAINER       | 90.55MB  | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/7/i386 (1 more)           | 34ebc449e97f | yes    | Centos 7 i386 (20200714_07:08)           | i686         | CONTAINER       | 83.72MB  | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8 (3 more)                | 3c980b7f2b1d | yes    | Centos 8 amd64 (20200714_07:08)          | x86_64       | VIRTUAL-MACHINE | 472.31MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8 (3 more)                | 25188125674b | yes    | Centos 8 amd64 (20200714_07:08)          | x86_64       | CONTAINER       | 125.23MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8-Stream (3 more)         | 472c6fbd783d | yes    | Centos 8-Stream amd64 (20200714_07:08)   | x86_64       | VIRTUAL-MACHINE | 488.50MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8-Stream (3 more)         | fac6147bf59b | yes    | Centos 8-Stream amd64 (20200714_07:08)   | x86_64       | CONTAINER       | 136.46MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8-Stream/arm64 (1 more)   | 914ae88a4981 | yes    | Centos 8-Stream arm64 (20200714_07:08)   | aarch64      | CONTAINER       | 132.72MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8-Stream/cloud (1 more)   | 284967f0a5a9 | yes    | Centos 8-Stream amd64 (20200712_07:08)   | x86_64       | VIRTUAL-MACHINE | 511.88MB | Jul 12, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8-Stream/cloud (1 more)   | eb677b861e46 | yes    | Centos 8-Stream amd64 (20200714_07:08)   | x86_64       | CONTAINER       | 151.26MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8-Stream/cloud/arm64      | 88bafb10fa38 | yes    | Centos 8-Stream arm64 (20200714_07:08)   | aarch64      | CONTAINER       | 147.17MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8-Stream/cloud/ppc64el    | 15eaf9ce55a4 | yes    | Centos 8-Stream ppc64el (20200714_07:08) | ppc64le      | CONTAINER       | 155.66MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8-Stream/ppc64el (1 more) | 6cedfe83c6b9 | yes    | Centos 8-Stream ppc64el (20200714_07:08) | ppc64le      | CONTAINER       | 140.54MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8/arm64 (1 more)          | afb6965dbdfb | yes    | Centos 8 arm64 (20200714_07:08)          | aarch64      | CONTAINER       | 121.66MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8/cloud (1 more)          | 6099bb04dc55 | yes    | Centos 8 amd64 (20200714_07:08)          | x86_64       | CONTAINER       | 140.05MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8/cloud (1 more)          | f6d70e969faf | yes    | Centos 8 amd64 (20200714_07:08)          | x86_64       | VIRTUAL-MACHINE | 496.13MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8/cloud/arm64             | b54ec18a6fdc | yes    | Centos 8 arm64 (20200714_07:08)          | aarch64      | CONTAINER       | 136.18MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8/cloud/ppc64el           | 1011e9c98bda | yes    | Centos 8 ppc64el (20200714_07:08)        | ppc64le      | CONTAINER       | 144.22MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+
| centos/8/ppc64el (1 more)        | 2df6d6ca3e80 | yes    | Centos 8 ppc64el (20200714_07:08)        | ppc64le      | CONTAINER       | 129.11MB | Jul 14, 2020 at 12:00am (UTC) |
+----------------------------------+--------------+--------+------------------------------------------+--------------+-----------------+----------+-------------------------------+

おおいね。CPUアーキテクチャとかクラウド向けとかいろいろあって大変です。

2021-06-17

いくつかの要素が混じりすぎてて、後で読みにくかったので、CentOSに関するところを別の記事に仕立て直した。

https://takuya-1st.hatenablog.jp/entry/2021/06/17/164311

LXC とホスト間でディレクトリを共有する

LXC とホスト間でディレクトリを共有する

lxc で debian を作って、そこでnginx を運用していると、dockerで volumeの共有みたいにホスト・コンテナ間でディレクトリを共有したい。

docker だと EXPOSE で ディレクトリを、起動時にvolume を指定するだけでいけるけど、lxc はそこまでかんたんじゃない。

LXCでディレクトリの共有の場合

LXCでコンテナを起動していると、ユーザー名とuid がlinux の機能で擬似的にリマップされているので、同じディレクトリでもパーミッションをみるための ower / group のパーミッションがぐちゃぐちゃになるので、事前に設定しなくてはいけない。

/var/www/html をLXCで共有するとき

ubuntu の www-data(uid 33 / gid 33 ) のユーザーでホストとコンテナでディレクトリの共有をする。

/var/www/htmlをホストとコンテナで共有する事を考えてみる。

lxc ホストが ubuntu で lxc のコンテナも ubuntu で 両方をdebian 系で統一して試した。 /var/www/ は www-data ユーザで扱うので www-data ユーザをマッピングする設定がいる。

uid のマッピング

最初に、uid をマッピングの準備をする

takuya@lxc-host:~$ id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data)
takuya@lxc-host:~$ lxc exec ubuntu1804 id www-data
uid=33(www-data) gid=33(www-data) groups=33(www-data)

www-dataがいないときは nginx / apacheがインストールされていないと思われる。

ホスト側で、www-data がオーナーのフォルダを作る

mkdir /opt/shared-www
chown www-data: -R /opt/shared-www

まず、ホスト側からコンテナ(ゲスト)に見せるフォルダを作る

ホストとコンテナの間でIDをマッピングする。

lxc config set ubuntu1804 raw.idmap 'both 33 33'

ホストとコンテナの間で、ディレクトリを共有するデバイスを作る

コンテナにディレクトリを渡すときは、設定は「デバイス」あつかいになるので config device 関連にまとめらている。

lxc config device add ubuntu1804 config-www-dir disk source=/opt/shared-www/ path=/var/www/shared

lxc config device で設定を確認する。

takuya@lxc-host:~$ lxc config device show vps
config-www-dir:
  path: /var/www/shared/
  source: /opt/shared-www/
  type: disk

再起動

最後に、IDマッピングを有効化し、 device disk を有効化するために、再起動する

lxc restart nginx

これでホストとゲストのコンテナの間でフォルダを共有することができる。

docker の expose のボリュームに比べて少し面倒ですね。

ポイント

ホスト・コンテナ間で uid/gidマッピングが必要

device config でデバイスとして追加する。

php で url から ホスト名を取り出す。 - parse_url

PHPでURLからホスト名だけを取り出す。

<?php  parse_url( $url, PHP_URL_HOST );

parse_url にフラグを入れるだけで、ホスト名を取り出すことができる。

実行するとこんな感じになります。

php > var_dump(parse_url( 'https://www.yahoo.co.jp:443/', PHP_URL_HOST ));

string(15) "www.yahoo.co.jp"

見て分かる通り、指定したものをちゃんと簡単に取り出せます。

ほんとなんで十分に検証もしないままコピペの正規表現パターンを書いちゃうんでしょうかねぇ。

parse_url 関数が多機能すぎるんでしょうか。

参考資料

https://www.php.net/manual/en/function.parse-url.php

php で DNS からレコードを調べてIPアドレスを取り出す - dns_get_record

ドメイン名のDNSレコードを調べてIPアドレスを取得する

dns_get_recordDNSの値をクエリすることが出来ます。

<?php
dns_get_record('www.yahoo.co.jp', DNS_A)

gethostbynameの、古くからあるIPアドレスを調べる方法を取ることが出来ます。

<?php 
gethostbyname('www.yahoo.co.jp'))

dns_get_record を使った場合の取り出し例

CNAME で指定されたDNSレコードの場合は、 DNS_A をフラグとして入れてあげると、IPアドレスが取り出せる。

php > var_dump(dns_get_record('www.yahoo.co.jp', DNS_A));
array(1) {
  [0]=>
  array(5) {
    ["host"]=>
    string(16) "edge12.g.yimg.jp"
    ["class"]=>
    string(2) "IN"
    ["ttl"]=>
    int(120)
    ["type"]=>
    string(1) "A"
    ["ip"]=>
    string(14) "183.79.219.252"
  }
}
php > var_dump(dns_get_record('www.yahoo.co.jp'));
array(1) {
  [0]=>
  array(5) {
    ["host"]=>
    string(15) "www.yahoo.co.jp"
    ["class"]=>
    string(2) "IN"
    ["ttl"]=>
    int(815)
    ["type"]=>
    string(5) "CNAME"
    ["target"]=>
    string(16) "edge12.g.yimg.jp"
  }
}
php >

参考資料

https://www.php.net/manual/en/function.dns-get-record.php

phpで文字列がメールアドレスかどうか調べる(RFC822) - filter_vars

phpで文字列がメールアドレスかどうか調べる。

<?php

filter_var('takuya@example.com', FILTER_VALIDATE_EMAIL ))

たったこれだけでRFC準拠のE-MAILのメールアドレスかどうかを調べることができる。

その他の出力結果はつぎのようになります。

php > var_dump(filter_var('takuya@example.com', FILTER_VALIDATE_EMAIL ));
string(18) "takuya@example.com"

php > var_dump(filter_var('takuya+sample@example.com', FILTER_VALIDATE_EMAIL ));
string(25) "takuya+sample@example.com"

php > var_dump(filter_var('takuya+sample@.com', FILTER_VALIDATE_EMAIL ));
bool(false)

php > var_dump(filter_var('takuya+sample@doc.com', FILTER_VALIDATE_EMAIL ));
string(21) "takuya+sample@doc.com"

php > var_dump(filter_var('takuya.@doc.com', FILTER_VALIDATE_EMAIL ));
bool(false)

php > var_dump(filter_var('takuya_1st@doc.com', FILTER_VALIDATE_EMAIL ));
string(18) "takuya_1st@doc.com"

php > var_dump(filter_var('tak.uya_1st@doc.com', FILTER_VALIDATE_EMAIL ));
string(19) "tak.uya_1st@doc.com"

php > var_dump(filter_var('tak..uya_1st@doc.com', FILTER_VALIDATE_EMAIL ));
bool(false)

RFC非準拠メールアドレスを捨てても大丈夫。

 むかしむかし、NTTドコモというメールアドレス発行者がいて、RFC非準拠メールアドレスを発行許可してくれました。 dd.@docomo.ne.jp のように@マークの前に ドットが入るものです。しかし現在では、ドコモのメールアドレスでは、@マーク前のドットは許可されされていません。スパムメール対策に敢えて準拠違反のメールアドレスを使うという暴挙が過去に行われていましたが、いまは昔です。

 Gmailでは ta..ku..ya@gmail.com のような ドットが連続するメールアドレスを使えましたが、これもいまは昔です。もう動きません。

 したがって、Phperが「妙ちくりん」なregular expression を書いたりコピペするよりも、FILTER_VALIDATE_EMAIL を使ってメールアドレスをバリデーションしたほうが確実なのです。

 なぜしないんでしょうね。コピペが横行していて、公式マニュアルを読まないのは少し不思議(SF)です。

メールアドレスのバリデーションは公式をまず使おう

php 組み込み関数 filter_var を使うほうが無難です。それでもどうしても対応できないものが出てきた時に、はじめてコピペや検索結果に出てくるアドバイスを見たらどうでしょうか。

<?php

filter_var('takuya@example.com', FILTER_VALIDATE_EMAIL ))

filter_vars に関するバリデーション一覧

https://www.php.net/manual/en/filter.filters.validate.php

マニュアルを少し見れば、変な正規表現パターンもテストも不要になるのではないでしょうか。

phpで 文字列がIPアドレスかどうか調べる- filter_vars

文字列がIPアドレスかどうか調べるには。

FILTER_VALIDATE_IP を filter_vars と組み合わせて使うとお手軽です。

<?php
function is_ipv4 ( $ip ){
  return filter_var($ip,  FILTER_VALIDATE_IP);
}

これで、v4かどうか調べることができる。

使い方と出力サンプルは次の通り

いくつかのタイプで調べてみると、動作がわかる。

php > var_dump(filter_var('a', FILTER_VALIDATE_IP));
bool(false)
php > var_dump(filter_var('127.0.0.1', FILTER_VALIDATE_IP));
string(9) "127.0.0.1"
php > var_dump(filter_var('127.', FILTER_VALIDATE_IP));
bool(false)
php > var_dump(filter_var('1.1.1.1', FILTER_VALIDATE_IP));
string(7) "1.1.1.1"
php > var_dump(filter_var('192.168.1.1/24', FILTER_VALIDATE_IP));
bool(false)
php > var_dump(filter_var('192.168.1.1', FILTER_VALIDATE_IP));
string(11) "192.168.1.1"
php >

FILTER_VALIDATE_IP と filter_var の組み合わせでバリデーションが出来て、ちゃんと動作しているのがわかるでしょうか。

v6 かどうか調べるには

FILTER_FLAG_IPV6  を使います。ただし、組み合わせて使います。

<?php
php > var_dump(filter_var('2001:a240:8383:a300::1', FILTER_VALIDATE_IP, FILTER_FLAG_IPV6 ));
string(22) "2001:a240:8383:a300::1"

マニュアル読もうぜ。

なぜphper は自作のヴァリでーションを書いてしまうのか。正規表現パターンをいいけど言語組み込みの機能は積極的に使ってほしいと思うんですよね。

https://www.php.net/manual/en/ref.filter.php

ubuntu で apt インストールした mariadb(mysql) のroot パスワードがわからないので初期設定を探した

ubuntu 20.04 で mariadb-server

mariadb-server をいれたけど、デフォルトのユーザーパスワードがわからない!

mysql をインストールしたときは、ユーザーパスワードの生成プロンプトが出てきたのに、最近のapt はプロンプト出さない傾向があるんですよ、とくにserver版のやつ

インストール済みのmariadb に接続する

uid 1 で、 mysql ユーザーもroot でログインすれば、パスワードがいらない。

sudo mysql -u root 

試してみた

### ubuntu 一般ユーザー→だめ
ubuntu@primary:/var/www$ mysql
ERROR 1698 (28000): Access denied for user 'ubuntu'@'localhost'

### ubuntu 一般ユーザーが mysql ユーザー root として → だめ
ubuntu@primary:/var/www$ mysql -u root
ERROR 1698 (28000): Access denied for user 'root'@'localhost'
### 上記の -p でパスワードプロンプト、、、パスワードが分からない。
ubuntu@primary:/var/www$ mysql -u root -p
Enter password:
ERROR 1698 (28000): Access denied for user 'root'@'localhost'
### sudo でやってみても、パスワードがないので詰まる。 未入力の状態でEnter → つながる!
ubuntu@primary:/var/www$ sudo mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 44
Server version: 10.1.44-MariaDB-0ubuntu0.18.04.1 Ubuntu 18.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

デフォルトはsudo パスワード=なしでログイン可能ですね

というわけで、 デフォルトはパスワード=なしでログイン可能ですよね。これってある意味やばいので注意が必要です。ただし、sudo 出来ない限りは大丈夫。 sudo ユーザーを増やしている場合は注意が必要ですね。

インストールが終わったら

初期化とユーザー登録と権限設定ですね。

MySQLの基本的コマンド(ユーザ・DB・権限・パスワード)の設定削除作成の早見表 -- sql 版 - それマグで!

ランダムなひらがな文字列を生成する-ruby でひみつの質問

ひみつの質問の回答をジェネレーターで作る

(1..10).each do
  puts (1..20).map{|e| (0x3042+Random.new.rand(0..82)).chr(Encoding::UTF_8)}.join
end

実行サンプル

ランダムな文字列を生成するのである。

/usr/bin/ruby himitu.rb
ふぉゔゃまゅめゅいごなこきむてぎなざさへ
ぽぽはとごだんむごよぇねとほうそわをゎつ
ねぽねなやしいづびぽぉばぐひごろへでおよ
がづつぷほぼゑたやかゆぺえへまよもいおぇ
りねっせぶぢけぺねあとほごせよんうゐだひ
ろざゆぃくばへごつちきゎそぱたついさげへ
ずじへめやむぺゐふぃまえしづめゃおゅなし
ふもぺょけにゃぜつかぢきいぎけのすむぉで
りこぐぶやをのうぐぱにずぬえぞはめぶゑち
もとをぷゅぱひよぱぢずゃぽんさけまぼしけ

仕組み

UTF-8 で 0x3042 が’あ’

0x3042 + ランダムな数字

数字.chr( Encoding::UTF_8 ) で、文字コードの数字を、文字に変換

あとはこれを必要文字数文繰り返す。

バリデーションで弾かれる可能性がある。

'ゔ', 'ゕ', 'ゖ' の3つの文字は、バリデーションで「かな」ではないと弾かれる可能性が高い。

世間に出回る、ひらがなチェック正規表現"regex": /^[ぁ-んー\s]+$/ になっているので 、’んー’以降に存在する 'ゔ', 'ゕ', 'ゖ'はひらがなとして認識されないかもしれない。

関連資料

秘密の質問ジェネレータを、pythonでぱぱっと - それマグで!

ssh の秘密鍵は何ビットやFingerprintのプロパティ情報を見る

SSH秘密鍵が何ビットだったか忘れた

随分前に作った秘密鍵なので、これが1024 / 2048 なのかすっかり忘れていました。

ssh-keygen で秘密鍵の情報を確認

秘密鍵の情報をみるには、ssh-keygenコマンドでやります。

ssh-keygen -l -f ~/.ssh/id_rsa

このコマンドを使えば、ビット数やRSAキーかどうか、Finterprintなどが表示できます。

実行例

takuya@~$ssh-keygen -l -f ~/.ssh/id_rsa
2048 SHA256:ikqYC8kkcxFABO/1+uEDhlZqm9Czt takuya@host (RSA)

これで、秘密鍵の指紋(Finterprint)が確認でき、キーの名前や、バイト数(上記の例では2048) を調べることが出来ます。

参考資料

How To: Inspect SSH Key Fingerprints

Apache2でmod_rewrite が動かない?

Apache2 で rewrite エンジンを動か無いときにチェックするもの

久しぶりに、ubuntu にApache2+php いれて /aaa/aaa を /index.php/aaa/aaa に転送しようとしたら出来ない。

apache2 の場合、rewrite を使うまでにいくつか手順が必要

  1. rewrite が有効になっていますか
  2. Allow Override が使えるか
  3. htaccess の記述内容は正しいですか

rewrite を有効にして、有効になっているか。

apache の場合、rewrite を使ってリクエストのPATHをキャッチオールするので、有効にする

sudo a2enmod rewrite 
sudo apache2 configtest
sudo apache2 restart

Allow Override

apache2.conf で Allow Orverride を有効にする

Allow Orverride はディレクトリに対する設定で書くので、apache2.conf に書く。

 <Directory /var/www/>
   Options Indexes FollowSymLinks
   AllowOverride All
   Require all granted
 </Directory>

.htaccess の記述

.htaccess の記述を確認する。rewrite を有効にしているかチェック

<IfModule mod_rewrite.c>

    RewriteEngine On

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !^(.*)\.(gif|png|jpe?g|css|ico|js|svg|map)$ [NC]
    RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>

rewrite を使う時

rewrite は標準でインストールされるが、htaccess で使うのに Allow Override がhttpd.confに必要で、一回書くとずっと使うので忘れますね。

nginx だと rewrite のルールは nginx のconfig に書くので、更に忘れますね。

参考資料

Apache/Apacheでmod-rewriteが動かない場合の原因のいくつか - Web関連技術調査

シェル ( /bin/sh ) での正規表現マッチ。

以前、bash正規表現について書いた。

今回は、今更だけど、あえて、bash/zsh で使われている [[ を使わずに、正規表現を使おうとしてみた。

expr よりは bash の機能を使ったほうがいい。

以前書いた記事にある。bash/zsh正規表現を使う方法が個人的には優れていると思う。

takuya-1st.hatenablog.jp

どうしても sh じゃないとだめなんだったときは expr を使う選択肢になる。

/bin/sh の場合は expr で正規表現を扱う。

シェルの正規表現は、次のようにかける。

expr "なにか文字列" : "regex"

または、次のように書く。

expr match "なにか文字列"  "regex"

expr は expression の略だったかとおもう。Expressionの名前の通り、文字列表現の式を評価をする。四則演算なども使います。

expr を使う上での注意。

expr は式を評価するので、結果がプリントされます。

通常の [ / test は結果をプリントせずにステータース・コードをexit code で返しますが、expr は文字列を出力するので注意。

expr で正規表現

正規表現をするときは次のように書きます。

expr hello :  'h.*o' 

または

expr match hello   'h.*o' 

if 文 と expr でマッチングで条件分岐

expr を正規表現マッチで返すと一致したかどうかを文字列でプリントするので、出力を捨てる必要がある。

if expr hello :  'hello' > /dev/null ; then
  echo match
fi

サンプル

正規表現/bin/sh で動くように regex をexpr で扱ってbashだけでなく汎ゆる場所で動くことを想定したらこんな感じになるが

#!/bin/sh


match_test () {
  printf "%-18s:" "$1"
  if expr "$1" : '.*apple' > /dev/null ; then
   echo match
  else
    echo does not match
  fi

}

match_test "Hello World."
match_test "This is an apple."
match_test "This is a pen."

実行結果

上記の実行結果

$ ./test.sh
Hello World.      :does not match
This is an apple. :match
This is a pen.    :does not match

細かい部分で [[ と違う。

正規表現の柔軟度を考えると、bash / zsh に組み込まれている [[ を使ったほうが正規表現の書きやすさ、マッチ判断のわかりやすさが上回っている。

関連資料

bashでif に正規表現を使った文字列マッチ条件分岐 - それマグで!