サービス運用 on えやみぐさ

aoirint.com 個人用メールサーバ

Fri, 09 Dec 2022 06:35:00 +0900

2022-12-09より、aoirint.comにて、個人用メールサーバの運用を始めました。

aoirint.comアドレス宛てにメールが送信できない、受信できない、不正中継されている、セキュリティ上の問題などがあれば、Twitter、Mastodon、Keybaseなどにご連絡ください。

更新履歴

2022-12-09 運用開始

構成

DNS

DNSでは、MXレコード、SPFレコードを設定しています。

外部からのメールを内部に転送するSMTPサーバ mx01.aoirint.com

SMTP


暗号化	STARTTLS（必須）
認証	なし
ホスト名（TLS証明書のコモンネーム）	mx01.aoirint.com
ポート番号	25
外部へのメール送信	禁止

SMTPS


暗号化	暗黙的TLS
認証	なし
ホスト名（TLS証明書のコモンネーム）	mx01.aoirint.com
ポート番号	465
外部へのメール送信	禁止

外部にメールを送信するSMTPサーバ smtp.aoirint.com

Submission


暗号化	STARTTLS（必須）
認証	平文パスワード
ホスト名（TLS証明書のコモンネーム）	smtp.aoirint.com
ポート番号	587
外部へのメール送信	許可（認証必須）

IMAPサーバ imap.aoirint.com

IMAPS


暗号化	暗黙的TLS
認証	平文パスワード
ホスト名（TLS証明書のコモンネーム）	imap.aoirint.com
ポート番号	993

POP3サーバ pop.aoirint.com

POP3S


暗号化	暗黙的TLS
認証	平文パスワード
ホスト名（TLS証明書のコモンネーム）	pop.aoirint.com
ポート番号	995

2022-12-04から2022-12-06にかけてmstdn.aoirint.comで発生していた障害について

Tue, 06 Dec 2022 15:30:00 +0900

2023-02-10: タイトル・文言の修正

2022-12-04 03:40頃から、mstdn.aoirint.comで障害が発生していました。

2022-12-04 03:40頃障害発生（WAN側IPアドレスの変更）
2022-12-06 15:00頃障害を認識、原因を特定、DNSレコードを変更
2022-12-06 15:10頃 TTL経過により解消の見込み

サービスの死活監視

サービスの死活監視は、内部ネットワークのSmokePing、および外部ネットワークのBetter Uptimeを使用しています。

以下の画像は、2022-12-04 00:00から06:00における、SmokePingによるNATループバックPingの監視記録です。これ以降、SmokePingの宛先IPアドレス変更が行われるまで、不通の状態が続きました。

現在のサーバ環境では、原因を特定できていない短時間の接続不良が毎日のように発生しており、今回の障害ではBetter Uptimeの停止通知が一時的なものでないことに気づかないまま、48時間以上経過することになりました。

今後の対応について、DDNSサービスやCloudflare等を活用したサーバ環境の安定化対策を検討しています。

Mastodon on Docker Composeで全文検索エンジンElasticsearchを有効化する

Wed, 23 Nov 2022 14:40:00 +0900

Mastodon on Docker Composeを立てる記事: https://blog.aoirint.com/entry/2020/mastodon_docker/

上の記事では、諸般の事情（主にスペック不足）によりElasticsearchを無効化した状態でMastodonインスタンスを立てていた。

2021年のElasticsearchのライセンス変更

クラウド事業者によるマネージドサービス提供における、オープンソースコミュニティへのコントリビューションの不足等を背景として、 2021年のバージョン7.11リリース以降、ElasticsearchのライセンスはApache 2.0から独自のElastic License 2.0（およびServer Side Public Licenseのデュアルライセンス）に変更された。

https://www.elastic.co/jp/pricing/faq/licensing

この記事では、Elastic License 2.0によってライセンスされる公式のElasticsearchの配布パッケージを使用する。

Elastic License 2.0の条文: https://www.elastic.co/licensing/elastic-license

ちなみにElastic License 2.0は、Elasticsearchをマネージドサービスとして提供することを禁止しているが、SaaSアプリケーションのバックエンドとして使用すること（Elasticsearch APIへの直接アクセスを提供しないサービス提供）に影響しないという立場が示されている。

Elasticsearchをバックエンドで使用するSaaSアプリを開発しているけど、どんな影響が生じる？

今回のソースコードのライセンス変更はお客様に一切影響しません。Elastic Licenseに基づいて、デフォルトの配布パッケージを使用できるほか、このパッケージをベースに無料でアプリケーションを開発することもできます。Elastic Licenseはsource-available license（ソース利用許諾）であり、コピーレフトの側面を持たず、デフォルトの機能を無料とします。具体的な例として、よろしければMagentoプロジェクトに関する質問への回答をご参照ください。

https://www.elastic.co/jp/pricing/faq/licensing#elasticsearch%E3%82%92%E3%83%90%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%83%89%E3%81%A7%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8Bsaas%E3%82%A2%E3%83%97%E3%83%AA%E3%82%92%E9%96%8B%E7%99%BA%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%81%91%E3%81%A9%E3%80%81%E3%81%A9%E3%82%93%E3%81%AA%E5%BD%B1%E9%9F%BF%E3%81%8C%E7%94%9F%E3%81%98%E3%82%8B%EF%BC%9F

I’m using Elasticsearch to put a search box on my cat-picture SaaS product.

This is permitted under ELv2. Meow!

I am a Managed Service Provider (MSP) running Elasticsearch and Kibana for my customers.

If your customers do not access Elasticsearch and Kibana, this is permitted under ELv2. If your customers do have access to substantial portions of the functionality of either Elasticsearch and Kibana as part of your service, this may not be permitted.

死活監視サービスBetter Uptimeを導入した

Wed, 23 Nov 2022 11:35:00 +0900

aoirint.com関連サービスにBetter Uptimeを導入し、死活監視情報の提供を開始しました。

登録時に電話番号が必要なのがネックだけれど、URLを入力して、オプションでカスタムドメインを使うためにDNSにCNAMEレコードを追加したくらいで、結構簡単に使い始められた。

プランは以下を参照。URL 10個まで無料で監視させられる（3分間隔）。

https://betterstack.com/better-uptime/pricing

カスタムドメインのステータスページ。

https://status.aoirint.com

えやみぐさの記事運用 2022-06-24

Fri, 24 Jun 2022 09:30:00 +0900

技術ノートチャンネルには「具体的な解決策が見つかったものを報告・共有する記事」を載せたかったかもしれない。

わかりませんでした。いかがでしたか？　を避けたい。

