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

■ GitLab 16.6.0へのアップグレードでデータベースマイグレーションに失敗する

毎回のことですが、今月も新しいGitLabのバージョンがリリースされたのでアップグレードしました。しかし、またしてもエラーによりアップグレードができませんでした。

以下のエラーメッセージが表示されました。

gitlab-ce-gitlab-ce-1 | PG::UndefinedObject: ERROR: constraint "fk_262d4c2d19" for table "ci_pipelines" does not exist

gitlab-ce-gitlab-ce-1 | /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migrations/constraints_helpers.rb:253:in `rename_constraint`

同様のエラーが以前にも発生していないか調べてみました。以下の情報を見つけました：

gitlabhq_development=# \d+ ci_pipelines

...

Referenced by:

TABLE "ci_pipelines" CONSTRAINT "fk_262d4c2d19" FOREIGN KEY (auto_canceled_by_id) REFERENCES ci_pipelines(id) ON DELETE SET NULL

TABLE "ci_pipeline_chat_data" CONSTRAINT "fk_5b21bde562" FOREIGN KEY (pipeline_id_convert_to_bigint) REFERENCES ci_pipelines(id) ON DELETE CASCADE

TABLE "p_ci_builds" CONSTRAINT "fk_87f4cefcda" FOREIGN KEY (upstream_pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE

TABLE "p_ci_builds" CONSTRAINT "fk_a2141b1522" FOREIGN KEY (auto_canceled_by_id) REFERENCES ci_pipelines(id) ON DELETE SET NULL

TABLE "p_ci_builds" CONSTRAINT "fk_d3130c9a7f" FOREIGN KEY (commit_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE

[Ensure that all tables that reference ci_pipelines have partition_id columnより引用]

上記の情報から、ci_pipelinesを参照しているテーブルにfk_262d4c2d19という制約が存在しないことがわかりました。

次に、以下の手順で修正を試みました：

上記の手順で修正を行ったところ、次のエラーが発生しました：

gitlab-ce-gitlab-ce-1 | Caused by:

gitlab-ce-gitlab-ce-1 | PG::UndefinedObject: ERROR: constraint "fk_fb57e6cc56" for table "ci_stages" does not exist

gitlab-ce-gitlab-ce-1 | /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migrations/constraints_helpers.rb:253:in `rename_constraint

ので、同様に

Foreign-key constraints:

"fk_c5ddde695f" FOREIGN KEY (pipeline_id_convert_to_bigint) REFERENCES ci_pipelines(id) ON DELETE CASCADE

"fk_fb57e6cc56" FOREIGN KEY (pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE

[Prepare foreign key constraints for bigint ci_stages.pipeline_idより引用]

上記の情報から、ci_pipelinesを参照しているテーブルにfk_262d4c2d19という制約が存在しないことがわかりました。

次に、以下の手順で修正を試みました：

$ docker compose exec gitlab-ce bash

root@gitlab-ce:/# gitlab-ctl status

run: gitaly: (pid 307) 30s; run: log: (pid 305) 30s

run: gitlab-kas: (pid 373) 19s; run: log: (pid 372) 19s

run: gitlab-sshd: (pid 311) 30s; run: log: (pid 310) 30s

run: logrotate: (pid 309) 30s; run: log: (pid 306) 30s

run: postgresql: (pid 375) 19s; run: log: (pid 374) 19s

run: redis: (pid 312) 30s; run: log: (pid 308) 30s

run: sshd: (pid 38) 80s; run: log: (pid 37) 80s

root@gitlab-ce:/# gitlab-psql

psql (13.11)

Type "help" for help.

gitlabhq_production=# ALTER TABLE ci_stages ADD CONSTRAINT fk_fb57e6cc56 FOREIGN KEY (pipeline_id) REFERENCES ci_pipelines(id) ON DELETE CASCADE;

ALTER TABLE

gitlabhq_production=# \q

root@gitlab-ce:/# exit

としらたら、無事にマイグレーションが終わって無事に16.6.0が起動しました。

GitLabのissueに入れるべきだけど、午前4時で眠いのでまた

■ SourcegraphのCodyを試す

CodyはSourcegraph製のGitHub Copilotです。

今まで似たようなものとして、Emacsでも使えるCodiumや、AWS CodeWhispererを使っていましたが、これはその一環です。

Sourcegraph Enterpriseのライセンスがある人は、Self Hostedの人もSourcegraph Codey Gatewayを利用してコード補完やChatが使えますが、試してみたところうまく行きませんでした。

Sourcegraph Cloudのサブスクリプション画面を開いてみると、CodyはEnableになりません。

確かに、Soucegraph 5からは有料になりましたが、Sourcegraph 4からUpgradeしたユーザーに配布された無料ライセンスでは無理かもしれません。

というわけで、OpenAIをLLMプロバイダとして利用します。

■ Google DriveをDebianで同期する

Debian用のものは見つからなかったので、Ubuntu用のgoogle-drive-ocamlfuseを使用します。

# cat < /etc/apt/sources.list.d/alessandro-strada-ubuntu-ppa-bionic.list >> EOF
deb [signed-by=/usr/share/keyrings/google-drive-ocamlfuse.gpg] http://ppa.launchpad.net/alessandro-strada/ppa/ubuntu xenial main
deb-src [signed-by=/usr/share/keyrings/google-drive-ocamlfuse.gpg] http://ppa.launchpad.net/alessandro-strada/ppa/ubuntu xenial main
EOF
# gpg --keyserver keyserver.ubuntu.com --recv-keys AD5F235DF639B041
# gpg --export AD5F235DF639B041 >/usr/share/keyrings/google-drive-ocamlfuse.gpg
# apt update
# apt install -y google-drive-ocamlfuse

使い方

$ google-drive-ocamlfuse -docsmode msoffice
$ mv ~/.gdfuse ~/.config/gdfuse 

で認証しconfigをMS Officeモードで作って、.configの下のほうが好みなので移して

$ google-drive-ocamlfuse ~/GoogleDrive

でマウントします。

$ google-drive-ocamlfuse -cc

調子が悪い場合はキャッシュをクリアしてください。

参考:

* hannesbe/install-google-drive-ocamlfuse-debian.sh

■ 以下は、AirCampusの視聴中のメモ作成時に発生する問題点と、それを解決するためのUserScript AirCampus視聴メモアクセレータ の説明です。

問題点：

AirCampusの視聴中にメモ欄を使う場合に、右側に表示されるメモ欄では、CTRL + ENTERでメモが保存されます。しかし、下のスクリーンショットに示す、ビデオの下の「メモ」タブの場合には、「保存」ボタンを押さなければメモが保存されません。

このため、視聴中にキーボードからマウスに手を移動しなければならず、集中力が途切れるという問題があります。

解決策：

上記の問題を解決するために、UserScriptを作成しました。このUserScriptを導入すると、「メモ」タブでも、CTRL + ENTERでメモが保存されます。これにより、視聴中にキーボードから手を移動する必要がなくなり、集中力を保ったままメモを作成できます。

これにより、AirCampusでのメモ作成がよりスムーズに行えます。

これにより、メモ作成の効率が向上し、集中力を保ったまま学習を進めることができるようになると思います。

■ GPT-4のテスト

昨日、BBTアルムナイセミナーに参加したら、OpenAI APIを試してみるためのAPIを公開してくれました。tDiaryのプラグインを使用して、本家のOpenAI APIでも正常に動作するかテストしてみます。

残念ながらGPT-4は使用できないAPIキーでしたが、本家のOpenAI APIでのテストは成功しました。

■ OpenAI API ChatGPT素直すぎ

今日の学び「ChatGPTでも入れたものしか返ってこない所詮は計算機」

最近、GitHub yGuy/chatgpt-mattermost-botを利用して、SlackもどきのMattermostでChatGPTもどきをやっているのだけど、オープンソースなので、色々手を入れている。

今回は、「トークン数が分かったほうが良いよな」と、返信の最後にトークン数を入れるようにした。

そしたら、最後の一行に足したつもりが、なんか二行出るようになった。

なんか、間違えたかな? と思って調べてみると、これチャットなので、過去の会話をassistantとしてプロンプトに入れているのだけど、それを見てChatGPTが真似して最後の行に自分でトークン数を入れて回答するようになっていた🎇

なんて素直な。いや、これは意図を理解して、入れてほしくなかったんたけど・・・

システムメッセージは別のPostについて、assistantに入れないように改良してあげないとな!

OpenAI APIの活用方法を考えて進めていると、色々な気づきがあります。

■ コミットメッセージ自動生成

- auto-commit ChatGPT以前のOpenAI API公開で作られているので、わりと早かった。去年から使っているけど、PullRequestは投げてない。

- di-sukharev/opencommit TypeScriptなのとカラフルなUI、絵文字を使ったメッセージを作ってくれるし。大きな変更はコミット単位、ファイル単位、行単位に分割して生成してくれる。

- shanginn/git-aicommit プログラムが小さい

■ コードレビュー

- /nfacha/OpenAI-Gitlab-PR-Review どんな修正をしたか、無駄なコードはないか? バグやセキュリティリスクが無いかレビューしてくれる。バグとかセキュリテイの問題を発見してくれたことはないし、無駄なコードの修正方法はバグっていた。

■ Chat連携

- yGuy/chatgpt-mattermost-bot Mattermostのスレッドを追っかけてChatGPTが返事をしてくれる。

■ 日記tDiary

- tdiary/tdiary-contrib plugin/chatgpt_elaborate.rb 日記を推敲してくれる。自分で作った。

■ 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.

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

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

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

■ 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推敲済み