DirectAdmin 1.684

[fln]

We are happy to announce the release of DirectAdmin 1.684.

A full release change log is here:

DirectAdmin 1.684​

The update should be automatically available for all installations subscribed to the current release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks!

 

[Richard G]

We appreciate all the feedback

Only found a re-occuring typo. On several places (at least 3) it says "buypass ACME", but that should be "bypass" as you're not buying a pass.

Oeps... my mistake.

 

[JosKlever]

Only found a re-occuring typo. On several places (at least 3) it says "buypass ACME", but that should be "bypass" as you're not buying a pass.

Only this provider is actually called "Buypass" as you can see via the announcement link, so it is correct..

 

[sparek]

Can I go on record and say that I'm not a fan of this new rapid release schedule?

 

[Richard G]

Only this provider is actually called "Buypass"

Hahaha sorry, you are correct, I totally misread that. LoL... I adjusted my post accordingly.

 

[DrWizzle]

Hahaha sorry, you are correct, I totally misread that. LoL... I adjusted my post accordingly.

Must admit Richard, I did find that amusing. It gave me a smile this afternoon, so thank you

 

[DrWizzle]

Can I go on record and say that I'm not a fan of this new rapid release schedule?

I have to say i'd agree here also, but it's also a double edged sword. I totally understand rolling out hotfixes and security patches are high priority and new features are often nice to have, especially if they save you time and sometimes software providers take an age to release. So you're damned if you do and damned if you don't I guess

 

[sparek]

I have to say i'd agree here also, but it's also a double edged sword. I totally understand rolling out hotfixes and security patches are high priority and new features are often nice to have, especially if they save you time and sometimes software providers take an age to release. So you're damned if you do and damned if you don't I guess

What new features have been added since 1.680? It looks like most of the changes in recent updates are fixes or updates. Could 1.681, 1.682, 1.683, and 1.684 all just be "hotfix" releases for 1.680? I would probably concede that 1.681 introduced the web based installer, so maybe 1.682, 1.683, and 1.684 being hotfix releases for 1.681.

I liked it better when DirectAdmin versions were 2 to 3 weeks or maybe even 4 weeks in-between. I'm not including the various "hotfix" releases that come about after each new version released.

I'm still on 1.680. I generally prefer waiting about 2 weeks+ before updating because I don't want to have to go through all of the "hotfix" releases. There's usually a thread on these forums after each release that gets to be 4 to 5 pages long of "issues" (to DirectAdmin's credit here I'm not sure if these are really issues or just end-users not understanding what something is) I like to let that play out first. Lately the release threads haven't gotten that long because the release schedule has been accelerated.

DirectAdmin 1.680 was released on July 17th.
DirectAdmin 1.681 was released on August 11 - 25 days after 1.680
DirectAdmin 1.682 was released on August 25 - 14 days after 1.681
DirectAdmin 1.683 was released on September 2 - 8 days after 1.682
DirectAdmin 1.684 was released on September 9 - 7 days after 1.683

I'll admit I dragged my feet on upgrading to 1.681. It was on my todo task list for the previous week, but I didn't get to it. The 11th was a Monday and I was getting read to deploy the 1.681 update that week, but 1.682 dropped so I postponed that. 1.682 lived for 14 days, that's on the cusp of what I like to allow for. I hadn't exactly prepped for the update to 1.682 but it was in the scheduling stage. But then 1.683 dropped, so that postponed 1.682. I never even considered updating to 1.683 and now I'm looking at 1.684. At this point I wouldn't be shocked if we're at 1.685 by the weekend.

Now, I could drop back to stable instead of current. But the delay (or lack thereof) is still the same. When a new current drops, the previous current falls to stable. So you're still looking at 14, 8, and 7 days in-between those releases.

To be fair, I'm sure not everyone follows my preferred method of testing each new release and letting "issues" play out to see how they may affect me in a production environment. I'm sure not everyone has the level of customization I have in my production servers and if you're just running vanilla DirectAdmin then update to update probably isn't a huge issue. For that you probably want more rapid releases because it minimizes the amount of time any "issue" stays there. But I'm just not one of those people. Majority rules, so I'm not necessarily complaining. But I am voicing an opinion in case anyone that handles DirectAdmin releases wants input on these rapid release schedules.

 

[fln]

Thanks for the feedback @sparek. Our goal for the time being is to try and keep-up and make a new release every week. Before it used to be 2 to 3 weeks between releases.

Faster release cycles allows us to bring improvements that would not normally be considered hot-fixes faster to the users. For example new versions of the 3rd party software. Also fixes for some things that are not newly introduced in the latest version (for example File Manager showing last modify time rather than file create time). Another reason for faster release cycle is to allow translation updates to propagate faster. Sometimes for minor translation fixes users need to wait a full release cycle.

The recent release pace was increased to help us deliver the CSF update faster. If CSF is not updated to the latest version (where auto updates are disabled) it keeps sending daily error messages about failures checking for new version.

Our goal is just to have a consistent release-cycle at fixed interval of time instead of waiting until we accumulate a specific amount of new features.

---

By the way a new build is pushed out with a small fix for the Evolution plugins page. When login-as feature is used plugin page used to not account for the top bar size and would hide a 50 pixels of plugin page bottom part. This would not normally be considered a normal fix (not a hot-fix) because plugins page was introduced in DA 1.681. But since it was spotted and fixed the same day we made a release we decided to just pull it into DA 1.684 to push it out faster.

 

[DrWizzle]

Under 3 hours between updates. Now that IS efficient service!

 

[sparek]

Thanks for the feedback @sparek. Our goal for the time being is to try and keep-up and make a new release every week. Before it used to be 2 to 3 weeks between releases.

Meh!

