Lycolog

<VirtualHost *:8080>
        ServerName example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/example-error.log
        CustomLog ${APACHE_LOG_DIR}/example-access.log combined
</VirtualHost>

nginx（前段）の設定

/etc/nginx/nginx.conf

httpセクションにupstream apacheを追記することで、conf.d/配下の設定ファイルから共通的に参照できるようにする。同じことを複数の設定ファイルに書くと構文エラーで起動しなくなる。

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    keepalive_timeout  65;

    upstream apache {
      server [::1]:8080;
    }

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

/etc/nginx/conf.d/example.conf

ここでは/etc/nginx/nginx.confで設定したupstreamにプロキシする設定を作っている。

proxy_set_header Host $host;はnginxが受けたホストヘッダをそのままApacheに飛ばすことで、Apache側がバーチャルホストでルーティングできるようにしている。Apacheとnginxで別々のホスト名にすることもできるが、そうした場合、Apache側はApache側で定義したホスト名で動作するため、CGIなどのスクリプトを動かすときに支障があるうえ、Apache側のホスト名をhostsに書かないと疎通できないこともあり、手間なので基本的に前段のドメインに合わせておくのが無難だ。

proxy_set_header X-Real-IP $remote_addr;はnginxにアクセスしてきたクライアントのIPをApacheに渡すための設定。そのままだとnginxのIPが渡ってしまう。

proxy_set_header X-Forwarded-Proto $scheme;もホストヘッダの転送と似ていて、nginxが受けたプロトコルスキーマをApacheに飛ばすための設定。こうしておくとApache側はhttpで受けているのに、httpsでアクセスされたものとして認識させることが出来るため、プロトコルスキーマ付きでURLを生成するCGIがいるときに都合がいい。単にスキーマを誤魔化しているだけなので実際は暗号化されていない。

