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

91–100 of 324 posts

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

#91

Post by Doxin »

eejjjj82 wrote: post #47
LockAndLol wrote: post #32

Earlier quoted context omitted.

`curl | sudo bash` should never have become a thing in the first place. To me, it's the most "WTF?" mode of installing anything. Especially when the source is HTTP. In what world is that secure? Pity Qubes is so heavy, otherwise I'd be using it

would you feel better if your Makefile looks like this: install: [ $(id -u) -ne 0 ] && echo 'please run sudo make install' || curl https//my.thing | /bin/sh it goes back to what jve said - it's a matter of trust. how often do you blindly run 'sudo make install' w/o reading the entirety of the build script? all the time I bet - it's because you trust the source

Basically all makefiles you run into in the wild for mature projects allow you to install it with a prefix. e.g. into the home folder. No need to sudo anything if you do that.

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

#93

Post by weberc2 »

Tade0 wrote: post #35
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…

Truth be told the whole front-end ecosystem relies on those servers being available, so in their absence any development everywhere would grind to a halt - as it almost did during the left-pad scandal. While I agree that this is not exactly the sanest approach, within the ecosystem there's no incentive to work differently. Also, like someone else mentioned - dependency hell only got worse over time - setting up a new…

There’s a pretty straightforward solution to this problem which is to run your own NPM server even if it’s only a caching proxy. For some orgs, the uptime provided by the third party servers is sufficient.

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

#94

Post by lmm »

Doxin wrote: post #87
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…

That's quite a negative view of the situation. The debian maintainers definitely don't insist that everything has to do things the apt-way. They only insist that packages for the official repos do so, which seems sensible enough to me. Everyone is still free to build their own deb packages or distribute their applications through install scripts or app images or any one of a hundred thousand different ways to distrib…

It's not just a question of being in the official repos. Even if you're running a private repository, the deb tooling is not suitable for building many kinds of software: it's unwilling to play nice with "external" dependencies, and still single-platform and limited in its functionality.

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

#95

Post by weberc2 »

mateuszf wrote: post #23
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…

It can be done using package managers too, for example using Nix. The problem here is not related to distribution method but rather dependency hell in javascriptland.

I would say the main issue is that Nix is super difficult and requires you to intimately know your entire dependency tree down into Linux particularities. JavaScript makes matters worse, but even packaging a nontrivial Python package pulled directly from Pypi is often difficult.

I want to like Nix, but it is far too pedantic to be practical. And this isn’t even mentioning the usability issues.

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

#96

Post by AndyMcConachie »

Things will break and I will need to be able to debug them.

New versions will be released and I will need to be able to upgrade to them.

Bugs will be found and I may need to know if I or my users are experiencing them.

Security holes will be found and I will need to either upgrade, or mitigate them in some other fashion.

All of the above realities mean I want well defined and understandable software. The less well defined and understandable a deployment is, the less I am interested in deploying it. Complexity is a cost, and this cost cannot be waived by simply chucking everying into a container.

Simplicity means cheap. It means time not wasted and it means fewer headaches.

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

#97

Post by dsr_ »

hvidgaard wrote: post #74
dsr_ wrote: post #42

Earlier quoted context omitted.

The whole point of having a distro with a good reputation is that you can incrementally outsource your trust to them, one package at a time. OpenSSL needs a fix? One package update per machine, and if you have lots of machines, you update that. With VMs, you can use the same tools you use with any other machine. With containers, you are responsible for figuring out which ones need which packages and how to re-build t…

If you can build on your distro of choice, you can rely on the same security audit and process. Keep track of the packages you link against and include in your image, and just rebuild your images when a new security update comes along. Then you replace the running one.

See that "keep track" bit? It's expensive unless you build a tool to do it for you -- which is what I said previously.

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

#98

Post by gchamonlive »

pram wrote: post #6

Terrible article IMO. Hadoop is an awful mess, but it has nothing to do with Docker, which is simplistic in comparison. "Ever tried to security update a container?" Yes, I have! In fact you can maintain patch compliance in a container pretty much the same way you'd maintain a VM or bare metal Linux installation!

I was confused when I read the article. I kept thinking it was actually a problem with hadoop and not docker, since docker is nothing but an abstraction on top of the Linux kernel.

I remember trying to produce a viable alpine based docker image for a flask backend service we had thar produced pdf using latex. Dependencies were really hard to pin down, had to resort to open issues on github, but utimately all packages were on the distribution, so it is not a problem with the tech itself, but the archaic way Java lets people to produce applications

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

#99

Post by AndyMcConachie »

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…

s/younger/less experiened/

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

#100

Post by dsr_ »

regularfry wrote: post #53
dsr_ wrote: post #42

Earlier quoted context omitted.

The whole point of having a distro with a good reputation is that you can incrementally outsource your trust to them, one package at a time. OpenSSL needs a fix? One package update per machine, and if you have lots of machines, you update that. With VMs, you can use the same tools you use with any other machine. With containers, you are responsible for figuring out which ones need which packages and how to re-build t…

The "one package at a time" model assumes you care about per-instance uptime and bandwidth costs. The "reset the world" model assumes rebuilds and reboots are cheap enough not to have to. I don't think either is necessarily wrong; there's not a huge distance between `apt-get install unattended-upgrades` and a daily (weekly, whatever) container rebuild except that you need to cron the latter. Unless you're using a dif…

You need to make the decisions, keep track, and do the work. If you've got the tools made for you, excellent. Otherwise you also have to build and maintain the tools -- which is my point.
Post reply on HN