Live data from Hacker News

The sad state of sysadmin in the age of containers

vitavonni.de

321–330 of 466 posts

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

#321

This 1 page poorly titled wrong rant is the #2 story on this site? "Ever tried to security update a container?" lol. you are doing it wrong. "Essentially, the Docker approach boils down to downloading an unsigned binary, running it, and hoping it doesn't contain any backdoor into your companies network." nope https://blog.docker.com/2014/10/docker-1-3-signed-images-pro... "»Docker is the new 'curl | sudo bash'«" no i…

I think you're wrong. I think most users are not installing trusted builds from their OS vendors. Piping curl to bash is incredibly common--many popular software packagers are doing it [1].

About a year and a half ago, I was playing around with Docker and made a build of memcached for my local environment and uploaded it to the registry [2] and then forgot all about it. Fast-forward to me writing this post and checking on it: 12 people have downloaded this! Who? I have no idea. It doesn't even have a proper description, but people tried it out and presumably ran it. It wasn't a malicious build but it certainly could have been. I'm sure that it would have hundreds of downloads if I had taken the time to make a legit-sounding description with b.s. promises of some special optimization or security hardening.

The state of software packaging in 2015 is truly dreadful. We spent most of the 2000's improving packaging technology to the point where we had safe, reliable tools that were easy for most folks to use. Here in the 2010's, software authors have rejected these toolsets in favor of bespoke, "kustom" installation tools and hacks. I just don't get it. Have people not heard of fpm [3]?

[1] http://output.chrissnell.com/post/69023793377/stop-piping-cu...

[2] https://registry.hub.docker.com/u/chrissnell/memcached/

[3] https://github.com/jordansissel/fpm

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

#322
post #205

Earlier quoted context omitted.

Recursively searching through all files in the current folder (aka the normal use case for grep) is accomplished by using "grep -r". It's on line 270 in "man grep". And that assumes that you know what grep is at all. Would it have hurt so much to call grep "regexsearch" instead? Maybe -r could be the default?

Use the built-in search. Edit: the rest of my comment (somehow submitted to soon!) man grep /recurs

or use 'grep':

    $ man grep | grep recursive
                  directory,  recursively,  following  symbolic links only if they
                  Exclude  directories  matching  the  pattern  DIR from recursive
           -r, --recursive
                  Read all files  under  each  directory,  recursively,  following
           -R, --dereference-recursive
                  Read all files under each directory,  recursively.   Follow  all

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

#323
post #269

I agree that many of these convenient setups are embarrassingly sloppy, but it's the sysadmin's responsibility to insist on production deployments being far more rigorous. No one can tell you how to build hadoop? Well, figure it out. Random Docker containers being downloaded? Use a local Docker repo with vetted containers and Dockerfiles only. I don't even allow vendor installers to run on my production systems. My e…

>> No one can tell you how to build hadoop? Well, figure it out. I get the impression that several people working on debian couldn't work this one out!

I think most people who use debian would tend to install things using debian packages, which in this case usually means adding cloudera to your apt sources list and using apt-get.

It is a pretty straightforward process:

http://www.cloudera.com/content/cloudera/en/documentation/cd...

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

#324

I agree that many of these convenient setups are embarrassingly sloppy, but it's the sysadmin's responsibility to insist on production deployments being far more rigorous. No one can tell you how to build hadoop? Well, figure it out. Random Docker containers being downloaded? Use a local Docker repo with vetted containers and Dockerfiles only. I don't even allow vendor installers to run on my production systems. My e…

> it's the sysadmin's responsibility to insist on production deployments

What decade are you from? No startups are hiring sysadmins to do any kind of work anymore. They're hiring "dev-ops" people, which seems to mean "Amateur $popularLanguage developer that deployed on AWS this one time."

That's the whole problem with the dev-ops ecosystem. None of these dev-ops people seem to have any ops experience.

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

#325
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 posted a slightly provocative tweet about this, and the CEO of NodeSource took exception... sad days.

https://twitter.com/kylegordon/status/590860756075294721

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

#326

Earlier quoted context omitted.

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

that only becomes applicable if you use their "manual" install steps on that security page.

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

#327
I completely agree with this except I think of it more as a problem of release engineering rather than system administration.

The trouble is, the sysadmin's job is to deploy things. The developers job is to write code. Often release engineering isn't thought of at all or if it is it's given to the last qualified or least suspecting folks without any requirement from operations.

Developers aren't taught about release engineering or deployment in school at all. In fact, it seems to me most university curricula do everything possible to hide all that from students.

Compounding that is the developers desire to get new code out conflicting with the sysadmins requirement to keep things stable in the face of limited QA automation. This leads to the common conflict between dev and ops.

This is to me a large part of what has led to the DevOps movement. This gives the developers information about the deployment and perhaps even access to it or a version of it and/or a voice in deciding how things are deployed.

Hopefully we can standardize things widely enough that universities can teach this without fear of focusing on useless technologies that will be discarded in 3-5 years.

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

#328
post #54
post #37

Earlier quoted context omitted.

Same for "framework" which is: I have no idea what I'm doing

Sometimes yes, but sometimes you started writing CGIs in C, then Perl, than you wrote your microframework, then you decided to use a standard one. This has been my evolution and even if I don't understand everything inside the frameworks I'm using now I have a general idea. And furthermore, what can we do about it? Writing code from scratch or maintaining or own frameworks is more or less the way to losing customers,…

Thank you for this. I hate the "frameworks are for people who don't know what they're doing!" meme. Sometimes they're just for people who have thought about the trade-offs and decided a popular framework has many advantages.

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

#329
post #134

Earlier quoted context omitted.

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"?

I don't consider packaging to be a sysadmin task. On any sane OS (i.e. anything not Linux/BSD), packaging is done by the upstream developers. That doesn't happen on Linux because of the culture of unstable APIs and general inconsistencies between distributions, but for my current app, I am providing DEBs and woe betide the distro developer who thinks it's a good idea to repackage things themselves ...

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

#330
post #249
post #205

Earlier quoted context omitted.

Recursively searching through all files in the current folder (aka the normal use case for grep) is accomplished by using "grep -r". It's on line 270 in "man grep". And that assumes that you know what grep is at all. Would it have hurt so much to call grep "regexsearch" instead? Maybe -r could be the default?

All the core unix tools have the problem of predating the vowel generation ( http://c2.com/cgi/wiki?VowelGeneration ).

'grep' isn't a case of disemvowelment (there's an e!), it's just a weird mnemonic that's outlived its referent.
Post reply on HN