カテゴリー: OS

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
WRN Crash detected, will quarantine last version of …

Collabora Online ログ

原因はパッケージ”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を引き継ぎ続けているため、こんな設定になっている・・・。

最近一部のhttpサーバをApacheからOpenLiteSpeedに変更した。ただ、問題があり、Apacheにはあるクライアント認証の機能がOpenLiteSpeedにはない。

さんざん迷った挙句、Apacheでreverse proxyを使用し、そこでクライアント認証することにした。「全部Apacheで良いじゃないか」という感じもするが、どうもApache+mpm_event+php-fmpの構成では、まれにプチフリするのが気になってしょうがない。設定が悪い気がするが、再現性がなく調査もできない。

案ずるより産むがやすし、動かしてみたら、とても軽快になった。reverse proxy分重くなるかと思ったが、杞憂であった。

以下、OpenLiteSpeedのadmin consoleをクライアント認証に設定する例。

前提

クライアント証明書は以下
　・CA証明書：/opt/myCA/cacert.pem
　・証明書失効リスト：/opt/myCA/crl.pem
Admin ConsoleはSSLなしで動作させ、localhost(127.0.0.1)以外は接続させない。（Admin ConsoleをSSLありのデフォルトの状態で動作させたい場合は、Apache設定のコメントを参照のほど。reverse proxyでSSLのエラーを無視させればちゃんとつないでくれる。）
以下はOpenLiteSpeedのAdmin configの設定。設定後、restart。

vi /usr/local/lsws/admin/conf/admin_config.conf
---
enableCoreDump            1
sessionTimeout            3600

errorlog $SERVER_ROOT/admin/logs/error.log {
  useServer               0
  logLevel                INFO
  rollingSize             10M
}

accesslog $SERVER_ROOT/admin/logs/access.log {
  useServer               0
  rollingSize             10M
  keepDays                90
}
# 以下のセクションを追加
accessControl  {
  allow                   127.0.0.1
}
# 以下のセクションを変更
listener adminListener {
  # addressとsecureの2行を変更
  address                 127.0.0.1:7080
  secure                  0
  #keyFile                 $SERVER_ROOT/admin/conf/webadmin.key
  #certFile                $SERVER_ROOT/admin/conf/webadmin.crt
  #clientVerify            0
}
---
systemctl restart lsws

Apach設定

Apacheでhttps://yourdomain.net:8000/にアクセスするとOpenLiteSpeedの管理コンソール（http://127.0.0.1:7080/）にアクセスする設定。ブラウザにクライアント認証の証明書が入っていないとはじかれる。SSLはLetsencryptで取得。
mod_proxy mod_proxy_httpはモジュールで入れること。

# Apacheのバーチャルホストの設定に以下を追加
<IfModule mod_ssl.c>
        <VirtualHost _default_:8000>
                ServerName yourdomain.net
                DocumentRoot /var/www/

                ErrorLog ${APACHE_LOG_DIR}/lsws/proxy_error.log
                CustomLog ${APACHE_LOG_DIR}/lsws/proxy_access.log common

                # Proxy設定
                <Proxy *>
                    Order deny,allow
                    Allow from all
                </Proxy>
                ProxyRequests Off
                ProxyPreserveHost On

                ProxyPass / http://127.0.0.1:7080/
                ProxyPassReverse / http://127.0.0.1:7080/

				# AdminConsoleをデフォルトのまま（SSLで）使用するなら以下
				#SSLProxyEngine On
                #SSLProxyCheckPeerCN off
                #SSLProxyCheckPeerName off
                #ProxyPass / https://127.0.0.1:7080/
                #ProxyPassReverse / https://127.0.0.1:7080/


                # クライアント証明書関係
                SSLEngine on
                SSLCACertificateFile /opt/myCA/cacert.pem
                SSLCARevocationFile /opt/myCA/crl.pem
                SSLCARevocationCheck chain
                SSLVerifyClient require
                SSLVerifyDepth 1

                # SSL
                SSLOptions +StdEnvVars
                Include    /etc/letsencrypt/options-ssl-apache.conf
                SSLCertificateFile /etc/letsencrypt/live/yourdomain.net/fullchain.pem
                SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.net/privkey.pem

        </VirtualHost>
</IfModule>

サイトへのアクセスも楽で、パスコンが盗まれたら失効すれば良いし、クライアント認証の良さは他のセキュリティには代えがたい。Google Authenticatorとかで二段階認証やると、アクセスのたびに入力しなきゃいけなくて面倒だし、フィッシングのリスクもあるし。