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

231–240 of 466 posts

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

#231

Post by michaelmior »

briffle wrote: post #143
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.

Copy-pasting from the internet can be just fine, for things like (for example) yum install because the tool itself has built in checks to make sure you have a valid, non-corrupt installer before executing, from someone you trust.

The point is that what ends up on your clipboard can be different from what you see and if a new line is there, then the command executes before you have a chance to change your mind.

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

#232

Post by skywhopper »

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 employer buys some software that is distributed as binary installers. So I've written a script that will run that installer in a VM, and repackage the resulting files into something I'm comfortable working with to deploy to production.

If a sysadmin is unable to insist on good deployment practices, it's a failure of the company or organization or of his own communication skills. If a sysadmin allows sloppy developer-created deployments and doesn't make constant noise about it, then they aren't doing their job properly.

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

#233

Post by deong »

vacri wrote: post #134
mike_hearn wrote: post #108

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 read that the other way around. He specifically asks people to refrain from packaging his software. I think the implicit implication is that he does want sysadmins to run his carefully constructed build scripts in order to install the application.

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

#234

Post by acveilleux »

redblacktree wrote: post #172
Twirrim wrote: post #148

Earlier quoted context omitted.

That's why you get someone who is capable of understanding it. You wouldn't hire some high school kid who's just about taught themselves HTML by reading a book for a week, and get them to write your web application from ground up. You'd hire someone who knows what they're doing. Why is it seen as any different for Operations work? There is a reason systems administration is a skilled field, and a reason they're paid…

I think the reason this happens less and less is that sysadmins are cost centers, not revenue generators. When you have developers do that work (poorly or not), you don't have a group that's purely cost. Those costs get hidden in the development group.

Indeed, the costs merely get hidden and a lot of system decisions boil down to one of:

1. I saw it done that way in some blog.

2. We did it like that at my last job.

3. Seems like it works.

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

#235

Post by gnaritas »

TeMPOraL wrote: post #206
falcolas wrote: post #201

Earlier quoted context omitted.

I don't get this. Tar isn't that hard. x = eXtract files from an archive f = File path to the archive c = Create a new archive from files v = print Verbose output z = apply gZip the input or output That's 99% of common tar right there. The remaining one percent is: j = apply bzip2 to the input or output (I admit, j is a weird one here, though that has made it stick in my memory) --list = does what's on the tin --excl…

It isn't, but so aren't dozens or hundreds of other commands you encounter when working with the command line. I managed to memorize a few invocations of tar (I listed them in another comment) but, for instance, I very rarely create a new archive so I'm never sure what flag I need to use. Part of the problem is that each command line utility has its own flag language, and equivalent functions often have different let…

Those case differences have meaning, -r is generally not dangerous while -R is; it's capitalized to make you stop and say hmmm, should I do this. All commands have the same flag language, command -options, and are all easily documented by man command; it quite literally couldn't get any simpler and unnecessary to memorize since you can look up any flag on any command with the same man command. Those who find it confusing haven't spent the least bit of effort actually trying because it's actually very simple and extremely consistent.

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

#236

Post by acveilleux »

TeMPOraL wrote: post #206
falcolas wrote: post #201

Earlier quoted context omitted.

I don't get this. Tar isn't that hard. x = eXtract files from an archive f = File path to the archive c = Create a new archive from files v = print Verbose output z = apply gZip the input or output That's 99% of common tar right there. The remaining one percent is: j = apply bzip2 to the input or output (I admit, j is a weird one here, though that has made it stick in my memory) --list = does what's on the tin --excl…

It isn't, but so aren't dozens or hundreds of other commands you encounter when working with the command line. I managed to memorize a few invocations of tar (I listed them in another comment) but, for instance, I very rarely create a new archive so I'm never sure what flag I need to use. Part of the problem is that each command line utility has its own flag language, and equivalent functions often have different let…

Frankly, if you're going to rely on a magic recipe from the web for production, you should absolutely document it locally and go through the process of understanding each commands.

As a former sys admin, I did that all the time. Who the hell can remember how to convert an SSL certificate to load it into a Glassfish app server? Didn't mean I couldn't step through all commands and figure out why it did that before I loaded the new cert... And next time, I just need to go to my quick hack repo for the magic incantation.

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

#237

Post by tammer »

stephenr wrote: post #32
blfr wrote: 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,…

Am dealing with this situation right now. Apparently wget -qO- https://get.docker.com/ | sh as root[1] is the "supported" way of installing Discourse

[1]: https://github.com/discourse/discourse/blob/master/docs/INST...

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

#238

Post by markrages »

tormeh wrote: post #205
wflann wrote: post #157

Earlier quoted context omitted.

I think, occasionally, it's a lot easier to grok a command through googling than reading the built-in help. A fair amount of built-in *nix documentation I have run across is mediocre or unhelpful.

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?

Recursive is not the default use for grep. stdin-stdout filtering is.

"regexsearch" is more work to type and more space taken up everytime 'grep' appears in a command-line. And says nothing about recursion.

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

#239

Post by legulere »

blfr wrote: 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…

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't been better before. Install media always got downloaded without ssl encryption or any certificate checks. This is still the same, but at least you won't get a hacked kernel today if you use secure boot.

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

#240

Post by peatmoss »

Anderkent wrote: post #221
stephenr wrote: post #121

Earlier quoted context omitted.

I would argue that anyone who is reasonably comfortable in a command line would resort to `man command`, `command --help` or `command -h` before googling for usage.

Nah, man pages are usually completely useless. I use man when I remember exactly what I want to do and just aren't sure if the flag was -f or -F. For everything else there's google.

Being a few years gone from working purely in tech, and having a decade of OSX desktop usage finally made me feel I'd gotten complacent. So I installed OpenBSD. Two things of note have happened:

1. I routinely need to look things up that are a bit murky in the deep recesses of my memory.

2. I am reminded continually of how nice it is to have man pages that are well written, are easily searchable, reference appropriate other pages, and are helpful enough to remind you of big picture considerations that you didn't realize you were facing when looking for a commandline flag.

Post reply on HN