Luis's questions

I'm installing Nextcloud on a FreeBSD system and I'm using lighttpd behind a nginx reverse proxy with terminal SSL.

lighttpd is able to serve static html files and can serve index.php, but without any styles, just the text.

When running lighttpd -D -f /usr/local/etc/lighttpd/lighttpd.conf and accessing cloud2.myhostname.com there's a bunch of errors as shown below.

The document root and all descendants are owned by www:www, the user and group under which lighttpd is running. All directories have permission of 770. All files have permission of 660.

The lighttpd error log shows that FastCGI is running, and the FastCGI is returning an error trace, which lighttpd logs as FastCGI-stderr: to indicate that the error trace is from it.

How to solve this?

server.c.1513) server started (lighttpd/1.4.59)
gw_backend.c.944) gw - found a host  0
gw_backend.c.944) gw - found a host  0
gw_backend.c.228) got proc: pid: 99023 socket: unix:/var/run/lighttpd/sockets/php.socket-2 load: 1
mod_fastcgi.c.487) FastCGI-stderr:{"reqId":"5HVsZcmvRCF7Qpm918A6","level":3,"time":"2021-10-25T22:03:55+00:00","remoteAddr":"111.222.33.44","user":"--","app":"PHP","method":"GET","url":"/index.php","message":"file_put_contents(/usr/local/www/nextcloud/data/.htaccess): Failed to open stream: Permission denied at /usr/local/www/nextcloud/lib/private/Setup.php#584","userAgent":"Mozilla/5.0 (X11; FreeBSD amd64; rv:93.0) Gecko/20100101 Firefox/93.0","version":"","exception":{"Exception":"Error","Message":"file_put_contents(/usr/local/www/nextcloud/data/.htaccess): Failed to open stream: Permission denied at /usr/local/www/nextcloud/lib/private/Setup.php#584","Code":0,"Trace":[{"function":"onError","class":"OC\\Log\\ErrorHandler","type":"::"},{"file":"/usr/local/www/nextcloud/lib/private/Setup.php","line":584,"function":"file_put_contents"},{"file":"/usr/local/www/nextcloud/lib/private/Setup.php","line":222,"function":"protectDataDirectory","class":"OC\\Setup","type":"::"},{"file":"/usr/local/www/nextcloud/core/Controller/SetupController.php","line":57,"function":"getSystemInfo","class":"OC\\Setup","type":"->"},{"file":"/usr/local/www/nextcloud/lib/base.php","line":939,"function":"run","class":"OC\\Core\\Controller\\SetupController","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/usr/local/www/nextcloud/index.php","line":36,"function":"handleRequest","class":"OC","type":"::"}],"File":"/usr/local/www/nextcloud/lib/private/Log/ErrorHandler.php","Line":92,"CustomMessage":"--"}}

mod_fastcgi.c.487) FastCGI-stderr:{"reqId":"5HVsZcmvRCF7Qpm918A6","level":3,"time":"2021-10-25T22:03:55+00:00","remoteAddr":"111.222.33.44","user":"--","app":"PHP","method":"GET","url":"/index.php","message":"file_put_contents(/usr/local/www/nextcloud/data/index.html): Failed to open stream: Permission denied at /usr/local/www/nextcloud/lib/private/Setup.php#585","userAgent":"Mozilla/5.0 (X11; FreeBSD amd64; rv:93.0) Gecko/20100101 Firefox/93.0","version":"","exception":{"Exception":"Error","Message":"file_put_contents(/usr/local/www/nextcloud/data/index.html): Failed to open stream: Permission denied at /usr/local/www/nextcloud/lib/private/Setup.php#585","Code":0,"Trace":[{"function":"onError","class":"OC\\Log\\ErrorHandler","type":"::"},{"file":"/usr/local/www/nextcloud/lib/private/Setup.php","line":585,"function":"file_put_contents"},{"file":"/usr/local/www/nextcloud/lib/private/Setup.php","line":222,"function":"protectDataDirectory","class":"OC\\Setup","type":"::"},{"file":"/usr/local/www/nextcloud/core/Controller/SetupController.php","line":57,"function":"getSystemInfo","class":"OC\\Setup","type":"->"},{"file":"/usr/local/www/nextcloud/lib/base.php","line":939,"function":"run","class":"OC\\Core\\Controller\\SetupController","type":"->","args":["*** sensitive parameters replaced ***"]},{"file":"/usr/local/www/nextcloud/index.php","line":36,"function":"handleRequest","class":"OC","type":"::"}],"File":"/usr/local/www/nextcloud/lib/private/Log/ErrorHandler.php","Line":92,"CustomMessage":"--"}}

