Category: OS

After updating Collabora Online, which was installed for NextCloud integration, from 22 to 23, the following error appeared when opening office-based files in NextCloud. (Ubuntu 22.04)

Failed to establish socket connection or socket connection closed unexpectedly.

NextCloud error

The logs of Collabora Online show no errors but the following warnings.

WRN Successfully sent ‘segfaultcount’ message segfaultcount 1
WRN Crash detected, will quarantine last version of …

Collabora Online logs

The reason was that the package “collaboraoffice” had not been updated.

To install, use the following command

apt install coolwsd code-brand

To update (upgrade), use the following command. Needed to add the package “collaboraoffice”.

apt install coolwsd code-brand collaboraoffice

I wasted a few days with this error…

apachectl restart is fine, but apachectl reload, apachectl graceful, etc. will not restart apache after stopping. It’s a bug that occurs when using opcache with mod_php.

I noticed that Apache “somehow” stopped every morning after upgrading freeBSD 13. I checked the time when it stopped, and found that it stopped when the log was rotated by “newsyslog” and when the certbot of “let’sencrypt” runs.

In “newsyslog”, the restart is done by sending a signal (30 SIGUSR1) to httpd.pid, and it seems that apachectl internally operates in the same way by sending a signal. After much Googling, I found the following bug report.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268318

I had no choice but to remove “/var/run/httpd.pid 30”, which is the part of the “newsyslog” configuration, and set the cron to hit the following command after “newsyslog” was run.

/usr/local/etc/rc.d/apache24 gracefulstop && /usr/local/etc/rc.d/apache24 start

I’m sure there are many ways to deal with this, but I decided to use the above temporary solution as a stopgap until the bug is fixed.

The certbot command was also changed to the above in the post-hook section.

I think FreeBSD Apache is the fastest for displaying websites, but the support period is too short, and if you leave it until the last minute, you will have to upgrade the OS every 3 months. It should be like ubuntu with 5 years free support and 10 years paid support.

After upgrading to FreeBSD 12.4 to 13.2, sshfs stopped working. sshfs gives the following error when mounted.

# sshfs -o allow_other,default_permissions,uid=1001,gid=1001 XXXX XXXXX
fuse: failed to open fuse device: No such file or directory

When I look at kldstat, there is no fuse.ko. I got the following error when trying to load it with kldload.

# kldload fuse.ko
kldload: can't load fuse.ko: No such file or directory

It seems that fuse.ko has been gone since 13.x and replaced by fusefs.ko. Anyway, I reinstalled fusefs-sshfs and fusefs-libs, modified /boot/loader.conf and /etc/rc.conf, and rebooted.

pkg -y install fusefs-sshfs fusefs-libs

vi /boot/loader.conf
---
# added
fusefs_load="YES"
---

vi /etc/rc.conf
---
# added
enable_fusefs="YES"
---

ssfs does work.

(It was OK to use “kldload fusefs.ko” without rebooting, but I rebooted to check the operation of the system reboot.)

I use multiple development environments and use the same SSH key for all of them. This time, I copied the ssh key from Windows to the Linux environment (ChromeOS) and when I access the server using the key, I got an error “load key “/home/xxxxxx/.ssh/test03/id_rsa” : invalid format”. The result was “Permission denied (publickey).

The newline code in the key file from Windows was CRLF, and when I changed it to LF, it worked.

If you are using VIM, you can use the following commands to replace the newline codes.

:e ++ff=unix # show newline code
:%s/^M//g # ^M can be entered by pressing [Ctrl] + [V] key and then [Ctrl] + [M] key.

This post is my reminder. I spend time on the same mistake every few years.

The below is how to login to Ubuntu www-data with SSH.

# work with root
sudo su -

# change www-data to login user
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
# set www-data password


su - www-data

