DirectAdmin 1.640 has been released

Many thanks to fln ! That happens when a customer decides to change the server certificate on his own !
A restore of exim.cert and exim.key from the backup solved the issue once fln pointed the error.

The good point is that the server has been upgraded from Debian 9 to Debian 10 !
 
Can someone also fix the HTML code text in the progress page when creating a backup? (See image)
It has been there a long time already.
 

Attachments

  • html in view.jpg
    html in view.jpg
    420.1 KB · Views: 33
Just faced up with one more issue:
Fresh install on Ubuntu 20.04 Nginx+Php-Fpm (without Apache)
exim didn't started due to next setting in /etc/exim.variables.conf:
trusted_users=mail:majordomo:apache:diradmin
after replacing apache to nginx we have:
trusted_users=mail:majordomo:nginx:diradmin - and all working
Please add both to default conf or check why it's not autodetected, thanks!
 
One suggestion that would be nice, on the Updates page where it shows the Update Channel, if that in addition to just showing the channel name, next to the channel name (inside the pull down box) show the current version that is available from the server and if it's an upgrade from the installed version. So when you click the pull down box you can see at a glance that another channel has received an update (good for when your using say beta channel to test a feature/fixes, and then latest beta moves to stable, then can move to that to get back off the beta channel).

Second, login timeout is annoying. It used to just timeout and go back to the login page (preferred). Now it seems to just stay on a page forever until you click on something else and then send you to the login page, as the session was timed out. Would really like the old behavior back, it has confused some customers, and leaves possibly information on screen after timeout you don't want people to see.

Using Evolution Skin, Standard Layout. I haven't checked it in any other skins or layouts.

@smtalk @fln
 
There appears to be a bug relating to USER level MX Record changes. I have a few users reporting that MX templates (selecting Google MX for example), and pressing save results in an "Options Saved" dialog appearing but no actual changes take place.

EDIT: Adding records in this interface manually does appear to work. It's just the templates that aren't working.

Can anyone @ DA confirm?

Strike this! I was using the wrong save button.
 
Last edited:
@fln
Could you also fix the login keys display?

Currently I cannot see the allowed IPs at all. And allowed calls are bugged and blocked calls is a giant list. (See attachment.)
 

Attachments

  • image2.jpeg
    image2.jpeg
    137.9 KB · Views: 16
  • image.jpeg
    image.jpeg
    131.3 KB · Views: 18
  • Like
Reactions: fln
fln said:
Hi @paulonichio would you be willing to share translation file with community? If you would send me the PO file I would import it to our community translation system at https://translate.directadmin.com. If you would create account there you could also update the outdated translations yourself as well.

If you want to use your old translations without sharing you need to create a new file at data/skins/evolution/assets/translations/custom/pt_BR.json.

Using DA to convert it from JSON you can achieve it with curl -k -s "$(da root-auth-url)/CMD_JSON_LANG?json=yes&lang=pt_BR" > /usr/local/directadmin/data/skins/evolution/assets/translations/custom/pt_BR.json
Click to expand...

Hi, i have the translation file pt_PT.json in /usr/local/directadmin/data/skins/evolution/assets/translations and in /usr/local/directadmin/data/skins/evolution/assets/translations/custom but it does not appear in the control panel for the client make the change.

I also have made:

curl -k -s "$(da root-auth-url)/CMD_JSON_LANG?json=yes&lang=pt_PT" > /usr/local/directadmin/data/skins/evolution/assets/translations/custom/pt_PT.json

and still no good