server {
  listen [::]:443 ssl;
  server_name  example.com;

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  access_log   /var/log/nginx/example.access.log;
  error_log    /var/log/nginx/example.error.log;

  location / {
    proxy_pass http://apache/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

余談：HTTP通信に用いられるHOSTヘッダーについて

HTTP通信で利用されるドメインは単にHOSTヘッダーにドメインを書いているだけなので、以下のようなことをするとhostsを書かなくとも疎通できる。

curl -H "HOST: lycolia.info" http://"[2403:3a00:101:13:133:167:8:98]"

これは一般的なHTTPクライアントの仕組みとして、まずドメインをDNSに問い合わせ、IPを取得したのち、ドメインをホストヘッダーに載せてIPアドレス宛にHTTP要求を出しているからだと思われる。

hostsの書き換えができない環境で、任意のドメインに対してHTTP要求を出したい時にも重宝するので、覚えておくと何かと役に立つ。

nginxからApache2へセキュアにリバプロしたときに真のクライアントIPを取得できるようにする

コメント（0件）

2025/10/14(火)Openwrt本体でメトリクスをグラフで見れるようにした

更新日：2026/05/21
投稿日：2025/10/14

ソフトウェア::OpenWrtジャンル::自宅サーバー技術::監視

luci-app-statisticsとcollectdを入れて下図のように各メトリクスのグラフを見れるようにした。collectdは、システム情報を定期的に収集し、さまざまな方法で値を格納するメカニズムを提供する小さなデーモンで、luci-app-statisticsはそれをLuCI上に表示するためのものっぽい。

確認環境

Env	Ver
OpenWrt	24.10.0

セットアップ

LuCIを開く
System→Software
luci-app-statisticsを入れる
画面リロード
Statics→Graphからグラフが見れることを確認

この時点で幾つかのプラグインが導入されたが、消したり入れたりして、結果として以下のものを導入した。

Collectdのプラグイン設定

/etc/collectd.confをいじると変更できる。

基本的にはLoadPlugin hogeでhogeプラグインを読み込み、以下の書式で設定するようだ。設定がなければLoadPlugin hogeだけでよい。

<Plugin hoge>
        Foo true
        Bar 1
        Baz "fuga"
</Plugin>

Collectdのプラグイン

collectd-mod-cpu：CPU使用率

collectd-mod-cpu

設定	内容	デフォルト
ValuesPercentage	`true`であれば、パーセンテージで取れる	true
ReportByCpu	`true`であれば、コアごとに取れる	true
ReportByState	`true`であれば、システム、ユーザー、アイドルなど、状態ごとに取れる	true

設定はデフォルトのままで良さそう。

collectd-mod-interface：ネットワーク転送量

collectd-mod-interface

Network→Interfaces→Deviceにあるものが見れる。

br-lanとMAP-E、PPPoEが見たいので以下のようにした。

LoadPlugin interface
<Plugin interface>
        Interface "br-lan"
        Interface "map-wanmap"
        Interface "pppoe-wanppp"
</Plugin>

collectd-mod-load：負荷(Load Average)

collectd-mod-load

uptimeコマンドで出てくる内容と思われる。1を超えていれば過負荷、割っていれば余裕がある。

Wikipediaによると、1ならその時間平均で全てのプロセスが実行され、1.73なら73%のプロセスが実行待ちになったと言う事のようだ。これを1分、5分、15分の平均で出しているとのこと。

設定項目がない。

collectd-mod-memory

collectd-mod-memory

メモリの使用量を取れる。

設定	内容	デフォルト
ValuesAbsolute	物理メモリ使用量の絶対数で報告するかどうか（つまりどういうこと？）	true
ValuesPercentage	メモリ使用量をパーセンテージで報告するかどうか	false

設定はデフォルトのままで良さそう。

collectd-mod-thermal

collectd-mod-thermal

デバイスの温度を取れる。

設定	内容	デフォルト
ForceUseProcfs	Linuxインターフェースではなく、procfsから熱源を取得する	false
Device	温度を取得するデバイス名
IgnoreSelected	`true`にするとDeviceで指定したデバイスを集計外にする	false

R86S U1の場合、thermal_zone1以外無価値に見えたので、thermal_zone1のみとした。thermal_zone0はマザーボードの温度のようだが、固定値しか出てこない。

LoadPlugin thermal
<Plugin thermal>
        Device "thermal_zone1"
</Plugin>

これだけだと余計なグラフが出てくるため、設定後に余計なグラフデータを削除する。

collectd-mod-uptime

公式にマニュアルはなさそうだが、起動時間を見れる。

LoadPlugin uptime

collectd-mod-rrdtool

collectd-mod-rrdtool

collectdが取得したメトリクスを保存したり、メトリクスのグラフを書くのに使われている模様。特に設定せずとも勝手に設定されるため設定を気にする必要性はなさそう。

ログは標準では/tmp/rrd/OpenWrt/に保存されているようなのでストレージの摩耗は気にしなくていい。（/tmp/はオンメモリストレージ）

トラブルシューティング

Thermalタブに壊れて表示されていない画像や、集計対象外のグラフが表示される

上図の青枠のように壊れて表示されていない画像や、集計対象外のものが表示されている場合、/tmp/rrd/OpenWrt/配下にある不要なメトリクスを削除することで非表示にできる。

例えば上図にあるthermal-cooling_device*にはまともにデータが入っていないため、画像が壊れて表示されている。rm -Rf thermal-cooling_device*で消すと出てこなくなる。

上図の状態になると、下図のように不要なグラフが表示されなくなる。

但しcollectd.confで以下のようにデバイスを絞っていないと、再び出てくると思われるので、設定で表示したいものだけに絞ってから消した方がよい。

LoadPlugin thermal
<Plugin thermal>
        Device "thermal_zone1"
</Plugin>

参考

[OpenWrt Wiki] Performance and logging

コメント（0件）

2025/09/30(火)GitHubのリポジトリをSSH認証経由で扱えるようにする

更新日：2026/04/07
投稿日：2025/09/30

Webサービス::GitHubソフトウェア::SSHOS::Linux::UbuntuOS::Windows

なんか突如としてGitHubにHTTP経由で繋ぐのが面倒くさくなったのでSSHで繋げるようにしたときのメモ。

確認環境

Windows 11 Pro 25H2
Ubuntu 24.04.3 LTS
RLogin 2.30.8

やり方

SSH鍵の作成

RLoginを開き、サーバーに接続→新規→サーバー→プロトコルを開く
認証キーボタンを押しED25519辺りで適当な名前で鍵を作成する
適当な場所に秘密鍵をエクスポートする。ここでは便宜上github.secとする
鍵を右クリックし、公開鍵をコピーして、どっかにメモっておく

GitHubへの登録

GitHubを開き、アカウント設定に移動、SSH and GPG keysを開く
SSH keys→New SSH Keyを開く
Titleに適当な名前を設定
Key typeはAuthentication Keyにする
RLoginで作った
コピーした公開鍵をKeyに貼り付ける
Add SSH keyボタンを押す

鍵束へのSSH鍵の登録

Windowsの場合

忘れた。

Ubuntuの場合

正攻法では以下だが、keychainを使ったほうが運用が楽。

# 鍵束への登録
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/github.sec

# 接続確認
ssh -T git@github.com

SSH Configを書く

Windowsの場合

ここではWindowsのSSHクライアントを利用する。

Gitに利用するSSHクライアントの設定をする

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"

作成したSSH鍵をC:/Users/<ユーザー名>/.ssh/に置く
C:/Users/<ユーザー名>/.ssh/configを開き、次の内容を記述
```
Host github.com
    User <ユーザーID>
    Hostname github.com
    IdentityFile C:/Users/<ユーザー名>/.ssh/github.sec
```
パス表現に%USERPROFILE%は通用しないので注意

Ubuntuの場合

作成したSSH鍵を~/.ssh/github.secに置く
chmod 600 ~/.ssh/github.secとかして自分しか見れないようにする

~/.ssh/configを開き、次の内容を記述

Host github.com
    User <ユーザーID>
    Hostname github.com
    IdentityFile ~/.ssh/github.sec

既存のリポジトリをSSH対応にする

ここではoriginがリモートであるとして進める。

git remote -vでリモートリポジトリの状況を確認
git remote remove originでHTTP通信になってるのを消す
git remote add origin git@github.com:Hoge/piyo.gitでSSH通信に書き換える
git fetchが通ればOK

トラブルシューティング

Permission Denied (publickey)が出る

鍵のパーミッションが600、.ssh/のパーミッションが700なのを確認する
ssh -T git@github.comで繋がるか確認する。繋がらなければこれまでの手順が何か漏れないか確認する
ユーザー名が間違っていても出る

コメント（0件）

2025/09/15(月)Mastodonのアップグレードメモ

更新日：2026/06/18
投稿日：2025/09/15

ソフトウェア::Mastodon

ハマったので残しておく。

前提条件

GitHubにMastodon本家をForkしたリポジトリがあり、そこをベースに運用している。

git remote -vの状態が以下の通りで、origin/mainが本番運用ブランチ。

mastodon        https://github.com/mastodon/mastodon.git (fetch)
mastodon        https://github.com/mastodon/mastodon.git (push)
origin  https://github.com/Lycolia/lycodon.git (fetch)
origin  https://github.com/Lycolia/lycodon.git (push)

やり方

マージブランチを作る
```
git checkout -b merge-latest
```
本家を取ってくる
```
git fetch mastodon
```
マージブランチにマージする
- バージョン指定
```
git switch merge-latest
git merge v4.5.9
```
- 最新版
```
git merge mastodon/main
```

セットアップする

sudo su - mastodon
# Rubyのアップデート用
cd ~/.rbenv/plugins/ruby-build
git pull
cd ~/live
RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install
# install
bundle install
yarn install
# DBがアカンことがあるので叩いておく
RAILS_ENV=production bundle exec rails db:migrate
# いつものリビルド
RAILS_ENV=production bundle exec rails assets:clobber
RAILS_ENV=production bundle exec rails assets:precompile
exit
# 再起動
sudo systemctl restart mastodon-web mastodon-sidekiq mastodon-streaming

動作確認OKならgit pushしてGitHub上で自分のところのmainにマージする。デフォルトでは本家に向くので注意
もう一度、前述4番のセットアップコマンド一式を流し、問題なければ終わり

トラブルシュート

正常に動いていない場合

ジャーナルを見てエラー原因を特定する。新規要素がらみのパラメーターが出てたらDBが怪しいのでRAILS_ENV=production bundle exec rails db:migrateで直る可能性がある。

sudo journalctl -u mastodon-web -f

If the version you need is missing, try upgrading ruby-build.といわれる場合

以下のコマンドを叩いてruby-buildを更新するといける

cd  "$(rbenv root)"/plugins/ruby-build
git pull

備考

Gitのタグは一意なので、mastodonリモートのタグを指定してもローカルで問題なく拾える。

コメント（0件）

2025/09/15(月)Dockerを使ってMastodonの開発環境を作る

更新日：2025/09/16
投稿日：2025/09/15

ソフトウェア::Mastodonジャンル::セットアップOS::Linux::Ubuntu

なんか昔のやり方が使えなくなってたので調べたメモ。

確認環境

Env	Ver
OS	Ubuntu 24.04.3 LTS
Docker	version 28.1.1, build 4eba377
Docker Compose	v2.35.1
Mastodonのバージョン	v4.5.0-alpha.2
Mastodonのコミットハッシュ	06803422da3794538cd9cd5c7ccd61a0694ef921

手順

DEVELOPMENT.md#dockerの手順通りにやると行ける。

docker compose -f .devcontainer/compose.yaml up -d
docker compose -f .devcontainer/compose.yaml exec app bin/setup
docker compose -f .devcontainer/compose.yaml exec app bin/dev

コンテナへのアタッチ方法

# 方法1
docker compose -f .devcontainer/compose.yaml exec app zsh

# 方法2
cd .devcontainer
docker compose exec app zsh

VSCodeがあるならDockerやRemoteほげほげ系の拡張を使い、devcontainer-appにAttach Shellしてもよい。

検証ユーザーの作成

次のコマンドでユーザーを作る

./bin/tootctl accounts create hoge --email hoge@example.com --confirmed

ユーザーの承認を行い、必要に応じてパスワードを使いやすいものに変更する

rails console
user = Account.find_by(username: 'hoge').user
user.approve!
# PW変更ここから
user.password = 'password'
user.skip_confirmation!
# PW変更ここまで
user.save!
quit

フロントエンドのビルドとサーバー起動

bin/rails assets:precompile
bin/dev