ホーム » コンピュータ (ページ 25)
「コンピュータ」カテゴリーアーカイブ
Makefile に git は邪道?
今まで、git はあんまり使ってこなかったが、講習会向けのファイル配布を github で簡単にできるようにするために、準備。
だけど、使い慣れていないからコマンドをいちいち確認。でも、add , commit , push の流れとかも、いちいちキー入力するのは面倒。IDE 環境使えば git コマンドも簡単なのかもしれないけど、オールドタイプは「make 使えばいいじゃん…」となってしまう。
git コマンド発行用 Makefile
以下の Makefile をプロジェクトに入れておけば、add, commit, push も “make”一発。
# git@example.com:foo/bar.git
GH_ID = foo
GH_PROJECT = bar
GH_SSH = git@example.com:$(GH_ID)/$(GH_PROJECT).git
REPOSITORY = origin
BRANCH = master
DATE := $(shell date +%Y/%m/%d)
HOSTNAME := $(shell hostname)
all: add commit push
@echo $(GH_SSH)
add:; git add -u
commit:; git commit -m $(DATE)-$(HOSTNAME)
push:; git push $(REPOSITORY) $(BRANCH)
pull:; git pull $(REPOSITORY) $(BRANCH)
ただ、この設定しちゃうと、ちょっとファイルを触っただけでも “make” しちゃう癖がついているので commit を乱発することになるので、バージョン管理という意味では邪道かもしれない。、
dotfile を git で管理
以前、git を活用している人の記事で、リモートサーバを渡り歩く時、自分用の .bashrc などの dotfile をいちいちコピーするのは面倒だから、git を使う…というのがあったのでやってみる。
- 自宅サーバで、ssh 経由で更新できる git サーバ環境を構築
- dotfile 用のフォルダを作り、対象の dotfile をコピー
- git init で dotfile フォルダを管理対象に
- $HOME/.bashrc など消して、ln -sf dotfile/bashrc .bashrc で参照するように設定。
- 前述 git コマンド発行用のMakefile なども準備して、make
- あとは、新しいサーバを触る時には、”git clone git@…dotfile.git”
iOS15でナビとのテザリングが改善
dovecot が動かない Let’s Encrypt 証明書問題
数日前から、iphoneで自宅サーバのメールを見ると証明書が有効期限切れとのエラーが表示される。パソコンから Thunderbird で見るのには影響がないようだ。設定を色々と確認しても改善しない。
/var/log/mail.log を見ると、”SSL issue: alert number 46″ などのエラーメッセージが残っていて、dovecot と合わせてググると、Let’s Encrypt のルート証明書が、2021/09/30 で切れるといった記事が見つかり、これが影響しているようだ。
dovecot の設定の修正
さらに検索すると、ようやく対応記事が見つかった。ssl_cert の cert.pem を fullchain.pem に替えるだけ。こちらの資料を見ても、dovecot とか postfix なら fullchain.pem を使うような説明がある。
((( /etc/dovecot/conf.d/10-ssl.conf ))) # ssl_cert = </var/lib/dehydrated/certs/自宅サーバ名/cert.pem ssl_cert = </var/lib/dehydrated/certs/自宅サーバ名/fullchain.pem ((( restart dovecot ))) $ sudo systemctl restart dovecot
postfix の設定の修正
同じような設定は postfix も使っていたはず。試しに、iphone でメールを出そうとすると、dovecot と同じような証明書が信用できないとのメッセージでメールが送れない。
((( /etc/postfix/main.conf ))) # smtpd_tls_cert_file=/var/lib/dehydrated/certs/自宅サーバ名/cert.pem smtpd_tls_cert_file=/var/lib/dehydrated/certs/自宅サーバ名/fullchain.pem ((( restart postfix ))) $ sudo systemctl restart postfix
国別拒否リストでVN,PH追加
自宅サーバへの攻撃のチェック中。IPアドレスの所属する国を確認した拒否リストを作ってフィルタリングしているけど、改めて攻撃者のIPアドレスを、whois を使って国を確認する。
今回は、現時点で許可している状態で、ssh への攻撃をドメイン毎に分類して作成したCクラスの拒否リストの国を確認したら、ベトナム 60 件、フィリピン 12件。ということで、日本としては仲良くしたい国かもしれんけど、ゴメン拒否の国に追加やわ。
WSLでX11 GUIを使う
Windows 11 の WSL になれば、X サーバなど準備しなくても動くようになるんだけどね。WSLのPythonでGUIアプリを動かすにはどうすればいいかと試してみた。
XcXsrv を入れてあったけど、面倒で環境作ってなかった。改めて X関係のソフトを入れてみた。
$ sudo aptitude install x11-apps fonts-ipafont inkscape gimp tgif $ export DISPLAY=192.168.xx.yy:0.0 $ xeyes
GIMPとかInkscapeとかGoogle Chromeなども入れてそれなりに上手く動くけど、emacs が上手く動かないな…
homebridge-gsh 不調が回復
最近、homebridge の機能を Google home から制御するためのプラグイン homebridge-gsh が動かない状態であった。ひとまず “Siri” 中心にしてたけど、回復。
google アシスタントで、homebridge との接続を解除して、デバイスをすべて削除した後、再度接続を行う。この時、google アシスタントのデバイスの登録画面などが随分雰囲気が変わっていたので、Google Home, アシスタントの機能が更新されて、homebrige と通信ができなくなっていたのが原因かもしれない。
Siriのシーン登録
Google Homeでhomebridge制御が動かないときがある
最近、Google home mini からRaspberry Pi の homebridge の制御で「homebridgeが見つかりません」の返答が返ってくることが増えた。
どうも、homebridge-gsh では裏で無料のクラウドサービスが使われているけど、たぶんこのクラウドの反応が悪いのかもしれない。(追記:google home の機能変更が原因?)
しかし、Home Pod mini を使い始めてるし、”Hey Siri”で頼むのに切り替えればいい。ただ、”Ok google, 行ってきます”で、テレビと部屋の照明を消す機能の、Siri での設定に悩んだ。
iOS ホームのシーンの登録
“Google Home”アプリでは、複数機能の連動ではルーティン機能を使っていたので、”Google Home” の iOS版ということで、”ショートカット機能”ばかり調べてた。でも、こういう設定は、iOS ではホームアプリのシーン機能だった。ただ、”Google Home”であれば、「いってきます」で、テレビを消した後に「天気」を喋らせたりと、機器制御以外の処理も連動できたけど、iOS “ホーム” では機器制御しかできない。
ntpが正しく動かなくなった
ntp サーバが正しく動かない
NTPが正しく動いていない。nagios で、check_ntp_peer コマンドにて、NTP サーバの動作を検証しているが、
# /usr/lib/nagios/plugins/check_ntp_peer -H 127.0.0.1 NTP CRITICAL: Server not synchronized, Offset unknown|offset=0.000000s;60.000000;120.000000;
にて、同期がとれていないとのメッセージ。いろいろと、/etc/ntp.conf を触ってみるが、うまく動いていない。
ntp プロセスを確認すると、
# ps ax | grep ntp 9999 ? Ssl 0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /run/ntp.conf.dhcp -u 122:130
となっていて、設定ファイル /etc/ntp.conf を参照せずに、/run/ntp.conf.dhcp を読み込んでいる。この設定ファイルでは、dhclient で DHCP にて IP アドレスをもらう際に、ntp-server が指定されていたら、それを使うための設定らしい。じゃあ、この /run/ntp.conf.dhcp を作っているのはだれ?となる。
NetworkManager が原因
色々と確認したら、NetworkManager が原因のようだ。NetworkManager が管理しているデバイスだと、上記の余計な設定をしてくれるらしい。時期的には、Debian/bookworm に切り替えて、普通に upgrade したら、NetworkManager の機能が増えたんだろう。
eth0 を NetworkManager の管理から外すと無事に動き出す
ということで、NetworkManager が eth0 の設定を触らないようにさせる。
((( /etc/systemd/network/eth0.network で固定アドレスを割振る設定 ))) [Match] Name=eth0 [Network] Address=192.168.xx.2/24 Gateway=192.168.xx.1 ((( /etc/NetworkManager/conf.d/99-unmanaged-devices.conf ))) [keyfile] unmanaged-devices=interface-name:eth0 ((( NetworkMangaerを再起動 ))) # systemctl reload NetworkManager ((( NetworkManagerの確認 ))) # nmcli device status DEVICE TYPE STATE CONNECTION eth0 ethernet 管理無し -- lo loopback 管理無し -- ((( ntpの起動状態を確認 ))) # ps ax | grep ntp 9999 ? Ssl 0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 122:130
ということで、無事に eth0 が NetworkManager の管理から外れ、ntp が正しい設定ファイル /etc/ntp.conf を読むようになった。
でも、”ps ax” を試すと、”dhclient eth0″ が動いている。どうも、IPアドレスの設定がおかしい。以前に、nmcli コマンドを試したときのゴミが残っているのかな。設定情報のファイルを編集。
((( /etc/NetworkManager/system-connections/eth0.nmconnection ))) [connection] id=static <-- ここが eth0 と書かれていた。ここは、dhcp か static になるべき。 uuid=xxxxxxxxxxx type=ethernet interface-name=eth0 :








