DirectAdmin v1.649 has been released

FBP said:
Is directadmin officially stopping the support of custom skins by taking this action?
Click to expand...
No - custom skins are still supported but the legacy skin system does not get any new features. Legacy skins are superseded by Evolution customizations system. You can customize Evolution to look differently without installing new skins.

New features are available via API so you still prefer to use legacy skins rather than customized Evolution you can always access new features via API by writing some JavaScript code in your skin. All new API endpoints are documented in the swagger (Open API) format.
 
yesterday my directadmin updated automatically to v1.649,
i get this error when accessing login page, how to fix this error.

Screenshot (193).png
 
hi @adamda, this file is part of the DA upgrade package. Most likely you have an incomplete installation, please make sure you have enough disk space and try executing command:

Code: 
da update --force

It will re-install all the files.
 
Vacation Messages setting is not working with default Core and Email_only feature sets. I need to add emailvacation to commands.allow in /usr/local/directadmin/data/templates/feature_sets/email_only/

Should it be ready there for Vacation Messages working by default?
 
  • Like
Reactions: fln
Another bug for autoresponder for email containing languages such as Japanese, Korean, Vietnamese...
It looks like the charset=UTF-8 is only set for the email body, not the subject. So if antispam filters check subject of autoresponder, the message will be blocked. Tested with both Enhanced and Evolution skins. So I assume it is something in the DA core?
 
Thanks for feedback @gate2vn. Feature set email_only is updated in DA 1.650 to allow email vacation actions.

As for the issue with UTF-8 subject is a bit tricky. It is not a regression but a feature request. Existing implementation does not specifically encode subject by RFC2047 rules. However RFC6532 allows UTF8 without specific encoding to be used in email headers. In practice it is supported by many email servers and in our tests we have successfully created vacation responders with UTF8 symbols in subject. It worked fine for gmail and a couple of different email providers.

Most of mailing list providers uses RFC2047 for subjects containing UTF8 subjects. So this approach is safer for maximum interoperability. Still it seems support for RFC6532 is already quite widespread. @gate2vn could share which email providers or email server software caused you issues with emails where subjects contains unencoded UTF8?
 
I have SpamExperts checking all emails, and those unencoded-subject messages are blocked.
For Enhanced skin, it seems changing the value of LANG_ENCODING in /usr/local/directadmin/data/skins/enhanced/lang/en/lf_standard.html to UTF-8 helps. But I don't know where in Evolution skin?
 
@gate2vn thanks, for feedback. Evolution always uses UTF-8 encoding so no modifications are needed to store vacation messages in plain UTF-8.

Another update 1.649 is now pushed out to stable release channel, it includes updates to CB software component versions.
 
The latest hotfix is just automatically installed on one of our servers. We noticed that a suspended MySQL-user was removed. Client was able to fix the issue manually. Did the hotfix change anything regarding mysql, databases or users? We didn't find anything in the logs that indicated that the user was removed manually.
 
No the only change in the latest release is in custombuild/versions.txt file.

Anything else could be just side effects of DA restarting after update or some generic maintenance being performed by dataskq (same actions that are always being performed on update, visible in the scripts/update.sh).

On update DA performs the following tasks:

Code: 
action=cache&value=showallusers
action=cache&value=safemode
action=convert&value=cronbackups
action=convert&value=suspendedmysql
action=syscheck

I would suspect action=convert&value=suspendedmysql you can try executing this task manually with da taskq --run 'action=convert&value=suspendedmysql' to see if the account would be removed again. Please note that this action is being performed on any DA update since 2013. Since the same action is being performed for the last 10 years I suppose it could be something related to the DBMS you use. Could you give us more details which MySQL/MariaDB version are you using?
 
fln said:
No the only change in the latest release is in custombuild/versions.txt file.

Anything else could be just side effects of DA restarting after update or some generic maintenance being performed by dataskq (same actions that are always being performed on update, visible in the scripts/update.sh).

On update DA performs the following tasks:

Code: 
action=cache&value=showallusers
action=cache&value=safemode
action=convert&value=cronbackups
action=convert&value=suspendedmysql
action=syscheck

I would suspect action=convert&value=suspendedmysql you can try executing this task manually with da taskq --run 'action=convert&value=suspendedmysql' to see if the account would be removed again. Please note that this action is being performed on any DA update since 2013. Since the same action is being performed for the last 10 years I suppose it could be something related to the DBMS you use. Could you give us more details which MySQL/MariaDB version are you using?
Click to expand...

Thanks for clearing this up! That explains why the suspended user was removed right after the update. Good to know which tasks are being run after the update, in case we have any issues after an update.
 
@SanderJ please note that action=convert&value=suspendedmysql should NOT remove suspended DB accounts. What it actually does is it tries to migrate users from a very old style of user account locking (where user would be stripped of its privileges) to a modern user locking mode (setting LOCKED flag or changing password). So the migration action tries to restore privileges if suspended user seems to have lost them and ensures it is still suspended using new mechanism (it depends on DMBS version).

So it would be great to get to the bottom of this and find out the root cause why account seem to have vanished. Since same account locking queries are being used when account is suspended or unsuspended this accident might be a symptom of some deeper problem.

Since the old locking style was used very long time ago (older than DA 1.44.0 released in 2013) it is safe to stop performing this migration step completely. At this stage there should be no live DA instances that have not yet migrated.
 
i get ionCube upgrade notification,
like when i did the upgrade i got this message
"
There is no ionCube loader available for PHP 8.2.
Restarting php-fpm82
"
what is this error and what should i do to fix it.
Please just me thanks.
 
@cap4a ionCube CB issue is not related to the DA 1.649 release, it was present in earlier versions as well and was fixed in DA 1.650 which is currently in beta release channel.
 
Thanks @fln.
So I just need to wait for the next official release and the upgrade notification error will be fixed, right?
 
It appears that in DA 1.649 the ability to use custom login page:

Login page | Directadmin Docs

DirectAdmin Knowledge Base
docs.directadmin.com

Version 1.20.4 | Directadmin Docs

DirectAdmin Knowledge Base
www.directadmin.com

with evolution skin was also removed. Files:

/usr/local/directadmin/data/templates/custom/login.html
/usr/local/directadmin/data/templates/login.html

are not working anymore. No more real customization.
 
You must log in or register to reply here.
Back
Top