DirectAdmin v1.647 has been released

CAISC said:
I dont think so? Didn't knew there was activation needed.

can you plz guide on the same
Click to expand...
I realized that it's not a new skin, but it's the menu management that changed according to the account levels, but I found it very interesting, it could be included in the icon grid.

Version 1.647 | Directadmin Docs

DirectAdmin Knowledge Base
docs.directadmin.com
 
A new build 94801a4766c9a00de9f996adfb5f2dc530665cfb is released, with the follwing hot fixes:
  • Fix for Evolution not showing menu at all if any of menu customization entries were malformed, thanks @xyntanl
  • Fix for grid icon heights, thanks @djcart
@Marks, @CAISC
You are probably referring the the alternative dashboard view (showing menu actions instead of dashboard widgets) it is a replacement for grid menu in Refreshed layout. You can toggle between widgets and grid with this button:
1677181522074.png
 
I don't use Roundcube. But DA backup is still trying to export Roundcube, then it leads to error when running backup
Code: 
RoundCube Backup Error:
Fatal error: Uncaught mysqli_sql_exception: Unknown database 'da_roundcube' in /usr/local/directadmin/scripts/backup_roundcube.php:128
Stack trace:
#0 /usr/local/directadmin/scripts/backup_roundcube.php(128): mysqli->select_db('da_roundcube')
#1 {main}
  thrown in /usr/local/directadmin/scripts/backup_roundcube.php on line 128
 
fln said:
After sub-domain is created you can change its document root using GUI, but there is no option to control the default document root (for new sub-domains).
Click to expand...
Sorry but this is very confusing. We completely disabled changing the document root for customers in the past. Keeping it easy for customers.

Is there any way the old Document Root structure can be enforced without customers also being able to change it.
An API call which keeps reverting changes of customers doesn't sound like a nice solution and is also confusing.

It would be better if allow_subdomain_docroot_override can be disabled by hosters and for hosters an overall document root can be set for all customers. This keeps the folder structure simple and also makes it easier for our webserver configs (such as virtual_host2_sub.conf ) to just follow one centrally maintained config.
 
Last edited:
When clicking "check server for problems" on the option "Ensure all subdomains to have explicit (custom) document root configured"
You get the error "Cannot reach the network."
 
  • Like
Reactions: fln
Hello;

I updated DirectAdmin v.1647 on 3 servers and, on all of them, "Logins Keys" stopped working, displaying only the error message "Failed to load login keys!".
It only works with administrator level (user and reseller shows error).

img1.png

Another problem is with the admin level, the ModSecurity icon no longer appears, but it still appears for the user level.

img2.png

These are the problems found at the moment.
Thanks!
 
  • Like
Reactions: fln
@paulonichio thanks. Could you please open a support ticket. There should be errors logged in the directadmin log, but I would be great to continue discussion on this issue in support system rather than a forum.
 
Just putting it out there that Evolution is good if you go with the icon grid layout and not the refreshed layout.
 
@Joriz, thanks for the feedback.

I agree completely removing users ability to change document root sounds tempting. I mean as a way of preventing them of from causing themselves some problems by accident. However this approach takes away a very important feature from a more advanced users. Depending on their website framework or just code-base in general it might be necessary for them to be able to change document root.

We are trying to make it best for both types of users by making docroot change operation is as much foolproof as possible but still allowing it. For example - DA will refuse to change docroot to a non-existing directory. If directory is removed afterwards DA will revert to using the default docrtoot directory (at config regenerate stage).

I must admit - making default subdomain docroot something configurable (in directadmin.conf) is a fair feature request. Still we are a bit reluctant to jump on it right away. Key reason behind it is because there is no easy way to express default subdomain docroot location as a simple string. It contains variable parts like domain, full subdomain, subdomain prefix. It would mean introducing some kind of placeholders system or mini template system just to parse this one option. If there would be a really strong use case for it we could reconsider, but right now I think the complexity involved in making it configurable is not worth the benefits it gives.

My opinion is that it would be ideal just to stop worrying about the document root location and embrace the idea that it can be changed. Meaning we should not really force any structure on it. Old accounts will have their docroots in old location, new accounts in new location, advanced users will most likely use completely custom location. As long as DA is aware of where it is it will be fine.