mod_fastcgi.c.487) FastCGI-stderr:{"reqId":"5HVsZcmvRCF7Qpm918A6","level":2,"time":"2021-10-25T22:03:55+00:00","remoteAddr":"111.222.33.44","user":"--","app":"no app in context","method":"GET","url":"/index.php","message":"Could not detect any host in https:///data/htaccesstest.txt","userAgent":"Mozilla/5.0 (X11; FreeBSD amd64; rv:93.0) Gecko/20100101 Firefox/93.0","version":""}

mod_fastcgi.c.487) FastCGI-stderr:{"reqId":"5HVsZcmvRCF7Qpm918A6","level":2,"time":"2021-10-25T22:03:55+00:00","remoteAddr":"111.222.33.44","user":"--","app":"no app in context","method":"GET","url":"/index.php","message":"Could not detect any host in http:///data/htaccesstest.txt","userAgent":"Mozilla/5.0 (X11; FreeBSD amd64; rv:93.0) Gecko/20100101 Firefox/93.0","version":""}

mod_fastcgi.c.487) FastCGI-stderr:{"reqId":"5HVsZcmvRCF7Qpm918A6","level":3,"time":"2021-10-25T22:03:55+00:00","remoteAddr":"111.222.33.44","user":"--","app":"PHP","method":"GET","url":"/index.php","message":"fopen(/var/log/nextcloud/nextcloud.log): Failed to open stream: Permission denied at /usr/local/www/nextcloud/lib/private/Log/File.php#84","userAgent":"Mozilla/5.0 (X11; FreeBSD amd64; rv:93.0) Gecko/20100101 Firefox/93.0","version":""}

gw_backend.c.303) released proc: pid: 99023 socket: unix:/var/run/lighttpd/sockets/php.socket-2 load: 0

The ejabberd server I'm configuring has the following configuration for certfiles and for the port 5222. Gajim, Psi and Pidgin can connect fine. Conversations cannot. There's some stream error.

ejabberd's log shows

