DirectAdmin v1.673

[fln]

I've gone into all my servers to clean up old configurations and move everything into the custom folder. Just a warning if anyone else is scratching their head why all sites are down.

Thanks for sharing this. The expected way to customize apache configs is to add customized version of configs in the /usr/local/directadmin/custombuild/custom/ap2/conf/extra directory. This way of customizing apache works with all DA versions.

We no longer ignore config file install errors to make sure we terminate the script if there are serious problems with the server - for example disk is full, of FS is corrupted. We are continuously making CB more reliable by not ignoring fatal errors.

 

[kevinb]

Thanks for sharing this. The expected way to customize apache configs is to add customized version of configs in the /usr/local/directadmin/custombuild/custom/ap2/conf/extra directory. This way of customizing apache works with all DA versions.

We no longer ignore config file install errors to make sure we terminate the script if there are serious problems with the server - for example disk is full, of FS is corrupted. We are continuously making CB more reliable by not ignoring fatal errors.

That is fine but the script doesn't actually warn you that it didn't complete. It warns about not copying the httpd-info.conf and then nothing else. It also deletes the directadmin-vhosts.conf without creating a backup file. There is some logic missing from the changes.

A better option might be to do a sanity check first, see if any files are customized, warn the user and wait for them to move to the custom folder.

 

[fln]

CustomBuild creates directadmin-vhosts.conf file on the fly as part of apache reconfiguration process. As soon as file-system errors are resolved (for example disk being full or files being inaccessible due to immutable flag) running da build rewrite_confs will re-create the directadmin-vhosts.conf file.

DirectAdmin never supported making files immutable as a way of customizing configs. Users of immutable flag just abused the fact that CustomBuild was careless about runtime errors. Not failing if file is immutable is not a feature, it is a bug. From CustomBuild perspective all customizations lives in the custom directory.

 

[kevinb]

CustomBuild creates directadmin-vhosts.conf file on the fly as part of apache reconfiguration process. As soon as file-system errors are resolved (for example disk being full or files being inaccessible due to immutable flag) running da build rewrite_confs will re-create the directadmin-vhosts.conf file.

DirectAdmin never supported making files immutable as a way of customizing configs. Users of immutable flag just abused the fact that CustomBuild was careless about runtime errors. Not failing if file is immutable is not a feature, it is a bug. From CustomBuild perspective all customizations lives in the custom directory.

Bash help | Directadmin Docs

DirectAdmin Knowledge Base

docs.directadmin.com

1) Fix your Documentation
2) Fix CustomBuild to actually report Success/Failure on Rewrite

 

[Richard G]

DirectAdmin never supported making files immutable as a way of customizing configs.

Sorry, but that statement is not quite correct. Maybe this goes for most files, but there are some files like the httpd.conf which are supported by making them immutable and is even still mentioned in the docs as you can see here in point 3.

 

[fln]

@kevinb thanks for the hint about the docs. Now I see how this pattern of using chattr +i have propagated among the DA users.

At the moment CB reports failures by terminating with a non-zero exit code and printing the message about failure. This particular problem would look like this:

# da build rewrite_confs
mv: cannot move '/etc/httpd/conf/extra/tmp.y1CKIICM1w.httpd-info.conf' to '/etc/httpd/conf/extra/httpd-info.conf': Operation not permitted
install_custom_file: failed to rename '/etc/httpd/conf/extra/tmp.y1CKIICM1w.httpd-info.conf' to '/etc/httpd/conf/extra/httpd-info.conf'
# echo $?
1

Not sure what kind of additional message you would like to see.

Anyway postponing the directadmin-vhosts.conf update after main configs rewrite would be a good improvement to keep apache functional.

 

[kevinb]

@kevinb thanks for the hint about the docs. Now I see how this pattern of using chattr +i have propagated among the DA users.

At the moment CB reports failures by terminating with a non-zero exit code and printing the message about failure. This particular problem would look like this:

# da build rewrite_confs
mv: cannot move '/etc/httpd/conf/extra/tmp.y1CKIICM1w.httpd-info.conf' to '/etc/httpd/conf/extra/httpd-info.conf': Operation not permitted
install_custom_file: failed to rename '/etc/httpd/conf/extra/tmp.y1CKIICM1w.httpd-info.conf' to '/etc/httpd/conf/extra/httpd-info.conf'
# echo $?
1

Not sure what kind of additional message you would like to see.

Anyway postponing the directadmin-vhosts.conf update after main configs rewrite would be a good improvement to keep apache functional.

Warning: The Rewrite Rules did not complete - Please check for errors.

The error currently, is very similar to what I would of seen in the past. Exiting with a non-zero code is great, except it isn't displayed unless you run another shell command.

 

