Introducing our new blog team

[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.