DirectAdmin v1.659

@gate2vn we were not able to reproduce the issue on our test machines. It would be best to open a support ticket to check out if this is something specific to your server.
 
We have noticed something different with v1.659 regarding the Auto-SSL requests. It seems that by default the script tries to request a wildcard SSL-certificate. Only after 2 failed attempts, it changes to file-validation for all known (sub)domains:


system.log:

Code:
2024:02:06-11:18:44: User test is being created by <redacted>.
2024:02:06-11:30:11: LetsEncrypt(32427): exit code: 1 for domain='test.<redacted>'
2024:02:06-11:41:46: LetsEncrypt(4554): exit code: 1 for domain='test.<redacted>'
2024:02:06-11:42:33: LetsEncrypt(4554): exit code: 0 for domain='test.<redacted>'

acme_provider_cert_logs - 11:30

Code:
2024/02/06 11:30:16 Could not obtain certificates:
        error: one or more domains had a problem:
[ftp.test.<redacted>] [ftp.test.<redacted>] acme: error presenting token: could not start HTTP server for challenge: listen tcp :80: bind: address already in use

acme_provider_cert_logs - 11:41

Code:
2024/02/06 11:30:41 [INFO] [*.test.<redacted>] acme: Trying to solve DNS-01
[test.<redacted>] time limit exceeded: last error: NS ns2.<nameserver>.nl. did not return the expected TXT record [fqdn: _acme-challenge.test.<redacted>., value: 11dFxeaAznFwZWyZWW4vdzWqZSEy86IY_ywtGhL3YlM]:
Failed to issue new certificate

acme_provider_cert_logs - 11:42

Code:
2024/02/06 11:42:20 [INFO] [test.<redacted>] acme: Trying to solve HTTP-01
2024/02/06 11:42:26 [INFO] [test.<redacted>] The server validated our request
  Validations succeeded; requesting certificates

We don't use the DNS-server on our DirectAdmin servers, because we have external nameservers for all our (customers) domains. Is there an option to skip the request of the wildcard in the first place, since it will allways fail?
 
@SanderJ, thanks for feedback and explaining your use-case. Admin-SSL used to prefer wildcard domains in previous releases as well, so I am not sure if it is related to this release. Anyway it would be good to check out this use case further and see if we could make it work smoother.

If you are using external DNS servers what kind of mechanism do you use to propagate new DNS records when user creates a subdomain, or make changes to DNSSEC or mail settings (MX, SPF, DKIM)?

A small update to DA 1.659 is released to update OpenLiteSpeed download URL. We used to download it directly from upstream, but OLS does not keep older versions available, so we added a fall-back to our mirrors.
 
We don't have any link between our DirectAdmin servers and our DNS-management. We have disabled the DNS-mangement option in DA on most servers. I have checked the system.log on the same server, and noticed that with DA 1.658 there was no attempt to request a wildcard SSL-certificate:

DirectAdmin 1.658 build cf601b4c3b84c86f803fa9128c5dc50c8a2a72a8

Code:
2024:01:16-14:09:20: Domain <domain_redacted> is being created via creation of User account
2024:01:16-14:11:13: LetsEncrypt(22782): /usr/local/directadmin/scripts/letsencrypt.sh request '<domain_redacted>' 4096 /usr/local/directadmin/data/users/jxffudvbpf/domains/<domain_redacted>.ssltmpRxLvON
 /var/www/html
2024:01:16-14:11:32: LetsEncrypt(22782): exit code: 0 for domain='<domain_redacted>'
2024:01:16-14:11:32: Ssl::save_cert_post: swapping snidomains: <domain_redacted>=(null) with <domain_redacted>=jxffudvbpf:<domain_redacted>
2024:01:16-14:11:32: Ssl::save_cert_post: swapping snidomains: www.<domain_redacted>=(null) with www<domain_redacted>=jxffudvbpf:<domain_redacted>

So it appears that with the latest release something did change in this process. Could this be related to the option "Manual Trigger: If used and successful, it will automatically set the mode to best match." which is set to "Wildcard" by default?
 
Hi,

This update includes

Code:
    openlitespeed updated from 1.7.19 to 1.7.19.1

But this version has been removed from github

