openlitespeedを設定していて、正しく設定していてもログが出力されない件があった。
■ 環境
Ubuntu 24.04 / OpenLiteSpeed 1.8.2
ユーザとグループをwww-dataに変更し、バーチャルホストをいくつか設定、バーチャルホストのログを、/usr/local/lsws/logsの下にファイル名を分けて出力するように設定したが、当該ログファイルは作成されるものの、ログの書き込みは行われない。
結論から言うと「/usr/local/lsws/logs」の所有者／グループも実行ユーザのwww-dataに変更すると動作するようになった。
chown -R www-data:www-data /usr/local/lsws/logs
ログファイルが作られるのと、なぜか設定していない「/usr/local/lsws/logs/access.log」にログが出力されたため、権限の問題だとは思えず、解決まで時間がかかった。
NextCloud連携用にインストールしていたCollabora Onlineを22から23にアップデートしたところ、NextCloudでオフィス系ファイルを開くと以下のようなエラーが出てくるようになった。(Ubuntu 22.04)
Failed to establish socket connection or socket connection closed unexpectedly.
NextCloud error
Collabora Onlineのログを見るとエラーは出ていないものの以下のwarningが出ている。
WRN Successfully sent ‘segfaultcount’ message segfaultcount 1
Collabora Online ログ
WRN Crash detected, will quarantine last version of …
原因はパッケージ”collaboraoffice”のアップデート漏れだった。
インストールは以下。
apt install coolwsd code-brand
アップグレードするときは以下。パッケージが違う・・。
apt install coolwsd code-brand collaboraoffice
このエラーで数日無駄にしてしまった・・。
apachectl restartはOKだが、apachectl reloadやapachectl gracefulなどは停止したまま起動しなくなる。mod_phpでopcacheを使用している場合に発生するバグらしい。
翌日気が付くとApacheが”なぜか”停止している。調べてもわからず、落ちたら起動するプログラムを組んで、落ちた時間を調べてみると”newsyslog”でログがローテートされたタイミングでおち、”letsencrypt”のcertbotのチェックのタイミングで落ちていた。
“newsyslog”では、httpd.pidにシグナル(30 SIGUSR1)を送る形で再起動しており、apachectlも内部的には同じようにシグナルを送って操作しているらしいので、いろいろググっていると以下のバグレポートを発見。
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268318
仕方ないので、”newsyslog”の設定のお尻からシグナルを送る部分である”/var/run/httpd.pid 30″を削除し、syslogを実行した後の時間あたりでcronを使って以下のコマンドをたたくように変更した。
/usr/local/etc/rc.d/apache24 gracefulstop && /usr/local/etc/rc.d/apache24 start
ログのローテートまでシェルで書けば良いのだが、virtual hostの設定毎にログを分けているため、テストするのも面倒＆そのうちバグフィックスされるまでのつなぎと思い、上の仮対応で良しとした。
certbotもpost-hookのとこを上記に変更した。
FreeBSDのApacheはWEBサイト表示では最速だと思っているが、サポート期間が短く、ギリギリまで放置すると3ヵ月毎にOSのアップグレードが発生する。数回再起動しなければならないうえ、こういうバグ対応まで考えると保守性は低い。ubuntuみたいに無償5年、有償10年みたいにすれば良いのに。
FreeBSD 12.4 => 13.2にアップグレードしたところ、sshfsが動作しなくなってしまった。sshfsでマウントすると以下のようなエラーが出る。
# sshfs -o allow_other,default_permissions,uid=1001,gid=1001 XXXX XXXXX fuse: failed to open fuse device: No such file or directory
kldstatで見るとfuse.koが無い。ロードしようとしてもエラー。
# kldload fuse.ko kldload: can't load fuse.ko: No such file or directory
13.xからfuse.koはなくなり、fusefs.koになったらしい。とりあえず、fusefs-sshfsとfusefs-libsを再インストールし、/boot/loader.confと/etc/rc.confを修正＆再起動。（再起動しなくても”kldload fusefs.ko”でOKだったがconf系の動作確認で再起動）
pkg -y install fusefs-sshfs fusefs-libs vi /boot/loader.conf --- # 追加 fusefs_load="YES" --- vi /etc/rc.conf --- # 追加 enable_fusefs="YES" ---
これでsshfsが動作するようになった。
開発環境が複数あり、ssh keyは使いまわしている。今回もWindowsで使っていたssh keyをたまに使うLinux環境(ChromeOS)にコピーして、SSHしたところ「load key “/home/xxxxxx/.ssh/test03/id_rsa” : invalid format」で”Permission denied (publickey).”となった。
結論から言うと、keyファイルの改行コードがCRLFとなっていて、LFに直したら動作した。
vimで修正するには
:e ++ff=unix :%s/^M//g # ^Mは[Ctrl] ＋ [V] キーを押してから、[Ctrl] ＋ [M] キーを押せば入力可能
何年かに1回同じミスで時間を使うので備忘録。
家で２つほどサーバ的なものを建てている。１つはUbuntu22だが、１つはWindows 7である。Windows 7なんかやめたいのだが、録画サーバとして設置してあり、諸事情で10にもできずそのままになっている。もうほとんど録画もしていないが、稀に録画することがあり、手仕舞いできない。
そんなWin7の録画サーバの調子が悪い。HDDが古くディスクエラーが頻発しているので、SSDに乗り換えることにした。
Win7の現在のHDDの構成は300GBでCドライブに80GBを充てていて、これをWindowsの「バックアップと復元」で新しい128GBのSSDに載せ替えるつもりだったが、「ディスク容量不足」でどうしてもできない。Cドライブだけではなく、HDD全容量以上のディスクが必要らしい。あれやこれややってみたがうまく行かない。
仕方ないので、Ubuntu 22をUSBから起動（インストールディスクから「try ubuntu」）して対応した。手順としては、SSD側でfdiskでパーティション作成、HDDからSSDにパーティション単位でddコピー、SSDでWindows7起動確認後、ついでにgpartedで容量を80GBから128GBまで拡張した。
以下、備忘録として手順を示す。HDDは/dev/sda、SDDは/dev/sdbとする。
下準備
# ルートで作業 sudo su - # なんとインストールできる！次回起動しても有効！ apt install ntfs-3g
手順１：/dev/sdaの現在のパーティション容量確認コマンド
#このコマンドの結果出てくる、/dev/sda1と/dev/sda2をコピーすることになる。 #そのため、コピー先に同じパーティション容量の/dev/sdb1と/dev/sdb2を作成する必要があるため、ここで/dev/sda1と/dev/sda2の容量を控えておく。 fdisk -l /dev/sda # あまり覚えていないが以下のような感じで出てくる。 # 2048から9602のパーティションと96043から999999のパーティションを/dev/sdbに作成する。 /dev/sda1 * 2048 96042 123456 7 NTFS /dev/sda2 96043 999999 123456 7 NTFS
手順２：/dev/sdbにパーティション作成。（NTFSではなく、sdb1はFAT32 (LBA))で作成する。）最後のwコマンドをするまで、実際には書き込まれないので安心して作業する。
fdisk /dev/sdb
コマンド (m でヘルプ): n
コマンドアクション
e 拡張
p 基本領域 (1-4)
p # 基本pらしい
領域番号 (1-4): 1 #sda1のコピー先なので1
最初 シリンダ (1-652, default 1): 2048 # 上で控えた開始
終点 シリンダ または +サイズ または +サイズM または +サイズK (1-652, default 652): 96042 # 上で控えた終了
# ２つ目を作成
コマンド (m でヘルプ): n
コマンドアクション
e 拡張
p 基本領域 (1-4)
p
領域番号 (1-4): 2 #sda2のコピー先なので2
# 上で控えた開始と終了の位置
最初 シリンダ (1-652, default 1): 96043
終点 シリンダ または +サイズ または +サイズM または +サイズK (1-652, default 652): 9999999
コマンド (m でヘルプ): t
選択した領域 1
16進数コード (L コマンドでコードリスト表示): c # FAT32 (LBA)
コマンド (m でヘルプ): t
選択した領域 2
16進数コード (L コマンドでコードリスト表示): 7 # NTFS
# 起動パーティション指定
コマンド (m でヘルプ): a
Partition number (1-4): 1
# 現在の状況確認
コマンド (m でヘルプ): p
# なんか色々出る。
# 書き込み
コマンド (m でヘルプ): w
手順3：パーティションコピー bsオプションは値を上げればコピーが早くなるわけではないらしい。32Mとか64Mあたりでやる。
# sda1はすぐ終わる dd bs=32M if=/dev/sda1 of=/dev/sdb1 # こっちは長い・・・ dd bs=32M if=/dev/sda2 of=/dev/sdb2
これでSSDから起動してみて起動できればOKである。NGだった場合は、fdisk -l /dev/sdbをよく見てみる。MBRの調整などは基本不要である。コピーが失敗していないか、ファイルシステムが違わないか、起動(boot)パーティションが指定されているかを確認する。
このあとはやらなくても良い（起動しなくなるリスク有り）のだが、gpartedを起動してパーティションサイズを拡張した。gpartedは必ずsudoコマンドで起動すること。
sudo gparted
GUIなので説明は割愛。対象のディスクを選んで、リサイズを選択してからドラッグしてリサイズする。
ローカルネットの中だけのサーバだが、そのうちセキュリティの問題でsambaが他のデバイスから繋がらなくなりそう。そうなったら破棄するか何かで対応しよう。。。
Ubuntu serverではwww-dataというユーザがいて、WEB系のプログラムを動作させるときのデフォルトユーザとなっている。
このwww-dataにSSHでログインしようとしたら手間取ったため、以下に方法を示す。
# rootで作業 sudo su - # www-dataをログインユーザにする。 mkdir -p /home/www-data chown www-data:www-data /home/www-data chmod 755 /home/www-data usermod -s /bin/bash www-data passwd www-data # 適当なパスワードを指定 su - www-data # sshの認証鍵を作成 cd .ssh ssh-keygen -t rsa chmod 600 ./* chmod 744 ~/.ssh # sshの設定に合わせて・・ mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys exit # sshの設定を変更（必要であれば） vi /etc/ssh/sshd_config --- # AllowUsersを設定してなければ不要 AllowUsers www-data ---
これでwww-dataのid_rsaを使ってSSHでログインできるようになる。ホームディレクトリの権限が755じゃないとSSHで”Permission denied (publickey)”となりはじかれるので注意。（ここがわからず時間がかかってしまった。。）
ここ数年、個人の開発環境はVS CodeでRemote Developmentを使って開発を行っている。これを最近話題のCode-serverでクラウド化すれば、PCを変えるたびに、ローカルにVS Codeをインストールする手間がなくなる。
ただ、開発環境はさくらインターネットのVPSの一番下の512MBプランなのでcode-serverを入れて重くなるのも嫌だな、となかなか手を付けずにいたが、今回試してみた。
OSや入っている主要プログラムは以下である。
Ubuntu 20.04 / Nginx / OpenLiteSpeed / Postfix / MariaDB / PostgreSQL / SSH / Code server (今回追加)
WEB系はNginxで受けて、裏で動いているOLSやCode-serverにproxyしている。
結論から言うと、この環境でもcode-serverはPHP程度の開発では問題ないレベルで動作している。「ローカルより若干遅いかな」、とか、「見た目が少し違うのでやりにくいな」と最初は感じたが、しばらくすると慣れて全く問題なくなった。
メモリはかなりカツカツで、コンパイルが必要な開発は無理そう。
セキュリティはクライアント認証をNginxに設定し、そこからProxyでCode-serverに繋いでいる。Code-server単体ではpassword設定しかできず若干不安があった。
同じくセキュリティ絡みで言えば、code-serverの起動オプションに[–disable-telemetry]を付けて起動している。これを付けないと、code-serverの開発元に諸処の情報が送付される。code-serverのインストール解説サイトで言及されていることがないため、たいした情報が送られているわけでもないかもしれないが念の為。
ちなみに、Code-serverのインストールに際し、HTTPのフロントエンドもApacheからNginxに変更した。理由はどうしても、ApacheのReverseProxyでCode ServerのWebsocketを通せず、やむなくNginxへの変更となった。軽い軽い言われているNginxだが、私の開発環境でProxyオンリーのフロントエンド利用ではApacheより遅く感じた。あくまで体感だが、１コアで最小限のセッティングにした場合、Apacheに分がありそう。
Apache Proxyで通らなかったCode ServerのWebsocketは「ProxyWebsocketFallbackToProxyHttp」(Apache 2.4.47)や、「ProxyWebsocketIdleTimeout」(Apache 2.5)を使えば動いた気がしたが、 Ubuntu 20.04のApacheのバージョンが2.4.41でそこまで試す気もなくあきらめた。
今回個人の開発環境を変更したが、会社の開発環境もCode server化したくなった。ただ、FreeBSD環境があったり、クローズドな社内ネットワーク内にサーバがあったりするので、保留。
ApacheからOpenLiteSpeedへのサーバ変更で困ったことの一つが、OpenLiteSpeedの実行ユーザを変更することがうまくいかないことであった。OpenLiteSpeedのユーザとグループはApacheと同じもので動かしたい。
設定ファイル”/usr/local/lsws/conf/httpd_config.conf”を見ると、上のほうにuser/groupの設定がある。単純にこの設定を変えてOpenLiteSpeedを再起動すると、一見、正常に動いているように見えるのだが、Admin consoleからServer logやライブフィードが見られないなどPHPでファイルアクセスした際のユーザがらみと思われる異常が散見された。
解決方法は上記のファイルでユーザ、グループを変更後、以下のコマンドでOpenLiteSpeedを再インストールすることであった。
apt -y install --reinstall openlitespeed # 念のため（不要かも） rm -rf /tmp/lshttpd systemctl restart lshttpd
正直、なぜ必要なのかはわからないが、これをやらないとOpenLiteSpeed経由で作成するファイルのユーザ／グループが設定ファイルのユーザ／グループにならない。
当該サーバはubuntuを使用しているため、aptでの再インストールとなっている。試していないが、Debian系特有の現象で、CentosなどのRedhat系ならこういった作業は不要なのかもしれない。
ApacheからOpenLiteSpeedにサーバを変更したのだがいくつか困ったことがあった。その一つが、OpenLiteSpeedでは”.user.ini”が効かなく、virtualhost毎にPHPの設定を微妙に変更できなくなってしまったことだ。
Admin console画面から設定を見ていると、virtualhostの[general]（一般）タブの下に「php.ini Override」という設定があり、PHPの設定の一部上書きが出来ると書いているではないか。これは幸いと設定、console画面から「穏やかな再起動」をしてみたが動かない。
何度も設定をやり直した挙句、弱って直接confファイルを修正して、systemctl restart lshttpd とコマンドラインから再起動したところ、難なく動作した。
その後は、Admin consoleから設定、再起動しても問題なく設定が反映されるようになった。
理由は不明。単に何か間違えていた可能性もあるが、コマンドラインから修正と再起動を行うと動くこともあるという参考までに。
ちなみに行った設定は以下。
phpIniOverride {
php_value default_charset "SJIS"
php_value mbstring.language "neutral"
php_value mbstring.internal_encoding "SJIS"
php_value date.timezone "Asia/Tokyo"
php_value error_reporting E_ERROR
}1990年代にWindowsで動かしていたコードやDBを引き継ぎ続けているため、こんな設定になっている・・・。