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

181–190 of 466 posts

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

#181

Post by mauricemir »

stephenr wrote: post #55
mauricemir wrote: post #14

Earlier quoted context omitted.

:-) I managed to get haddoop running on a small cluster from scratch Michael Nolls turtorial is a good starting point. Full stack should mean you can and have used a soldering iron in anger and also have at least a CCNA level of networking.

When you say anger, do you mean to threaten the developer who wants to run `chmod 777 /var/www` when their just-installed php app released in 2003 won't allow uploads? Edit: Maybe I should have added a /sarcasm to my comment?

I think branding them is going a bit to far

      ...
For a first offense

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

#183

Post by shanemhansen »

TeMPOraL wrote: post #95
tormeh wrote: 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.

https://xkcd.com/1168/ comes to mind. And yes, I Google half of the command invocations too (but usually type them in by hand so that I can remember them faster instead of copy-pasting).

I usually get tar right on the first try. I only have to remember 2 variants (extract file and create file):

    tar xf ./foo #automagically works with bz2 and gz files
    tar cf /tmp/out.tar . #add z for compression

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

#184

Post by dschiptsov »

TeMPOraL wrote: post #111
dschiptsov wrote: post #101

What is really ironic is that none of this "tools" solves any fundamental problem of so-called version hell and none of this containers are fundamentally different from ./configure --prefix=/xxxx && make && make -s install with or without following chroot /yyyy The big "innovation" of having so-called "virtual env" (they call it "reproducible [development] environment) for each "hello world" (a whole python/ruby/java…

> Programmer must be aware of which version of what API implemented with what version of package or library he using and explicitly assert and maintain these requirements, like all the very few sane software projects (git, nginx, redis, postgress) do. Except that when you're doing anything that looks like an actual end-user application (as opposed to infrastructure), you end up using dozens of libraries which themsel…

> as the only reasonable way for giving a service application to people to deploy on their machines

Take a look how git or nginx compiles from the source on any machine imaginable.

There is absolutely no fundamental problem with ./configure; make; make install.

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

#185

Post by exelius »

erikb wrote: post #178
exelius wrote: post #173

System administration is as important as ever. Docker and other containers just simplify system administration across many different machines. The standard Unix user land tools are excellent and very flexible, but they are fucking god awful at configuration management. Docker solves the problem of "how do I make sure I have the same versions and configurations of everything on all 500 of my compute nodes without havi…

Sorry, I don't see a response to the key point here. If Docker doesn't sign its containers and doesn't check signatures before applying one to a running system, then it's simply not secure. It may be one little feature of all the things Docker does for you. But that's what's lacking according to the blog post's author.

But Docker does sign containers and has since 1.3. It needs to be configured properly though. Maven signs packages by default and won't install dependencies unless the checksums match (large orgs run their own Maven repositories and only proxy trusted repositories).

This is why you still need system administrators. We just call them DevOps now. Any decently large organization would have a Docker SME whose job it is to know how to set up Docker securely.

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

#186

Post by shanemhansen »

juliangregorian wrote: post #158
jannic wrote: post #147

Earlier quoted context omitted.

No, you don't: http://thejh.net/misc/website-terminal-copy-paste

Okay, but this relies on CSS trickery. If you had navigated to a text URL this would not be a vector.

What's a text url? The only way I can see this not being a vector is if you browse with css (and javascript for good measure) turned off. Or use lynx.

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

#187

Post by shanemhansen »

pjc50 wrote: post #41
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…

Maintaining autoconf/automake stuff is a pain. Using it is usually as simple as "configure;make;make install". It doesn't do dependency management though, which is an externalised cost. But that's what rpm/deb do. I see the attraction of containers and disk image based management. It's much less time consuming. But it's very much the opposite of ISO9001-style input traceability.

Sorry, I don't know what ISO9001 is, but isn't deploying an image extremely conducive to traceability? No non-deterministic scripts are ran on production servers.

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

#188

Post by tobz »

An interesting point that I didn't see the author bring up is the concept of how Docker images can be built in a layered fashion, and the potential for a false sense of security.

For example, you start with some sort of base image -- say phusion/baseimage-docker[1] -- and proceed to layer your application on top of it. You "trust" Phusion. They do Phusion Passenger, it's a real piece of software you heard of, and it's not some random person on the internet.

At some point, there's a bug, a problem, a security flaw, and you're waiting on them to fix it... nothing, nothing. Maybe they get hacked and their base image is now infected. I haven't bothered to look, but I'm guessing it would be a trivial amount of work to start the process of culling the most popular base images used by public Dockerflles, looking for the biggest trojan horse.

It seems like the whole model is ripe for pushing an understanding of what is actually running on a machine -- soup to nuts -- to the way side, and establishing a non-existent trust on the building blocks you're using, lulling people into a false sense of security about their containers. A lot of people already believe that they're already doing something much more secure by running containers, and arguably, they are... except for all of the places where malicious software can be added in, and the potential container breakout techniques.

[1] https://github.com/phusion/baseimage-docker

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

#189

Post by sciurus »

stephenr wrote: post #169
jkyle wrote: post #160

Earlier quoted context omitted.

> Unfortunately I was stupid enough to ddg it (duckduckgo it, as opposed to google it) and apparently this exact use-case was previously the recommended way of installing RVM[2] Not only "previously", it's the current recommended way to install rvm. From their front page: >> curl -sSL https://get.rvm.io | bash -s stable [1] http://rvm.io/

Oh I agree there are problems still, but its an improvement over the previous - it's using HTTPS and it's calling the RVM domain - before it was plain HTTP to bit.ly

Also the installer is now signed via GPG.

https://rvm.io/rvm/security

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

#190

Post by apk17 »

lmm wrote: post #43
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…

> 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. Maven has exactly the same capabilities as deb does - you can depend on versions, depend on a range of poss…

> No, it's just the opposite. All the dependencies and project structure are right there in declarative XML. It's what make should have been.

When make was written most machines would have just exploded at the sight of a typical build.xml, and downloading tens or hundreds of packages from anywhere was simply out of the question.

Also, 'dependency' means something completeley different in make as opposed to maven - I don't think modern build systems do even care much for make-style deps.

Post reply on HN