Have tried perl -pi -e 's/language=en/language=pt_PT/' /usr/local/directadmin/data/users/*/user.conf to force te change in all the clients but still in the default language (english)

any help?

Thanks
 
hi @jmmm, current Evolution skin does not support adding additional languages. Only existing language files can be replaced or updated. For example if you placed pt_PT.json contents as pt_BR.json it would be visible when one selects pt_BR.

Based on the language tag it seems you would like to add Portuguese (Portugal) language file. In our shared translations platform at https://translate.directadmin.com Portuguese (Portugal) is barely translated and therefore not included in the distribution bundle. If you would to share your pt_PT translation PO file, I could import it into online translation system. Then it it would get released with Evo in the next DA release and no language file replacements would be needed..
 
fln said:
hi @jmmm, current Evolution skin does not support adding additional languages. Only existing language files can be replaced or updated. For example if you placed pt_PT.json contents as pt_BR.json it would be visible when one selects pt_BR.

Based on the language tag it seems you would like to add Portuguese (Portugal) language file. In our shared translations platform at https://translate.directadmin.com Portuguese (Portugal) is barely translated and therefore not included in the distribution bundle. If you would to share your pt_PT translation PO file, I could import it into online translation system. Then it it would get released with Evo in the next DA release and no language file replacements would be needed..
Click to expand...
Hi @fln thanks but that i not my question.... before in 1.639 (and earlier) we have the pt_PT language correctly working with no problem at all in /usr/local/directadmin/data/skins/evolution/lang

But now after the (auto) update to 1.640 version the Portuguese Language (pt_PT) does not appear in the control panel

My question is how can i make it appear in the control panel. I dont want to replace pt_PT for pt_BR or backwards, i just want that pt_PT appears (or both)

What i need to do?

I still have the files in /usr/local/directadmin/data/skins/evolution/lang ; /usr/local/directadmin/data/skins/evolution/assets/translations/custom and /usr/local/directadmin/data/skins/evolution/assets/translations/

Thanks
 
Yes. Having additional languages (not bundled with Evolution on install) is no longer supported starting DA 1.640. We are trying to consolidate all the translation files into central translation repository that would be released with each DA update. It is still possible to replace translations for existing languages but it is not possible to create new languages.

We would really appreciate if you would share your translations with everyone, so that we could release it with the next DA version.
 
OK @fln, this change was not a good change... at this time we have cliets that are asking why the control panel has changed the language and they cant find Portuguese (Portugal)...

Can you please help-me and point-me for a solution?

Can i use my pt_PT file and rewrite the pt_BR ?

then use the command "perl -pi -e 's/language=en/language=pt_BR/' /usr/local/directadmin/data/users/*/user.conf" to globally change the language in users to pt_BR?

Thanks
 
Yes. Quick and dirty solution to fix it immediately would be dump pt_PT translations over pt_BR and change language to pr_BR:

Code: 
curl -k -s "$(da root-auth-url)/CMD_JSON_LANG?json=yes&lang=pt_PT" > /usr/local/directadmin/data/skins/evolution/assets/translations/custom/pt_BR.json
perl -pi -e 's/language=.*/language=pt_BR/' /usr/local/directadmin/data/users/*/user.conf

If we had a good quality translation of pt_PT available in translate.directadmin.com it would get released with new DA versions and there would be no need to use pt_BR as a substitute language. Sharing the translation improvement efforts with other community members would help to get new features translated changed translations updated quicker.
 
Quick update, we have re-packaged the latest 1.640 release to include a hot-fix for setting correct /home/tmp permissions on fresh DA installs. Latest build ID is now 8c3f499aab9e9b51feb3e1fcb07de4138c858f67.
 
@quags we could introduce a special variable in directadmin.conf to enable such mode. However I think it only hides the real issue instead of fixing. Could you give me more details why would you like to keep only one instance of dataskq running?

Even if single dataskq instance takes quite some time to execute it truncates the task log so that subsequent concurrent dataskq calls will have nothing more to do. Strictly serializing all dataskq calls is trivial to implement but could have a very nasty consequences. For example if you start a backup for a huge account it could take hours to finish, with concurrent dataskq disabled all other actions would be stuck until the large backup or restore job gets finished.

If you are worried about multiple backup jobs running concurrently you can limit them to with the max_concurrent_backups config parameter in the directadmin.conf file, link to feature description.
 
Thanks @Jayjayuk. It took us some time because initially this bug was hidden by the fact that the same code that introduces it also fixes it if executed again. It only revealed itself when we removed duplicate file structure setup operations from the setup.sh script.
 
Does this fix the issue with the missing DNS Management button? It started happening out of nowhere with all of my accounts
 
You must log in or register to reply here.
Back
Top