↑日記で日々積み重ねた情報をトップの「わんこのページ」にまとめています。

おのたく日記 YouTubeも始めました→

2023-06-03(Sat) [長年日記] この日を編集

■ logcheckのメールが大きすぎ

今日の学び「jornalctlはロケールに合った日付で返す」

最近、logcheckのメールが大きくなっています。内容を見てみると、以下のようになっていました。


5月 30 12:05:54 on-o.com sm-mta[1699926]: 34U35qGY1699926: milter=greylist, action=data, continue
5月 30 12:05:54 on-o.com sm-mta[1699926]: 34U35qGY1699926: milter=greylist, action=eoh, continue
5月 30 12:05:54 on-o.com sm-mta[1699926]: 34U35qGY1699926: milter=greylist, action=header, continue

時間が日本語になっているため、フィルターをすり抜けてしまっている可能性があり、ロケール設定が悪いことが原因かもしれません。ただ、システムロケールを変えるのは面倒です。今回、調べてみたところ、システムロケールをLANG=ja_JP.UTF-8にしているため、rsyslogのロケールがja_JPになっていてログの日付が日本語になっているのだと思いましたが、/var/log/mail.logを見ると時間は正しくなっていました。


2023-05-28T00:02:28.983494+09:00 on-o.com sm-mta[2451659]: 34RF2S4v2451659: milter=greylist, action=connect, continue
2023-05-28T00:02:29.008603+09:00 on-o.com sm-mta[2451659]: 34RF2S4v2451659: milter=greylist, action=helo, continue

一部だけ日本語になっているのかとgrepで探し回ったけど、見つかりませんでした。

そうこうしているうちに、logcheckがjorunalctlでログを取得していることに気がつきました。以下がそのログです。


$ journalctl |grep milter=greylist|head
5月 29 21:40:30 on-o.com sm-mta[4067371]: 34TCeUN04067371: milter=greylist, action=connect, continue
5月 29 21:40:31 on-o.com sm-mta[4067371]: 34TCeUN04067371: milter=greylist, action=helo, continue

あたり🎯今回の問題はこれによるものでした。


--- /etc/cron.d/logcheck.org	2010-01-03 15:18:23.000000000 +0900
+++ /etc/cron.d/logcheck	2023-06-03 06:04:02.863906271 +0900
@@ -2,6 +2,7 @@

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
+LANG=C

@reboot         logcheck    if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck -R; fi
2 12 * * *       logcheck    if [ -x /usr/sbin/logcheck ]; then nice -n10 /usr/sbin/logcheck; fi

対策として、cronで起動されるlogcheckにLANG=Cを加えて、様子を見ることにしました。

■ In English: logcheck email is too large

Today's lesson: "journalctl returns a date that matches the locale"

Recently, logcheck emails have become too large. Upon reviewing the content, it appears as follows:

Since the time is in Japanese, it may have slipped through the filters and the cause may be due to bad locale settings. However, changing the system locale is a hassle. Upon investigation, it was found that rsyslog's locale was ja_JP because the system locale was set to LANG=ja_JP.UTF-8, causing the date on the logs to be in Japanese, but upon checking /var/log/mail.log, the time was correct.

Although I searched with grep to find parts that were in Japanese, I couldn't find any.

In the meantime, it was noticed that logcheck was obtaining logs with jorunalctl. The following is the log:


$ journalctl |grep milter=greylist|head
5月 29 21:40:30 on-o.com sm-mta[4067371]: 34TCeUN04067371: milter=greylist, action=connect, continue
5月 29 21:40:31 on-o.com sm-mta[4067371]: 34TCeUN04067371: milter=greylist, action=helo, continue

This was the cause of the problem.

As a countermeasure, LANG=C was added to logcheck launched by cron, and the situation will be monitored.

[ツッコミを入れる]

2023-05-30(Tue) [長年日記] この日を編集

■ slackもどきのMattermostにChatGPTのbotの「chatgpt-mattermost-bot」を使っています。

一度メンションしたスレッドには答えてくれるけど、最初はメンションしないと出てこないのが面倒だけど、ChatGPTを普通に使えるのは便利。

