Speaking of introducing the new blog team, the blogs seem to be down?
Best Carsten
Den 19-05-2016 kl. 21:37 skrev Daniel Pocock:
On 19/05/16 21:25, Florian Snow wrote:
Debian has only had a major upgrade once every two years.
That's not what I mean; I mean regular updates. They should not break anything in Debian, I understand that. My point is just that we may have to use a Wordpress plugin (for example for LDAP) that may or may not play nice with all versions of Wordpress. In an ideal world, we would just not use such a plugin, but in reality, we may need it to provide the service we want to provide.
In the past, the system hackers installed upgrades, and, I presume, had to check if the blog was still running. We want to reduce the workload of the admins here by having a separate team take care of anything service (e.g. blog) related. The sysadmins should be able to install an OS update without having to check the blog specifically.
One way to deal with this is to package the plugin for Debian too, I've done that for various Drupal modules. Then the packages are being used and tested by more people.
It also means you can install the packages on a test server with minimal effort and evaluate upgrades before doing the upgrade on a real server.
I would hope the system-hackers group would coordinate the date of any major OS upgrade with you.
I would hope so for a switch from Jessie to Stretch for example. For regular updates, I think no such interaction should be required. Now, the problem I was talking about is that by using a non-packaged version of Wordpress, we decouple things a bit.
The scenario with using the packaged version could look like this: A sysadmin installs updates and one of those is for Wordpress. This update breaks LDAP authentication and possibly even brings down the whole Wordpress instance. That means the blog hackers have to act immediately to fix the issue, at a time that may be inconvenient.
You could use dpkg to put a hold on the Wordpress package version, but then you wouldn't get the security updates.
The scenario with upstream Wordpress could look like this: A sysadmin installs updates and Wordpress is not affected. Wordpress tries to do an automatic update and cannot do it because of the LDAP plugin. That means the blog hackers still need to act soon, but they can start when it is more convenient and when they have more time to actually track down and fix the problem.
As packaged systems are very standard, you should be able to easily replicate the server in a test environment and do a trial run of the upgrade and test any plugins before upgrading the real server.
I agree this would be ideal. I am afraid that we don't have the manpower for such a setup, though.
A test server doesn't have to be a fully public hosted server, it could even be your own laptop or home PC with apache and wordpress packages installed
When you use packaged software you also benefit from the testing that other people do on their systems.
Discussion mailing list Discussion@fsfeurope.org https://mail.fsfeurope.org/mailman/listinfo/discussion