Search results

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']) ...

I can not check the version on the spamexperts server as that is far out of my reach. But it seems like the remote server can not validate the directadmins server certificate for a domain.

Anybody have an idea? The domain has a valid letsencrypt cert on the domain, including the www and mail. 2021-09-13T22:15:30.149+02:00 spamexperts d6fe6b981c2315c79b41cac35f30b1e9: INFO "1mPkhB-00038K-Ou","com-mpt-out002.mailprotect.be","mydomain.com","info","queued","2021-09-13...

Hmm, still failing on CentOS 7.9 here. Installing clamav 0.104.0 ... Found /usr/local/directadmin/custombuild/clamav-0.104.0.tar.gz Extracting ... Done. Configuring clamav 0.104.0 ... /usr/local/directadmin/custombuild/custom/clamav/configure.clamav: line 2: ./configure: No such file or...

Try: yum install libarchive before running ./build versions. This fixed it for me on Centos 8.3+

I had the same issue. Choose the 'refreshed' and looks like I'm unable to switch back. Als damn hard to find the options :)

Still same issues... :/