いつものように、Azure OpenAI Serviceで使えるようにする、Pull Requestを投げた。

[ツッコミを入れる]

2023-05-15(Mon) [長年日記] この日を編集

■ tDiary用のChatGPTプラグインを作りYahoo校正支援プラグインの修正した

私は日記を書く際、ChatGPTを利用して推敲しています。しかしこれを行うためには毎回ChatGPTを開く必要があり、面倒でした。そこで、自分でtDiary用のプラグインを作成し、GitHubにプルリクエストを出しました。このプラグインにはOpenAI APIを使用した校正・推敲機能があります。詳細については、#248 ✨新機能(plugin/chatgpt_elaborate.rb): OpenAI APIを使用した校正・推敲プラグインを作りましたをご覧ください。

また、参考にしたYahoo校正支援プラグインは既にサービスが終了しているV1でした。そこで、私はV2に対応するように修正を加え、プルリクエストを送信しました。詳細については、#247 🚚(plugin/yahoo_kousei.rb): Yahooの校正支援のAPI V2対応をご覧ください。

私はtDiaryのコントリビュートにプルリクエストを送信するのが初めてだと思っていました。そこで、参考にするべく、マージされたプルリクエストを調べていたところ、自分が忘れていたプルリクエストがあったことに気づきました。それは、#243 Add Launchpad on OpenID pluginで、2021年7月26日に送信されたものでした。すっかり忘れてました。

#OpenAI推敲済み

[ツッコミを入れる]

2023-05-14(Sun) [長年日記] この日を編集

■ ChatGPTにGitMojiのMozc辞書を作ってもらった

なんかGitMojiという、Commitメッセージの頭に付ける絵文字が有ることを知った。

なんなのかChatGPTに聞いて、Mozc(Google日本語入力)に登録できる辞書を作ってもらった。

これ、簡単に行かず何度も、区切り文字とか順番とか入れ替えてもらってやっとできた。

sparkles ✨ 記号新機能の追加

bug 🐛 記号バグ修正

art 🎨 記号デザインの変更

zap ⚡️ 記号パフォーマンス改善

fire 🔥 記号不要なコードの削除

memo 📝 記号ドキュメントの追加や更新

lipstick 💄 記号 UIの改善

truck 🚚 記号ファイルの移動や名称の変更

wrench 🔧 記号ツールやライブラリのアップデート

lock 🔒 記号セキュリティ関連の修正

かな打ちでは単語を打つのが難しいので、新しいよみも考えて追加した

しんきのう ✨ 記号新機能の追加

ばぐ 🐛 記号バグ修正

でざいん 🎨 記号デザインの変更

かいぜん ⚡️ 記号パフォーマンス改善

せいのう ⚡️ 記号パフォーマンス改善

りふぁくた 🔥 記号不要なコードの削除

めも 📝 記号ドキュメントの追加や更新

どっく 📝 記号ドキュメントの追加や更新

こすめ 💄 記号 UIの改善

ゆーあい 💄 記号 UIの改善

いどう 🚚 記号ファイルの移動や名称の変更

つーる 🔧 記号ツールやライブラリのアップデート

せきゅりてぃ 🔒 記号セキュリティ関連の修正

■ OpenAI APIのChatGPTで校正・推敲をしてもらうtDiaryプラグインを開発した

OpenAI APIのChatGPTを使用したtDiaryプラグインで文章の校正・推敲を行うことに挑戦中ですが、うまくいかず苦戦しています。しかし、昨晩の夢で宇宙人と交信をし、彼らの文明について学ぶという不思議な体験をしました。皆さんも最近見た面白い夢があれば、ぜひ教えてください。

これは、chatgpt_elaborate.rbのチェックをするために行っています。

というのはやめて、面白い文章にしてください。

とやったりして色々、文章が変わっていったが、ついに下のようなのが出てきた。

■ タイトル：「宇宙人に会って夢の中で文明を学んだ話」

OpenAI APIのChatGPTを駆使したtDiaryプラグインで文章の校正・推敲に挑戦していた私。しかし、その苦戦を吹き飛ばすような不思議な体験が夢の中で待っていた。

