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

41–50 of 435 posts

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

#41

Post by ebiester »

megaman22 wrote: post #14
pc86 wrote: post #5

> None of these "fancy" tools still builds by a traditional make command. Is there anything more "get-off-my-lawn" than "These tools don't use the thing I like!"

But I just don't understand why we have to have 47 half-built over-complicated build systems or job runners or whatever the new fad term is for every language, when there's something that does what they all do, is battle-tested, and has been around for decades. Everyone repeat after me. Makefiles are not scary. I can write a shell script. Do I really need to learn grunt/gulp/webpack/npm/rake/fake/maven/gradle/ant and…

I've written a makefile from scratch.

My challenge to you: I want a makefile that has 20 third party dependencies and can be built on osx, linux, and windows.

I can do this within an hour with gradle, ant, or maven. The ecosystem doesn't exist for this in make, and anything I could come up with to make it possible would end up being a tool that would look like automake and the monstrosity that it entails.

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

#42

Post by YouAreGreat »

> The first internet worm spreading via flawed docker images?

Good question, why don't we see exploits of all that implicit trust to the degree that, eg, the DOS shareware scene gave your PC visible virus infection, or the early internet gave us worms that would bog down the whole net?

My attempt at an answer: Because the black hats aren't hobbyists anymore. Visibility is for amateurs.

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

#43

Post by realharo »

megaman22 wrote: post #14
pc86 wrote: post #5

> None of these "fancy" tools still builds by a traditional make command. Is there anything more "get-off-my-lawn" than "These tools don't use the thing I like!"

But I just don't understand why we have to have 47 half-built over-complicated build systems or job runners or whatever the new fad term is for every language, when there's something that does what they all do, is battle-tested, and has been around for decades. Everyone repeat after me. Makefiles are not scary. I can write a shell script. Do I really need to learn grunt/gulp/webpack/npm/rake/fake/maven/gradle/ant and…

As a counter-example, this is a few hand-picked sections from a Makefile for OpenSSL.

https://gist.github.com/anonymous/d885c3bb66a319d22f9d60c1ef...

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

#44

Post by bovermyer »

rdeboo wrote: post #12
bovermyer wrote: post #8

Earlier quoted context omitted.

I think the author's point was this: "Unless you compile it yourself, you can't trust it."

How is it more secure? Do you read the entire source code to search for backdoors?

I didn't say I agreed with the statement. Which I don't.

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

#45

Post by [deleted] »

bovermyer wrote: post #8
cwyers wrote: post #3

> And since nobody is still able to compile things from scratch, everybody just downloads precompiled binaries from random websites. Often without any authentication or signature. Apache has official mirrors that host repo files for various package managers so you can install using apt-get or whatever it is that replaced yum (dnf? dnf): https://www.apache.org/dyn/closer.lua/bigtop/bigtop-1.2.1/re... So precompiled bi…

I think the author's point was this: "Unless you compile it yourself, you can't trust it."

[deleted]

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

#46

Post by sushisource »

dagss wrote: post #24
megaman22 wrote: post #14

Earlier quoted context omitted.

But I just don't understand why we have to have 47 half-built over-complicated build systems or job runners or whatever the new fad term is for every language, when there's something that does what they all do, is battle-tested, and has been around for decades. Everyone repeat after me. Makefiles are not scary. I can write a shell script. Do I really need to learn grunt/gulp/webpack/npm/rake/fake/maven/gradle/ant and…

I wish there was something like an updated Make, a tool that works for everything but updated to 2018. For instance Make works based on timestamps and therefore works very poorly together with git. Switch to another branch and you can get weird effects based on what files were updated and not and often trigger needless rebuilds. And everyone uses git these days. GNU Make, just using hashes instead of timestamps, woul…

Gradle does this. There is definitely a few extra seconds of overhead compared to make, but that's hardly intolerable.

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

#47

Post by w4tson »

cwyers wrote: post #13
bovermyer wrote: post #8

Earlier quoted context omitted.

I think the author's point was this: "Unless you compile it yourself, you can't trust it."

There are over 2.9 million lines of code in Apache Hadoop alone, not counting dependencies. If you can't trust Apache, you can't trust Hadoop, regardless of whether or not you can compile it yourself.

EXACTLY. It’s just software. There’s no easy answers here. There’s vulns in everything from hypervisors to node modules. Building from scratch isn’t going help.

Pragmatic solutions where possible. Like scanning containers, using OWASP tools on your repos etc

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

#49

Post by leetbulb »

bovermyer wrote: post #8
cwyers wrote: post #3

> And since nobody is still able to compile things from scratch, everybody just downloads precompiled binaries from random websites. Often without any authentication or signature. Apache has official mirrors that host repo files for various package managers so you can install using apt-get or whatever it is that replaced yum (dnf? dnf): https://www.apache.org/dyn/closer.lua/bigtop/bigtop-1.2.1/re... So precompiled bi…

I think the author's point was this: "Unless you compile it yourself, you can't trust it."

I believe this is true and if so, then the argument should be against package managers, not Docker specifically. Most (if not all) of the official Docker images are built either by compiling the binaries from source, properly installing the binaries from the base distro's package manager, or pulling and verifying a pre-built binary from the vendor's website. For most cases, I don't see anything wrong with any of these.

Personally, what I like is no longer having to setup arch specific build machines containing all of the build tools and dependencies for all binaries that I wish to self-compile. Instead, I either use the vendor's Dockerfile which already contains everything it needs to build from source or I simply write my own if there is not one available. Building and distributing these binaries in the form of Docker images is a breeze using Gitlab CI and container registry and is just as easy with a small VPS and Docker Hub.

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

#50

Post by eropple »

GalacticDomin8r wrote: post #40
eropple wrote: post #19

Earlier quoted context omitted.

Makefiles aren't scary. But they're also not particularly good. I use Rake (or Gulp, or whatever) because then I can use Ruby (or JavaScript, or whatever). Shell plumbing is fine for informal and small-scale stuff, and I make my code conform if somebody down the line (who may be me) wants to get out their duct tape, but the world is more complex than what /bin/sh can see. Shell is the lowest common denominator. Expec…

> but the world is more complex than what /bin/sh can see That is blatantly false, but I get the premise behind it. Writing and maintaining complex stuff in bourne or bash is not fun or easy. I always use bourne until certain level of complexity or awkwardness is reached. It's pretty easy to write and dead simple to troubleshoot.

Blatantly false? OK, put up. Forget `sh`'s JSON parsing, I'll make it easy on you--show me its arrays. Arrays, plural, you can't use $@ as a bail-out; I need more than one. Show me hashes. Show me sets. Show me the basic building-block primitives of software, because build pipelines are software. It's 2018. If your language can't do this stuff without babysitting, it effectively can't do it because nobody's got the time to babysit your easy-25%-of-Perl language

And yeah, I did say `sh`, because that is what you can practically be expected to have kicking around alongside `make` on a system where I can't just install something worthwhile. If I have them, then there's no reason to write much harder to troubleshoot shell scripts (and, thank you quotebarf, more likely to be incorrect) than to open Pry.

Post reply on HN