Live data from Hacker News

The sad state of sysadmin in the age of containers

vitavonni.de

81–90 of 466 posts

Re: The sad state of sysadmin in the age of containers

#81
I love a good rant as much as the next guy, but unfortunately, rants are rarely actionable.

> Maven, ivy and sbt are the go-to tools for having your system download unsigned binary data from the internet and run it on your computer.

The root of the problem is that out of the total number of libraries available in language X, only a small subset is packaged in Debian/RHEL. This may be more egregious with large, Java enterprisy software, but you could easily end up with the same problem in Ruby or Python.

You cannot reasonably expect developers to package and maintain all their dependencies properly. The least worse solution would be to:

- still use maven to manage dependencies

- create a Debian/RHEL package incorporating the dependencies (effectively vendoring them in the package)

Unfortunately, it is not that simple, because you need to make sure that your vendored-in-the-package dependencies are somewhere where they will not conflict with another package with the same idea and the same dependencies (or better, the same idea and a different version of the same dependencies). Which means you need to keep them out of /usr/share/java and make sure the classpath points at the right location.

However, it seems that developer tend to avoid this kind of rigmarole and instead go for the "install dependencies as a local user" for certain classes of application (eg, webapps) because packaging is not fun.

Re: The sad state of sysadmin in the age of containers

#82
post #62
post #49

Earlier quoted context omitted.

Docker didn't fuck up when they hired the square guys. http://blog.docker.com/2015/03/secured-at-docker-diogo-monic... I agree that security and provenance is a real issue in Docker. It is however being worked on, and it will be solved. Presumably we will end up with some sort of app-store like framework with proper signatures and verification. Docker can't do everything at once. Give them a chance. The new version o…

Cool, they hired some people, but I haven't noticed better security for it yet. Security is a real issue in docker and it is being worked on, but I don't think "give them a chance" is a justifiable response. They're not focusing on it strongly. They already should have focussed on it and didn't. Their entire codebase was written without a security design in place, so there's likely deep-seated refactoring that'll nee…

I agree that security should have been in place before they went 1.0. However, if you look at the work on the version of the registry (docker/distribution on github), they are taking things more seriously and trying to get the basics right.

I find your last point a bit strange. We all know the Docker development experience is a lot better than raw lxc. I'm saying you can (and probably should) be more careful about provenance than the Docker Hub is. Note that there are alternatives to the Hub with better provenance stories e.g: https://access.redhat.com/search/#/container-images (from https://securityblog.redhat.com/2014/12/18/before-you-initia...) This might make things a bit more awkward than it was before, but it's still not the same as raw LXC.

I feel your anger and I think it's understandable, but that doesn't mean things won't get better.

Re: The sad state of sysadmin in the age of containers

#83

I was doing sysadmin the "right way" a long, long time ago, and I don't see much difference. Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. There's no wisdom or security to be gained from the act of running "make", much less "make install".

> There's no wisdom or security to be gained from the act of running "make", much less "make install".

You were not doing sysadmin right. DESTDIR and checkinstall are two vital tools that are learned from the mistakes of make/make install.

Re: The sad state of sysadmin in the age of containers

#84
post #24

As an ex sysadmin I really like the container infrastructure. Manage the whole configuration on the main machine with puppet and deploy the blackbox applications (everything ruby and java related) with docker/rocket.

Maybe you can send a copy of your BRMS to your competitors while you are it.

Re: The sad state of sysadmin in the age of containers

#85
post #75
post #61

Earlier quoted context omitted.

There's a huge difference. > Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. What matters is that the source code is auditable. It only takes one person to investigate something suspicious, raise a flag and get it fixed. This is certainly still true for Debian - not being a…

Assuming you: - trust your compiler and linker - trust your tar extractor / package manager / whatever - trust your editor - trust your http library (or whatever you used to download/distribute the code)

It comes down to trusting two key things. Trusting your initial distribution download (which contains the package signing keys), and trusting the toolchain (in a Reflections on Trusting Trust way).

But the deeper you go, the harder it is for malicious code to reside there. In theory it's possible, but in practice I'd like someone to show me some code somebody could have written into the toolchain a decade ago, without hindsight, which could still exist today.

Whichever way, it's clearly far tougher for a malicious actor to compromise a system by injecting something into a distribution ecosystem than it is to inject a signed-by-unknown-reputation binary-only package into the Maven ecosystem.

Re: The sad state of sysadmin in the age of containers

#86
post #80

This rant is about containers, prebuilt VMs, and the incredible mess they cause because their concept lacks notions of "trust" and "upgrades". Prebuild VMs? Sure, I wouldn't touch them except for evaluating a project, and for commercial software you may not have a choice. But docker containers at least usually provide a dockerfile that describes exactly how a binary image is built. You just clone the source repo, aud…

then you are doing containers wrong...

The old-school sysadmins I know scoff at Docker's idea of 'containers'. Linux containers were already a thing, and don't need an entire copy of an OS ported around with them. To them, containers are a way of enveloping a process to limit it, not a way of distributing packaged software. They may or may not be doing 'docker' right, but they certainly know what 'linux containers' are.

Re: The sad state of sysadmin in the age of containers

#87
post #41
post #12

Earlier quoted context omitted.

> Many people have this weird aversion to doing basic sysadmin stuff with Linux. What makes it weird is that it's really simple. Often easier than figuring out another deploy system. While I agree with the articles main points - the GNU build system is far from simple. Basically an arcane syntax limited to unix-based systems and 5 or 6 100+ page manuals to cover. It doesn't excuse it - but I think it's easy to see wh…

Maintaining autoconf/automake stuff is a pain. Using it is usually as simple as "configure;make;make install". It doesn't do dependency management though, which is an externalised cost. But that's what rpm/deb do. I see the attraction of containers and disk image based management. It's much less time consuming. But it's very much the opposite of ISO9001-style input traceability.

> Using it is usually as simple as "configure;make;make install".

"Usually" indeed. Because if it breaks, you do need to know the implementation details to figure out what's wrong.

Re: The sad state of sysadmin in the age of containers

#88

Earlier quoted context omitted.

:-) I managed to get haddoop running on a small cluster from scratch Michael Nolls turtorial is a good starting point. Full stack should mean you can and have used a soldering iron in anger and also have at least a CCNA level of networking.

When you say anger, do you mean to threaten the developer who wants to run `chmod 777 /var/www` when their just-installed php app released in 2003 won't allow uploads? Edit: Maybe I should have added a /sarcasm to my comment?

"in anger" means used in a real-life situation, not just playing around.

Re: The sad state of sysadmin in the age of containers

#89
post #4

This bothers me as well. Even tasks as simple as adding a repository are now being "improved" with a curl | sudo bash style setup[1]. However, installing from source with make was (and remains) a mess. It may work if you're dedicated to maintaining one application and (part of) its stack. But even then it usually leads to out of date software and tracking versions by hand. Many people have this weird aversion to doin…

I have found a lot of these platform as a service providers are way more complicated than doing things from scratch.

Re: The sad state of sysadmin in the age of containers

#90

Earlier quoted context omitted.

:-) I managed to get haddoop running on a small cluster from scratch Michael Nolls turtorial is a good starting point. Full stack should mean you can and have used a soldering iron in anger and also have at least a CCNA level of networking.

When you say anger, do you mean to threaten the developer who wants to run `chmod 777 /var/www` when their just-installed php app released in 2003 won't allow uploads? Edit: Maybe I should have added a /sarcasm to my comment?

    alias fix-permissions="chmod -R 777 /"
Post reply on HN