ssh のポートフォワーディングのやり方IPv6アドレス編
ssh のポート転送は便利で手軽に使えるものです。
ipv6 でも同じです。
ssh -L 8080:[2001:a253:838xxxxxx]:80 root@192.168.100.1
sshでもIPv6の指定はcurlなど同じ
[v6 addr]:port
のように、ブラケットで囲めばいい。
[2011:123:ff:]:port
tcpdump を使って届いてるパケットを見ることが出来る。 ping の応答が返ってこないしとしても、応答パケットのルーティング設定が間違っている可能性もある。
そのため、ping の宛先でパケットがちゃんと届いているかチェックするとルーティングテーブルの問題を切り分けやすい。
tcpdump icmp
これで、ping パケットを見ることが出来る。
ping パケットが指定したホストから送信されているかどうかを見るには、tcpdump のフィルタリング機能で、フィルタすると便利。
tcpdump src 192.168.1.123 and icmp
and 条件で送信元を絞ることが出来る。
知っておくとネットワークトラブルでパニクらずに住む
init.rd は initramfs を起動するためもの。/boot のパーティションに存在している。
update-initramfs で起動する。grub から起動される最小限のlinux。
initrd ファイルはcpio なので 、cpio で展開しようとしてみる。
あれれ
cd `mktemp -d` && sudo cat /boot/initrd.img-`uname -r` | cpio -ivd . kernel kernel/x86 kernel/x86/microcode kernel/x86/microcode/AuthenticAMD.bin 62 ブロック
1ファイルしかない?そんな馬鹿な
takuya@d001:/tmp/tmp.On03d1x9GP$ tree . . └── kernel └── x86 └── microcode └── AuthenticAMD.bin 3 directories, 1 file
調べてみたら、このcpio ファイルはいくつかの組み合わせなのでうまく行かない。
そうだね。cpio ってtar みたいなもんだもんな
binwalk コマンドをいれて、中身を見てみると。。。末尾にgzip 圧縮されたものがある。
takuya@d001:/tmp/tmp.On03d1x9GP$ binwalk /boot/initrd.img-`uname -r` DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 0 0x0 ASCII cpio archive (SVR4 with no CRC), file name: ".", file name length: "0x00000002", file size: "0x00000000" 112 0x70 ASCII cpio archive (SVR4 with no CRC), file name: "kernel", file name length: "0x00000007", file size: "0x00000000" 232 0xE8 ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86", file name length: "0x0000000B", file size: "0x00000000" 356 0x164 ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode", file name length: "0x00000015", file size: "0x00000000" 488 0x1E8 ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode/AuthenticAMD.bin", file name length: "0x00000026", file size: "0x00007752" 31184 0x79D0 ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000" 31744 0x7C00 ASCII cpio archive (SVR4 with no CRC), file name: "kernel", file name length: "0x00000007", file size: "0x00000000" 31864 0x7C78 ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86", file name length: "0x0000000B", file size: "0x00000000" 31988 0x7CF4 ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode", file name length: "0x00000015", file size: "0x00000000" 32120 0x7D78 ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode/.enuineIntel.align.0123456789abc", file name length: "0x00000036", file size: "0x00000000" 32284 0x7E1C ASCII cpio archive (SVR4 with no CRC), file name: "kernel/x86/microcode/GenuineIntel.bin", file name length: "0x00000026", file size: "0x0024CC00" 2443952 0x254AB0 ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000" 2444288 0x254C00 gzip compressed data, from Unix, last modified: 2019-10-18 08:19:18
ここから、bs がわかるので、それを取り出してみる。
takuya@d001:/tmp/tmp.On03d1x9GP$ dd if=/boot/initrd.img-`uname -r` bs=2444288 skip=1 | gunzip | cpio -tdv | head drwxr-xr-x 13 root root 0 Oct 18 17:19 . drwxr-xr-x 2 root root 0 Oct 18 17:19 bin -rwxr-xr-x 1 root root 9424 Feb 1 2019 bin/cpio -rwxr-xr-x 1 root root 5751 Feb 14 2019 bin/cryptroot-unlock -rwxr-xr-x 1 root root 108760 Jan 14 2019 bin/date -rwxr-xr-x 1 root root 9624 Feb 1 2019 bin/dd -rwxr-xr-x 1 root root 8792 Feb 1 2019 bin/dmesg -rwxr-xr-x 1 root root 9992 Feb 1 2019 bin/fstype -rwxr-xr-x 1 root root 8920 Feb 1 2019 bin/halt -rwxr-xr-x 1 root root 19872 Feb 1 2019 bin/ipconfig
お、ファイルが見えるぞ。
それではこのファイルを取り出してみる
takuya@d001:/tmp/tmp.IrvVwlLK99$ dd if=/boot/initrd.img-`uname -r` bs=2444288 skip=1 of=img.cpio.gz takuya@d001:/tmp/tmp.IrvVwlLK99$ gunzip img.cpio.gz takuya@d001:/tmp/tmp.IrvVwlLK99$ cpio -idv < img.cpio takuya@d001:/tmp/tmp.IrvVwlLK99$ ll 合計 194292 drwx------ 13 takuya takuya 4096 10月 18 17:35 ./ drwxrwxrwt 21 root root 4096 10月 18 17:35 ../ drwxr-xr-x 2 takuya takuya 4096 10月 18 17:35 bin/ drwxr-xr-x 3 takuya takuya 4096 10月 18 17:35 conf/ drwxr-xr-x 2 takuya takuya 4096 10月 18 17:35 cryptroot/ drwxr-xr-x 11 takuya takuya 4096 10月 18 17:35 etc/ -rw-rw-r-- 1 takuya takuya 198891008 10月 18 17:34 img.cpio -rwxr-xr-x 1 takuya takuya 7077 10月 18 17:35 init* drwxr-xr-x 10 takuya takuya 4096 10月 18 17:35 lib/ drwxr-xr-x 2 takuya takuya 4096 10月 18 17:35 lib64/ drwxr-xr-x 2 takuya takuya 4096 10月 18 17:35 run/ drwxr-xr-x 2 takuya takuya 4096 10月 18 17:35 sbin/ drwxr-xr-x 10 takuya takuya 4096 10月 18 17:35 scripts/ drwxr-xr-x 7 takuya takuya 4096 10月 18 17:35 usr/ drwxr-xr-x 4 takuya takuya 4096 10月 18 17:35 var/
取り出せました。
chroot してみる
takuya@d001:/tmp/tmp.IrvVwlLK99$ sudo chroot . /bin/sh BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu7) built-in shell (ash) Enter 'help' for a list of built-in commands. #
更に単純な方法
takuya@d001:/tmp/tmp.gTlrfnehcs$ unmkinitramfs /boot/initrd.img-`uname -r` .
systemd.path を試していきます。
パスの監視というと理解しくいかもしれませんが、フォルダの監視です。フォルダを監視してなんかやります。もちろんファイルも監視できます。
inotify でアプリを書くより手軽です。
systemd でパスを監視することができる。
xxxx.path と xxxx.service をペアで作成し登録すればオッケ。
再帰的(recursive)なパス監視はできない。
inotify を使っているので、 nfsなどネットワーク越しでは使えない。
gvfs/gio でマウントしていると inotifyが発動するはずなので cifs でもつかそう
今回は、次のファイルを作って試していきます。
~/.config/systemd/user/desktop.service ~/.config/systemd/user/desktop.path
systemd のユーザー空間について、過去の資料を参考に
[Unit] Description=DesktopSample [Service] WorkingDirectory=/home/takuya/Desktop ExecStart=/bin/echo Hello From Service [Install] WantedBy=default.target
[Unit] Description=DesktopSample [Path] ## PathModified と PathChanged は別物 ## 再帰的( recursively ) にパスの監視はできない。 ## inotify をベースにしている PathChanged=/home/takuya/Desktop #PathModified=/home/takuya/Desktop [Install] WantedBy=default.target
systemctl --user daemon-reload
enable して
systemctl --user enable desktop.service systemctl --user enable desktop.path
restart しておく
systemctl --user restart desktop.service systemctl --user restart desktop.path
コレで起動するので、あとはログを見ながら、動作する様子を見る
path の監視が起動したときのログ
journalctl --user -f -u desktop.path
service が起動したときのログ
journalctl --user -f -u desktop.service
-f
をつけているので、ログは tailf と同じく following される。
いくつか、ファイルを作成したり、ファイルを更新したりして パスを書き換える実験をしておく
cd ~/Desktop/ echo 更新テスト > a echo 更新テスト2 > a echo 更新テスト3 > a echo 更新テスト4 >> a echo 更新テスト5 >> a rm a touch a chmod 777 a rm a mkdir a rmdir a
あとは、ログを見ながら、このタイミングでイベント発火するとか確認しておけばいい。
代わりに、PathChanged を複数書くことができます。
このように複数書くことができます。
[Path] PathChanged=/home/takuya/Desktop PathChanged=/home/takuya/Desktop/.hidden PathChanged=/home/takuya/Desktop/.gitignore PathChanged=/home/takuya/Desktop/.git
PathModifiedとPathChanged がある。man systemd.path を見るとあれこれ書いてある。
PathChanged について
PathChanged= may be used to watch a file or directory and activate the configured unit whenever it changes. It is not activated on every write to the watched file but it is activated if the file which was open for writing gets closed.
PathModified については
PathModified= is similar, but additionally it is activated also on simple writes to the watched file.
たぶん、次のようなことだと思う。 - PathChanged は open → close されたら発動 - PathModified append された発動
open されたまま、追記されていくデータファイルやログファイルを追いかけるでもない限り PathChanged で問題ないと思われる。
などがある。それぞれ次の名前で定義されている
PathExists=, PathExistsGlob=, PathChanged=, PathModified=, DirectoryNotEmpty=
「できる」だけであり、痒いところまで手が届くような使い勝手がいいものではない。
ただ、systemd のユーザー空間と組み合わせて、ユーザー空間で独自にぱぱっと関する程度ならお手軽でいいと思う。
例えば、ファイルが新規作成された、更新された、truncate されたとか、ディレクトリ内部に作成されたファイル名が知りたい。などなど。 細かい点について作業をしたいもののが欲しいなら inotify 系の python や npm/fsevent 系を使って細々書いておき、書いたpython を service 化するほうがずっといいだろうな。
systemd.path はgnome デスクトップなどで作成されるファイルを手軽に監視して同期したいなどで重宝すると思います。
ubuntu で 4k ディスプレイを使っていると、解像度が細かすぎてしんどい。
windows 10 からは拡大率150% などが選べるが、 ubuntu はデフォルト設定では 200%/100%しか選べなかった。
gsettings で 実験的機能を有効にしてあげると、解像度の拡大倍率を指定できて、MacOSのretina モードみたいなことができるようになる。
gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']" gsettings set org.gnome.mutter experimental-features "['x11-randr-fractional-scaling']"
設定するとこの通り、150%が出現する。これで快適になる。
もとに戻すには reset を使う
gsettings reset org.gnome.mutter experimental-features
https://www.linuxuprising.com/2019/04/how-to-enable-hidpi-fractional-scaling.html?m=1
network-manager で unmanaged になって、ubuntu desktop (gnome) からネットワークが管理できなかった。
ubuntu は 1年前から、 netplan が導入されているので、ubuntu server は systemd-networkd で管理、 ubuntu desktop は NetworkManager で管理することになっている。
network-manager のときは、 network-manager が /etc/network/inteface をparsing して管理デバイスを見つけた上で除外し、残ったデバイスを管理するようになっている。
ただし、この設定はキャッシュされるらしい。(マジだったら、コレはホントめんどくさいわ)
networkd のときは、 networkd の起動後に /etc/network/intefaces を取得して管理する。こっちも面倒くさい。
使ってもいいんだけど、依存関係が多くて面倒くさいので、除外して切り分ける
sudo systemctl stop systemd-networkd.service sudo systemctl disable systemd-networkd.service sudo systemctl mask systemd-networkd.service
netplan は networkmanager を使う設定にして、シンプルにする。
takuya@:~$ cat /etc/netplan/01-netcfg.yaml network: version: 2 renderer: NetworkManager
netplanの設定を再生成してあげる
sudo netplan generate
これで、余計なものは動かなくなる。
ただし、場合分けのために除外し過ぎくらい除外してる。なので、netplan apply すら動かない。
この辺は、正直言ってubuntu の問題だろうなぁ。 networkmanager を指定してるのに 一旦 networkd を経由しようとしている。
takuya@:~$ sudo netplan generate takuya@:~$ sudo netplan apply Failed to start systemd-networkd.service: Unit systemd-networkd.service is masked. Traceback (most recent call last): File "/usr/sbin/netplan", line 23, in <module> netplan.main() File "/usr/share/netplan/netplan/cli/core.py", line 50, in main self.run_command() File "/usr/share/netplan/netplan/cli/utils.py", line 130, in run_command self.func() File "/usr/share/netplan/netplan/cli/commands/apply.py", line 44, in run self.run_command() File "/usr/share/netplan/netplan/cli/utils.py", line 130, in run_command self.func() File "/usr/share/netplan/netplan/cli/commands/apply.py", line 153, in command_apply utils.systemctl_networkd('start', sync=sync, extra_services=netplan_wpa) File "/usr/share/netplan/netplan/cli/utils.py", line 82, in systemctl_networkd subprocess.check_call(command) File "/usr/lib/python3.7/subprocess.py", line 363, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['systemctl', 'start', '--no-block', 'systemd-networkd.service']' returned non-zero exit status 1.
NetworkManager の設定ファイルは、/etc/NetworkManager だけでなく、 /usr/lib/NetworkManager などにデフォルト設定あったりして、それらがマージされて /etc/NetworkManager で上書きするようになっている。
takuya@:~$ sudo NetworkManager --print-config # NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf (lib: 10-dns-resolved.conf, no-mac-addr-change.conf) (run: netplan.conf) (etc: 10-globally-managed-devices.conf, default-wifi-powersave-on.conf) ## 略
/etc/NetworkManager で設定ファイルを見てもすべてが記載されているわけでじゃないので、 --print-config で最終的な設定を確認するのがポイント
ifupdown は /etc/network/interfaceを管理するので、 ifupdown も切り分けのために一旦無効化する。
sudo apt uninstall ifupdown sudo apt uninstall ifupdown2 sudo apt uninstall netscript-2.4
設定方法は、いくつか考えられるのだけど、umamanged になる問題を解決するために、すべての設定をOFFにしたり消していく。
takuya@:~$ cat /etc/NetworkManager/NetworkManager.conf [main] #plugins=ifupdown,keyfile plugins=keyfile dns=default [keyfile] unmanaged-devices= #[ifupdown] #managed=true [device] wifi.scan-rand-mac-address=yes
ちなみに、ifupdownのmanaged は ifup/ifdown で管理される /etc/network/intefacesを nmcli で管理するかどうか。
あれこれ、余計なものを排除した結果動くようになる、
takuya@:~$ sudo systemctl status network-manager.service ● NetworkManager.service - Network Manager Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-10-21 17:20:33 JST; 10s ago Docs: man:NetworkManager(8) Main PID: 4474 (NetworkManager) Tasks: 4 (limit: 4915) Memory: 4.0M CGroup: /system.slice/NetworkManager.service └─4474 /usr/sbin/NetworkManager --no-daemon 10月 21 17:20:33 j5005 NetworkManager[4474]: <info> [1571646033.9682] device (enp3s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'assume') 10月 21 17:20:33 j5005 NetworkManager[4474]: <info> [1571646033.9809] device (enp3s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'assume') 10月 21 17:20:33 j5005 NetworkManager[4474]: <info> [1571646033.9813] device (enp3s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'assume') 10月 21 17:20:33 j5005 NetworkManager[4474]: <info> [1571646033.9819] manager: NetworkManager state is now CONNECTED_LOCAL 10月 21 17:20:33 j5005 NetworkManager[4474]: <info> [1571646033.9832] manager: NetworkManager state is now CONNECTED_SITE 10月 21 17:20:33 j5005 NetworkManager[4474]: <info> [1571646033.9834] policy: set '有線接続 1' (enp3s0) as default for IPv4 routing and DNS 10月 21 17:20:33 j5005 NetworkManager[4474]: <info> [1571646033.9876] device (enp3s0): Activation: successful, device activated. 10月 21 17:20:33 j5005 NetworkManager[4474]: <info> [1571646033.9885] manager: NetworkManager state is now CONNECTED_GLOBAL 10月 21 17:20:33 j5005 NetworkManager[4474]: <info> [1571646033.9892] manager: startup complete 10月 21 17:20:34 j5005 NetworkManager[4474]: <info> [1571646034.0348] bluez5: NAP: added interface 00:09:DD:50:6C:BF
takuya@:~$ nmcli d DEVICE TYPE STATE CONNECTION enp3s0 ethernet 接続済み 有線接続 1 lo loopback 管理無し --
unmanaged だったのが
managed になる。
過渡期とはいえ、systemd 関連の更新と整合性を保つために、あれこれ機能が追加されている。
あれこれ過渡期だからでしょうね。 nmcli や netplan を諦めて /etc/network/interfacesだけに戻すか、素直にnetworkd だけにしたほうが将来的に楽なのかなぁ。
今回驚いたのは ifup/down のコマンドを提供するパッケージが3つもあったことだった。ネットワーク周りはカオスですね。
Ubuntu のネットワーク周りはカオス。というか、最近のLinuxのネットワーク周りはディストリ間でsystemdによる共通化を受容している段階なのでややこしい。
Ubuntuのデスクトップ版は主にNetworkManagerで管理しているんだけど、DNSの設定は、resolv.confに直接書かずにリンクになってたりする。これがちょっと不満なので、直接 /etc/resolv.confに書き込んでほしい。
[main] plugins=ifupdown,keyfile dns=default
sudo systemctl restart network-manager
もし。/etc/resolv.confがsymlinkになって利すると面倒なので、いったん/etc/resolv.confを空にしておくといいかも
sudo rm /etc/resolv.conf; sudo touch /etc/resolv.conf
再起動後、DHCPで割り振られたDNSサーバーが直接参照できるようになる。
takuya@:~$ ll /etc/resolv.conf -rw-r--r-- 1 root root 89 2019-10-11 15:38 /etc/resolv.conf
# Generated by NetworkManager search local nameserver 192.168.2.1 nameserver 192.168.2.5
https://qiita.com/onokatio/items/af0035d1563acbbfeed2
これによると、次のようになる。
dns の設定だけでも、
と、相互に依存しながら編集してるので、注意しないとデフォルト設定がどこに流れているのかわからなくなるよね。。。
たとえば、github のプルリクなど、リモートのgit branch から自分の手元に、同じものを取り出したいときがあります。
git branch -a | \grep remote
たとえば、次のようにほしいブランチ名を確認します。
takuya@i$ git branch -a | \grep remote | grep add remotes/origin/add_table_column remotes/origin/add_notify remotes/origin/createAddUpdateModel
これで、必要なリモートブランチ名を確認出来ました。github のプルリクをブランチベースでやっていると、プルリクに表示されてます。
リモートブランチの名前が見つからないときは、次のように fetch します。
git fetch
リモートブランチの名前が見つからないなんて、そんなことを起きるの?と疑問を感じるかもしれません。リモートブランチはfetch しない限り出てきません。gitは分散レポジトリなのでリモートブランチの更新を取り出す必要があります。
次のように、リモートブランチを取り出し、ローカルブランチの名前を付けます。別の名前も可能ですが、同じ名前にしておくのが無難だと思います。
takuya@$ git checkout -b add_notify origin/add_notify Branch 'add_notify' set up to track remote branch 'add_notify' from 'origin'. Switched to a new branch 'add_notify'
これで、リモートブランチをローカルに取り出してソースコードを見ながら、実験できますね。
同じ名前を使うのであれば、次のように省略することも可能です。
git checkout -b origin/add_notify
というか、省略した此方を一般的に記事で紹介されるのではないでしょうか。ただこちらはローカルとリモートの対応がわかりづらく、ミスを誘発しやすいので最初は localと remote origin の両方を指定したほうがいいのかもしれません
もちろん、さらなる短縮化が出来て、無意識のうちにこれを使ってる可能性があります。私もこれです。
Branch 'add_notice' set up to track remote branch 'add_notice' from 'origin'. Switched to a new branch 'add_notice'
checkout のメッセージをよく読むと、
remote branch の add_notice が origin にあるのでそこから、追跡してブランチをセットアップするよ。(Branch 'add_notice' set up to track remote branch 'add_notice' from 'origin'.) と書いてありますね。つまり、このメッセージが出てきたらOK、省略したcheckout でもちゃんとoriginから取り出せたことが解るようです。
systemd でタイマーを作って、enableして見たんだけど。動かないんですよ。
という手順なんだけど、start コマンド実行が大事。 timer はstart しないと動かないとか盲点でした。
dig するだけのサービスを試しに laravel で作ってみて、それでタイマーを動かすことに。
takuya@:~$ ln -sr laravel_checkip.service /etc/systemd/system/ takuya@:~$ ln -sr laravel_checkip.timer /etc/systemd/system/
サービスファイルをチェックする。
takuya@:~$ sudo systemctl start laravel_checkip.service
サービスをenableにして、タイマーをenable にする。
takuya@:~$ sudo systemctl enable laravel_checkip.service takuya@:~$ sudo systemctl enable laravel_checkip.timer
タイマーはenable してもそのままでは動かない。
takuya@:~$ sudo systemctl list-timers --all NEXT LEFT LAST PASSED UNIT ACTIVATES n/a n/a n/a n/a laravel_checkip.timer laravel_checkip.service 8 timers listed.
なんでかわからんけど start すると 動き出した。enable だけでいいと思ってたけど記憶違いだったらしい
takuya@:~$ sudo systemctl start laravel_checkip.timer
動き出した。
takuya@:~$ sudo systemctl list-timers --all NEXT LEFT LAST PASSED UNIT ACTIVATES Wed 2019-09-18 21:01:56 JST 56min left n/a n/a laravel_checkip.timer laravel_checkip.service 8 timers listed. takuya@:~$
SystemCtrlのタイマーを作るときは、この手順をする。
takuya@:~$ sudo systemctl enable laravel_checkip.service takuya@:~$ sudo systemctl enable laravel_checkip.timer takuya@:~$ sudo systemctl start laravel_checkip.timer
Consoleとかあるし、API作れば実現はできる。でも既存のものと組み合わせるときは、DBを直接書き換えたほうが早い時がある。
本当はプロジェクトの外部から直接触るのは良くないと思うし、プロジェクト側にAPIを作ったり、メンテナンス用のコマンドをプロジェクト内部につくったり、メンテナンス用のデータ復旧をMigration や Fixtgure / UnitTestと同様に作るべきなんだろうけど。
<?php /// laravel の Eloquent を外部から使う設定 // 必要なものをロード require_once __DIR__.'/vendor/autoload.php'; // DB の接続情報をいれる $capsule = new Illuminate\Database\Capsule\Manager(); $capsule->addConnection([ "driver" => "sqlite", "database" => __DIR__."/database/database.sqlite", ]); $capsule->setAsGlobal(); $capsule->bootEloquent(); /// /// AccessLogs モデルを保存してみる。 require_once __DIR__.'/app/Model/AccessLogs.php'; $al = new App\Model\AccessLogs(); $al->body = "Hello from External World "; $al->save();
<?php // 必要なものをロード require_once __DIR__.'/vendor/autoload.php';
今回は、$PROJECT_HOME/sample.php においたのでこのように書いている。
ただしくは、次のautoloadをlaravel で使っているのでこれを使う。(詳しくは laravel/public/index.php を見ればわかる。
<?php $PROJECT_PATH/vendor/autoload.php
必要なロードが出来たので、DBを使うための初期設定をする。
ここでの目標は bootEloquent();
を実行することです。
<?php // DB の接続情報をいれる $capsule = new Illuminate\Database\Capsule\Manager(); $capsule->addConnection([ "driver" => "sqlite", "database" => __DIR__."/database/database.sqlite", ]); $capsule->setAsGlobal(); $capsule->bootEloquent();
laravel で作っている model を 明示的にロードして、new して save する。
<?php /// AccessLogs モデルを保存してみる。 require_once __DIR__.'/app/Model/AccessLogs.php'; $al = new App\Model\AccessLogs(); $al->body = "Hello from External World "; $al->save();
これですべて解決する。
関数名は、関数名を表す変数に入っている(BASHで確認)
echo ${FUNCNAME[0]}
これを使うと、自分自身の関数名を実行中に参照できる。
takuya@Desktop$ function sample() { echo ${FUNCNAME[0]} ; }; sample sample
便利。
実行後に関数を消したいから
関数を使い終わったら片付けたいときがあります。一時的な関数として、処理をブロックに分けるだけの目的で使うことがります。
function sample001() { # なにか処理 ## 処理が終わったら自分自身消す。 unset ${FUNCNAME[0]} ; };
これを実行するとこのようになります。 実行後は関数が消えています。これで名前を汚さずに自分の関数をシェルスクリプトで使えます。
takuya@Desktop$ function sample001() { > echo ${FUNCNAME[0]} ; > unset ${FUNCNAME[0]} ; > }; takuya@Desktop$ sample001 sample001 takuya@Desktop$ sample001 -bash: sample001: コマンドが見つかりません
bashrc のような dotfile で環境設定をする処理に使います。
環境設定するsample.sh をシェルスクリプトで書いた場合
function sample001() { ## なにか処理 echo 環境設定をした }; sample001
source すると関数がENVに残ってしまう。
$ source sample.sh $ sample001
そのために、長い処理をブロック単位に分けて書くとき無駄に関数を設定すると、unset を忘れがちになってしまう。
そこで、source するシェルの環境設定ファイルを書く場合に関数を自分自身で unset しておけば汚さずにすむ
function sample001() { ## なにか処理 echo 環境設定をした ## 使い終わったら消す unset ${FUNCNAME[0]} ; }; sample001
$ source sample.sh $ sample001 # not found
このように、自分自身の関数名を知るノウハウは、シェルスクリプトで環境設定をブロック単位で管理することがしやすくなるので本当に便利りだ!!とおもった
nginx には ストリームをそのまま転送することが出来る機能があるので、TCP・IPのポートフォワードができて、ルーター的な動作が出来ます。
stream { upstream ssh { server 192.168.2.8:22; } server { listen 2222; proxy_pass ssh; } }
まだ試してないのですが、 443 を ssh / ssl の両方で待ち受けることも可能になってるようです。今使ってる グローバルIP上の nginx が非対応なので試すのは少し先になりそう
Run Non-SSL Protocols on the Same Port as SSL in NGINX 1.15.2
NGINX で ssh TLSを同時に扱うときは次のようにします。
https://takuya-1st.hatenablog.jp/entry/2022/04/06/005007
lvm コマンドを実行したいと思っても、root に制限されているので、使えないことがあり困ったので、一般ユーザーに開放することにした。
Cmnd_Alias LVM = /sbin/lvchange,/sbin/lvconvert,/sbin/lvcreate,/sbin/lvdisplay,\ /sbin/lvextend,/sbin/lvm,/sbin/lvmchange,/sbin/lvmconf,/sbin/lvmdiskscan,\ /sbin/lvmdump,/sbin/lvmetad,/sbin/lvmsadc,/sbin/lvmsar,/sbin/lvreduce,\ /sbin/lvremove,/sbin/lvrename,/sbin/lvresize,/sbin/lvs,/sbin/lvscan,\ /sbin/pvchange,/sbin/pvck,/sbin/pvcreate,/sbin/pvdisplay,/sbin/pvmove,\ /sbin/pvremove,/sbin/pvresize,/sbin/pvs,/sbin/pvscan,/sbin/vgcfgbackup,\ /sbin/vgcfgrestore,/sbin/vgchange,/sbin/vgck,/sbin/vgconvert,\ /sbin/vgcreate,/sbin/vgdisplay,/sbin/vgexport,/sbin/vgextend,\ /sbin/vgimport,/sbin/vgmerge,/sbin/vgmknodes,/sbin/vgreduce,\ /sbin/vgremove,/sbin/vgrename,/sbin/vgs,/sbin/vgscan,/sbin/vgsplit takuya ALL=(ALL) NOPASSWD: LVM
sudo pvs
lvm 関連のコマンドは、lvm のサブコマンドや
takuya@:~$ lvm WARNING: Running as a non-root user. Functionality may be unavailable. lvm> help pvremove Remove LVM label(s) from physical volume(s) pvs Display information about physical volumes pvscan List all physical volumes segtypes List available segment types systemid Display the system ID, if any, currently set on this host tags List tags defined on this host vgcfgbackup Backup volume group configuration(s) vgcfgrestore Restore volume group configuration vgchange Change volume group attributes vgck Check the consistency of volume group(s) vgconvert Change volume group metadata format vgcreate Create a volume group
takuya@:~$ ll /sbin/ | grep lvm 107:lrwxrwxrwx 1 root root 3 2017-03-18 01:29 lvchange -> lvm 108:lrwxrwxrwx 1 root root 3 2017-03-18 01:29 lvconvert -> lvm 109:lrwxrwxrwx 1 root root 3 2017-03-18 01:29 lvcreate -> lvm 110:lrwxrwxrwx 1 root root 3 2017-03-18 01:29 lvdisplay -> lvm
あとはこの結果を xargs などで配列にしてあげればいい
やり方はいくらでもあると思う。
takuya@:~$ ll /sbin/ | grep lvm | cut -d ' ' -f 13 | sort | uniq | xargs -I@ echo /sbin/@ |xargs echo | tr ' ' ' ,' /sbin/lvchange,/sbin/lvconvert,/sbin/lvcreate,/sbin/lvdisplay,/sbin/lvextend,/sbin/lvmchange,/sbin/lvmconfig,/sbin/lvmdiskscan,/sbin/lvmsadc,/sbin/lvmsar,/sbin/lvreduce,/sbin/lvremove,/sbin/lvrename,/sbin/lvresize,/sbin/lvs,/sbin/lvscan,/sbin/pvchange,/sbin/pvck,/sbin/pvcreate,/sbin/pvdisplay,/sbin/pvmove,/sbin/pvremove,/sbin/pvresize,/sbin/pvs,/sbin/pvscan,/sbin/vgcfgbackup,/sbin/vgcfgrestore,/sbin/vgchange,/sbin/vgck,/sbin/vgconvert,/sbin/vgcreate,/sbin/vgdisplay,/sbin/vgexport,/sbin/vgextend,/sbin/vgimport,/sbin/vgimportclone,/sbin/vgmerge,/sbin/vgmknodes,/sbin/vgreduce,/sbin/vgremove,/sbin/vgrename,/sbin/vgs,/sbin/vgscan,/sbin/vgsplit
このメモは随分前に書いていて、公開してなかったものなので、情報が古い可能性があります。昔LVMを触り始めたころに何故か sudo lvs が出来なくてこういうことをしました。今はできるはず。
sudoers のサンプル程度に使ってください。
CPUにAES-NI の命令セットが載っているのに、ディスクを暗号化しないなんて、勿体無いとちょっと思ってるんです。
iPad / iPhone の iOS はもちろんのこと、Androidですらディスクは暗号化されているというのに、PCを使う我々は暗号化ディスクを使わずに平文で使うのはもったいない。
takuya@:~$ cat /proc/cpuinfo | /bin/grep flags | head -n 1 | xargs -n1 echo | sort | /bin/grep -i aes
AESがあるんですよね。IntelのCPUは安くてもAES付いてるので優秀だと思います。
Ubuntuのインストールなどで、ディスクの暗号かを選ぶと すべてのディスクは dm-crypt で暗号化される。
dm-crypt で起動ディスクのパーティションを暗号化したら、
当然ですが、/ root の全てが暗号化されるので、パスフレーズを入れて解除しないと、起動ができません。
通常のノートpcであれば問題ないのですが、遠隔からリモート再起動をしようとすると詰みますよね。
そこでSSH経由でパスフレーズを授受するする方法が一般的です。
linuxの起動は、いくつかのbootstrapに分かれているので
途中の initramfs のところで暗号化ディスクのロックを解除している。
通常はここでパスフレーズの入力になっている。
今回は、この場所にSSHを導入してリモートからロック解除を出来るようにする。
使うサーバーは簡易SSHサーバーのdropbearを使う。
apt-get install openssh-server dropbear busybox ## ubuntu の場合は、更に次が必要。 sudo apt install dropbear-initramfs
dropbear をインストールしたら。dropbear-initramfs も一緒に導入された。
鍵の場所は debian /ubuntu の場合は、最初から決まっていて
ここに公開鍵を入れる
/etc/dropbear-initramfs/authorized_keys
/etc/dropbear/
もあるが、こっちはinitramfs では使わない。## 2024-04-03 追記
ここで入れた公開鍵が dropbearのSSHサーバー で使われるものになる。
私は無精をして、次のようにコピーして利用した。
sudo cp /root/.ssh/authorized_keys /etc/dropbear-initramfs/authorized_keys
authorized_keys が準備できたら、 iniramfs を作り変えて dropbear を入れた initramfs を作る
sudo update-initramfs -u
最後に、grubに環境変数を設定して、initramfs に渡るようにします。
GRUB_CMDLINE_LINUX="ip=192.168.2.99::192.168.2.1:255.255.255.0::eth0:none"
このフォーマットは、決まっていて、次のように書いている。
ip=[dropbear_ip]::[gateway]:[netmask]::[nic]:none"
最後にGrubの起動設定を書き換えて、dropbear に ip='' が渡るようにする。
update-grub
ssh -o "HostKeyAlgorithms ssh-rsa" root@192.168.2.99
このときに、ユーザー名は root になる、IPは先程指定したIPアドレス。秘密鍵は、authorized_keys で指定した公開鍵とペアになるものを使う。
# crypt-unlock
ここでパスを入れれば、GUIからロック解除するのと同じ意味になる。
ちなみに、 Ctrl+Alt+F2 で切り替えたCLI(Xを使わない)モードでもcrypt-unlockが出来る。なので、手順が心配ならSSH経由にする前にcrypt-unlockを事前試してもいいと思う。
かんたんにロック解除は出来ますが、authorized_keys の入った initramfs は当然ですが暗号化されていません。ここもセキュリティを確保したいとなるとPXEブートなどで遠隔からgrub とinitram を導入するなどの手順を使うことになるんでしょうね。
initramfs でdropbear を有効にしたら、NetworkManagerで、ネットワークデバイスが unmanaged になります。systemd が起動するより前に ネットワークデバイスが管理下に置かれるからみたいだけど。バグ?だよねこれ。
NetworkManagerが eth0(enp3s0)が 管理無しでどうやっても unmanaged になって、nmcli がmanaged にならないので、非常に苦しんだが。このdropbearが原因だった。
dropbear-initramfs
と /etc/dropbear/
に付いて追記