Introducing our new blog team
floriansnow at fsfe.org
Thu May 19 19:25:03 UTC 2016
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 at lists.fsfe.org or system-hackers at fsfeurope.org.
Daniel Pocock <daniel at 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
> 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?
More information about the Discussion