Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

vitavonni.de

Post reply on HN
Print view View original

201–210 of 324 posts

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

#201

Post by takeda »

GordonS wrote: post #122
the_duke wrote: post #58

Earlier quoted context omitted.

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.

I have seen this many times, generally the high profile containers do that, and these issues are more common among my peers. This requires self discipline and containers were pushed as a panacea for environments where the discipline is lacking.

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

#202

Post by Zyst »

rumanator wrote: post #186
Zyst wrote: post #156

Earlier quoted context omitted.

Oh, check out Nix https://nixos.org/nix/ I use it for most of my dependencies, and software in OS X/Windows WSL/Linux It is a lovely environment to work with. Has completely changed how I feel about package management and the like. I know you were asking figuratively but something does happen to slot in that space.

> Oh, check out Nix Nix is a non-sequitur. Nix requires specific packages and package versions to be specified, and Nix requires the build process to be "free from side effects". That fails to address both problems stated by the OP, and actually try to reimplement what Debian's package building process already does. Other than trying to publicize Nix, your comment adds nothing to the discussion.

>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?

By having control over which required dependencies are downloaded. As Nix does. Why would you settle for not solving that problem?

Sorry to hear you don't think my comment adds to the discussion, but I'd disagree

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

#203

Post by HorstG »

xchaotic wrote: post #184
HorstG wrote: post #118

Earlier quoted context omitted.

Installing multiple versions is possible, given proper semver and good arguments for it: There are quite a few libfoo5, libfoo6, libfoo7 packages. What isn't and shouldn't be possible is installing libfoo 6.6.5 and 6.6.6 at the same time, because those should be compatible. And not being easy to replace (i.e. ABI- and API-compatible) means that security and bug fixes will be missed. Of course this is work for applica…

I think these are noble but naive approaches - we have been developing software for a few decades now and sometimes the software is not compatible without the developer knowing it. You should be able to use whichever version of the software you need.

"Whichever version you need" comes with the responsibility of providing security and bugfix upgrades in a timely fashion. Almost all developers fail spectacularly at this, with latencies in the order of months. This is clearly not viable.

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

#204

Post by GordonS »

Avamander wrote: post #185
GordonS wrote: post #176

Earlier quoted context omitted.

Sorry, I don't follow. If I have a makefile, I can inspect it and see what it does. If I have shell script (or indeed a makefile!) that calls `curl | bash`, I can inspect that shell script and see the URL that is used with curl, and then inspect the contents that the URL returns.

You can't see what comes from `curl | bash` before you actually pipe it to bash, click the link and read the article please.

OK, I see - in theory, an attacker in control of the backend could write a handler that could craft a bash script that writes different content when `curl | bash` is used.

TBH, while I take your point, I do think it's a little disingenuous of you to claim that "You don't have the opportunity" to inspect the script prior to executing it - you ordinarily will, but can't in the unlikely event of an attack like the article describes, which would require an attacker to be in full control of the web server.

Off the top of my head, this could be mitigated in a couple of ways:

1. Hash a known-good script and check the hash matches prior to executing (this does however mean that you need to update the hash every time the remote script is changed)

2. Use curl to download the remote script to a local file first, and provide the opportunity to inspect it prior to piping it into bash

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

#205

Post by solarkraft »

rumanator wrote: post #121
lmm wrote: 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?

Jealousy is the characterisation of exactly that behavior/aspiration to have everything managed through the OS's package manager. It's a nice effort, but for people not firmly within the ecosystem it's often a hard effort to justify to package something specifically for every distribution.

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

#206

Post by PaulHoule »

icedchai wrote: post #161
PaulHoule wrote: post #143

Uh... I've built Hadoop from source, it is not that bad.

I've also built it from source, admittedly back in 2012. It wasn't that bad, either! My concerns were building an AMI image, not "packaging" it in a more traditional sense.

I think most of the conventional image building tools are stupid. (e.g. they take something that could be done in 10 minutes and make it take an hour, are prone to failure because of too many round trips, ...)

I made rather complex images that included a large database (e.g. 30 GB) and Java apps, and found the easy way to do it was write a program that analyzes the problem, writes a shell script that builds a bastion and builds the software, then put that in the cloud-init... The machine "phones home" via SQS to tell the controlling server to shut it down and image it.

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

#207

Post by fargle »

JustSomeNobody wrote: post #59
jwr wrote: post #19

I recently had a similar discussion with people using npm for building a CSS framework library. I tried to explain the concept of getting a pre-downloaded tarball and using "make" (or similar) to produce target artifacts from source files in a deterministic, repeatable and reliable manner, without relying on any third-party servers being available and without pulling in dependencies that might have changed. It seems…

I don’t think it’s age so much as it’s “well, that’s just what everyone does now”. If you want to work in this industry you have to follow the herd; for better or worse. I certainly don’t agree with it, but people have bills to pay.

What if "well, that's just what everyone does" is just wrong? I trimmed the word "now" from the quote because lazy sloppy short-term thinking is nothing new. Good configuration management takes a lot of work and pays great returns, only not in the very short-term. It's not surprising that inexperienced devs will fall into this trap.

And just why do you "Have to follow the herd"? Pretty sure just about everything new and creative (good or bad) was a result of not following the herd. I recommend going where you need to go. If a herd starts following you, that's great. At least they'll be slipping and sliding on the shit you leave behind, not the other way round.

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

#208

Post by pjc50 »

xchaotic wrote: post #184
HorstG wrote: post #118

Earlier quoted context omitted.

Installing multiple versions is possible, given proper semver and good arguments for it: There are quite a few libfoo5, libfoo6, libfoo7 packages. What isn't and shouldn't be possible is installing libfoo 6.6.5 and 6.6.6 at the same time, because those should be compatible. And not being easy to replace (i.e. ABI- and API-compatible) means that security and bug fixes will be missed. Of course this is work for applica…

I think these are noble but naive approaches - we have been developing software for a few decades now and sometimes the software is not compatible without the developer knowing it. You should be able to use whichever version of the software you need.

> sometimes the software is not compatible without the developer knowing it

Sure, but this should be considered either a defect or something highlighted by a major version number jump.

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

#209

Post by briffle »

rumanator wrote: post #121
lmm wrote: 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?

you can use a tool like snap or appimage to pull down the newest full release of your software.. at least then, all the dependancies are 'bundled' into the image, and your not having people go randomly install crap from around the internet with no real way to update.

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

#210

Post by adgasf »

jeltz wrote: post #200
gerbilly wrote: post #114

Earlier quoted context omitted.

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…

Take a look at Ninja and Bazel. I ahree with you that CMake is worse than autoconf but I would argue that the tools which came after CMake are better than CMake and autoconf. So while there certainly are regressions not every new generation is worse than the previous.

Ninja is an optimized back-end for other build-systems (including but not limited to CMake). It's not really intended to be used directly.
Post reply on HN