[fln]

The fact that immutable flag was referenced in the docs changes the situation. We will release an update to handle such cases in a better way. Thanks.

 

[fln]

An update is released to add an extra error message if rewrite_confs operation failed. Also the order in which configs are updated are changed to start with static files, before updating files that will be further updated in next steps (for example directadmin-vhosts.conf).

This will not prevent or avoid problems on servers that used immutable flag on configs in /etc/httpd, but should keep apache functional until the problem is resolved by moving customized files into the /usr/local/directadmin/custombuild/custom/ap2/extra directory.

 

[kristian]

Exiting with a non-zero code is great, except it isn't displayed unless you run another shell command.

Just a super sidetrack comment here. I have my bash prompt show me the last error code if non-zero. It is a very useful piece of information to just have available. Exactly how you want to do this depends on how you build up your prompt, but something like this would insert the non-zero error code in front of your existing prompt:

PS1="\$(ec=\$?; if [[ \$ec -ne 0 ]]; then echo \"\$ec \"; fi)"${PS1}

 

[fln]

One more update is released. It fixes old modsecurity library version detection. Without the fix CustomBuild does not show that an update to modsecurity package is available.

 

[Strator]

We no longer ignore config file install errors.

DirectAdmin never supported making files immutable as a way of customizing configs.

fln, since you're stating this almost like a religious dogma, could you please make sure these things actually work BEFORE closing the loopholes we got used to over the years? Tricks like immutable log files is what the older members here learned the hard way, when the expected way to alter configs didn't work and so we ultimately ended up altering what to expect.

To give an example, changing daemon_smtp_ports or tls_on_connect_ports via exim.variables.conf.custom still doesn't work, even though the comments suggest otherwise, you need to edit exim.variables.conf directly and then make it immutable. Paving the path is surely the best way of changing the habits of old.

 

[romans]

fln, since you're stating this almost like a religious dogma, could you please make sure these things actually work BEFORE closing the loopholes we got used to over the years? Tricks like immutable log files is what the older members here learned the hard way, when the expected way to alter configs didn't work and so we ultimately ended up altering what to expect.

To give an example, changing daemon_smtp_ports or tls_on_connect_ports via exim.variables.conf.custom still doesn't work, even though the comments suggest otherwise, you need to edit exim.variables.conf directly and then make it immutable. Paving the path is surely the best way of changing the habits of old.

About customization of those 2 EXIM options.
I had:

[root@server2 ~]# exim -bP tls_on_connect_ports
tls_on_connect_ports = 465
[root@server2 ~]#
[root@server2 ~]# exim -bP daemon_smtp_ports
daemon_smtp_ports = 25 : 587 : 465
[root@server2 ~]#
[root@server2 ~]# lsof -Pp 1423284 | grep TCP | head -3
exim    1423284 mail    4u     IPv4            7929820      0t0     TCP localhost.localdomain:25 (LISTEN)
exim    1423284 mail    5u     IPv4            7929821      0t0     TCP localhost.localdomain:587 (LISTEN)
exim    1423284 mail    6u     IPv4            7929822      0t0     TCP localhost.localdomain:465 (LISTEN)
[root@server2 ~]#

then I added new random values here:

[root@server2 ~]# tail -2 /etc/exim.variables.conf.custom
daemon_smtp_ports=24 : 587 : 469
tls_on_connect_ports=469
[root@server2 ~]#

Run this command:

da build exim_conf

and I see the following results:

[root@server2 ~]# exim -bP daemon_smtp_ports
daemon_smtp_ports = 24 : 587 : 469
[root@server2 ~]#
[root@server2 ~]# exim -bP tls_on_connect_ports
tls_on_connect_ports = 469
[root@server2 ~]#
[root@server2 ~]# lsof -Pp 1423921 | grep TCP | head -3
exim    1423921 mail    4u     IPv4            7933476      0t0     TCP localhost.localdomain:24 (LISTEN)
exim    1423921 mail    5u     IPv4            7933477      0t0     TCP localhost.localdomain:587 (LISTEN)
exim    1423921 mail    6u     IPv4            7933478      0t0     TCP localhost.localdomain:469 (LISTEN)
[root@server2 ~]#

It seems it works fine for me.
Or I made the customization not in the way you did and expected ?

 

[Strator]

Run this command:

da build exim_conf

Ok, I'm having a big slice of humble pie. But seriously, how are you supposed to guess that, instead of restarting exim, you need to rebuild exim.conf? Knowing what to look for, I found this here - hence the humble pie - but if I hadn't known beforehand, I never would have.

Glad I came to the wrong thread to nag about it (and thanks for enlightening me). And now, please continue discussing DirectAdmin.