On Tue, Oct 30, 2018 at 11:28 AM Jonathan Riddell <[email protected]> wrote: > > On Mon, 29 Oct 2018 at 20:56, Luca Beltrame <[email protected]> wrote: > > - As far as I remember, they *only* supported deployment with Docker. > > This is is IMO a terrible and black-magic approach > > Seems like a perfectly sensible and modern way to deploy. You can log > into the running container fine and twiddle as needed.
Sorry, Docker might be a wonderful way to test applications, but it's totally unsuitable for production workloads. First, the contents of that Docker image can be confirmed how exactly? While the Dockerfile might be available for us to inspect somewhere, is it possible for us to verify that what is supposed to be in the *binary* image (which isn't signed) is what the build log for that Dockerfile actually produced? Second, it's impossible for Sysadmin to delegate management of a Docker container to anyone. Having access to Docker's management socket grants effective root rights over the host to the people with access to that, thanks to Docker's lack of user namespaces, ability to launch privileged containers (which have no limits on their access to the physical host) and have arbitrary folders on the system (including the whole root filesystem should one want to) mounted as volumes into a container. Escalation to root on the system would be as simple as 1-2-3. This means if anything goes wrong with it a Sysadmin would have to be the one to take a look, investigate and resolve the issue. For non-containers we can fully delegate this (even in the case of Ruby apps - Passenger is awesome for auto-scaling and letting people control this sort of stuff) so this would be a substantial step backwards and would increase the barrier to entry and pressure on the Sysadmin team. Virtually all of our servers run multiple workloads, which means the second point is a *hard* deal breaker for us. Case in point, the current server for the Forum (known as Silk) also hosts amongst other things: the Dot, Akademy site, Krita.org, Techbase, Userbase, our CiviCRM instance and our website statistics collection system (Matomo). Additionally, we use LXC ( https://linuxcontainers.org/ ) for running all of the workloads on our primary servers. Running Docker within LXC requires relaxing the security constraints that LXC containers have imposed on them under normal conditions, making them inherently less secure, which sounds like a bad idea to me. > > > - It uses (used to use?) PostgreSQL as database, for which Sysadmin > > isn't really keen on using unless absolutely necessary > > Shrug, personal taste. Sorry, but that's not a case of personal taste. Virtually all of our servers, with few exceptions, run MySQL / MariaDB and I don't think it's a good idea to run two database servers on the same system (more maintenance, two things to keep backed up, plus we don't have as much experience for problems with Postgres when compared with MySQL) > > > - The UX is not as best as it looks, hijacks stuff like the back button > > on the browser and what not > > Shrug, personal taste. > > > - The "app" on mobile is a joke, basically a web view of the mobile page > > I'm told the app works fine web view or no, doesn't seem a reason to > dislike an app. > > > > I think KDE should consider moving away from mailman and onto > > > > Does Discourse have a mail interface to avoid breaking user workflows? > > How should a migration be handled? Don't forget we'll lose distributed > > archiving of the mailing lists as well (very useful). > > It certainly notifies by e-mail, I've not yet worked out how it treats > incoming e-mail. > > It has import filters for mailman and maybe phpBB but also if we ever > got to a point where we dropped the current systems entirely they can > just be turned read only and continue to be used as archives. > > > Also, don't forget that "should", to quote a seminar I was at recently, > > should become "I/we/they will". If no one is willing to put support > > with the (aged! I'm not saying it's perfect) forum infrastructure why > > do you think one would put up with the new? > > Of course it would need someone to do the work, but it would mean > replacing two systems with one. > > Jonathan Cheers, Ben
