Servers の履歴(No.8)

• 履歴一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• Servers へ行く。
  • 1 (2022-12-28 (水) 05:45:03)
  • 2 (2022-12-28 (水) 05:55:42)
  • 3 (2022-12-30 (金) 04:15:45)
  • 4 (2022-12-30 (金) 09:33:08)
  • 5 (2022-12-30 (金) 12:02:00)
  • 6 (2022-12-31 (土) 06:19:34)
  • 7 (2022-12-31 (土) 06:32:29)
  • 8 (2023-01-02 (月) 03:20:51)

---

Management

GitLab†

Configuration†

• https://blog.xiaket.org/2017/exposing.ssh.port.in.dockerized.gitlab-ce.html

Backup†

/root/backup_procedure.bash

• https://docs.gitlab.com/ee/install/docker.html#back-up-gitlab

Backing up the GitLab secrets file is required to avoid complicated steps when recovering GitLab from backup. The secrets file is stored at /etc/gitlab/gitlab-secrets.json inside the container, or $GITLAB_HOME/config/gitlab-secrets.json on the container host.

Upgrade†

• https://docs.gitlab.com/ee/update/#upgrade-paths

Upgrade 2022-12-31†

Upgrade from 10.7.3 to 15.7.0.

Instant restoration: Run docker-compose up at /home/git/gitlab-2022-12-30

Migrate legacy storage into hashed storage†

• https://docs.gitlab.com/ee/administration/raketasks/storage.html#on-legacy-storage

Two projects (yshimmyo/graduation_thesis and yshimmyo/IMUReceiver) occured errors that the repositories are read-only. I used ruby console of gitlab runtime and manually release read-only attributes following the below article.

Projects::HashedStorage::RepositoryInUseError: Target repository 'yshimmyo/IMUReceiver' cannot be made read-only: Repository already read-only

• https://gitlab.com/gitlab-org/gitlab/-/issues/289816

Listen Port†

From a certain (undetermined) version, gitlab parses `external_url` and if the url does not begin from `http://`, the webserver does not listen on :80. I added a nginx configuration environment variable on docker-compose.yaml:

nginx['listen_port'] = 80

Known Problem†

Timestamps of repositories are updated into a same datetime during migration. Accordingly, the order of the project list sorted by Updated date is awkward. One of the solutions against this problem is to use file timestamps in repositories kept as before upgrade and manually manipulate the DB. This is a little bit dangerous so I don't want to do unless it is absolutely necessary. Contact administrator if you think it is a serious problem.

TODO†

Zero downtime update†

• https://gitlab.com/gitlab-org/gitlab/-/issues/27091

Succession of update manner†

We encourage everyone to run the latest stable release ...

If you are unable to follow our monthly release cycle, there are a couple of cases you must consider.

https://docs.gitlab.com/ee/policy/maintenance.html#upgrade-recommendations

Mattermost†

Configuration†

Initiate†

docker-compose -f docker-compose.yml -f docker-compose.without-nginx.yml up -d

Upgrade 2022-12-31†

Instant restoration: Run docker-compose at /home/mie/mattermost-2022-12-30

migration of database†

• https://docs.mattermost.com/install/install-docker.html#upgrade-from-mattermost-docker
• https://github.com/mattermost/mattermost-docker/issues/489
• https://github.com/mattermost/mattermost-docker/issues/445

migration of non-db data†

You can copy `app` volumes directly with a few structure changes.

• https://github.com/mattermost/docker/issues/42

Upgrade chain of mattermost server†

Current version (2022-12-30) of mattermost is 5.26.0. Upgrading from the version requires a chain upgrade.

https://forum.mattermost.com/t/failed-to-get-channel-members-after-upgrade/13101/5

See Also†

See also https://adaptive.u-aizu.ac.jp/gitlab/yshimmyo/configuration-of-adaptive-u-aizu-ac-jp

Contact†

Yohei Shimmyo <d8221101@u-aizu.ac.jp> <qwpmb554@gmail.com>