でも、具体的な解決策がわからないんだけど、これどうしたらいいのか悩んでる、ということを共有する記事もほしい。 Twitterに投げるには分量が多いとか。

未解決タグを付ける方法はありそう？でも20%くらい解決したんだけど…みたいな場合に中途半端な未解決タグが付きそう。

前の記事を参照して、解決策1個みつけたわ、みたいな記事があってもいいと思うんだけど、それが100%の解決策でなかったりする場合にベストアンサーではないよねみたいなことがある。質問IDでも振って紐づけるか？？？

この記事にリンクしている記事一覧とかあればそれでいいのか？（実装が面倒かも？）まあタイトル詐欺しなければどういう運用しても別にいいのでは…

記事が増えすぎて質が落ちる・埋もれるかもしれんという問題はあるかも？先にJoplinとかScrapboxとかである程度整理してからの方が雑記事になりにくそう。

そういうのを作業ログチャンネルに入れたかったんだけど、なんだかんだそのレベルの文章をアップロードするのは面倒くさい。

記事としてのまとまりが悪くなりがちな気がする（話題があちこち飛んだり、矛盾した考えがあったりする）。

JoplinとかScrapboxに書くのがちょうどいい？　うーん。

https://blog.aoirint.com/entry/2022/pip_compile_metadata_generation_failed/

上を書くにあたって、Joplinに下書きして、記事としてまとめたものを公開して、下書きをScrapboxに公開する、とバージョン違いのコピーが3個できた。

Joplin: コンセプトがはっきりしないMarkdownの下書き
ブログ: 一応方針を固めたもの、Markdown
Scrapbox: Joplinの下書きをScrapbox書式に修正したもの

これがこういうバージョン違いなんですよ、ということを説明するDBがほしくなる。

バージョンの同期とか面倒だし、あんまりいろんなところに分散させたくないな、とは思うんだけど、いきなりScrapboxに書くのは軽重問わずセンシティブな情報が事故で公開されるということが起きそうで怖い。

でも正直、バージョン管理とか面倒なことを考えているのは無駄な気もする。

記事を書くモチベーションを上げたいんだけど、それとは関係ないのではと思った。

今回については、はじめは自分用のメモのつもりで書いていたけど、Joplinだとどんどん新しいノートが増えて埋もれるし、あんまり検索にヒットしなくて公益性があるなと思ったから記事化した。

埋もれることについては、だいたいキーワードを総当たりの文字列検索でなんとかなるんだけど、ちょっとしたメモ書きは整理するのが難しいし、Joplin上には1700ノートくらい、Evernoteにはツイートとかも保存しているから42000ノートくらいあって、この中に埋もれさせるのは微妙な感じがする…

それよりも、SSGに10分かかるのが微妙。

あと、noindexした記事がGitHubの公開リポジトリを通じてGitHub Searchにひっかかったり、Googleにインデックスされる可能性があったり、いまの実装だとnoindexなのにサイトマップに送信されてしまったりが微妙。

雑記チャンネルは、検索性・一覧性を悪くするためにわざとタイトルを付けなかったり、複数の内容を1記事に収めたりしていたんだけど、古いやつをちょっと分割してみた。

粗探しをする人とかエゴサーチャーとか正義の晒し屋とか伝書鳩とかに見つかりにくくしたいんだけど、ある程度こなれてきたらいいのかなとちょっとだけ思った（麻痺）。

Nextcloud 23から24へアップデート

Sun, 29 May 2022 23:52:00 +0900

23系で最新23.0.5に更新

docker-compose pull # nextcloud:23
docker-compose exec -u www-data app php occ db:add-missing-indices
docker-compose exec -u www-data app php occ maintenance:repair
docker-compose exec db mysql_upgrade -p

drawioアプリの互換性
- https://github.com/pawelrojek/nextcloud-drawio/issues/177

docker-compose pull # nextcloud:24
docker-compose exec -u www-data app php occ db:add-missing-indices
docker-compose exec -u www-data app php occ maintenance:repair
docker-compose exec db mysql_upgrade -p

自宅サーバのWebサービスをVPSで中継するようにした

Thu, 07 Apr 2022 11:00:00 +0900

これまで自宅サーバへの外部からの接続には、数年前から自宅のグローバルIPアドレスにフリーのドメインを紐づけて使っていたのですが、 3月末に更新を忘れてこのドメインを失効させてしまいました。

自宅サーバでは、主に個人用のWebサービスや身内用のゲームサーバが動いています。

同じドメインを再取得するには追加の料金がかかりますし、（若干用途が規約的に怪しいこともあり）新しくドメインを取り直す気にもなれなかったので、以前から契約していたVPSをTCP/UDPプロキシとして使ってみることにしました。

この記事では、nginx.confのhttpディレクティブとstreamディレクティブそれぞれについて、拡張子でincludeを切り分けるようにする構成にしています。基本的には、nginx.confに以下のように記述するイメージです。