夢の中で私は、宇宙人と交信をし、彼らの文明について学ぶことができた。彼らの技術や文化、社会システムに驚嘆しつつ、私は彼らとの会話を楽しんだ。

そして、目が覚めると、私は自分の文章の修正に取り組むことができるようになっていた。不思議な夢のおかげで、私はより良い文章を生み出すことができたのだ。

この体験を通じて、私は夢はとても面白く、人生にとって大切なことを教えてくれると感じた。皆さんも最近見た面白い夢があれば、ぜひ共有していただきたい。

[ツッコミを入れる]

2023-05-10(Wed) [長年日記] この日を編集

■ [NodeJS][Azure][OpenAI] NodeJSでAzure OpenAI Serviceを利用する方法

結論:openai npmパッケージでは、OpenAPI Generatorを利用しているので、それに渡すOptionにバラメターを加えることでOpenAIと同じようにAzure OpenAI serviceの呼び出しが可能。

NodeJSでAzure OpenAI Serviceを利用する方法について説明します。

"OpenAIのAPIと同じようなAPIを使えるとMicrosoftが言っているAzure OpenAI Serviceが始まっています。

See: Azure OpeAI ServiceのREST APIリファレンス

しかし、OpenAIのAPIと異なり、Azure版は呼び出しURLが異なったり、API Keyの送り方が違うため、多くのOpen API用のオープンソースについてのライブラリが対応していないようです。また、Azure OpenAI Studioで出てくるサンプルコードでも、PythonとC#しか出てきていません。

Azure OpenAI Studioで出てくるサンブルコード

OpenAI向けのJavaScriptやTypeScript用のopeai npmパッケージでも特にAzureに関するドキュメントが見つかりませんでしたが、Azure OpenAI Serviceに対応するためには以下の3つの変更が必要です。

BASE_URLを変える。ENDPOINTとモデル・デプロイ名をURIに入れる

HTTPリクエストヘッダに"api-key"を付ける

パラメータにapt-version=2023-03-15-previewを付ける

上記の変更を加えたコードは以下のようになります。


   switch (apiType) {
     case 'azure':
       this.openAiApiConfiguration.baseOptions =  {
         headers: {
           'api-key': apiKey,
         },
         params: {
           'api-version': '2023-03-15-preview',
         }
       };
       if (basePath) {
         this.openAiApiConfiguration.basePath = basePath + 'openai/deployments/' + MODEL;
       }
       break;
     case 'openai':
     default:
       if (basePath) {
         this.openAiApiConfiguration.basePath = basePath;
       }
       break;
   }
   this.openAI = new OpenAIApi(this.openAiApiConfiguration);

github/takuya-o opencommit/src/api.tsから引用

以上が、NodeJSでAzure OpenAI Serviceを利用する方法です。

同じように他のプログミング言語でもOpenAPI Generatorを利用しているならば、OpenAIのコンストラクタに渡すOptionにパラメーターを追加することでOpenAIと同じようにAzure OpenAI serviceの利用が可能だと思います。

[ツッコミを入れる]

2023-04-27(Thu) [長年日記] この日を編集

■ [GCE] Google Cloud Engineの無料VMのバージョンアッブ

Googleクラウドでは、小さなVMを1つならば無料で使えるので、CI/CD用のgitlab-runner走らせたり、そのキャッシュのオブジェクトストアとかに、ずっと利用している。

ふと気がつくと、2017年11月にVMを作成してから、ずっとそのまま使っていた。今日、最新の15.11のgitlab-runnerに上げようとして

$ docker pull gitlab/gitlab-runner

としたら、メタデータが何やらというエラーでpullできない。

おうちサーバではエラーも無いので、これを機会に新しいVMを作成することにした。

本当は、無料のCPUがf1-microからe2-microに変わったときにも新しくする機会が有ったのだけど、同時にいくつも変えるのが不安だったので、やっていなかった。

なんと古いVMのCOS(Container Optimized OS)は、cos-dev-64-10133-0-0

Google, Container-Optimized OS, 64-10133.0.0 dev, Kernel: ChromiumOS-4.4.96 Kubernetes: 1.7.8 Docker: 17.03.2

