Live data from Hacker News

The sad state of sysadmin in the age of containers (2015)

vitavonni.de

121–130 of 324 posts

Re: The sad state of sysadmin in the age of containers (2015)

#121
post #77

You've got to look at this in a context where platform package managers like apt are simultaneously 1) platform-specific 2) jealous, insisting that every language has to conform to their way of doing things and 3) fundamentally not very good, having very limited ability to do things like install packages for a single user or install multiple versions of the same package. Platform package managers like maven have been…

> jealous, insisting that every language has to conform to their way of doing things

Let's ignore for a moment all your baseless assertions and focus on the following question: how do you ensure that a build is reproducible if you have no control on which required dependencies are downloaded by a build system which requires root access?

Is jealousy the only explanation that comes up to you?

Re: The sad state of sysadmin in the age of containers (2015)

#122
post #6

Terrible article IMO. Hadoop is an awful mess, but it has nothing to do with Docker, which is simplistic in comparison. "Ever tried to security update a container?" Yes, I have! In fact you can maintain patch compliance in a container pretty much the same way you'd maintain a VM or bare metal Linux installation!

You missed the bigger point. Just look at the popular images on Docker hub. A lot of them involve messy build steps, including downloading binaries or source tarballs without verification. It's often hard to know which dependencies a Docker image has, and therefore hard to track vulnerabilities and redeploy fixed images. A lot of docker containers end up either running for a long time, or get rebuilt and redeployed o…

> A lot of them involve messy build steps, including downloading binaries or source tarballs without verification

Do they though?

Whenever I write Dockerfiles that depend on external downloads, I always check the hash matches one baked into the Dockerfile itself, and I've always seen others doing the same.

Re: The sad state of sysadmin in the age of containers (2015)

#123
post #102

Earlier quoted context omitted.

No. I think I have never run `sudo make install`. Things I install come from package managers. Docker or a VM is used to test other software. And of course trust is important, but if I encounter things like `curl | bash`, my trust is lost.

What difference does it make if you run `make install` or `curl | bash`? In both cases, you are running code you have not audited yourself. Or are you the kind who inspects every Makefile and installer script before installing? If not, why is one better than the other?

Because at least with make install you can have some trust in the delivery method, ie encrypted git or whatever. If you use just plain http....

Re: The sad state of sysadmin in the age of containers (2015)

#124
post #94
post #87

Earlier quoted context omitted.

That's quite a negative view of the situation. The debian maintainers definitely don't insist that everything has to do things the apt-way. They only insist that packages for the official repos do so, which seems sensible enough to me. Everyone is still free to build their own deb packages or distribute their applications through install scripts or app images or any one of a hundred thousand different ways to distrib…

It's not just a question of being in the official repos. Even if you're running a private repository, the deb tooling is not suitable for building many kinds of software: it's unwilling to play nice with "external" dependencies, and still single-platform and limited in its functionality.

> it's unwilling to play nice with "external" dependencies

This baseless assertion is simply out right wrong. See for example Debian's docs on Private Package Archive:

https://wiki.debian.org/DebianRepository/Setup

Re: The sad state of sysadmin in the age of containers (2015)

#125

Earlier quoted context omitted.

would you feel better if your Makefile looks like this: install: [ $(id -u) -ne 0 ] && echo 'please run sudo make install' || curl https//my.thing | /bin/sh it goes back to what jve said - it's a matter of trust. how often do you blindly run 'sudo make install' w/o reading the entirety of the build script? all the time I bet - it's because you trust the source

No. I think I have never run `sudo make install`. Things I install come from package managers. Docker or a VM is used to test other software. And of course trust is important, but if I encounter things like `curl | bash`, my trust is lost.

Whether it's `sudo make install` or `curl | bash`, in both cases you have the opportunity to first inspect the code that will be executed.

Re: The sad state of sysadmin in the age of containers (2015)

#126
post #89

Earlier quoted context omitted.

No I don't. I use Debian derivatives because I can apt get all my stuff without thinking hard, because those package maintainers have done the hard work.

Well, clearly not, since you can't install Hadoop. Before you blame that on Hadoop, remember that it only requires some really quite basic things from its package manager, which apt is nevertheless completely unable to do: use libraries in the normal recommended way, play nice with Java, work cross-platform.

> Well, clearly not, since you can't install Hadoop.

You are complaining that you can't automatically install broken packages out of the box through the official repo.

And packaging an application is the responsibility of the people working on that application, not the OS.

What's your point?

Re: The sad state of sysadmin in the age of containers (2015)

#127
post #49

Standard Makefiles are really under appreciated today. They are simple and can be used with most any language, version controlled and have been around for decades.

Agreed (although I so wish they weren't utterly dependant on tabs!)

I even sometimes use makefiles in conjunction with Docker, for example to automatically add the correct tags to a build - it's much easier to type `make build` that to remember a massive invocation for `docker build`.

Re: The sad state of sysadmin in the age of containers (2015)

#128

> I’m not complaining about old-school sysadmins. They know how to keep systems running, manage update and upgrade paths. Sadly these ways of olde didn't scale. They could only do it for a handful of servers, change request took months and the systems were not to be 'touched'. > And since nobody is still able to compile things from scratch, everybody just downloads precompiled binaries from random websites. Often wit…

> They could only do it for a handful of servers, change request took months and the systems were not to be 'touched'.

Those old ways of doing things were indeed slower than they needed to be in many cases, and I'm glad that we sped them up. I don't believe that we needed to throw the baby away with the bathwater though.

The problem now is that we build systems which are unmanageable and unmanaged. 'Throw it in a container and let it run' is not scalable either: it scales neither security not maintainability. Instead of scaling, it just punts.

Enabling one to do something one shouldn't do (i.e., deploy insecure software into production) is not a virtue.

Re: The sad state of sysadmin in the age of containers (2015)

#129
post #71

Earlier quoted context omitted.

Makefiles are too low level to be convenient for anything other than simple projects on one platform.

If the alternative you are hinting at is CMake, I can't really agree with you. I tried it recently and was shocked at how awful the syntax and usability was. It's begging for a tool to auto-detect your dependencies from source. I was trying to port an existing project to it and I gave up when I realised that I'd have to manually create about 30 CMakeList.txt files or whatever they call them. Meanwhile during the same…

I am definitely not hinting at CMake!

Better options are Bazel, Buck and Please. Please is the most light-weight option.

Re: The sad state of sysadmin in the age of containers (2015)

#130
post #66

Earlier quoted context omitted.

It is way bigger then security, and hits upon quality of life and reliability. Without a deterministic build I don't know what I check in actually works across environment, or if the deployment artifact works.

checksums are a thing, as well as package mirrors or outright holding onto the file and checking in a binary. There's loads of ways to know what you are using without needing to strip mtime's from zip files.

Checksums, solve a different problem. How does a developer know his code which works on his laptop will work on production. One of, but not the only, conditions for that are that his development artifact builds with the same dependencies as it will build in production. Their are a lot of possible causes for Dev/Prod to differ wildly. One of them are poor build practices.
Post reply on HN