Hi Daniel,
I really appreciate your input. However, this is getting very technical quickly, so maybe we should move these discussion to the appropriate team lists where details of implementation can be discussed. Those mailing lists could be either blog-hackers@lists.fsfe.org or system-hackers@fsfeurope.org.
Daniel Pocock daniel@pocock.pro writes:
This means that the system-hackers group (or any other sysadmin) can easily deploy those fixes to servers immediately using
apt-get update && apt-get upgrade
I understand and that is what I do on my servers. In case of the FSFE servers, this requires a bit more coordination between (now) different teams.
These changes are usually made for some good reason and it varies a lot from one package to the next.
I never doubted that. It did create additional problems for me in the past, though. Again, we will see what works best and then decide.
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.
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.
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.
Is anybody aware of a web-based tool that can be used to edit text files and commit the changes in a Git repository?
That is something we need to figure out in the blog hackers team. I already looked into a lot of different solutions, but it appears there is no real backend solution out there. The problem of just editing markdown can be solved with tools that are out there, but images are another problem we need to tackle. Do you want to join our team so we can get your input there?
Happy hacking! Florian