I'll withhold the rest of my opinions on this. But I will add this... and maybe other administrators of larger number of production servers will chime in (maybe they chime in stating they don't have a problem with this).

Rapid release schedules, frequent updates, or just updates in general are one thing when you have a server system of one server. Or two, or three... I don't really know where the cut off starts. But take 10 servers... it's probably a little different. 20 servers... even more different. 50 servers...

The more users you have the more opportunities you have for uncovering issues caused by an update. The more servers you have with these opportunities you more likely you are to reach a collision. Say you have 50 servers. You update 12 of them, everything is going fine. Suddenly a user on one of those 12 servers finds a bug in the update. Do you continue updating the other 38 servers? Or do you pause? You know there's an issue... do you want to bring that issue about to the other 38 servers? If you pause and wait for another release, then you go through updating the servers again. This time you get to 20 servers before someone finds a bug. Now you've got 30 servers that are two versions behind already. And it just starts to spiral out of control.

Would a real LTS release be a solution here? I'm not talking about just pushing the previous current to stable. This would involve differentiating between "fixes" and "features". So that "fixes" are pushed back to the LTS release but new "features" can continue to be added and the versions can keep incrementing. But those of us that just want a stable set of working "features" without the headache of working with new "features" all the time can continue to use an LTS version that only gets "fixes" from newer versions.

A just think some input from administrators that have a lot of servers (no clue what defines "a lot") regarding their opinions of this rapid release schedule, could be valuable.

Also administrators that have extensive use of customizations - whether that be CustomBuild compilation or configuration customizations or the extensive use of event hooks - what are their opinions of this rapid release schedule?

 

[ju5t]

We manage 10+ servers with DirectAdmin and most of the time we're fine with the increased pace.

Our user base is manageable, for us. It helps that we don't have many active control panel users -- most use it every few months or less. I'm sure my opinion will change when we grow to 50+ servers or when users get more active. The issues we have seen are often related to the services DirectAdmin manages. If it happens, we rollback (on all servers) and wait for a solution. We then update the service together with all other updates in a next release. We can deal with that.

Breaking changes are different. We've seen a few, and although they can be rolled back, an opt-in approach for existing installations would have been better. It would give us time to handle the changes later. If there's anything we would like to see different it would be this.

 

[kristian]

maybe other administrators of larger number of production servers will chime in

We manage a fair amount of servers, and we automate everything we can, everything from initial setup, to upgrades, and config management.

The number of releases in itself isn't necessarily bad for us. The challenge is when a release requires us to make adjustments to our automation, or customization, or do *something* in order for things to continue working. We don't always have time to do those changes right then and there, which means we may decide to e.g. hold off on updating certain pieces of software.

An example is the recent Dovecot 2.3 -> 2.4 update neededing configuration changes. This of course was pushed from Dovecot, and not Directadmin, so maybe an unfair example. Another is the Exim change related to sender address spoofing protection. This required us to actively disable it for services to continue as before, as opposed to actively enable it when we were ready to add the protection. We had to hold off updating Exim until we had the time to add the setting for AUTH_BLOCK_SENDER_SPOOFING into our automation. A third example is the change for MySQL/MariaDB configuration structure. A good thing, but when Directadmin automatically converts configuration files that we manage from automation, if we do not intervene, our automation will recreate the old files, which may possibly cause problems.

If there are too many such changes rapidly, it can indeed quickly spiral out of control, and when you first start lagging behind, it can be a massive headache to get back up to date.

We also have a myriad of customizations in /usr/local/directadmin/data/templates/custom/, /usr/local/directadmin/custombuild/custom/, and /usr/local/directadmin/scripts/custom/, and I wish there was a good way to be notified when e.g. a customized config had its upstream version changed.

So in summary I guess I don't really mind a frequent release schedule, as long as things don't break, and that we can actively enable new features, rather than having to scramble to make sure our automation doesn't break/overwrite these new features, or our clients suddenly get a new "feature" we don't want. I realize this isn't always possible, and might mean extra work for the DA team, but I think the stability would improve, and generally make the whole system easier to manage for all of us admins.

 

[sparek]

So in summary I guess I don't really mind a frequent release schedule, as long as things don't break, and that we can actively enable new features, rather than having to scramble to make sure our automation doesn't break/overwrite these new features, or our clients suddenly get a new "feature" we don't want. I realize this isn't always possible, and might mean extra work for the DA team, but I think the stability would improve, and generally make the whole system easier to manage for all of us admins.

I think this speaks to my main concern.

I'm not faulting DirectAdmin for having bugs in each new release - this is just part of software development. But rapid release schedules means that we either have to skip over several versions to insure stability or experience those bugs on our systems as a cost of the rapid release schedule.

Automatic DirectAdmin updates and software in general doesn't work for us. Automatic notification of new updates work, but I don't want them applied until I have had a chance to review them. And such is the case with DirectAdmin. We get notified when a new version of DirectAdmin has been released. We then wade through these forums to discover what issues are popping up for other uses with that release. Various hotfixes usually get released and when that slows, the release would seem to be fairly stable so we push through the upgrade.

We have a lot of customizations, including the paths that you mentioned, as well as customized event hooks and Exim and Dovecot configuration customizations. Our preference is to be aware of potential issues with these customizations before applying an update. We typically update our low usage service first so if there is a major conflict with something this usually rises to the top.

As for monitoring template changes, we wrapped the DirectAdmin update process into our own script. Before it starts the DirectAdmin update, it grabs a copy of /usr/local/directadmin/data/templates/custom and then after the DirectAdmin update finishes, it compares the differences between that pre-update copy and the versions that exist after the DirectAdmin update. If changes are made to the templates, then we have to adjust our own customized templates to match. This is again why we update low usage servers first.