[Discuss] systemd sucks and containers suck and language-specific package repos suck

[dsr at randomstring.org (Dan Ritter)]

markw at mohawksoft.com wrote: 
> In an ideal world, this is kind of true, but also not really. Let me first
> articulate what is wrong with the software development model in one word:
> "libraries"

I prefer "dependencies".


> In this case, VMs and containers solve the problem. By no means do I
> assert that they do it efficiently or even well, but they do solve the
> problem in a performant way without rewriting everything we've been doing
> for 40 years.

That's an adequate description of something between technical
debt and code rot.

A different perspective:

Rather than telling people that they had to write better code and make
better decisions, we give up and wrap their messes in an abstraction -
a container or a VM image.

Still a mess. In fact, it allows us to have bigger messes which
we understand less and thus can't debug as well, leading to worse
performance, worse security, and more time spent on administrative
overhead.


> Secondly, VMs provide a level of abstraction, security, and resource
> allocation.
> 
> Abstraction, I can run a Windows server (or any OS/system) VM on a well
> managed Linux server farm.

That's not abstraction, that's legacy infrastructure and resource
homegenization. You now have 2 systems, the Linux host and the Windows VM,
and both of them now need to be managed, and managed in different ways.


> I can freeze it, move it to a different system,
> start it, and perform maintenance or work on the previous machine.

This is an unambiguous advantage of VMs.


> Security is a huge advantage for VMs. A VM only has privilege to the
> resources it has. If I spin up a postgresql service in a VM and analytical
> service in another VM, but leave the postgresql system isolated from the
> analytical front end, the postgresql database is more protected and the
> analytical front end can be restarted and reinstalled if it is
> compromised.

If they are truly isolated, then they can't communicate. So they won't be
isolated, but rather forced to communicate through a specific interface,
either a TCP port or a UNIX domain socket.  Any attack which works to
subvert the logic of the front end to read things that shouldn't be read,
or write things that should not be written, will still work.

You've eliminated the class of attacks where a problem in the front end
is used to do something to the filesystem or kernel which it shares with
the PG system... but that didn't have to be the case, because if the
communication method is a TCP socket, the front end doesn't need to be a
VM on the same hardware as the database, it can be a completely different
machine. Which is likely what happens anyway, because the hardware which can
support a database server is too valuable to be wasted hosting the RAM
and disk space and I/O of an analytical front end. The front end, along
with all the other clients, will likely be on other physical machines.

Meanwhile, we now have to worry about not just cross-user/group/namespace
attacks but also VM escapes.


> Resource allocation is big too. You can "rent" a VM to a customer.

Several major classes of attacks only work when someone has decided to
run arbitrary code from untrusted people on hardware that they thought
they could trust.


> > It turns out that reading the wrong data out to a hostile user is
> > an attack, and one which a read-only VM image does not solve. It
> > is also the case that nearly all "read-only" VM images are not
> > read-only. They are, at best, selective in the places that they are
> > allowed to write.
> 
> That's not true. Most large server clusters are connected to a SAN of some
> kind. The VM image is presented via fibre or iscsi and can be marked
> read-only at the SAN. Which is how you do it in a secure environment.

Most businesses don't run SANs. 20 (or 200) machines in racks is much
more normal than 20,000 machines across three datacenters.

If the solutions being presented for small businesses don't work without
the resources of giant corporations, that's bad in and of itself. It leads
to the deployment of software ecosystems that, as Rich has mentioned,
simply require thirteen different VM or container images orchestrated
by an autoscaler. It is not a recipe for reslience.

No homes, to a first approximation, run SANs. (Actually, I know
a couple of people who do. They really don't count.)


> > In other words, UNIX permissions and mount options can do the same thing,
> > cheaper.
> 
> "Cheaper" is a dangerous word. To what are you referring? Cost of the
> machine? Cost of maintenance? Cost of interconnects? The SLA cost if
> something goes wrong. In the end it is an economics decision that leads
> the tech decision. VMs are safer, easier to maintain, easier to upgrade,
> easier to fail-over, and easier to back up.

Cheaper in terms of how much human time is spent reasoning about
what is going on and where it isn't working.

-dsr-