それマグで!

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

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

Windows のDHCPと固定(static)をコマンドで切り替える。

windows の netsh で dhcp と固定IPを切り替えられる。

DHCP固定IPアドレスを切り替えができるようになるので手軽に、IPをオンオフするプログラムを使わずとも、コマンドラインで完結する。

ただし、DHCPをオフにしてしまうと、DNSサーバーとデフォルトゲートウェイが変わってしまうので注意が必要。

現在の設定を確認する。

netsh interface ip show config  eth01

Configuration for interface "eth01"
    DHCP enabled:                         No ### 
 ( 略

DHCPをONの状態からオフにする。

DHCPをオフにすると、GatewayDNSも消えちゃうので、ちゃんと自分でやる必要があったので注意。

netsh interface ip set address eth01 static 192.168.11.189/24 gateway=192.168.11.1
netsh interface ip set dnsservers eth01 static 192.168.11.1 primary yes

DHCP をONにする。

IPアドレスの固定と一緒に覚えておく必要があります。

 netsh interface ip set address eth01 dhcp
 netsh interface ip set dnsservers eth01 dhcp

DNS を固定・DHCP切り替える。

DNSを固定からDHCPの経由からのオファーに切り替える。

 netsh interface ip set dnsservers eth01 dhcp

DNSDHCPオファーから、固定に切り替える

netsh interface ip set dnsservers eth01 static 192.168.11.1 primary yes

DHCPの切り替えはちょっとめんどくさいかも

わたしは、普段LinuxサーバーなどはDNSを固定で運用しているのですが、Windowsなどは完全にDHCPからのオファーを使うことにして dhcp を設定ています。

固定IPに変えるとDNSが固定になるのは、DHCPがそういうものなので仕方がないのです。

Windowsの1つのNICに複数のIPアドレスを割り当てる。

windows でも ip addr add したい。

macLinux を使っていると、 ip addr add のようなコマンドで、一つのネットワークカード(イーサネット・アダプタ)に、複数のIPアドレスを割り当てることが出来ます。

linux での例

Linux では設定を書き換えなくても、次のコマンドで手軽に、IPを追加することが出来ますよね。

ip addr add 192.168.1.10/24 dev eth1
ip addr add 192.168.2.10/24 dev eth1
ip addr add 192.168.4.10/24 dev eth1

また、IPごとにゲートウェイを変えることができるので、便利なんですが。。。

Windowsでも同じことがしたい

Windowsでも、ネットワーク・アダプタに複数のIPアドレスを割り当てたい。ネットワークを構築しているといちいち差し替えるのがだるいので、同じようなことがしたいなと思っていた。

windows 特有の制限(DHCPオフでStaticが必須・管理者)

DHCPをオンにしたままでは、複数のIPを追加できません。(やり方はあるだろうけど、netsh で単純にやるのは不可能に近いと思います。)

Linuxだと、DHCPをオンにしたままで、IPアドレスを追加することが出来ますが、Windowsでは出来ないようです。いったん、Staticに変えてあげる必要があります。

また、ネットワークの設定変更には管理者権限が必要です。

PS C:\Users\takuya> netsh interface ipv4 add address name=eth01 address=192.168.4.1 mask=255.255.255.0
The requested operation requires elevation (Run as administrator).

netshを使って、IPアドレスを複数割り当てる。

IPアドレスを、一つに複数を追加することが出来ます。

このコマンドを実行するとStatic設定になります。DHCPと共存が出来ません。

DHCP取得済みのIPアドレスデフォルトゲートウェイは削除されます。DHCPデフォルトゲートウェイと通信できなくなるので注意してください。

PS C:\WINDOWS\system32> netsh interface ipv4 add address name=アダプタ名 address=192.168.5.1 mask=255.255.255.0

管理者権限で、IPアドレスを追加する。

PS C:\WINDOWS\system32> netsh interface ipv4 add address name=eth01 address=192.168.5.1 mask=255.255.255.0

ゲートウェイを正しく設定し直す。

Staticになるので、デフォルトゲートウェイが消えちゃうので、デフォルトゲートウェイを設定し直す。

PS C:\WINDOWS\system32> netsh interface ipv4 add route 0.0.0.0./0 'my-eth01' 192.168.11.1

または

route add 0.0.0.0/0 192.168.11.1

DHCPがオフになっちゃうので結局は、ゲートウェイを設定しなくちゃいけないんですよね。Windows のネットワークのDHCPとStatic の排他処理はなんとかならないものか。

省略形

引数名を明示しなくても、順番で指定できる、またネットマスクも省略できる。

netsh interface ipv4 add address name=アダプタ名 address=192.168.5.1 mask=255.255.255.0
netsh interface ipv4 add address アダプタ名  192.168.5.2/24 

消す(利用後)

netsh interface ipv4 delete address eth01 192.168.5.2

使いにくい・・・慣れよう

linux の ip addr add みたいにアドレスを手軽に追加できないのが辛い。DHCPをオフにしてデフォルトゲートウェイゲートウェイの設定をし直ししなくちゃいけないのが辛い。

うまくメトリックを調整できればいいんだけど。

windows のdhcp と固定を 切り替える。

windows のネットワークを切り替えをコマンドプロンプトでやる。

DHCPのオンと、固定IP(static) をWindowsのコントロールパネルからポチポチ切り替えるのがめんどくさい。

マウス移動多すぎるし、コントロールパネルが「設定」に隠れて探しくくなって手間が多い。

Windowsネットワークアダプタを固定IPにする。

PS C:\WINDOWS\system32> netsh interface ipv4 set address name=eth01 static 192.168.5.100 255.255.255.0 192.168.5.1

name=名前で利用する、アダプタ名称は、netsh interface ipv4 show ineterfaces / netsh interface ipv4 show config のコマンドで事前に調べておく。

DHCP を有効にする。

PS C:\WINDOWS\system32> netsh interface ipv4 set address name=eth01 dhcp

DHCPをオンにして自動取得するようにするは、次のコマンドを使う。

set dhcp したら、即座にDHCPの取得が始まる。ipconfig renew をしなくてもいい。

name は省略可能なので、もっとシンプルに書ける。

name=XXX の部分の name は省略が可能なので、もっとシンプルに書くことが出来てわかりやすく、覚えやすくなる。

PS C:\WINDOWS\system32> netsh interface ipv4 set  address eth01 static 192.168.5.100 255.255.255.0 192.168.5.1

PS C:\WINDOWS\system32> netsh interface ipv4 set  address eth01 dhcp

これで、コマンドの窓の履歴から、矢印キーとEnterで切り替えと有効化を連続して試せるようになり、ネットワークを扱うときに格段に楽になります。

windows のネットワーク・デバイス名をnetshで変更する。

windows のネットワークのデバイス名を変更する。

netsh を使って、Windowsのアダプタ(ネットワークインタフェース)の名称を、手軽に変更することが出来ます。

C:\Users\takuya> netsh interface set interface name='旧名称' newname='新名称'

ネットワークの名称はそのままだと、日本語だったり、イーサネットXXのようなわかりにくい名前なので、xNIXライクに、ethX のような名前に変更したら便利かもしれないとおもってやってみました。ネットワークアダプタのデフォルト名称が本当にわかりにくくて、複数のLANポートを持っていると混乱するのでわかりやすい名前をつけておけばWindowsも使いやすくなるのではないでしょうか。

変更前の状態

PS C:\Users\takuya> netsh interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
 20          25        1500  disconnected  Wi-Fi
 14          25        1500  connected     イーサネット
  8          65        1500  disconnected  Bluetooth ネットワーク接続 2

変更します。

PS C:\Users\takuya> netsh interface set interface name='イーサネット' newname='eth01'

変更後の状態

PS C:\Users\takuya> netsh interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
 20          25        1500  disconnected  Wi-Fi
 14          25        1500  connected     eth01
  8          65        1500  disconnected  Bluetooth ネットワーク接続 2

ipv4 を指定しましたが、ipv6 のアダプタ名も併せて変わっています。

v6 を指定して interface 一覧を出力すると、こちらも変わっています。

PS C:\Users\takuya> netsh interface ipv6 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
 20          25        1500  disconnected  Wi-Fi
 14          25        1500  connected     eth01
  8          65        1500  disconnected  Bluetooth ネットワーク接続 2

コントロールパネルでも確認できます。

f:id:takuya_1st:20201025154020p:plain

netsh でインタフェースの名前を変えることが出来ました。

ただし、windowsLinuxなどとは管理体系が似ているようで異なるので、ちょっと癖があります。

とくに、netsh interface で ipv4 /ipv6 を指定するが、設定がどちらにも影響するのがちょっと不自然なコマンドな気がしますね。

windows のnetsh でネットワークの一覧を出力する

windows のネットワーク周りで便利なコマンド netsh

netsh コマンドがあれば、xBSDやLinuxみたいに、柔軟にネットワーク周りを扱うことが出来ます。

ネットワークのデバイス一覧を出力する。

netsh コマンドでネットワークの一覧をプリントするには、次のコマンドが便利です。

PS C:\Users\takuya> netsh interface ipv4 show interfaces

実例。

PS C:\Users\takuya> netsh interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          75  4294967295  connected     Loopback Pseudo-Interface 1
 20          25        1500  disconnected  Wi-Fi
 14          25        1500  connected     イーサネット
  8          65        1500  disconnected  Bluetooth ネットワーク接続 2

ifconfig っぽく表示する。

リストを展開した形式でびゅすることもできる。

PS C:\Users\takuya> netsh interface ipv4 show config

実例

PS C:\Users\takuya> netsh interface ipv4 show config
Configuration for interface "イーサネット"
    DHCP enabled:                         Yes
    IP Address:                           192.168.2.189
    Subnet Prefix:                        192.168.2.0/24 (mask 255.255.255.0)
    Default Gateway:                      192.168.2.1
    Gateway Metric:                       0
    InterfaceMetric:                      25
    DNS servers configured through DHCP:  192.168.2.1
                                          192.168.2.5
    Register with which suffix:           Primary only
    WINS servers configured through DHCP: None

Configuration for interface "Wi-Fi"
    DHCP enabled:                         Yes
    InterfaceMetric:                      25
    DNS servers configured through DHCP:  192.168.2.1
                                          192.168.2.5
    Register with which suffix:           Primary only
    WINS servers configured through DHCP: None


Configuration for interface "Bluetooth ネットワーク接続 2"
    DHCP enabled:                         Yes
    InterfaceMetric:                      65
    DNS servers configured through DHCP:  None
    Register with which suffix:           Primary only
    WINS servers configured through DHCP: None

Configuration for interface "Loopback Pseudo-Interface 1"
    DHCP enabled:                         No
    IP Address:                           127.0.0.1
    Subnet Prefix:                        127.0.0.0/8 (mask 255.0.0.0)
    InterfaceMetric:                      75
    Statically Configured DNS Servers:    None
    Register with which suffix:           Primary only
    Statically Configured WINS Servers:   None

特定のネットワーク・インタフェースを出力する。

名前を指定することで、特定のネットワークを表示することができる。

PS C:\Users\takuya> netsh interface ipv4 show config  "名前"

実例。

PS C:\Users\takuya> netsh interface ipv4 show config  "Loopback Pseudo-Interface 1"

Configuration for interface "Loopback Pseudo-Interface 1"
    DHCP enabled:                         No
    IP Address:                           127.0.0.1
    Subnet Prefix:                        127.0.0.0/8 (mask 255.0.0.0)
    InterfaceMetric:                      75
    Statically Configured DNS Servers:    None
    Register with which suffix:           Primary only
    Statically Configured WINS Servers:   None

ipconfig でもいいけど、netsh のほうが

ipconfig でも十分に間に合うのですが、netsh のほうがより細かいところに手が届く感じですし、コマンドと使い方がまとまっていて覚えやすい。また検索しやすい感じですね。

旧姓併記をしても現状何もメリットがないことがわかる。

免許証やマイナンバーカードに旧姓併記ができるようになった。 しかし、実際には「通用」できないことがわかる。

旧姓併記をしても現状何もメリットがないことがわかった

旧姓併記についてアレコレ、試行錯誤してる人も多い。

http://megamikostation.com/maiden-name-writing/ https://www.dailyshincho.jp/article/2019/11251131/?all=1&page=1

ネットを調べると旧姓併記で試行錯誤して五里霧中のなか挫折している人が数多くいる。

旧姓の通用は、「通称利用」という厳しい壁が立ちはだかる。それはLGBTの方々が名前や性別を変えるよりとても大変で、しかも理解が得られない。なんなら、在日朝鮮人の方々のほうが「通称利用」に正当な理由が認めらやすい、とても矛盾を孕んだ制度になっている。

銀行で旧姓利用に成功した例。

ネットを調べると、条件付きながら、旧姓の利用に成功した方々のブログが見つかる。銀行などで冷笑を浴びながら、粘り強く辛抱強く交渉してようやく認められるようだ。

通称名関係届を提出すれば、旧姓が使用できるようにいたします」と対応を変えた。はじめは「できません」としか言わなかったが、旧姓を通称として使用している場合、その名義で口座を作ることを認める特例があるそうだ。

ちゃんと説明すれば、対応できるようだ。

手続きに要した時間は、交渉も含めて1時間強。「旧姓を仕事で使用している」などの合理的な理由が必要とはいえ、証明までは求められない点で、より旧姓での口座使用が容易になったと思われる。総務省が旧姓使用を制度として後押ししているというのもプラスに働いたのかもしれない。

なるほど、銀行は緩和されたみたいですね。

緩和されているとはいえ、支店長クラスの決裁が必要ということになっている

信用金庫で試してみた。

地元の信用金庫でチャレンジしたが、「絶対ダメ」と言われた上、「支店長に相談」のうえ、銀行として対応を検討する。時間が必要という。

急いでいたので、旧姓利用を諦め、新規口座開設をし直すことになった。

ゆうちょ銀行

信用金庫でもだめだったし、ゆうちょ銀行(現在日本で最大規模の口座数を保持する、消費者に一番身近な金融機関)でチャレンジしたがだめだったので、電凸してみた。

とりあえず、ゆうちょ銀行に凸撃する。 https://www.jp-bank.japanpost.jp/contact/ctt_index.html

電話を掛けて、ゆうちょ銀行に突撃しておいた。

Q 旧姓併記した身分証があれば名前変更なくそのまま使えるのではないのか。
A できません。ゆうちょ銀行では一切できません。お名前変更のお届けを出して頂く必要がございます。

Q 総務省から全銀協などを通して、協力の要請が2017年頃にあったと思いますが、4年間も何もしてないのですか
 仕事などで、振り込みを受ける際に不便なので、旧姓併記の身分証をを通用させたいのですが、何が必要ですか?
A できないのです。ゆうちょ銀行として、旧姓併記の身分証を「氏名の変更がされたこと」の確認はできます。
 なにかしら手続きが、必要になったときに「名前の変更」が必要になります、併記では身分証として使えません。

Q 旧姓併記の身分証ができて数年経ちますが、ホームページに記載は無いのですか。
A 結婚の際には、届け出の名前を変更していただくとと記載があります。
Q 併記の身分証について記載はありますか?と聞いてるのですが?
A ですから、結婚など名前が変わられた際は
Q だーかーら、旧姓併記の身分証の名前使えません。対応しませんと、HPに記載、これが有るのか無いのか?
A ですから、結婚など・・
Q はいー、、、ないのですね?。わかりました。
A 他になにか
Q 大丈夫です。記載は無いこと、旧姓併記の利用に対応しない。とわかったので十分です。ありがとうございました。
A ありがとうございました。

夫婦別姓異世界のお話?

参考WEB記事においても、苦言が呈されていた。

https://www.dailyshincho.jp/article/2019/11251131/?all=1&page=4

しかし、自民党安倍晋三首相は7月3日の夫婦別姓に関する党首討論会で夫婦別姓制度を「認めない」姿勢を貫いている。  旧姓を住民票に併記できるようになったことは、姓を変更した側の不便を少し解消してくれた。しかし、「特例」扱いでようやく銀行口座を使える程度では、まだまだ「夫婦別姓制度はなくても大丈夫」とはいえない状況だ。  選択制夫婦別姓制度の導入や、旧姓を本名同様に扱えるシーンの拡大など、今後の展開に期待したい。

人間の尊厳に関わる部分なので「基本的人権」だと私は思うんだが。どうだろうか。

旧姓併記に関する情報

タイムゾーン(時刻)を設定する(dpkg-reconfigureの対話ダイアログなし)

タイムゾーン設定がめんどくさい。

ロケールタイムゾーンを設定をちまちま手作業でやるのがめんどくさい。

タイムゾーン設定(有人)

dpkg-reconfigure locales # ja_JP.UTF-8

タイムゾーン設定(無人

timedatectl set-timezone Asia/Tokyo

時刻設定のダイアログは

なれないうちは、勉強を兼ねて手順を意識してたほうがいいけど、なれると、もう手順を飛ばしたいよね。タイムゾーン設定・ロケール・初期ユーザーなど。 docker だとカスタムイメージをdockerfile でつくるし、LXC なら config でできる。楽しないとね

ただし、timedatectl はsystemd

takuya@:$ apt-file  search bin/timedatectl
systemd: /usr/bin/timedatectl

systemd が導入されない、docker イメージなどでは使えないので注意が必要

更新

2020-12-17 更新

ロケール(地域言語)を設定する(dpkg-reconfigureの対話ダイアログなし)

言語・地域のロケール設定がめんどくさい。

LXCで新規インスタンスを起動したり、dockerfile や インストールスクリプトを書いていると、ロケール設定がめんどくさい。手作業でやっていると、dpkg-reconfigure を使えばいいんですけど、不便。起動までコピペでやろうとすると、dpkgでストップしちゃって離席放置ができない。

地域・言語の設定をする方法

ロケール設定を、対話ダイアログでやる場合は、次のようになるが、

dpkg-reconfigure locales # ja_JP.UTF-8

無人で、自動でワンライナーで設定しようとすると次のようになる。

locale-gen --purge "ja_JP.UTF-8"
dpkg-reconfigure --frontend noninteractive locales

既存のロケールを一旦削除して作り直す場合

LANG=ja_JP.UTF-8 update-locale 

一般ユーザーなら sudo をつける。

sudo update-locale LANG=ja_JP.UTF-8

日本語版をインストールすればいいのでは?

lxc launch 
docker run 

など、コンテナの日本語イメージをわざわざ作成し選択するメリットよりも、ロケールでやったほうが楽そうなんですよね。

デプロイやバックアップ用のSFTPアクセスだけを許可する、公開鍵を使う。

SFTP だけができるユーザーを作ると。

バックアップ用やデプロイ用に、ユーザーを作るのがめんどくさい。

ちょっとしたコマンドは実行できなくてSFTPさえできればいいときに、デプロイ用のユーザを作って /etc/ssh/sshd_config で管理するのも面倒

そこで、www-data やroot などの nologin ユーザーにSSH接続を許可してSFTPだけを使うようにする。

公開鍵を登録する autorized_keys でアレコレできる。

authorized_keys に設定を書き込めば、制限や細かい設定を鍵ごとに帰ることできる。そこで、SFTPだけの許可をauthorized_keys に追記する。

authorized_keys に次のようにかけば、OK

command="internal-sftp" ssh-rsa AAAAB3NzaC1yc2EAAAA

chrroot する場合は

authorized_keyにオプションをつけたものを書き込めばいいみたい。

command="internal-sftp -d /var/www" ssh-rsa AAAAB3NzaC1yc2EAAAA

SFTP さえあれば事足ることが多い。

自分以外のlinuxユーザーアカウントが、SSHアクセスしたい場合の大半はファイル転送だと思うんだ。いちいちコマンド実行できるSSHを許可するのも面倒だよね。ということで、

関連資料

SFTPユーザを作る話 → SSHをSFTPに制限して、ディレクトリを制限(chroot)した専用アカウントを作る - それマグで!

Ahtorized_keys で公開鍵ごとに機能制限する話 → sshの公開鍵authorized_keys ファイルの制限機能について調べてみたら楽しかった. - それマグで!

参考資料

https://stackoverflow.com/questions/23448900/public-key-authorization-on-sftp-chroot-directory#31477162

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 でデバイスとして追加する。