Code:
# curl -I https://github.com/litespeedtech/openlitespeed/releases/download/v1.7.19.1/openlitespeed-1.7.19-x86_64-linux.tgz
HTTP/1.1 404 Not Found
Server: GitHub.com
Date: Tue, 06 Feb 2024 15:13:28 GMT

OLS version must be changed to 1.7.19.2


Regards
 
@dmtinc, yes this is why an update is already released. DA 1.659 still uses 1.7.19.1 as preferred OLS version, but if it fails to download from github it will fallback to our mirrors. OpenLiteSpeed 1.7.19.2 will be available on the alpha release channel tonight if it passes our integration test suite for all distros.
 
An update is released with speed improvements for database create and delete operations. Speed improvement should be noticeable for accounts having hundreds or more databases.

@SanderJ what is the value of admin_ssl_default_wildcard in DA config? You can check it with da c | grep wild.
 
@fln Thanks for pointing me in the right direction!

admin_ssl_default_wildcard was not set directadmin.conf, so the default value of 1 was being used.

Changing the value to 0, and restarting directadmin solved the issue.
 
Can you please make Evolution more mobile friendly? On the file manager, Every time I edit files it seems to zoom in and out etc. on the latest Android Chrome browser. Thank you and I appreciate your dedication to working on this control panel.
 
Seeing this update but I can't update these 3 now ?

EximUpdate4.96.2-12-g29d01ae2a4.97.1
PHP 8.2Update8.2.118.2.15
PHP 8.1Update8.1.248.1.27
 
Yeah I did. But can't update these 3

Exim:

make[1]: Leaving directory `/usr/local/directadmin/custombuild/tmp/tmp.siJoWdDIrK.exim-4.97.1.tar.gz/build-Linux-x86_64'
make[1]: *** [exim] Error 1
make: *** [all] Error 2
doExim: failed to compile '/usr/local/directadmin/custombuild/cache/exim-4.97.1.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.siJoWdDIrK.exim-4.97.1.tar.gz'
failed to compile exim 4.97.1

PHP 8.2

checking if iconv supports errno... no
configure: error: iconv does not support errno
install_php: failed to compile '/usr/local/directadmin/custombuild/cache/php-8.2.15.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.dGXirOhYmM.php-8.2.15.tar.gz'

PHP 8.1

checking if iconv supports errno... no
configure: error: iconv does not support errno
install_php: failed to compile '/usr/local/directadmin/custombuild/cache/php-8.1.27.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.VDa4i1hqXZ.php-8.1.27.tar.gz'
 
About "staging".


maybe it could have text like "non-production",
some client don't know if it can use or not, and they just use without thinking.
Well, I think Let's Encrypt calls it staging so that's why it's referred to as staging.

But this honestly should probably be an option that is not easy for customers to find, or I'm not really even sure what the value of having a menu for this is.

The people that need to use staging are going to know that they need to use staging. For everybody else, they just need production. Give users too many options and they're bound to click on them and see what they do and complain when something doesn't work right.

Chances are... if you're someone that needs staging... you know how to do this without a GUI menu telling you what to do.

I'm not really sure where this option is available. But if it's available for end-users (not admin, not resellers) then I question if it's needed. At the very least it needs to be able for the admin to choose to display this or not.
 
Yeah I did. But can't update these 3
Did you try this before updating?

Most straightforward way to clean-up old system would be:
  1. da build remove_items - remove all libraries except iconv.
  2. da build remove_old_local libiconv - remove iconv.
  3. da build all - rebuild everything. Note: after iconv is removed, but before everything is rebuilt some services will not work if restarted.

A more cautions approach minimizing service downtime could be:
  1. da build list_removals - check how many of the old libraries there are, useful if any of them needs to be restored.
  2. da build remove_items - remove all libraries except iconv.
  3. da build remove_old_local libiconv - remove iconv and create backup (actually only to create backup :)).
  4. da build restore_old_local libiconv - restore back iconv so that all existing software would work fine for the time being.
  5. rm -f /usr/local/include/{iconv.h,libcharset.h,localcharset.h} - remove only iconv headers (we still have full iconv backup just in case)
  6. da build all - rebuild everything, iconv from /usr/local should not be used by the rebuit software
  7. da build remove_old_local libiconv - remove iconv for good now.
 
Back
Top