http {
        include /etc/nginx/conf.d/*.http;
}

stream {
        include /etc/nginx/conf.d/*.stream;
}

関連ツイート
- https://twitter.com/aoirint/status/1510309731642257408
- https://twitter.com/aoirint/status/1511896279731040261

また、この記事の内容には関係ありませんが、envsubstでconfigファイルに環境変数を注入する、nginxのDocker Hub公式Dockerイメージのtemplate機能を使用しているため、 nginx設定ファイルの拡張子がtemplateになっています。

上のツイートに関連して、certbot --nginxで自動生成される/etc/letsencrypt/options-ssl-nginx.confを手動でnginx.confに統合しているので、以下の設定ではコメントアウトされているincludeがあります。

構成

自宅サーバ側：systemd + autosshによる自動SSH接続＆リモートポート転送
VPS側：nginxによるHTTPリバースプロキシ・UDPプロキシ

自宅サーバ側

~/.ssh/config

Host vps*
    HostName VPS_IPADDR
    Port VPS_SSH_PORT
    ServerAliveInterval 10
    ServerAliveCountMax 5
    TCPKeepAlive yes
    IdentitiesOnly yes
    IdentityFile ~/.ssh/vps

Host vps-forwarding-homeserver
    # SERVICE1
    RemoteForward 127.0.0.1:VPS_SERVICE1_PORT 127.0.0.1:LOCAL_SERVICE1_PORT

    # SERVICE2
    RemoteForward 127.0.0.1:VPS_SERVICE2_PORT 127.0.0.1:LOCAL_SERVICE2_PORT

/etc/systemd/system/autossh-vps.service

[Unit]
Description=AutoSSH VPS

[Service]
Type=simple
Restart=always
User=user
Group=user
WorkingDirectory=/home/user
ExecStart=/usr/bin/autossh -N vps-forwarding-homeserver

[Install]
WantedBy=multi-user.target

VPS側

HTTPリバースプロキシ（SSHポート転送使用）: myservice.http.template

server {
    server_name myservice.example.com;

    client_max_body_size 500M;

    add_header Strict-Transport-Security 'max-age=15552000; includeSubDomains; preload';

    location / {
        #auth_basic "Auth required";
        #auth_basic_user_file /secrets/myservice.htpasswd;

        proxy_pass http://127.0.0.1:VPS_MYSERVICE_PORT;
        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        send_timeout 3600s;
        proxy_connect_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_read_timeout 3600s;
        #proxy_max_temp_file_size 2048m;
    }

    location /.well-known/acme-challenge/ {
        root /letsencrypt-webroot;
    }

    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/myservice.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myservice.example.com/privkey.pem;
    # include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

server {
    if ($host = myservice.example.com) {
        return 301 https://$host$request_uri;
    }

    server_name myservice.example.com;
    listen 80;
    return 404;
}

UDPポート転送（SSHポート転送不使用）: myserviceudp.stream.template

server {
        listen VPS_SERVICEUDP_PORT udp reuseport;

        proxy_pass HOME_IPADDR:HOME_SERVICEUDP_PORT;
        proxy_connect_timeout 3600s;
        proxy_timeout 3600s;
        #proxy_max_temp_file_size 2048m;
}

はてなブログから古い記事を移した

Tue, 22 Feb 2022 20:40:00 +0900

新しい記事 blog.aoirint.com へ投稿しつつ、古い記事は aoirint.hatenablog.com に残っていましたが、古い記事を blog.aoirint.com に移しました。

古い記事にはリダイレクトと移動先へのリンクを設置しています。

https://github.com/x-motemen/blogsync

blogsyncで記事を取得したあと、以下のようなスクリプトでfrontmatterを変換しました。

以前の移行時の作業ミスでMarkdown記事がHTMLになってしまっていたので、手動でMarkdownに書き戻しました。

import glob
import yaml
from datetime import datetime
from pathlib import Path
import frontmatter as FM

for path in glob.glob('**/*.md', recursive=True):
  if path.startswith('output'):
    continue

  print(path)
  with open(path, 'r') as fp:
    frontmatter = FM.load(fp)
    # docs = yaml.safe_load_all(fp)
    # frontmatter = next(docs)
    # body = next(docs)

  body = frontmatter.content
  print(frontmatter)
  print(body)

  title = frontmatter['Title']
  if title.startswith('（移動済）'):
    print(f'Skipped: {title}')
    continue

  print(f'Processing: {title}')

  original_url = frontmatter['URL']
  date: datetime = frontmatter['Date']
  draft = frontmatter.get('Draft', False)

  tags = frontmatter.get('Category')
  category = tags[0] if tags else None

  new_frontmatter = {
    'title': title,
    'date': date.strftime('%Y-%m-%d %H:%M:%S'),
    'draft': draft,
    'channel': '技術ノート',
  }
  if category:
    new_frontmatter['category'] = category
  if tags:
    new_frontmatter['tags'] = tags

  output = yaml.dump(new_frontmatter, default_flow_style=False, sort_keys=False, allow_unicode=True)
  output_lines = output.split('\n')
  output_lines.insert(0, f'---')
  output_lines.insert(1, f'# moved from {original_url}')
  output_lines.insert(-1, f'---')
  output = '\n'.join(output_lines)
  output += f'# {title}\n\n' + body + '\n'

  dest = Path('output', path)
  dest.parent.mkdir(parents=True, exist_ok=True)

  with open(dest, 'w') as fp:
    fp.write(output)

えやみぐさの改修ログ 2022-02-20

Sun, 20 Feb 2022 08:10:00 +0900

えやみぐさ: blog.aoirint.com

えやみぐさのGatsby設定ファイルのTypeScript化

レイアウト用の型定義をgatsby-nodeやgatsby-configで利用するために、これらのGatsby設定ファイルをTypeScript化することになりました。以下の記事が参考になりました。

https://miyauchi.dev/ja/posts/gatsby-typescript/

えやみぐさに「チャンネル」機能を追加

トピックの異なる記事を分離するために、「チャンネル」という単位で記事を分類するようにしました。

これまで、えやみぐさの記事は、カテゴリとタグによって分類していました。しかし、この2つだけでは、例えば日記と技術記事の記事一覧を分離することができません（RSSや最近の記事一覧で問題になる）。えやみぐさに異なるトピック・ジャンルの記事を統合するために、既存のカテゴリとタグによる分類を維持し、新しい階層を加えることにしました。これまでのカテゴリ・タグは、チャンネル別に機能するようにしました。

いまのところ、この記事は作業ログというチャンネルに属しています。通常の技術ノートに比べて、気軽にページを作ることができるようにと考えています。あとで内容の一部を技術ノートに移す・写すこともあるかもしれません。現在の技術ノートはあまり品質がよくない（メモ書きレベル）ので、作業ログに移してもいいかなと思っているのですが、そこそこ記事数があり、中身を確認しながら再分類するのが手間なのでやっていません。作業ログは、作業を中断したり、力尽きたりしたりして、中途半端な内容や矛盾した文章が載っていることがあるかもしれませんが、自分用のメモなので気にしないでいきたいと思っています。

えやみぐさの記事管理方法とURLフォーマットについて

えやみぐさでは、記事のURLをentry/<作成年>/<slug>というフォーマットにしています。このフォーマットは、えやみぐさの記事をファイルシステム上で管理しやすくするために選んだものです。

えやみぐさの記事を作成するときは、URLと対応したパスにディレクトリを作成し、index.mdファイルを配置します。これは、記事に付随するリソース（画像や音声ファイルなど）と記事本体をまとめて管理するためにそうしています。

比較として、entry/<slug>方式では、ふつうに構成すると1ディレクトリにすべての記事ディレクトリを配置することになります。例えば、2020年には下書きを含めて31件の記事があるのですが、次の年も同じ数の記事を書いたとすると、計62件、その次の年なら計93件になることが予想されます。昔書いた記事に補足を入れたいときや、新しい記事を書きたいときに、100件のサブディレクトリがあるディレクトリを操作するのは、誤操作が起きやすい点、目に入る情報量が多く気が散る点から、望ましくない・苦手です。

entry/<作成年>/<作成月>/<slug>やentry/<作成年>/<作成月>/<作成日>/<slug>も考えられますが、自分の記事作成ペースと、手作業で管理するのが手間に感じる点から採用しませんでした。

えやみぐさのURL永続性について

インターネット上のURLは、永続化することが望ましいという考え方があります。例えば、ブックマークしておいたページが消えていると困りますし、リンクが貼られているとリンク切れを起こしてしまいます。

記事のURLの永続化には、URLの割り当て方法が関わってきます。ブログシステムでのURLの割り当て方法としては、記事タイトルの一部などによる「スラグ」を利用する方法、 DB上の連番IDを利用する方法、時刻や日付を利用する方法、ランダムなIDを利用する方法、が思い付きます。えやみぐさでは、記事のURLをentry/<作成年>/<slug>というフォーマットにしています。

CMS・Wikiなどでは、URLを永続化するためにリダイレクトが自動で貼られる仕組みが用意されている場合がありますが、えやみぐさのコンテンツ管理方式（GitリポジトリにMarkdownファイル）では、リダイレクトによってURLを永続化するのは難しく、実装しても運用するのはそれなりの手間になります（例えば、リダイレクトだけの実体のない記事ページが記事ファイル一覧に含まれる、増え続けるリダイレクトリストの管理など）。

できるだけ記事URLを書き換えないようにしてはいますが、リンクが貼られにくい雑記については、 URL永続性を維持する動機がないので、適当に管理すると思います。

記事のURL名前空間は、チャンネル間で共通にしています（entry/slugのこと）。えやみぐさでは、チャンネル・カテゴリ・タグのようなタクソノミーは、あとで書き換えることがある、という運用を考えています。

えやみぐさの記事一覧について

これまで、えやみぐさのトップページでは、カテゴリの一覧と、各カテゴリの全記事リストを表示する方式をとっていました。これは、過去に書いた技術記事を素早く参照するためのものでした。この記事の執筆時点でも、技術記事用のチャンネル「技術ノート」では、同様の方式で記事一覧を表示するようにしています。

えやみぐさのデプロイ自動化について

えやみぐさを管理するGitリポジトリは、Gatsbyプロジェクトリポジトリと記事リポジトリの2つに分かれています（submoduleで管理しています）。記事の可搬性とレイアウト・記事の分離のためにそうしていますが、固有記法を使うこともあるかもしれませんし、まああまり細かいところは気にしないで運用しています。

えやみぐさのデプロイは、GatsbyプロジェクトリポジトリにpushされたときにはGitHub Actionsが走りますが、記事リポジトリにpushされたときには走りません。

記事を更新したときには、親のGatsbyプロジェクトリポジトリのsubmoduleを更新する手間があります。

Webサイトのレイアウトを調整すること、記事を更新すること、をうまく共存させながら、この手間を解消したいのですが、あんまりいい方法が思い付いていません。。。

例えば、記事を書くときにいちいちGatsbyでレンダリングするのは重くて手間なので、Gatsbyプロジェクトをcloneせずに記事を追加するような運用をしたいと思っていますが、レイアウトをいじるときには実際の記事があった方がいい、というような感じで、どうしたらいいのかなと思っています。

workflow_dispatchをうまく組めば、片方のリポジトリが更新されたときにデプロイ走らせることはできると思うけれど、ローカルで動かすときに微妙な気がしている…

えやみぐさのデプロイにおける「2重コミット問題」を解消した

「2重コミット問題」：テーマリポジトリと記事リポジトリを分離するため、submoduleを使って管理するとき、submoduleと親リポジトリの2つにそれぞれコミットするのが手間になる問題

API経由でWorkflowを実行する。スコープの広いPATが必要なのが難しいところなので、抵抗あったのだけれど、まあ便利なので仕方がない。

MediaWikiのセットアップ

Thu, 03 Feb 2022 07:00:00 +0900

インストール

Docker Hub公式のDockerイメージが公開されている。

Mediawiki - Official Image | Docker Hub

事前準備

docker-compose.yml

version: '3.8'
services:
  mediawiki:
    image: mediawiki:1.37
    restart: always
    ports:
      - '127.0.0.1:8000:80'
    links:
      - database
    volumes:
      - ./app/images:/var/www/html/images
      # After initial setup, download LocalSettings.php to the same directory as
      # this yaml and uncomment the following line and use compose to restart
      # the mediawiki service
      # - ./LocalSettings.php:/var/www/html/LocalSettings.php
      # - ./app/extensions:/var/www/html/extensions
  # This key also defines the name of the database host used during setup instead of the default "localhost"
  database:
    image: mariadb:10.7
    restart: always
    volumes:
      - database-data:/var/lib/mysql
    environment:
      # @see https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/DefaultSettings.php
      MYSQL_DATABASE: my_wiki
      MYSQL_USER: wikiuser
      MYSQL_PASSWORD: example
      MYSQL_RANDOM_ROOT_PASSWORD: 'yes'
volumes:
  database-data:

nginx設定ファイル (/etc/nginx/sites-enabled/wiki.example.com.conf）

server {
    server_name wiki.example.com;

    proxy_set_header HOST $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # auth_basic "Authentication Required";
    # auth_basic_user_file /path/to/.htpasswd;

    location / {
        proxy_pass http://localhost:8000;
    }
}

手順

docker-compose.yml、nginx設定ファイルを作成
- 必要に応じてsudo certbot --nginxでHTTPS対応
添付ファイルのアップロード先ディレクトリを作成 mkdir -p app/images
docker-compose up -dでMediaWikiを起動
- 起動時にwikiexamplecom_mediawiki_1 is up-to-dateのようなログが表示されるので、isより前のMediaWikiコンテナ名を控える
ブラウザから初期設定
設定ファイルLocalSettings.phpをコピー
- sudo docker cp MediaWikiコンテナ名:/var/www/html/LocalSettings.php ./LocalSettings.php
拡張機能をコピー
- sudo docker cp MediaWikiコンテナ名:/var/www/html/extensions ./app/extensions
docker-compose.ymlを開き、./LocalSettings.php、./app/extensionsのコメントアウトを解除
コンテナを再作成
- sudo docker-compose up -d --force-recreate

拡張機能のインストール

インストール手順

拡張機能の配布ファイル（tar.gz）をサーバにダウンロード
配布ファイルを展開
展開した拡張機能ディレクトリをapp/extensions以下にコピー（app/extensions/Mathのように）
- Dockerコンテナ内では/var/www/html/extensions/Mathのように配置される
LocalSettings.phpにwfLoadExtension( '拡張機能ディレクトリ名' );のように追記
- wfLoadExtension( 'Math' );
- wfLoadExtension( 'SyntaxHighlight_GeSHi' );
「メンテナンス：再起動」を実行
「メンテナンス：データベース構造の更新」を実行

数式（Math）

シンタックスハイライト（SyntaxHighlight）

設定

ロゴを変更

ロゴ変更 LocalSettings.php

## The URL paths to the logo.  Make sure you change this from the default,
## or else you'll overwrite your logo when you upgrade!
#$wgLogos = [ '1x' => "$wgResourceBasePath/resources/assets/wiki.png" ];
$wgLogos = [ '1x' => "$wgResourceBasePath/images/logo.png" ];

ロゴ変更手順

LocalSettings.phpを編集
ロゴ画像をapp/images/logo.pngに配置
「メンテナンス：再起動」を実行

既定のタイムゾーンを変更

Manual:Timezone - MediaWiki

タイムゾーン変更 LocalSettings.php

# Time zone
#$wgLocaltimezone = "UTC";
$wgLocaltimezone = "Asia/Tokyo";

タイムゾーン変更手順

LocalSettings.phpを編集
「メンテナンス：再起動」を実行

メンテナンス

再起動

sudo docker-compose up -d --force-recreate

データベース構造の更新

Manual:update.php - MediaWiki

sudo docker-compose exec -u 1000 mediawiki php maintenance/update.php

Hexo

Wed, 17 Nov 2021 04:00:00 +0900

https://hexo.io/docs/#Installation

npm install -g hexo-cli

$ hexo help
Usage: hexo <command>

Commands:
  help     Get help on a command.
  init     Create a new Hexo folder.
  version  Display version information.

Global Options:
  --config  Specify config file instead of using _config.yml
  --cwd     Specify the CWD
  --debug   Display all verbose messages in the terminal
  --draft   Display draft posts
  --safe    Disable all plugins and scripts
  --silent  Hide output on console

For more help, you can use 'hexo help [command]' for the detailed information
or you can check the docs: http://hexo.io/docs/

hexo init <folder>は空のディレクトリに対して実行する必要がある。いったん仮のディレクトリを作ってからコピーする。.github、.gitignoreファイルがあるのでコピー忘れに注意。

Hexoで日記用のブログを用意した

Wed, 17 Nov 2021 04:00:00 +0900

Twitterは開かれすぎていて恥ずかしいし、下手な投稿をすると、エゴサする人とか、有識者とかを変に刺激して、攻撃的な反応をされることがある場所になっている。それはとても疲れるので、そういう攻撃にさらされにくく、個人的な文章を公開できる場所がほしかった。自分の考えを整理する機会がないので、半分自虐のお気持ち表明みたいなこともやるかもしれない。そういう意味で、自分への免罪符と、覗きに来る人への立て札として、サイト名をVent・排気口としている（あもあすの影響）。

こういった自分の思っていることを書く文章というのは、大抵の場合、恥ずかしくなったり、書くことがなかったりで、1つ2つ書いた時点で消したり、使わなくなってしまったりする。過去の記事タイトルや概要が一覧表示されると、恥ずかしくて消したくなってしまう。

そのあたりを考えると、細かいことを気にせずに書ける方法がいい。はてなブログは、UIは使いやすくて好きなのけれど、PRO版でないと、はてなキーワード機能で有識者を引き寄せてしまうのが怖い。SNS化されていない場所がいい。それならWordPressか、と思って一度VPSに立ててみたけれど、Markdownで書けない（プラグインのことは考えたくない）のがつらい。Markdownといっても、ソフトブレークなちゃんぽんだけど。 DokuWikiとかMediaWikiが向いているとは思わない。Sphinxもカテゴリ/タグ機能がない感じが微妙。 DBが必要というのはイケていない。ならGit管理だ、GitHubだ、SSGだ、となる。それで、なんかモダンなTypeScriptで書かれたHexoを試しに使ってみた、ということになる。ふだんはPythonで書かれたMiyadaikuを使っているのだけれど、ユーザが少ないので、あまりいいテーマがない。となると自作することになるのだけれど、2,3記事で爆破するかもしれないものにそこまでの労力をかけたくない。といっても、いまこのブログもデフォルトテーマのLandscapeを使っていて、その理由はあまりいいテーマがなかったからなのだけれども。Lightはよかったけどコメント欄が消せねえ。 Git管理結構、GitHub結構、SSG結構なのだけれども、_postsディレクトリに過去の記事が全部出てくるのがイケてない。slugという仕組みとマッチしていない（なんでURLに2回日付が出てくるんですかね）。記事を作るときに記事の名前が必要なのもイケてない。画像を追加したら、音声を追加したら、どんどんリポジトリが重くなる。まあフルクローンする機会もそうそうないか。世の中のサービスはすぐにサ終するので、外部にアップロードはしたくない。ほかにもURLの永続性とか、いろいろ考え始めるとキリがないので、そのあたりの運用は適当になることをご承知おきいただきたい。あまり納得のいっていないHexoから乗り換えるときにURLをリダイレクトさせるとか面倒くさいので。あとなんか記事ジェネレータがバグっていて、生成されたmdファイルがそのままだとビルドできない（なぜか{}がfront-matterに入り込んでいて、タイトルもUTC時刻になっている）

うーん、万が一この記事が攻撃の対象になったときに、言及している対象に迷惑がかからないように、とか余計なことを考えてしまう。それだったら記事を分割して、余計な言及をあいまいにして…としたりしなかったり（戻したり）しながら書いている。とても無駄だし、とてもストレスになる。はてなキーワードはこの意味でよくない。記事を分割すると書くまでもない、みたいなことが拾えずに気になってしまう。

リンクを張るならnoreferrerしないと、解析に残ってしまうな…。

https://github.com/hexojs/hexo-filter-nofollow

これでよさそう。

悪意があるのかないのかわからないけど、攻撃的な反応と受け取ったことで、精神ダメージを受けている人を同時に2人観測するのはあんまりよくない（ふにちかさんとヒホさん）。そしてこういうのがエゴサにひっかかってしまうので、noindexせざるを得ない。

WordPress

Sat, 13 Nov 2021 13:00:00 +0900

https://hub.docker.com/_/wordpress

docker-compose.yml

version: "3.9"

services:
  wordpress:
    image: wordpress:5.8.2-apache
    restart: always
    ports:
      - "${SERVER_PORT}:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wordpress:/var/www/html

  db:
    image: mariadb:10.7
    restart: always
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
      MYSQL_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - db:/var/lib/mysql

volumes:
  wordpress:
  db:

.env

SERVER_PORT=127.0.0.1:8000

ArchiveBox

Sat, 06 Nov 2021 23:00:00 +0900

curl -O 'https://raw.githubusercontent.com/ArchiveBox/ArchiveBox/master/docker-compose.yml'

docker-compose.yml

# Usage:
#     docker-compose run archivebox init --setup
#     docker-compose up
#     echo "https://example.com" | docker-compose run archivebox archivebox add
#     docker-compose run archivebox add --depth=1 https://example.com/some/feed.rss
#     docker-compose run archivebox config --set PUBLIC_INDEX=True
#     docker-compose run archivebox help
# Documentation:
#     https://github.com/ArchiveBox/ArchiveBox/wiki/Docker#docker-compose

version: "3.9"

services:
    archivebox:
        image: archivebox/archivebox:sha-f809e3b
        command: server --quick-init 0.0.0.0:8000
        ports:
          - "${SERVER_PORT:-8000}:8000"
        environment:
            ALLOWED_HOSTS: "*"
            MEDIA_MAX_SIZE: 2g
            # SEARCH_BACKEND_ENGINE: sonic     # uncomment these if you enable sonic below
            # SEARCH_BACKEND_HOST_NAME: sonic
            # SEARCH_BACKEND_PASSWORD: SecretPassword
        volumes:
            - "${DATA_ROOT:-./data}:/data"

    # To run the Sonic full-text search backend, first download the config file to sonic.cfg
    # curl -O https://raw.githubusercontent.com/ArchiveBox/ArchiveBox/master/etc/sonic.cfg
    # after starting, backfill any existing Snapshots into the index: docker-compose run archivebox update --index-only
    # sonic:
    #    image: valeriansaliou/sonic:v1.3.0
    #    environment:
    #        SEARCH_BACKEND_PASSWORD: SecretPassword
    #    volumes:
    #        - ./sonic.cfg:/etc/sonic.cfg:ro
    #        - ./data/sonic:/var/lib/sonic/store


    ### Optional Addons: tweak these examples as needed for your specific use case

    # Example: Run scheduled imports in a docker instead of using cron on the
    # host machine, add tasks and see more info with archivebox schedule --help
    # scheduler:
    #    image: archivebox/archivebox:latest
    #    command: schedule --foreground --every=day --depth=1 'https://getpocket.com/users/USERNAME/feed/all'
    #    environment:
    #        USE_COLOR: True
    #        SHOW_PROGRESS: False
    #    volumes:
    #        - ./data:/data

.env

SERVER_PORT=127.0.0.1:8000
DATA_ROOT=./data

初期設定

管理ユーザの作成、プライベートサーバ化、再起動。

Overleaf Community Edition

Fri, 05 Nov 2021 05:00:00 +0900

https://overleaf.com/

オンラインLaTeXエディタのShareLaTeXとOverleafは、Overleaf v2として2017年に統合され、OverleafはShareLaTeXのエディタを使うようになった。

Overleaf（ShareLaTeX）は、overleaf.comで提供されているクラウド版と、セルフホスト可能なオープンソース版（Community Edition）が公開されている。

https://github.com/overleaf/overleaf

この記事では、Overleaf Community Editionの公式Dockerイメージ（イメージ名はsharelatex/sharelatex）を使って、セルフホストする。

https://hub.docker.com/r/sharelatex/sharelatex/

クラウド版とCommunity Editionの機能の違いは、以下を参照。

https://www.overleaf.com/for/enterprises/features

使用できない機能

Git管理

Git管理やGitHub連携については、Community Editionには実装されていない（クラウド版のみ）。クラウド版のGit管理はクローズドソースなファイル履歴APIを利用して実装されており、これが技術的な課題になっているらしい。

Overleafに管理させないでよいのなら、ファイルは/var/lib/sharelatex/data/compiles/{project_id}-{user_id}に保存されるので、ここを監視して自動コミットするようなプログラムを使ってもいいかもしれない。

# 後者のIDがユーザIDであることの確認
docker-compose exec mongo mongo sharelatex --eval "db.users.find()"

テンプレート

クラウド版・Pro版限定機能。

docker-compose.yml

version: '3.9'
services:
  sharelatex:
    image: sharelatex/sharelatex:3
    restart: always
    depends_on:
      mongo:
        condition: service_healthy
      redis:
        condition: service_started
    ports:
      - "${SERVER_PORT}:80"
    volumes:
      - "${DATA_ROOT}:/var/lib/sharelatex"
      - "${TEXLIVE_ROOT}:/usr/local/texlive"
    environment:
      # https://github.com/overleaf/overleaf/wiki/Configuring-Overleaf
      SHARELATEX_APP_NAME: Overleaf Community Edition
      SHARELATEX_MONGO_URL: mongodb://mongo/sharelatex
      SHARELATEX_REDIS_HOST: redis
      REDIS_HOST: redis

      ENABLED_LINKED_FILE_TYPES: 'project_file,project_output_file'

      # Enables Thumbnail generation using ImageMagick
      ENABLE_CONVERSIONS: 'true'

      # Disables email confirmation requirement
      EMAIL_CONFIRMATION_DISABLED: 'true'

      # temporary fix for LuaLaTex compiles
      # see https://github.com/overleaf/overleaf/issues/695
      TEXMFVAR: /var/lib/sharelatex/tmp/texmf-var

      # SHARELATEX_SITE_URL: http://sharelatex.mydomain.com
      # SHARELATEX_NAV_TITLE: Our ShareLaTeX Instance
      # SHARELATEX_HEADER_IMAGE_URL: http://somewhere.com/mylogo.png
      # SHARELATEX_ADMIN_EMAIL: support@it.com

      # SHARELATEX_LEFT_FOOTER: '[{"text": "Powered by <a href=\"https://www.sharelatex.com\">ShareLaTeX</a> 2016"},{"text": "Another page I want to link to can be found <a href=\"here\">here</a>"} ]'
      # SHARELATEX_RIGHT_FOOTER: '[{"text": "Hello I am on the Right"} ]'

      # SHARELATEX_EMAIL_FROM_ADDRESS: "team@sharelatex.com"

      # SHARELATEX_EMAIL_AWS_SES_ACCESS_KEY_ID:
      # SHARELATEX_EMAIL_AWS_SES_SECRET_KEY:

      # SHARELATEX_EMAIL_SMTP_HOST: smtp.mydomain.com
      # SHARELATEX_EMAIL_SMTP_PORT: 587
      # SHARELATEX_EMAIL_SMTP_SECURE: false
      # SHARELATEX_EMAIL_SMTP_USER:
      # SHARELATEX_EMAIL_SMTP_PASS:
      # SHARELATEX_EMAIL_SMTP_TLS_REJECT_UNAUTH: true
      # SHARELATEX_EMAIL_SMTP_IGNORE_TLS: false
      # SHARELATEX_EMAIL_SMTP_NAME: '127.0.0.1'
      # SHARELATEX_EMAIL_SMTP_LOGGER: true
      # SHARELATEX_CUSTOM_EMAIL_FOOTER: "This system is run by department x"

  mongo:
    image: mongo:4.0
    restart: always
    volumes:
      - "${MONGO_ROOT}:/data/db"
    healthcheck:
      test: echo 'db.stats().ok' | mongo localhost:27017/test --quiet
      interval: 10s
      timeout: 10s
      retries: 5

  redis:
    image: redis:5
    restart: always
    volumes:
      - "${REDIS_ROOT}:/data"

.env

SERVER_PORT=127.0.0.1:8000
DATA_ROOT=./data/sharelatex
TEXLIVE_ROOT=./data/texlive
MONGO_ROOT=./data/mongo
REDIS_ROOT=./data/redis

設定

https://github.com/overleaf/overleaf/wiki/Quick-Start-Guide

TeXLiveのフルインストール

TeXLiveのフルバージョンは巨大なため、Dockerイメージには最小構成のみが含まれている。フルバージョンを使うには、インストールコマンドを実行する必要がある。

Wiki.jsのセットアップ

Tue, 01 Jun 2021 05:00:00 +0900

メモリ消費量

$ docker stats
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
e225b6b77209   wikijs_wiki_1   0.01%     127.6MiB / 7.681GiB   1.62%     13.1MB / 22.7MB   44.5MB / 1.45MB   11
13d085313406   wikijs_db_1     0.00%     44.57MiB / 7.681GiB   0.57%     6.64MB / 4.09MB   4.27MB / 102MB    8

初期状態で150-200MiB程度の消費量と思われる。

下記の環境をサーバとして、別端末からNATループバックによる接続を試したところ、ページ遷移時のロードや記事の保存に少しだけ時間がかかるように思われたが、Wikiサイト自体がなかなか開かない、というような重さではなかった。

CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
Memory: 8GB
Storage: SSD
OS: Ubuntu Desktop 18.04

docker-compose.yaml

version: "3.9"
services:
  db:
    image: postgres:13-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_PASSWORD: wikijsrocks
      POSTGRES_USER: wikijs
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data

  wiki:
    image: requarks/wiki:2
    depends_on:
      - db
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:3000"

volumes:
  db-data:

基本的に初期設定で問題ない。

Mastodonをdocker-composeで立てる（Ubuntu 18.04）

Sun, 06 Dec 2020 11:00:00 +0900

内容はコミットID44d5c6bc8ffd92cd201380dabe35748e50b6af68、Mastodon Dockerイメージバージョンv3.2.1（Digest：sha256:41cd5fb48d8b15ec806f08ab06fec98df33ec9b83a1f879e0fb30da9994018dc）におけるもの。docker-composeの設定ファイルバージョンは3。

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Codename: bionic

$ uname -r
5.4.0-56-generic

$ docker -v
Docker version 19.03.14, build 5eb3275d40

$ docker-compose -v
docker-compose version 1.27.1, build 509cfb99

$ docker images tootsuite/mastodon --digests
REPOSITORY           TAG                 DIGEST                                                                    IMAGE ID            CREATED             SIZE
tootsuite/mastodon   v3.2.1              sha256:41cd5fb48d8b15ec806f08ab06fec98df33ec9b83a1f879e0fb30da9994018dc   37ca50fc92bd        6 weeks ago         1.86GB

今回はDocker Hub上のイメージを使用し、ローカルビルドをしない想定でいく（ごちゃごちゃするので）。 Mastodonを改造したい場合など、必要に応じてgithub:tootsuite/mastodonをFork/Cloneし、自分で/CIでビルドして信頼できるDockerレジストリに登録すればいいと思う。

静的サイトジェネレータMiyadaiku + GitHub Actions + GitHub Pagesでブログを作る

Wed, 09 Sep 2020 09:48:39 +0900

概要

新しく静的サイトジェネレータでブログ環境を整備した。細かい使い方には触れないが、構成を書いておく。

静的サイトジェネレータとCI/CD

静的サイトジェネレータ

静的サイトジェネレータというのはSphinx（Python製）とかJekyll（Ruby製、GitHub Pages標準らしい）とかHugo（Go製）みたいなやつで、 MarkdownだとかreStructuredTextだとかのファイル群からHTMLを生成するツール。

Miyadaiku

MiyadaikuはPython製の静的サイトジェネレータ。 Flaskで使うテンプレートエンジンのJinja2が使えることが特徴みたい。Jinja2はDjangoのテンプレートエンジンに似ている。テンプレート上でどんな変数が使えるかはMiyadaikuの領域なので、ドキュメント（とサンプルテンプレート、ソースコード）を見ていくしかないかも。

GitHub Actions

GitHub上のリポジトリに対してpushやPull Requestがなされた時に事前に指定した処理を実行することのできるGitHubの機能。 Jenkinsなどに近そう。また、GitLabにも同様の機能があったはず。 GitHubのサーバで動く仮想環境上でDockerのような使い方でテストケースの実行やリリースファイルのビルド、サーバへのデプロイ、つまりCI（Continuos Integration、テストやビルドの自動化）/CD（Continuous Delivery、デプロイの自動化）を設定できる。 Pull Requestなどへの自動ラベル付けやSlackへの通知なんかも設定することがあるのかな。この設定はYAMLファイルとしてGitリポジトリ内に保存しますが、秘密鍵/トークンなどの情報を参照するための機能もあるみたい。バージョン管理システム的な点ではGitは分散型なので文書自体の分散バージョン管理はできるが、 GitHubが落ちたら解消するまで（手元にリポジトリがあっても）GitHub ActionsによるCI/CDができないのが難点な気がする。

GitHub Status

考えていること

レンダリング後のHTMLファイルの分離

Markdownを書いている時に見えるところに（レンダリング後の）HTMLファイルを置きたくない。できれば何も考えずに（Markdownで書いた）メモファイルを置くのに使っていた適当なディレクトリの上でコマンドを実行したら HTTPサーバを介して（オプションで指定したテーマなどで）いい感じにレンダリングしてくれるようなものがいい（HTMLファイル自体にファイルシステムからアクセスできる必要はない）と思っていた。

このHTMLはMarkdownファイル群とレンダリングのオプションだけでいつでも生成可能なので、レンダリング後のファイル自体が見えなければ、後からこのファイルを何かの間違いで編集してしまって正規性（再レンダリングしても差分がない状態）が崩れてしまうことがない。それからMarkdownファイルをGitで管理する場合、レンダリング後のファイルの差分には実質的に意味がないので、（見える）commitに含めたくない気持ちがある。

この部分は適切に.gitignoreやCI/CDを設定すれば大抵の静的サイトジェネレータで実現可能だろうと思う。今回はGitHub Actionsを使って、GitHub上の仮想環境にリポジトリから文書を読み込んでHTMLを自動生成し、文書と履歴を共有しない別ブランチ（gh-pages）に自動でcommitされるように設定する。

GitHub Actionsを動かすには.github/workflows以下にYAMLファイルを配置する。例えばこのような感じ。GitHub Pagesへのデプロイ（gh-pagesブランチの更新）にはgithub:peaceiris/actions-gh-pagesを使っている。

# deploy.yml
name: Deploy

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
  push:
    branches: [ master ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      - name: Setup Python
        uses: actions/setup-python@v2
        with:
          # Version range or exact version of a Python version to use, using SemVer's version range syntax.
          python-version: 3.x

      - name: Install dependencies
        run: pip3 install -r requirements.txt

      - name: Run miyadaiku-build
        run: miyadaiku-build --output public .

      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public

name、runのところをコピーして増やせばコマンドを増やすことができる。

Jekyll Blogging お試し

Mon, 01 Jun 2020 01:22:51 +0900

https://jekyllrb.com/

Ruby製の静的ウェブサイト生成ツール（Static Site Generator）。なんかMarkdownとかで書いたサイトをいい感じにHTMLにしてくれるやつ。

Dockerイメージの準備

Ruby, RubyGems, gcc, makeが入っていれば動くらしい。公式Dockerイメージもあるみたいだけど、あえてスルーしてrubyイメージからやってみる。

ふだんRubyは使わないので試行錯誤。

https://hub.docker.com/_/ruby

まずはイメージをビルド。

FROM ruby:2

WORKDIR /code

RUN gem install jekyll bundler

ここでgem installしてもいいのか、という問題がありそうだけどよくわからない..（キャッシュについてはいいとして）

sudo docker build . -t myjekyll

ひとまずこれでイメージの準備はできた。

sudo docker run --rm -v `pwd`/myblog:/code -e BUNDLE_PATH=vendor/bundle myjekyll jekyll new ./

これで./myblog（/code）に新しいJekyllプロジェクトが生成される（合わせて依存ライブラリがmyblog/vendor/bundleにインストールされる）。

vendorを除いたフォルダ構成はこんな感じ。

myblog/
├── 404.html
├── about.markdown
├── _config.yml
├── Gemfile
├── Gemfile.lock
├── index.markdown
└── _posts
    └── 2020-05-31-welcome-to-jekyll.markdown

もし既存のプロジェクトを使う場合、bundle installでライブラリを取得する（Gemfileに書かれた依存ライブラリがmyblog/vendor/bundleにインストールされる）。

sudo docker run --rm -v `pwd`/myblog:/code -e BUNDLE_PATH=vendor/bundle myjekyll bundle install

最後に開発用サーバを立てる。

Raspberry Pi 3B+（Raspbian）でNextcloud（Docker）を動かす（MySQL）

Wed, 27 Nov 2019 02:06:47 +0900

※ Dockerは入ってるものとします。あとスワップ領域を用意しておいたほうがいいかな

docker run --name ncdb --restart unless-stopped -v NEXTCLOUD_DIR/db:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=MY_ROOT_PASSWORD -e MYSQL_DATABASE=nextcloud -e MYSQL_USER=nextcloud -e MYSQL_PASSWORD=MY_PASSWORD hypriot/rpi-mysql --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

docker run --name ncapp --restart unless-stopped --link ncdb -p MY_PORT:80 -v NEXTCLOUD_DIR/www:/var/www/html -e MYSQL_DATABASE=nextcloud -e MYSQL_USER=nextcloud -e MYSQL_PASSWORD=MY_PASSWORD -e MYSQL_HOST=ncdb:3306 -e NEXTCLOUD_TRUSTED_DOMAINS="MY_DOMAIN" nextcloud

NEXTCLOUD_DIR/www/config/config.php
- overwriteprotocol: 'https'
- overwritewebroot: ''
- overwrite.cli.url: 'https://MY_DOMAIN'
- この設定をしないとhttps環境ではクライアントからログイン（Grant access）できない（webrootはいらないかな）

サービス運用 on えやみぐさ

aoirint.com 個人用メールサーバ

更新履歴

構成

DNS

外部からのメールを内部に転送するSMTPサーバ mx01.aoirint.com

SMTP

SMTPS

外部にメールを送信するSMTPサーバ smtp.aoirint.com

Submission

IMAPサーバ imap.aoirint.com

IMAPS

POP3サーバ pop.aoirint.com

POP3S

2022-12-04から2022-12-06にかけてmstdn.aoirint.comで発生していた障害について

サービスの死活監視

Mastodon on Docker Composeで全文検索エンジンElasticsearchを有効化する

2021年のElasticsearchのライセンス変更

死活監視サービスBetter Uptimeを導入した

えやみぐさの記事運用 2022-06-24

Nextcloud 23から24へアップデート

自宅サーバのWebサービスをVPSで中継するようにした

構成

自宅サーバ側

~/.ssh/config

/etc/systemd/system/autossh-vps.service

VPS側

HTTPリバースプロキシ（SSHポート転送使用）: myservice.http.template

UDPポート転送（SSHポート転送不使用）: myserviceudp.stream.template

はてなブログから古い記事を移した

えやみぐさの改修ログ 2022-02-20

えやみぐさのGatsby設定ファイルのTypeScript化

えやみぐさに「チャンネル」機能を追加

えやみぐさの記事管理方法とURLフォーマットについて

えやみぐさのURL永続性について

えやみぐさの記事一覧について

えやみぐさのデプロイ自動化について

えやみぐさのデプロイにおける「2重コミット問題」を解消した

MediaWikiのセットアップ

インストール

事前準備

docker-compose.yml

nginx設定ファイル (/etc/nginx/sites-enabled/wiki.example.com.conf）

手順

拡張機能のインストール

インストール手順

数式（Math）

シンタックスハイライト（SyntaxHighlight）

設定

ロゴを変更

ロゴ変更 LocalSettings.php

ロゴ変更 手順

既定のタイムゾーンを変更

タイムゾーン変更 LocalSettings.php

タイムゾーン変更 手順

メンテナンス

再起動

データベース構造の更新

Hexo

Hexoで日記用のブログを用意した

WordPress

docker-compose.yml

.env

ArchiveBox

docker-compose.yml

.env

初期設定

Overleaf Community Edition

使用できない機能

Git管理

テンプレート

docker-compose.yml

.env

設定

TeXLiveのフルインストール

Wiki.jsのセットアップ

メモリ消費量

docker-compose.yaml

Mastodonをdocker-composeで立てる（Ubuntu 18.04）

静的サイトジェネレータMiyadaiku + GitHub Actions + GitHub Pagesでブログを作る

ロゴ変更手順

タイムゾーン変更手順