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
[email protected]
https://mail.fsfeurope.org/mailman/listinfo/discussion
_______________________________________________
Discussion mailing list
[email protected]
https://mail.fsfeurope.org/mailman/listinfo/discussion
