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

201–210 of 466 posts

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

#201

Post by falcolas »

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 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
    --exclude = does what's on the tin
    --strip-components = shortcut for dropping a leading directory from the extracted
I haven't used a flag outside of these in recent memory.

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

#202

Post by rockdoe »

mdellabitta wrote: post #126
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. They also have a great track record at it. The analog of the aspects of what Debian does that you're talkin…

But the problem is that the ones doing the vetting (i.e. Debian) have given up on making a vettable distribution because the build is so broken.

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

#203

Post by stephenr »

23david wrote: post #168
stephenr wrote: post #32

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,…

In my experience, this is mainly describing the sad state of sysadmin work at tech startups. Larger and profitable tech companies tend to take sysadmin work a bit more seriously and give more resources and authority (and pay...) to their TechOps/Devops/Security teams.

It seems reasonably common in agency type companies - at the start often their "infra" is an account with a managed web hosting company, ahd when their needs grow it doesn't always become a core part of the business

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

#204

Post by tobz »

andrewvc wrote: post #195
tobz wrote: post #188

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'…

FWIW you can easily recreate a base image by just copy/pasting the Dockerfile for that image at the top of your own. I did this for the Jruby images we base our stack on. I've been doing both dev and ops work for nearly a decade. I feel for what the guy is saying, but these aren't tech problems, they're process problems. Relying on apt packages for everything makes using more recent features ridiculously hard and slo…

Sure, and that's all reasonable stuff. I mostly posted this because while encouraging people to use wildly insecure installation processes like 'curl ... | sudo bash' is terrible, it's easily recognized as being terrible. To me, the Docker ethos is, perhaps, deceptively bad in terms of security. Deceptive enough that it it can lull people into a false sense of security, etc etc.

I mean, we'll see if it happens. My fears might be entirely unfounded, or phusion/baseimage-docker might get trojaned. Who knows. :P

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

#205

Post by tormeh »

wflann wrote: post #157
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.

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?

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

#206

Post by TeMPOraL »

falcolas wrote: post #201
TeMPOraL wrote: post #95

Earlier quoted context omitted.

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 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 letters. For instance, very often one command has "recursive" as "-r" while another has it as "-R". It's impossible to remember it all unless you're a sysadmin.

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

#208

Post by plausibility »

jkyle wrote: post #160
stephenr wrote: post #32

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,…

> 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/

It's also (one of the) recommended ways to do it for Docker[1]. I've noticed a few blog posts that touch on "here's how to use Docker for X" suggest piping it straight into `sudo sh` without so much as looking at what's going to be run first. Sigh.

[1] http://get.docker.io/

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

#209

Post by markbnj »

I think the author is mixing up a few different topics. If you're going to blame container frameworks for people sharing software in insecure ways you might as well blame the fact that executables are portable between compatible systems. Might as well blame the fact that there's a network while you're at it. We run docker throughout our infrastructure, but it is a deployment and dependency management technology, not a vector for infection. We run only our own images, which are all built from source or validated binaries. So what do insecure or unreliable practices have to do with containers, specifically?

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

#210

Post by jacquesm »

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?

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