DirectAdmin 1.63.9 has been released

I'm seeing a new problem that I believe started in 1.63.9.

I cannot use the "Compress and download" feature in the File Manager. I'm greeted with an error in console:
Code:
TypeError: undefined is not an object (evaluating 'd["a"].state.session.serverValues')

It seems to affect the public demo installation of DirectAdmin as well. Willing to try any troubleshooting if necessary!
 
The amount of bugs in the new DA versions is crazy. I miss the times when instead of a updates every week and reinventing the wheel it was just a simple, stable panel.
 
@cocoban78, field version in the skin.conf is only used for cache-busting (making Evo notice new version is available and all assets need to be re-downloadd). Changing would only make Evolution reload all assets instead of using locally cached ones.

Glad to hear it you tracked it down to `wordpress=off` instead of `wordpress=OFF`. Config values in the user.conf are case sensitive.

Such errors should be visible in the DA log, example:

Code:
root@server:~# journalctl -u directadmin -f
-- Logs begin at Sat 2022-04-23 06:04:01 EDT. --
...
Apr 24 06:20:58 server.example.net directadmin[21087]: 2022/04/24 06:20:58 error authenticating basic-auth error=field wordpress: unexpeced value: off username=admin
Apr 24 06:21:20 server.example.net directadmin[21087]: 2022/04/24 06:21:20 error authenticating basic-auth error=field wordpress: unexpeced value: off username=admin

Do you have any ideas how off value could have gotten into user.conf? DA service itself would always write it in uppercase form as OFF. Tracking the source of the issue could help us prevent similar issues in the future.
 
The amount of bugs in the new DA versions is crazy. I miss the times when instead of a updates every week and reinventing the wheel it was just a simple, stable panel.
Well, I'm out of the hosting business now thankfully, just have a VPS for my own sites/projects....... We can blame cPanel pricing changes for all these issues - everyone flocked over here, demanded DA to "look" like cPanel, then Evo skin became BLOATED like cPanel's....... I miss Enhanced, but it's broken now, some features missing, etc.
 
@fln

There also seems to be a permission issue with home/tmp directory which stops restoring sites on new servers.
 
hi everyone, we prepared a new Evolution version with fixes for:
  • Compress and download menu entry in File Manager now works
  • Some email related features were visible (but non-functional) for users not having access to email
And was ready for a release but just noticed @Jayjayuk message. You mean restoring accounts from backups?
 
hi everyone, we prepared a new Evolution version with fixes for:
  • Compress and download menu entry in File Manager now works
  • Some email related features were visible (but non-functional) for users not having access to email
And was ready for a release but just noticed @Jayjayuk message. You mean restoring accounts from backups?
Yep from backups, did 3 different servers over the weekend, all needed home/tmp changing to 1777 I think off the top of my head to be able to restore.
 
@Jayjayuk have you noticed what permissions did this dir had before? Because actually on each install or upgrade we are setting /home/tmp to 1777. It is done by da permissions (used to be /usr/loca/directadmin/directadmin p). That is why I wrote it off as some accidental miss-configuration not related to the upgrade.

You can check this out with:

Code:
# chmod 0444 /home/tmp
# stat /home/tmp
...
Access: (0444/dr--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
...
# da p
# stat /home/tmp
..
Access: (1777/drwxrwxrwt)  Uid: (    0/    root)   Gid: (    0/    root)
...

And da p is part of upgrade procedure after new tarball is extracted, so if anything upgrade should fix it rather than break it.

Will see if I can find some other (not upgrade related) action that would change /home/tmp permissions. My hypothesis is that some not yet known (but popular) action messes up permissions but DA upgrade gets blamed.
 
@fln

They were all fresh installs. All had the same issue on different servers.

I didn’t note the previous permissions, but if the install is the same I guess it would happen again.
 
Both DA install and DA upgrade scripts makes sure /home/tmp is 1777 so it is not directly related to this upgrade. If anyone is able to find this issue again please fill a ticket in our support system. We will be able to investigate the issue further.

For now I pushed Evolution upgrade, new DA 1.63.9 build is d70b0dc358e928045ca87a791ec0be9bc1a4734a, it includes only new Evolution with the following fixes:
  • Compress and download menu entry in File Manager now works
  • Some email related features were visible (but non-functional) for users not having access to email
 
@Peter Laws couple of comments regarding the current state of Evolution.

I agree that current version of Evolution might sometimes feel clunky and this is exactly what we are working on improving it. Despite Evolution being JS based single-page-application it still forced to use the same API and skin system as older skins like Enhanced.

We are working on upgrading the API and skin system for Evolution to unlock its full potential.

Old skins are not broken, but they do not receive any new features.
 
@fln I can confirm that the Compress and download feature in File Manager fixed in the newest build.

Thanks for the incredibly fast resolution! Much appreciated.
 
Both DA install and DA upgrade scripts makes sure /home/tmp is 1777 so it is not directly related to this upgrade. If anyone is able to find this issue again please fill a ticket in our support system. We will be able to investigate the issue further.
Is da p equal to the ./set_permissions.sh all command? Because only this command fixed it for me on a fresh Debian installation. For some reason I'm not getting this error on CentOS but this might be happenstance because I wasn't able to figure out a pattern when this error occurs but for now, if it occurs, it was always on Debian/Ubuntu.
 
Not really. Command da p fixes permissions of DA owned files at /usr/local/directadmin and ensures configured directory structure exists (creates or fixes /var/log/directadmin, /home/tmp, /var/spool/virtual, /etc/virtual if needed). It is needed because extracting DA installation or upgrade tarball creates root owned files while DA service expects them to be owned by system account diradmin.

Script ./set_permissions.sh on the other hand takes care of fixing user owned files in user home dirs as well it takes much longer and covers large portion of the files in the file system. But both takes care of ensuring permissions for /home/tmp.
 
Good afternoon,

I believe this version has introduced a bug with the Wordpress Manager.

When I create a new Wordpress installation on a new account, if I select "create new" database, the database username is not selected in the select box after being created. If I select "use existing" the database list provides two different options but they are JSON objects, the username field is selectable.

Attempting to proceed produces an "Invalid database credentials" screen, but still installs files in the user home folder.

Let me know if you need more information on this.

Version1.63.9 (build d70b0dc358e928045ca87a791ec0be9bc1a4734a)
DA build for OSlinux_amd64
Detected server OSrhel8_amd64
Uptime14 minutes, 9 seconds
Update Channelcurrent
Evolution Versionmaster-1958 (build efc8475147f5428afab19ceb3a583213e413d031)
 

Attachments

  • Screen Shot 2022-04-27 at 12.20.15 PM.png
    Screen Shot 2022-04-27 at 12.20.15 PM.png
    177.4 KB · Views: 17
thanks @simplificare we confirmed the regression on Wordpress Manager and pushed Evolution update to address the issue. New build ID is d211222a4e7c7fd004bb81f8e1da54e09a46104d.
 
So, when is 1.63.9 expected to be stable - as in not finding any more bugs or issues?

This is kind of what I hate about not having a stable branch. I'm just following this thread and waiting for the number of bugs and issues to die down before I upgrade to 1.63.9.

Seems to me that there is real big issue with beta testing these releases. They get developed in an R&D department but it's only until they get out into the real world when bugs and flaws are identified. Don't get me wrong, this is likely going to happen with any software release - DirectAdmin is no different. But seems it might be a good idea for DirectAdmin to incentivize "beta testing" releases in a production environment before releasing it out to the general public. Perhaps a price discount for licenses that run these new releases in a "beta testing environment" so that bugs and flaws can be identified before it goes out to the general public.

Of course, if the discount is not enough to entice a larger segment of DirectAdmin licensees or if those licensee aren't actually using DirectAdmin in an environment to identify bugs and flaws - then I'm not sure how well this would work.

Just seems that with every release there's at least 3 or 4 weeks of constant tweaking until the release has most of the bugs worked out.

I guess everyone wanting a more stable, "I don't have time to deal with these bugs" experience can do what I'm doing and just wait for all of the constant tweaking to subside.
 
Back
Top