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

vitavonni.de

Post reply on HN
Print view View original

131–140 of 466 posts

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

#131

Post by rimantas »

hultner wrote: post #119
blfr wrote: 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've seen people copy pasting stuff along the lines of `wget --no-check-certificate | sudo sh` into their terminals from some random internet source. I'm pulling my hair saying are you even aware of what you're doing?

What do you expect them to do, download .tar.gz, extra, read every line of code and them make; make install? Or just make; make install? How is that any different?

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

#132

Post by Nursie »

prottmann wrote: post #115
Nursie wrote: post #56

Earlier quoted context omitted.

>> A container is a container, as long as docker itself has not bug, the container can only harm the containers content. Presumably a container has network access of some sort? Malicious code could start probing and attacking anything exposed that way. >> this will be a problem for Docker, VMs, Real-Servers, whatever too. The implication is that you wouldn't get into this situation with a 'Real-Server' so easily, bec…

But you assume that a container HAS full network access. A firewall must be configured, but a firewall must be configured for a VM too. My point is, that their is not so a huge difference for production systems.

>> But you assume that a container HAS full network access.

No, I'm presuming it has some sort of network access, a malicious container could (for instance) still probe other containers for vulnerabilities, serve malware etc etc without full network access.

>> A firewall must be configured, but a firewall must be configured for a VM too. My point is, that their is not so a huge difference for production systems.

If you're downloading VM images from somewhere and running them without checking what's in them you'll run into the same problem, sure.

The problem being pointed out here is that when applications are bundled outside of the purview of a packager like debian you -

  - don't have as much trust in the origin of the app
  - don't have an easy way to keep up on library patchlevels etc for security

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

#133

Post by gregor7777 »

mauricemir wrote: post #44
hurin wrote: 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…

I have never under stood why some many people are not ok with using the command line. A few years back we had an issue where a mysql script was over the limit for phpmyadmin - my fairly experienced colleague he was unaware that you could log into the cli and use mysql from the cli.

I'd like to think this post is an exaggeration.

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

#134

Post by vacri »

mike_hearn wrote: post #108
geocar wrote: post #25

Earlier quoted context omitted.

Makefiles don't really enter into it and getting software signed by the developer isn't that valuable or useful. The value of debian is not that they package (or repackage) everything into deb files but that they resolve versioning and dependancy conflicts, slip security fixes into old versions of libraries (when newer version break API/ABI), and make it possible to integrate completely disparate software into a syst…

Debian has a terrible track record. Just look at the OpenSSL/Valgrind disaster. As a former upstream developer myself (on the Wine project), all Linux distros found unique ways to mangle and break our software but Debian and derived distros were by far the worst. We simply refused to do tech support for users who had installed Wine from their distribution the level of brokenness was so high. You may feel that develop…

I find it weird that you consider 'packaging' to be something a sysadmin should do, but 'building' to be something they should not do. Aren't they both forms of 'prepping code for use'?

And then state that you don't want your own software packaged. So, if a sysadmin is not allowed to build and not allowed to package, how are they supposed to get your code into production? "curl foo | sh"?

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

#135

Post by Nursie »

prottmann wrote: post #114
kryptiskt wrote: post #76

Earlier quoted context omitted.

> A container is a container, as long as docker itself has not bug, the container can only harm the containers content. So given that there are no bugs and as long as the Linux kernel is free from local privilege escalation exploits. That seems long odds to trust in.

The same trust i have in a VM or a RM.

Not true if the software in your VM or RM is managed by a package manager and comes from a place that issues security updates, patches etc.

One of the criticisms in the article is that much of what's going on now, either with containerisation or weird build systems like Hadoop's, misses out on this.

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

#136

Post by vacri »

kibibu wrote: post #75
rlpb wrote: 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)

Trust isn't binary. It's a scale of weighted risks.

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

#137

Post by caw »

rickette wrote: post #97
DomreiRoam wrote: post #10

"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." You should setup a maven repository (Nexus, Artifactory) for your organisation if you want to have more control on binaries. Seems that artifactory can host docker files: https://www.jfrog.com/confluence/display/RTF/Docker+Reposito...

Right, do folks really belief Maven, Ivy, Gradle, Sbt are tools you use in production? These are developer tools for use on workstations and CI servers. If you want to promote your stuff to other environments like production use your own private repository (Nexus, etc).

They may be if you have a team without much sysadmin experience. The way you develop could be the way you deploy to production.

These are the same teams that have overprivileged accounts for the database or sudo-enabled users running applications or chmod 777 all over the place.

Even things like Chef cookbooks have this going on. If you want to build from source because it's not in your repository, then you're necessarily going to need to drag in sbt or gradle. (see https://github.com/hw-cookbooks/kafka/blob/develop/recipes/d... as an example). Sure you could figure out the mirrors and download the correct binary from the website. You could also use this recipe to compile everything and then package it up to host yourself. (Both of these actions require writing custom recipes). Not everyone has time to do this, and this magical recipe you found online works great on the development server! Just add it to the production server and now we've just used sbt in production on a software team.

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

#138

Post by lighthawk »

> Update: it was pointed out that this started way before Docker

Yes, like in the 90's, at least, when people started using Java. Even prior to Maven there were jars, and we didn't really know what was in them. And prior to that, I didn't understand how every piece of software or hardware worked.

I was a big proponent of Gentoo when it came out because of building everything from source, but the fact is: I don't have time to look through and understand every line of code. Even compilers can and have injected malicious behavior in the past. Firmware cannot even be trusted.

Some level of trust and reliance on others needs to be there. While it is true that there will always be people that betray that trust, without the trust, we would be hermits living alone off the land- which may not be so bad, but that's another story.

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

#139

Post by mercurial »

microtonal wrote: post #125
mike_hearn wrote: post #102

Earlier quoted context omitted.

Maven packages aren't actually unsigned either. They're downloaded over SSL and to get into Maven Central you need to sign with a GPG key. The problem is that you normally cannot find a path to the developers through the web of trust, of course, but that's not Maven's fault. That's the fault of the web of trust (more accurately called "handful of strings of trust"). Debian/Red Hat code signing doesn't prove very much…

The problem is that you normally cannot find a path to the developers through the web of trust, of course, but that's not Maven's fault. It is Maven's vault. Debian could have taken the same approach, but instead they have decided to vet prospective developers for a few years, and use one signing key for package indexes. As a result, in Debian: - It is feasible to actually check packages, because you don't need a lar…

> It is Maven's vault. Debian could have taken the same approach, but instead they have decided to vet prospective developers for a few years, and use one signing key for package indexes.

Yes. But this creates a much higher barrier to entry. As usual, it is a trade-off, but it is obvious that with a Debian-like system, the number of packages on Maven/CPAN/Pypi/Rubygems would be considerably smaller.

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

#140

Post by gibsonje »

I thought this post was overly cynical and full of generalizations. I don't really understand what point is trying to be made here.

"Everybody" "Nobody" "Nobody" "None of" "everything got Windows-ized" every sentence is a broad generalization on top of cynicism so it's hard to find any value in the point trying to be made.

Post reply on HN