Search results

Oh great! I totally missed that. The specific server indeed had a yum cache error and didn't get updated. Thanks for pointing it out to stupid me!

Still having that issue with the '-no-header' at line 348 in scripts/letsencrypt.sh where cert renewals fail because of a non-existent parameter to 'ss'. Also still having TLSA records that not seem to get updated after letsencrypt renews certificates. This actually results in customers moving...

SSL / TLS related: For some reason I noticed ssl generation issues with the '-no-header' parameter. But this was fixable by removing the parameter from the letsencrypt.sh but... I also get a bunch of failing DANA (tlsa) checks so I have to manually generate new tlsa records. I thought this was...

Same issues here...

Try putting the timeslot before the wordpress rules. Maybe add the [L] to the rule to make it the last evaluated rule (within the timeslot). Otherwise your. Not tested it myself tho.

You configure haproxy on server1 and split http requests based on hostnames. You can find examples here: https://www.haproxy.com/documentation/haproxy-configuration-tutorials/

I've done this once using haproxy as an frontend. Maybe you can dive into that?

Another option if you have the resources... Get 1 hidden pdns server to which you connect your customer servers via the supermasters table so this server get's all local dns mutations via named. Next, get 2 or 3 vps (on different continents preferably) which act as mysql slaves of the hidden...

The /var/run/mysqld is created with mysqld's initialize fase when it starts. Thats because of the FHS standard that some dictates that /run/stuff should be deleted and recreated. (IIRC)

Wait, the /var/run/ directory is located on the root fs. Even though /run/ should be gone (tmpfs), /var/run/ shouldn't be.

Is the /var/run/ mounted as tmpfs? This is done very often als the */run/ is only for running processes and at reboot there are none yet.

Seems like you have a different socket path in one of your mysql config files. Maybe a rogue ~/my.cnf somewhere? A host : port type of connection in one file and a socket=/bla/bla somewhere else?

Still no answer, but removing the ssl vhost in /etc/httpd/conf/ips.conf seems to fix it so far that roundcube on ipv6 works again...

I noticed it works on a centos 8 setup and on a little older centos 7 it failed. The newer one also does a 301 to change /roundcube to /roundcube/ (trailing slash). So the older one ends up in the wrong place somehow... Where the failing response is a 404: # wget -6 https://server1/roundcube...

Yes. ipv6 is working, also for aliases like /phpmyadmin, just not when it's '/roundcube'. On ipv4 RC works. Weird eh?

Bump. Still having the same issues. :( access_log:2a01:xxx:45dd - - [15/Nov/2021:16:32:58 +0100] "GET /roundcube HTTP/1.1" 404 3590 "-" "Wget/1.19.5 (linux-gnu)" access_log:2a01:xxx:45dd - - [15/Nov/2021:16:33:16 +0100] "GET / HTTP/1.1" 200 3644 "-" "Wget/1.19.5 (linux-gnu)" Update: This...

Not sure if it's related, but a number of customers with different client setups report 404 errors when trying to login into roundcube, either via DA or directly at /roundcube/. Others, me included, experience no error at all.

Yups, I've seen it on LFD too.

You still might have a php 5.6 roaming around on the server. The error is caused bij the '??' operator which was introduced in php 7.0.

Here too It's the null coalescing operator which is added in php 7.0. This is probably on systems that still have a php 5.6.x installed. You can change line 33 of /usr/local/directadmin/plugins/custombuild/admin/tabs/edit_options.php to $group[$key] = isset($value['current']) ...