2021-07-15 16:15:01.459 [info] <0.381.0>@ejabberd_listener:accept:273 (<0.649.0>) Accepted connection 88.88.88.72:65069 -> 192.168.7.5:5222```

For Gajim, besides a line like the one above, it has two more when opening the connection:

2021-07-15 16:16:10.465 [info] <0.651.0>@ejabberd_c2s:process_auth_result:268 (tls|<0.651.0>) Accepted c2s SCRAM-SHA-256 authentication for test1@myserver by mnesia backend from 88.88.88.72
2021-07-15 16:16:10.550 [info] <0.651.0>@ejabberd_c2s:bind:442 (tls|<0.651.0>) Opened c2s session for test1@myserver/gajim.W2AAA7JO

Part of the ejabberd's config file is:

certfiles:
  - "/usr/local/etc/ejabberd/certs/myserver.pem"
  - "/usr/local/etc/ejabberd/certs/myserver.key"
listen:
  -
    port: 5222
    ip: "192.168.7.5"
    module: ejabberd_c2s
    max_stanza_size: 262144
    shaper: c2s_shaper
    access: c2s
    tls: true
    starttls: true
    starttls_required: true
    protocol_options:
        - "no_sslv2"
        - "no_sslv3"
        - "no_tlsv1"
        - "no_tlsv1_1"
    ciphers: "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"
    dhfile:
      "/usr/local/etc/ejabberd/certs/c2s_dh2048.pem"

I've also tried commenting out the ciphers and no_ssl*, no_tls* but to no avail.

The ejabberd server is running not at the gateway but in a LAN location with port forwarding enabled.

What is wrong between Conversations and ejabberd?

I would like to run a service inside a chroot in a NetBSD 9.1 amd64 system. The service runs if invoked from OS. The service in question is dendrite-monolith-server. I just copied the file for ease of use to start sitting inside the chroot in /bin/.

# ldd bin/start 
bin/start:
        -lpthread.1 => /usr/lib/libpthread.so.1
        -lc.12 => /usr/lib/libc.so.12

They are hard linked:

# ls -l usr/lib
total 8560
-r--r--r--  2 root  pe  2079984 Feb 22 23:40 lc.12
-r--r--r--  2 root  pe  2079984 Feb 22 23:40 libc.so.12
-r--r--r--  2 root  pe    93656 Feb 22 23:40 libpthread.so.1
-r--r--r--  2 root  pe    93656 Feb 22 23:40 lpthread.1

In the chroot /dev, did MAKEDEV all to create the devices.

Copied ld.elf_so to the chroot /libexec directory

# ls -l /libexec/
total 324
-r-xr-xr-x  1 0  1000  164344 Feb 22 23:47 ld.elf_so

ksh93 is statically linked:

# chroot ./ /bin/ksh93
#
# /bin/start 
/bin/ksh93: /bin/start: not found

What's wrong or missing?

In my Linux server (4.9.9_1 kernel, x86_64) enp5s0 has a static ip 192.168.1.30 and enp9s0 is given an address via dhcpcd.

# ip route ls
default via 192.168.1.1 dev enp5s0 src 192.168.1.30 metric 202 
default via 39.53.131.254 dev enp9s0 src 39.53.131.237 metric 203 
39.53.130.0/23 dev enp9s0 proto kernel scope link src 39.53.131.237 metric 203 
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.30 metric 202

The first thing I don't understand is why does the system set two default routes, although preference is given to one based on metric.

What I want to do is to delete the second default route via 39.53...., to add another routing table, set ip rule for that to add an identical default route but for the new routing table.

When:

# ip route del default via 39.53.131.254 dev enp9s0
# echo $?
0

The routing table doesn't seem to have changed, though:

    # ip route l
    default via 192.168.1.1 dev enp5s0 src 192.168.1.30 metric 202 
    default via 39.53.131.254 dev enp9s0 src 39.53.131.237 metric 203
39.53.130.0/23 dev enp9s0 proto kernel scope link src 39.53.131.237 metric 203 
192.168.1.0/24 dev enp5s0 proto kernel scope link src 192.168.1.30 metric 202

After a ip route flush cache:

# ip route show cache

shows nothing.

What should I do?

I've read several of the related topics posted here, but I have not been able to avoid this innodb error.

The steps I've taken to replicate data from a Slackware server - 5.5.27-log (S) to a FreeBSD slave - 5.5.21-log (F) were these:

1. (S) flush tables with read lock;
2. (S) in another terminal show master status;
3. (S) stop mysqld via command line in third terminal;
4. (F) while both servers are stopped, rsync mysql datadir from (S), excluding master.info, mysql-bin and relay-* files; Also tried rsync of all files;
5. (F) start mysqld (skip-slave)

121018 12:03:29 InnoDB: Error: page 7 log sequence number 456388912904 InnoDB: is in the future! Current system log sequence number 453905468629. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: for more information.

This kind of error happens for a lot of tables.

I know I can use dump, but the database is large, ca. 70GB and the systems are slow (old), so would like to get this replication to work with data transfer.

What should I try to solve this issue?