で、当然だけどサポートも終了している。

新しいのは、cos-105-17412-1-66

Google, Container-Optimized OS, 105-17412.1.66 LTS, Kernel: COS-5.15.90 Kubernetes: 1.25.5 Docker: 23.0.0 Family: cos-105-lts, supports Shielded VM features

新しいVMでのお試しgitlab-runnerでのCIもうまく行き、オブジェクトストアにもキャッシュができている。

お引越しキットも正しく動くことも分かったし今後はこまめにupdateしよう。

[ツッコミを入れる]

2023-01-01(Sun) [長年日記] この日を編集

■ [Debian] マシン再起動したらclamav-daemonが立ち上がらない

今日の学びは「リブートしたら変わるかも」。

12月27日の日記でライブラリだけ古いのものにしたのが悪るかったのか、マシンをリブートしたら


clamd[9958]: *** stack smashing detected ***: terminated

とエラーがでてclamav-daemonが起動できない。


# systemctl status clamav-daemon
× clamav-daemon.service - Clam AntiVirus userspace daemon
    Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled; preset
   Drop-In: /etc/systemd/system/clamav-daemon.service.d
            └─extend.conf
    Active: failed (Result: signal) since Sun 2023-01-01 21:11:09 JST; 2min 39
  Duration: 73ms
      Docs: man:clamd(8)
            man:clamd.conf(5)
            https://docs.clamav.net/
   Process: 24062 ExecStartPre=/bin/mkdir -p /run/clamav (code=exited, status=
   Process: 24068 ExecStartPre=/bin/chown clamav /run/clamav (code=exited, sta
   Process: 24069 ExecStart=/usr/sbin/clamd --foreground=true (code=killed, si
  Main PID: 24069 (code=killed, signal=ABRT)
       CPU: 56ms

1月 01 21:11:09 machine systemd[1]: Starting Clam AntiVirus userspace daemon...
1月 01 21:11:09 machine systemd[1]: Started Clam AntiVirus userspace daemon.
1月 01 21:11:09 machine clamd[24069]: *** stack smashing detected ***: terminat
1月 01 21:11:09 machine systemd[1]: clamav-daemon.service: Main process exited,
1月 01 21:11:09 machine systemd[1]: clamav-daemon.service: Failed with result '

■ とりあえず、前回バージョンを下げたライブラリを元に戻してみた。


[UPGRADE] libclamav9:amd64 0.103.7+dfsg-0+deb11u1 -> 0.103.7+dfsg-1+b2

そしたら、無事に動いた・・・

前回もリブートすればよかったかものかも。前回の本当の原因は不明。

[ツッコミを入れる]

2022-12-27(Tue) [長年日記] この日を編集

■ clamav-daemonが起動できなくなる

今日の学びDebian testingはドックフード、動かないときにはstableをためそう。

Debianでapt upgradeで


[UPGRADE] clamav:amd64 0.103.7+dfsg-1+b1 -> 0.103.7+dfsg-1+b2
[UPGRADE] clamav-daemon:amd64 0.103.7+dfsg-1+b1 -> 0.103.7+dfsg-1+b2
[UPGRADE] clamav-freshclam:amd64 0.103.7+dfsg-1+b1 -> 0.103.7+dfsg-1+b2
[UPGRADE] clamav-milter:amd64 0.103.7+dfsg-1+b1 -> 0.103.7+dfsg-1+b2
[UPGRADE] clamdscan:amd64 0.103.7+dfsg-1+b1 -> 0.103.7+dfsg-1+b2

したら

Mon Dec 26 22:11:14 2022 -> --- Stopped at Mon Dec 26 22:11:14 2022

Mon Dec 26 22:11:14 2022 -> Socket file removed.

Mon Dec 26 22:11:14 2022 -> +++ Started at Mon Dec 26 22:11:14 2022

Mon Dec 26 22:11:14 2022 -> Received 0 file descriptor(s) from systemd.

Mon Dec 26 22:11:14 2022 -> clamd daemon 0.103.7 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)

Mon Dec 26 22:11:14 2022 -> Log file size limited to 4294967295 bytes.

Mon Dec 26 22:11:14 2022 -> Reading databases from /var/lib/clamav

Mon Dec 26 22:11:14 2022 -> Not loading PUA signatures.

Mon Dec 26 22:11:14 2022 -> Bytecode: Security mode set to "TrustSigned".

Mon Dec 26 22:11:14 2022 -> ERROR: Malformed database

とウィルスデータペースの署名がだめでclamav-daemonが起動できなくなっていた。

メール送信時のウィルスチェックでも引っかかって送信できず・・・

Received signal: wake up

ClamAV update process started at Mon Dec 26 23:10:50 2022

daily database available for update (local version: 26761, remote version: 26762)

ERROR: cdiff_apply: Incorrect digital signature

ERROR: downloadPatch: Can't apply patch

The database server doesn't have the latest patch for the daily database (version 26762). The server will likely have updated if you check again in a few hours.

main.cld database is up-to-date (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)

bytecode.cld database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2)

freshclamも Incorrect digital signature となってウィルスデータベースの更新もできていない。

何が悪いのかわからず、クラウドでdebian11(bullseye)を起動してみるとちゃんと動く。

そのデータベースを持ってくると動かない。

逆に、こちらのデータベースをクラウドに持っていっても動く・・・

どうやら、testingのDebian12(bookworm)が悪いらしいことに気がついたので


[DOWNGRADE] libclamav9:amd64 0.103.7+dfsg-1+b2 -> 0.103.7+dfsg-0+deb11u1

としたら、とりあえずclamav-daemonが起動できるようになった。

ワークアラウンドだけど、めでたし

[ツッコミを入れる]

2022-12-17(Sat) [長年日記] この日を編集

■ [RaspberriPi] ラズベリーパイ3B+がPXEブート失敗する

今日の学び「bootcode.binは最新を使おうね」

ネットワークスイッチを入れ替えたので、Raspberry Piを再起動したら、緑のLEDの4回点灯を繰り返すだけでブートしない。

こいつはおうちサーバからDHCP,tftp,NFSするネットワークブートのラスパイなので、サーバ側のログを見てみると

022-12-17T21:44:51.715385+09:00 mirara dnsmasq-dhcp[2393288]: 653460281 available DHCP subnet: 192.168.1.255/255.255.255.0

2022-12-17T21:44:51.718150+09:00 mirara dnsmasq-dhcp[2393288]: 653460281 vendor class: PXEClient:Arch:00000:UNDI:002001

2022-12-17T21:44:51.719008+09:00 mirara dnsmasq-dhcp[2393288]: 653460281 PXE(eth0) b8:27:eb:00:00:12 proxy

2022-12-17T21:44:51.720555+09:00 mirara dnsmasq-dhcp[2393288]: 653460281 tags: eth0

2022-12-17T21:44:51.721994+09:00 mirara dnsmasq-dhcp[2393288]: 653460281 broadcast response

2022-12-17T21:44:51.723694+09:00 mirara dnsmasq-dhcp[2393288]: 653460281 sent size: 1 option: 53 message-type 2

2022-12-17T21:44:51.724436+09:00 mirara dnsmasq-dhcp[2393288]: 653460281 sent size: 4 option: 54 server-identifier 192.168.1.2

2022-12-17T21:44:51.725068+09:00 mirara dnsmasq-dhcp[2393288]: 653460281 sent size: 9 option: 60 vendor-class 50:58:45:00:00:00:00:00:74

2022-12-17T21:44:51.725581+09:00 mirara dnsmasq-dhcp[2393288]: 653460281 sent size: 17 option: 97 client-machine-id 00:44:44:44:44:44:44:44:44:44:44:44:44:44...

2022-12-17T21:44:51.726018+09:00 mirara dnsmasq-dhcp[2393288]: 653460281 sent size: 32 option: 43 vendor-encap 06:01:03:00:00:00:00:00:00:00:14:00:00:11...

2022-12-17T21:44:58.692729+09:00 mirara dnsmasq-dhcp[2393288]: 23206708 available DHCP subnet: 192.168.1.255/255.255.255.0

2022-12-17T21:44:53.896282+09:00 mirara dnsmasq-tftp[2393288]: sent /tftpboot/bootcode.bin to 192.168.1.3

2022-12-17T21:44:53.896624+09:00 mirara dnsmasq-tftp[2393288]: file /tftpboot/bootsig.bin not found for 192.168.1.3

って、ことで/tftpboot/bootsig.binが無いのがいけないらしい。名前からしてサイン証明書みたい。しかも、調べてみるとPXEブートにはbootsig.binはいらない模様。

「RXE RPi3 boot stops」とオープンのままなissueと同じ現象みたいなので呆然した。

そういえば、先日ラズベリーパイの中でapt udgradeしたなぁと思い出してbootcode.binを見ていみると

/tftpboot/2021-10-30-raspios# ls -l bo*

-rw-r--r-- 1 root root 52476 11月 16 11:47 bootcode.bin

あたらしいのが来ている。

/tftpboot# ls -l bootcode.bin*

lrwxrwxrwx 1 root root 31 12月 17 21:51 bootcode.bin -> 2021-10-30-raspios/bootcode.bin

-rwxr-xr-x 1 root root 50268 2月 8 2017 bootcode.bin.old

というわけで、2017年製の古いbootcode.binから新たらしいbootcode.binに変えたら無事に起動することができた。

[ツッコミを入れる]

2022-12-08(Thu) [長年日記] この日を編集

■ [git][OpenAI] gitコミットメッセージをAIに作ってもらう

gitのコミットメッセージを生成してくれるauto-commitがおもしろい。何でも答えてくれるChatGPTが巷を騒がせているOpenAIのコード生成OpenAI CodexのAPIを利用している。

OpenAI Codex は Python で最も機能を発揮しますが、JavaScript、Go、Perl、PHP、Ruby、Swift、TypeScript、さらには Shell など、12 を超える言語にも対応しています。

[https://openai.com/blog/openai-codex/より引用]

GitHubのリリースに、Debianパッケージもあるので、そのままインストール。

Alpineなどでは、


$ curl -fsSL https://raw.githubusercontent.com/m1guelpf/auto-commit/main/install.sh | sh -

とすると、$HOME/.binにauto-commitがインストールされる。Open AIのダッシュボードのQuickstart tutorialのAdd your API keyで、Create new secret keyすると、OPENAI_API_KEYが作れるので、環境変数に入れておく。


export OPENAI_API_KEY='sk-XXXXXXXX'

って、.bashrcの最後に書けばいいかな。

■ auto-commitを試してみた


$ git diff --staged
diff --git a/docker-compose.yml b/docker-compose.yml
index 2e4ca4a..42d017a 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -52,6 +52,20 @@ services:
        ipv4_address: $IP_ADDRESS01
    hostname: node-red01
+  node-red02:
+    image: nodered/node-red:2.1.4
+    restart: always
+    environment:
+    - NODE_RED_ENABLE_PROJECTS=true
+    - NODE_OPTIONS=${NODE_OPTIONS}
+    - TZ="Asia/Tokyo"
+    #Secret Variables
+    - GOOGLE_CLOUD_PROJECT=${GOOGLE_CLOUD_PROJECT}
+    user: $CUID:$CGID
+    volumes:
+    - ./data02:/data
+    hostname: node-red02
networks:
  default:
    ipam:

とdocker-composeにserviceを1つ追加してみたら


$ auto-commit --dry-run

Add node-red02

This is a test commit.

だそうだ。なんか"This is a test commit."とか入っているので、commitメッセージをeditできるように-rオプションをつけて起動して


$ auto-commit -r
Loading Data...
Finished Analyzing!
Proposed Commit:
------------------------------

Add node-red02

This is a test commit.

------------------------------
Do you want to continue? (Y/n) y
--エディタ起動--
Committing Message...
[docker-compose 71f9c4c] Add node-red02
1 file changed, 14 insertions(+)
[docker-compose b913b55] Add node-red02
Date: Fri Dec 9 02:02:49 2022 +0900
1 file changed, 14 insertions(+)

とするのが良いみたい。

[ツッコミを入れる]

トップ追記

tDiary 日記の書き方 Plug-inの使い方 README