DirectAdmin v1.657

Zhenmue said:
its extremely frustrating the amount of cases we have of clients loosing their SSL's, not renewing automatically them. and support is very unfriendly and slow.

am i the only one? we have few clients every week with SSL alert because their SSL was not renewed? s:
Click to expand...
I'm so glad that I'm not the only one with SSL issues.

I have a ticket with John and we're currently trying out a custom ZeroSSL integration that allows the use of the paid ZeroSSL plans (the ones without rate limits).

So far, we've seen less issues but they still seem to pop up.
 
I have the same problem with no response from DA support. I checked in several server this realese and users can’t be able to use procedure lost password so this situation is not comfortable for admin because I have to sent password to each that requist.
 
Jamie@DreamIT Host said:
I'm so glad that I'm not the only one with SSL issues.
Click to expand...
I'm not a specialist in this, but I'm just wondering if a TTL record of 5 seconds is enough, if it should not be a bit longer?

This is in the letsencrypt.sh script:
Code: 
${DA_BIN} taskq --run "action=dns&do=add&domain=${DOMAIN_TO_USE}&type=TXT&name=_acme-challenge&value=\"${3}\"&ttl=5&named_reload=yes"
results in the named.db file in:
Code: 
$TTL 5  ; 5 seconds
_acme-challenge         TXT     "p-9S77zYxxxxxxxxx"
I can be mistaken and I'm not sure but I thought this value was 5 minutes. But I can be wrong.
 
I found one more bug. I have added MFA but after 7-10 days browser again require add code from app however I checked Trust this device for 30 days and I didn't cache cookies from browser. I had to write code from app again, but code doesn't work and I had to create Two step Authentication again. The same situation is my third try when I have an issue with MFA.
 
Last edited:
pat0 said:
I've also accidentally noticed some strange behavior in the latest current and stable when it comes to passwords - changing passwd on ssh doesn't automatically logout user from Directadmin which has always happened in previous version.
Click to expand...
This is expected. If you have an active session changing password does not automatically log-it out.

If you are changing the password because it could have been leaked you can kill all active sessions in the user profile page.
 
Thanks for reporting password reset issue @inomi13. We have released a hot-fix to the current release channel to fix password reset feature on Evolution skin.


Richard G said:
Any clue on the other password issue?
Click to expand...

Password change after FTP and main account password desync issue is not new, but we will look into this, thanks.
 
@fln hotfix resolve an issue with lost-password feature but still exist an issue with translate. Screen below. I added custom transtalate in /usr/local/directadmin/data/skins/evolution/lang/custom and almost string I can be able to customize but this text I can't be able. When I set another languge for example german or french this text still apears in english. The same an issue I found in several servers which have another release DA.

lol.jpg
 
I have updated directadmin to version 1.657 and I realized that the update has deleted files in the /usr/local/directadmin/scripts/ directory, specifically it deleted the backup_data.sh file, on all my servers that I have applied the update the file was deleted backup_data.sh file in the /usr/local/directadmin/scripts/ directory.

Can someone explain to me why this happens? It didn't happen before.
 
@exemaco, this is because of the following change:

Version 1.657 | Directadmin Docs

DirectAdmin Knowledge Base
docs.directadmin.com

Please make sure to keep all custom files in special directories (for example /usr/local/directadmin/scripts/custom for scripts). We need to be able to cleanup DA owned files to support removing no longer used content. Without this change /usr/local/directadmin grows forever with no longer used/relevant scripts, templates and other files.
 
On all of our servers, the update to 1.657 seems to have deleted our custom feature sets in /usr/local/directadmin/data/templates/feature_sets/. The user packages reverted to 'allow all commands' under feature sets, so all users could access lots of things they shouldn't have been able to!! Anyone else have this issue?
 
@jigster, please make sure all custom feature sets are stored in /usr/local/directadmin/data/templates/custom/feature_sets. Non custom directory is reserved for feature sets that gets bundled with DA. Directory /usr/local/directadmin/data/templates/feature_sets is cleaned up as part of DA update.
 
@fln thanks. The documentation here doesn't seem to reflect this which is confusing, maybe that could be updated. Do we need to keep the custom feature sets ONLY in /usr/local/directadmin/data/templates/custom/feature_sets (and not in /usr/local/directadmin/data/templates/feature_sets as well)? And do we need to run anything to propagate any changes in /usr/local/directadmin/data/templates/custom/feature_sets to become live? Thanks
 
Richard G said:
You might need to do a bit of better reading.
Click to expand...
Thanks, I did read it carefully. I don't wish to quibble over semantics but I understood the text to mean you can add custom sets to /usr/local/directadmin/data/templates/feature_sets (which is actually NOT where they should go), or add sets to /usr/local/directadmin/data/templates/custom/feature_sets/ to override the default ones. The wording is ambiguous, and I'm sure others will misinterpret this too, hence why I suggested the wording be updated to be more clear, so there's no ambiguity.
 
jigster said:
but I understood the text to mean you can add custom sets to /usr/local/directadmin/data/templates/feature_sets
Click to expand...
You forget to look at part of the text. There is really nothing ambigious about it. And I'm not even native English. ;)
Custom sets can be added to this path using different names, OR
Click to expand...
It's quite clear, either the feature is in the feature_sets directory under a different name, or you use the same name in a custom directory.
Anyway, this is indeed nothing to discuss here, but as said, I don't see any unclearness in this.
 
Richard G said:
You forget to look at part of the text. There is really nothing ambigious about it. And I'm not even native English. ;)

It's quite clear, either the feature is in the feature_sets directory under a different name, or you use the same name in a custom directory.
Anyway, this is indeed nothing to discuss here, but as said, I don't see any unclearness in this.
Click to expand...
I think it's unclear whether "this path" in the text refers to the path stated before or after that sentence. No worries, happy to agree to disagree!
 
You must log in or register to reply here.
Back
Top