Live data from Hacker News

The sad state of sysadmin in the age of containers

vitavonni.de

301–310 of 466 posts

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

#301

Earlier quoted context omitted.

Surely at minimum Hadoop developers could tell you!

Have you even been in a project where the developers didn't know how to build it? It's a strange situation, with huge environments being passed from one computer to another, and treasured with more care than the code itself.

A legend at one company about 5 years ago is that the company's next world-shaking product was being built partially with a single computer that was shipped around from office to office, because no one knew how to build the build environment again. Again this was circa 2010. :-)

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

#302

Earlier quoted context omitted.

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.

This is why you have a strong passphrase on your ssh private key.... right?

Hum... No. It's trivial to use those scripts to do all kinds of harm. A strong passphrase only protects against this one example.

For example, it won't protect against stealing the .ssh folder and installing a keylogger at your computer.

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

#303

Earlier quoted context omitted.

I agree that the "just curl this into bash" instructions are nightmare - on any platform. I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management": This is where you have a team (either for a single project or a team at a consulting agency, etc) that is effectively all development-focused staff, possibly with some who dabble in Infrastructure/Ops. In this environment,…

I think part of this is because there aren't any trusted, fully open source, artifact repositories that work with the various package indices out there. Like, most of the way deployment should work is that you come up with some collection of packages that need to be installed and you iterate through and install them. Bob's your uncle. Thing is, all the packages you need live out in the wild internet. Ideally, you'd j…

"And on top of that developers don't necessarily know how to set up a PyPi or a RPM index or whatever so that the storage is reliable and you've got the right security settings or whatever else. (I know I sure don't and I'm not really "

Setting up RPM is shockingly easy. It can get more complex, but the basic system is:

  REPOBASE=/srv/www/htdocs/
  createrepo -v  $REPOBASE
  gpg -a --detach-sign --default-key "Sign Repo" $REPOBASE/repodata/repomd.xml
  gpg -a --export "Sign Repo" > $REPOBASE/repodata/repomd.xml.key
That will create a repo from all the .rpm files in the REPOBASE. Also you will of course need a GPG key pair, but that can be generated with `gpg --gen-key` where you give it a description of "Sign Repo" (or change the above commands to the key description you used).

Then you get to decide on the deployment machine if you want to trust the repo (or you don't trust any and import the key via some other process, aka direct gpg import).

Of course you can find a bunch of more detailed explanations with $SEARCHENGINE, but if it takes more than a day to figure it out, your doing something wrong.

Building a set of RPM's isn't that much harder if you have a proper build system. But these are the kinds of things you give up when you decide to grab the latest immature hotness created by someone on their day off.

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

#304
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 agree that the "just curl this into bash" instructions are nightmare - on any platform. I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management": This is where you have a team (either for a single project or a team at a consulting agency, etc) that is effectively all development-focused staff, possibly with some who dabble in Infrastructure/Ops. In this environment,…

It's also the recommended way to install Kubernetes.

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

#305
post #284

The 'curl | sudo bash' mention reminds me of OS X Homebrew. The one-liner installation script is still published in the home page front and center (though it's running from a trusted source Github). http://brew.sh/ One might argue that that easy of oneliner installer script is exactly what make Homebrew gains popularity. And dev machine is different from production environment in terms installation packages. Still, I…

I agree, I think accessibility made it popular. Security and ease of use are usually opposing forces.

The article has some interesting discussion points. I don't understand the absolute fear of | bash installers. It's open source, read the script. That's the argument people make for `./configure; make; make install` programs. I think it's because it's new, or it's too easy.

But the article does have a point about trusted containers. But security isn't a download or a product anyway. Security isn't even guaranteed.

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

#306

Earlier quoted context omitted.

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?

Re-connecting a pin to a cpu that broke off should be enough qualification. Anger will be present in spades.

Christ it's annoying enough just using a credit-card to fix bent pins. Hats off for reconnecting them!

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

#308
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…

I have never under stood why some many people are not ok with using the command line. A few years back we had an issue where a mysql script was over the limit for phpmyadmin - my fairly experienced colleague he was unaware that you could log into the cli and use mysql from the cli.

Command line is modern day voodoo. There are ton of commands, each with a specific use, each with own their specific incantation, which can mixed in extremely powerful ways. But my theory is the main reason people would prefer not use it, is that improper usage can be harmful and sometimes destructive.

The same reason people prefer to use garbage collected and dynamically typed programming languages.

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

#309

I'm a bit puzzled. Let's say I decide to not download the binary but build it from source. Unless I actually read the source, I'm trusting the community to have read it, which consists of other people thinking I have read it. In my view, this is true for the OS itself. So unless I read everything, I'm fucked. And I don't. Thus I'm fucked. Do I miss something?

This is also pretty much what happened with OpenSSL. Which is why I'm amused by the holier-than-thou attitudes in here.

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

#310

Earlier quoted context omitted.

There's nothing wrong with curl | sudo bash style setups as long as it's over https and the certificate gets checked. The advantages are that it's easy and you can make it work on almost all unix-like systems out there. The only disadvantage is that you have one additional weak point: The server can get contaminated. Before you had to contaminate one of the many developer machines / build machines. The situation hasn…

No, it's just plain bad. To pick one example why... Just because it's easy to run doesn't mean it's easy to support or maintain. Chances are `curl | bash` scripts aren't designed for your particular OS, so it's yet another form of software that you have to learn how to update, as opposed to using the OS-level update mechanism, such as yum, apt, or even brew to some extent. Being a good sysadmin doesn't stop at instal…

Not to mention that in plenty of environments production systems don't have access to the internet to begin with, so curl/wget | bash is a non-starter.
Post reply on HN