Live data from Hacker News

The sad state of sysadmin in the age of containers

vitavonni.de

121–130 of 466 posts

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

#121
post #92

Earlier quoted context omitted.

>[1] yes this is an exaggeration No, it's not :(

It's just automated copy-pasting of commands you don't understand from the internet, which is something everyone who runs Linux (and is not a wizard) does all the time. It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. Unfortunately, this has never been a priority in Unix-land as far as I've gathered.

I would argue that anyone who is reasonably comfortable in a command line would resort to `man command`, `command --help` or `command -h` before googling for usage.

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

#122
post #92

Earlier quoted context omitted.

>[1] yes this is an exaggeration No, it's not :(

It's just automated copy-pasting of commands you don't understand from the internet, which is something everyone who runs Linux (and is not a wizard) does all the time. It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. Unfortunately, this has never been a priority in Unix-land as far as I've gathered.

It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing.

But it isn't all that hard to understand a clean Unix. I have never copied or typed a command that I don't understand.

One problem may be that most Unices these days is not as clean anymore as, say OpenBSD or NetBSD. E.g. the recent X stack, with D-BUS, various *Kits, etc. is quite opaque. This madness was primarily contained to the desktop and proprietary Unices, but seems to spread through server Linuxes these days as well (and no, this is not an anti-systemd rant).

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

#123
post #99

The contract between operations and dev (as concepts, not as people) is in need of renewal. To my mind, that was what "devops" was supposed to be, but it's been a bit of a dogpile in the years since the term gained popularity. Systems are opaque to most developers, and many developers wish to make their software opaque to the system on which it runs. This is a failure on behalf of our entire profession, not any one g…

It would be nice to have a well known 'devops manifesto'. I google'd it and came across this: https://sites.google.com/a/jezhumble.net/devops-manifesto/. Which I think is actually pretty decent - the emphasis on cross functional product teams, for instance.

In my mind, that is largely what devops is about - team ownership of the entire product, which includes infrastructure. Instead of having a silo'd 'ops' team writing ansible scripts and doing deployment, this should be part of the team (which could mean having an opsy guy on the team).

Anyways, as it pertains to containers, I think containers are more a practice than a principle. It tends to happen naturally when you want reproducible builds and continuous delivery. It's not really about making systems opaque to software, imo, but rather making your product artifacts reproducible (if you rely on running ./configure; make at deploy time, you never know what you'll end up with since dependencies are dynamically determined).

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

#124
post #92

Earlier quoted context omitted.

>[1] yes this is an exaggeration No, it's not :(

It's just automated copy-pasting of commands you don't understand from the internet, which is something everyone who runs Linux (and is not a wizard) does all the time. It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. Unfortunately, this has never been a priority in Unix-land as far as I've gathered.

It's not the same by any measure.

When you read the script in a browser, than pastes it in a terminal, you know that "scp -r ~/.ssh u@somehost.com" isn' there.

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

#125

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 e…

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 large WoT.

- You know that the maintainer of a package was a least vetted for some time before they could put anything in the archive.

With Maven:

- It's infeasible to check the signatures, since nearly no one has a complete enough WoT.

- Anyone can submit a library, no vetting necessary.

- Maven does not check signatures by default.

So, basically the only thing you can do in Maven is hand-pick a small set of libraries. Verify them in some way and stick to specific versions, putting their checksums in your POM. Unfortunately, as the article already touches upon, too many Java libraries pull in half of the internet, so it may not be very practical.

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

#126
post #25
post #11

make is the least-auditable build tool imaginable. You don't have to obfuscate a Makefile, they come pre-obfuscated; you could put the "own me" commands right there in "plain" Make. Not to mention that it's often easier to tell whether a Java .class file is doing anything nefarious than whether a .c file is. How many sysadmins read the entire source of everything they install anyway? Maven, on the contrary, is the bi…

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…

> 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 system. They also have a great track record at it.

The analog of the aspects of what Debian does that you're talking about here in the HStack world are companies like Cloudera, who, surprise, make their stuff available as debs and PPAs.

Building your own Hadoop from source and complaining that the resulting product is unvetted is sort of like doing a git pull of all the Linux dependencies and building that.

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

#129
post #92

Earlier quoted context omitted.

It's just automated copy-pasting of commands you don't understand from the internet, which is something everyone who runs Linux (and is not a wizard) does all the time. It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. Unfortunately, this has never been a priority in Unix-land as far as I've gathered.

It's really really bad, but people will continue doing it until commands/things become so easy we can actually understand what we're doing. But it isn't all that hard to understand a clean Unix. I have never copied or typed a command that I don't understand. One problem may be that most Unices these days is not as clean anymore as, say OpenBSD or NetBSD. E.g. the recent X stack, with D-BUS, various *Kits, etc. is qui…

> But it isn't all that hard to understand a clean Unix. I have never copied or typed a command that I don't understand.

Well, good for you. I can assure you that it's not the case for almost anyone who approached Linux after the likes of Mandrake were released and/or tried to make it work on anything different from a traditional server.

I'm all for trying to understand what one is doing (and I wholeheartedly agree with TFA's point), but the reality is that very few people in the world really understand all intricacies of one's operating system. This does not excuse poor security practices, but it explains their background.

Post reply on HN