From the operational complexity there is nothing to worry about. DirectAdmin takes care of setting SDOCROOT to the actual subdomain document root. So as long as you use tokens (not hard-coded paths) in config templates everything should will be fine.

Hope this gives some insight in how we see this issue.
 
I setup a new user, with dns-only feature. Use move_domain.sh script for moving in a domain from an existing account on the same server. After that, logging to the new one. Error appears: The request you've made cannot be executed because it does not exist in your authority level. And no other command works, even logout.

Set up a new user, with dns-only feature or email-only feature. The same error.
If switch to core, then DA is working with that new user.
 
Last edited:
fln said:
Hope this gives some insight in how we see this issue.
Click to expand...
Thanks for the insight. Can we please have all hotfixes published to the change log?

The current process of posting hotfixes in the forum makes understanding the changelog difficult and somewhat pointless (if they're not all in the same place).
 
fln said:
Hope this gives some insight in how we see this issue.
Click to expand...
Thanks for the long explanation. Using SDOCROOT it will be implementend easier in our own webserver configuration.

We are currently looking in how we can implement custom documents roots for customers in an easy to understand and maintainable way. :)

Jamie@DreamIT Host said:
Can we please have all hotfixes published to the change log?
Click to expand...
Totally agree. Now it is not clear what is fixed in hot fixes except when you keep reading the forum.
 
Regarding subdomains and DocumentRoots - I think a better idea would be to remove the whole concept of "subdomains" entirely.

Just have "domains"

Is there really any need to distinguish a subdomain from an (I'll call them...) addon domains?

If you create an "addon" domain - example.tld - it's going to create a DocumentRoot in /home/%user%/domains/example.tld/public_html

If you create a "subdomain" - sub.example.tld - it's going to create a DocumentRoot in /home/%user%/domains/sub.example.tld/public_html

I would propose adding an option to the Domain Setup, such that a "domain" is allowed to share a DocumentRoot with another domain - essentially a domain "alias" or "parked" domain - which effectively just symlinks /home/%user%/domains/alias.tld/public_html -> /home/%user%/domains/source.tld/public_html

Nothing stops you from creating a sub.example.tld in the Domain Setup part already.

This is what I have done since I started using DirectAdmin, it simplified things a bit. When a client wants to create a traditional subdomain, I just instruct them to create a new domain name - but use the full subdomain (i.e. sub.example.tld) as the domain to create.

Creating a domain alias or parked domain requires a little bit more work, because they have to submit a ticket for us to create the symlink (although technically they could that themselves, but most clients don't understand the process... and that's totally understandable).
 
Direcadmin in GUI Protected Directories not working for the subdomains

Directadmin versions 1.647 (9b59737897896a2b06d192968288e82a2b537dbc

domain = example.tld
subdodomain sub.example.tld

directadmin creating folder for the domain and subdomain
/home/username/domains/example.tld
/home/username/domains/sub.example.tld


Protected Directories --->>> Add Protected Directory

user can see and exit only /home/username/domains/example.tld folder
can't exit /home/username/domains/sub.example.tld for creating Protected Directory in subdomains folder.
 
  • Like
Reactions: fln
@Hostmavi thanks for bringing protected directories to our attention. This is a limitation that was affecting all users using custom sub-domain document roots, but it was not visible until we started using custom domain roots by default. We are expect to fix this issue with our next release.
Regarding the hot-fixes, we never introduce any new features with the hot-fixes. Hot-fixes only makes sure already documented features works as we expect (and as they are already documented). And it usually affects only a handful of installations with a specific configuration. The existence of hot-fixes can be completely ignore except for those who reported an issue and waiting for a fix. And issues gets reported only in our ticketing system and forum.
 
fln said:
And issues gets reported only in our ticketing system and forum.
Click to expand...
That is a bit of a problem. Because currently we don't know if we found a new bug or something which is already known. Causing a lot of time investigating and reporting issues. Wasting time for both parties.

Hotfixes should be more clear with a clear version numbering and description in the change log. I hope this can be improved. :-)


Regarding protected directories great to hear this is getting improved.
 
You must log in or register to reply here.
Back
Top