# make ssh keys
cd .ssh
ssh-keygen -t rsa
chmod 600 ./*
chmod 744 ~/.ssh
# change the name if you need. depending on your ssh setting.
mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys

exit

vi /etc/ssh/sshd_config
---
# Add below line if you find other "AllowUsers" setting.
AllowUsers www-data
---

exit

Now, you can login as www-data user with id_rsa file from your local environment. I got an error “Permission denied (publickey)” because I forgot to set “chmod 755 /home/www-data”. It takes time to solve it.

I changed my http server from Apache to OpenLiteSpeed and had a few problems. One of them was that I could not change the running user and group of OpenLiteSpeed.

Just changing the configuration file “/usr/local/lsws/conf/httpd_config.conf” and rebooting OpenLiteSpeed doesn’t work. It looked working but I noticed there were a number of user-related anomalies when accessing files with PHP, such as not being able to see the server log or live feed on the Admin console.

The solution is to change the user and group in the above file, then reinstall OpenLiteSpeed with the following command.

apt -y install --reinstall openlitespeed
# below may not necessary
rm -rf /tmp/lshttpd
systemctl restart lshttpd

I don’t know why this is necessary, but if you don’t do this, the user of the file you create via OpenLiteSpeed will not be the user of the configuration file.

I used the command “apt” because I’m using Ubuntu. It may be a phenomenon peculiar to Debian systems, and this “reinstall thing” may not be necessary for Redhat systems such as Centos.

I changed my http server from Apache to OpenLiteSpeed and had a few problems. One of them is that “.user.ini” file does not work on OpenLiteSpeed.

Instead of using “.user.ini”, you can use the [php.ini Override] setting from [General] tab of the virtual hosts setting on the Admin console.

As a side note, I failed many times when I set up this from the Admin console until I modified the virtual host configuration file directly and rebooted the system from command line using “vi” and “systemctl restart lshttpd”.

After this manually changing, the change from the Admin console is working too.

It might be my simple mistake, but I am writing this side note in the hope that it might be helpful to you.

My setting of [php.ini Override] in the virtual host config file is below.

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
}

I recently changed some of my http servers to OpenLiteSpeed from Apache. When changing the servers, I have a problem: OpenLiteSpeed does not have the client authentication feature that Apache has.

I was debating but finally decided to use a reverse proxy in Apache and authenticate clients there. I know “Then, just use Apache. Why you need to use OpenLiteSpeed?”. But I was not comfortable with Apache, because Apache sometimes freezed up a little, once or twice a week. I know my Apache configuration was something bad, but I couldn’t fix it.

I thought the servers would be too slow for the reverse proxy, but my fears were unfounded. It’s very fast and comfortable after the change.

Below is an example to configure Client Side Certificates for Admin console of OpenLiteSpeed。

Premise

Client certificate
=> Certificates of CA : /opt/myCA/cacert.pem
=> Certificate Revocation Lists : /opt/myCA/crl.pem
Setting of Admin Console of OpenLiteSpeed is below. (There is no need to use SSL. )

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
}

# add this section
accessControl  {
  allow                   127.0.0.1
}

# change this section
listener adminListener {
  # change below two lines
  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

Configuration of Reverse Proxy on Apache

Below is an Apache configuration that accesses the OpenLiteSpeed Admin console “http://127.0.0.1:7080/” via “https://yourdomain.net:8000/”.
mod_proxy and mod_proxy_http modules needed.

Then you are able to protect your site with client certifications.

# Add below to your apache virtual host settings
<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/

				# If you want tp use Admin Console with SSL
				#SSLProxyEngine On
                #SSLProxyCheckPeerCN off
                #SSLProxyCheckPeerName off
                #ProxyPass / https://127.0.0.1:7080/
                #ProxyPassReverse / https://127.0.0.1:7080/


                SSLEngine on
                # Client Side Certificates
                SSLCACertificateFile /opt/myCA/cacert.pem
                SSLCARevocationFile /opt/myCA/crl.pem
                SSLCARevocationCheck chain
                SSLVerifyClient require
                SSLVerifyDepth 1

                # Sever Side Certificates (by letsencrypt)
                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>

The advantages of Client Side Certificates are irreplaceable by other security method. It’s easy to visit a site and easy to revoke your certificate when you lost your computer.
Setting up 2FA, two-step verification, such as Google Authenticator, requires entering credentials every time you visit a site, and there is a risk of phishing scams in the first place. It’s a little bit pain for me.