Hacker News Reader

Comment by stephenr | Hacker News Reader

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, when a decision about something like "how do we get a reliable build of X for our production server deployment system" needs to be made or a system needs to be supported, no idea is "bad", because no one has the experience or confidence to be able to say "that's a stupid idea, we are not making `curl http://bit.ly/foo | sudo bash` the first line of a deployment script"[1]

[1] yes this is an exaggeration, but there are some simply shocking things happening in real environments, that are not far off that mark.

Edit: to make it absolutely clear about what I was referring to with [1]:

The specific point I was making was running something they don't even see (how many people would actually look at the script before piping it to bash/sh ?) from a non-encrypted source, and relying on a redirection service that could remove/change your short url at any time.

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]

[2] http://stackoverflow.com/questions/5421800/rvm-system-wide-i...

View on HN

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 just be able to take a package, vet it, and put it in your local artifact store and then when your production deployment system (using apt or yum or pip or gems or maven or whatever) needs a package, it looks at your local artifact store and grabs it and goes about its business. Never knowing or touching the outside world.

And your developers would all write their apps to deploy through the normal packaging methods that everyone and their mother is already familiar with and they could just put them into the existing package index as well.

But you've gotta lay out pretty serious moola (from when I last looked into available solutions to this) or set up a half dozen different artifact stores if you want to do things that way. And good luck managing your cached and private artifacts if you do. 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 interested in reading all of the ones I'd end up needing).

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

With docker, as referenced in TFA... you can simply vet a base image, and use that for your application... upgrades? create a new/updated base image and test/deploy against that.

And how do you "simply vet a base image"?

Same as everything: look at how it was built. Many of the images are built by CI systems according to Dockerfiles and scripts maintained in public GitHub repos. Audit those, then use them yourself if you're worried about the integrity of the services and systems between the code and the repository.

> 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

But then there's a circular dependency because the GPG key is retrieved by the bash script that is wget'd.

It doesn't have to be circular. The script is secured by HTTPS (and hopefully has the key embedded in the script itself?) which can then retrieve the installer and verify it using the key.

The problem is that in this scenario, the GPG key and signature serves no practical purpose.

The whole security, whether GPG is invoked or not, relies on the security of the HTTPS connection alone.

If the HTTPS cannot be trusted alone, then everything is lost as a compromised HTTPS connection can be used supply both a comprimised GPG key and a compromised package, or, indeed, anything at all that is legal to `| sudo bash`...

And HTTPS security boils down to:

1. The difficulty of altering (or exploiting privileged position wrt) the global routing table to setup MitM or MitS scenarios.

2. The difficulty of obtaining a valid looking certificate for an arbitrary domain.

Any situation where a government actor is the adversary poses intractable challenges to both 1 and 2 above. (And before you say NSA/GCHQ would never care about XYZ, consider China...

Even if you trust "normal" https certificates, it's still a much more risky proposition. Those certificates only really say that somebody control the domain - not (in general) that he actually owns it or is responsible in any way, and, more critically, don't vet whether somebody is trustworthy or not. You can easily get some other similar-sounding domain as a malicious agent, and validly get an https certificate for that.

So even if you trust https works, it's still a tricky proposition - it's not really similar to a distro's package distribution channel.

Indeed, and I didn't even go over trusting the actual source of the bash script or the security/integrity of the server(s) it's hosted on even if the cert is all A-OK.

It gives people a way to choose the level of security they care about. Those who are willing to trust HTTPS can trust HTTPS. Those who aren't can obtain the GPG key and check its signature by another mechanism (WoT) and manually verify the package signature.

Those who would go out of their way to do the GPG check are also the same people who are horrified by `curl .... | sudo bash`

Yes, that's the point. Those who aren't horrified can do that. Those who are can get the package "by hand" and do the GPG check themselves.

Same issue when people post GPG keys on their website. You can't verify them.

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

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/

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

No, that's Discourse install instructions quick, hand-wavy way of telling you to install Docker if you don't already have it. If your cloud environment already has Docker installed, you can skip that step.

Are you really trying to say that the instructions for installing Docker should be considered in-scope for a guide to install Discourse on a cloud server?

They've included a short snippet that will get you a Docker, in the way recommended by Docker, for whatever your base system is. Many production systems do not move at the pace of Docker development, so it's not practical to run Docker from your distribution's package archive. Some distros will not have distributed packaged Docker releases at all.

What's wrong with these instructions? If you are really "dealing with this" right now, it is worth noting that something like 20 or more supported platforms have specific Docker installation instructions from the Docker website.

https://docs.docker.com/installation/#installation

From a quick sample of those instructions, only the Ubuntu instruction page uses the wget|sh method, and it's using an SSL connection to Docker's own website to add an apt source with signatures in the supported way. This way should work on any Debian-based or Yum-based distro, and writing the instructions like this must likely save Discourse from getting a lot of "How do I docker" issues and e-mails from their clueless users.

So, would you prefer that part just says "installing Docker is out of scope" or should the Discourse developers go through every distro and cloud system and document the specific instructions for that? To do that would completely defeat the purpose of even using Docker at all.

I concur - to elaborate, I'm not actually the one installing Discourse. I support a 'Kumbaya' group of data scientists who have never heard of docker.

Quick directions like these aren't questioned by users who just want to get things done, and they invite security risks just as the parent & article suggest.

There are many more depressing examples of this at http://curlpipesh.tumblr.com

Funny tumblr but makes me care-confused.

I understand that curl pipe sh could have security problems but I also don't see it as that much different than the "normal" and "ok" way of doing things. I would consider something like the below pretty normal.

  wget https://whatever.io/latest.tgz
  tar xzf latest.tgz
  cd whatever-stable
  ./configure && make
  sudo make install

Because of familiarity, we aren't going to be too worried about what we are doing. If we are on a secure system (like a bank or something) then we've probably already gone through a bunch of hoops (source check, research) and we mitigate it like anything else.

What is so different about

  curl https://whatever.io/installer.sh | sudo bash

We didn't check the md5s in the first example, so yolo, we don't care about the content of the tarball we just `make install`-ed. We're assuming the webserver isn't compromised and that https is protecting the transfer. Is it because the tarball hit the disk first? Does that give us a warm fuzzy? Is it because "anything could be in installer.sh!!!?! aaaaah!". Well, anything could be in Makefile too right? Anything could be in main.c or whatever.

I agree that curl sh | sudo bash makes my spidey sense tingle. But if I really cared, I would read the source and do all the normal stuff anyway. So I think it's some kind of weird familiarity phase we're all in.

I wouldn't consider what you presented as the "normal" or "ok" way of doing things either, especially not on anything resembling a live (i.e. not development/sandbox) environment.

A distro (or official vendor, or possibly a trusted third-party) repo of pre-built, signed packages would always be my first choice.

If one of those isn't available, my next step would be to create a package for the tool in question, part of which is setting up a file for `uscan` to download new source archives, and compare against the signatures.

In this scenario we (as in the organisation) are now responsible for actually building and maintaining the package, but we can still be assured that it's built from the original sources, we can still install it on production (and even dev, staging, whatever) servers with a simple call to apt/aptitude, and dependencies, removal, upgrades, etc are still handled cleanly.

About "ok". You're right. I probably used a loaded word without context. I too use whatever default package repo, followed by "extras" or whatever is available. You described a sane and nice process. I guess my point is, at some point we are are assuming "many eyes" (the binaries might be built with the previously mentioned make;configure steps) unless you are auditing all sources which is unlikely. Especially unlikely on dev machines. Even after that it seems like there is an infinite continuum of paranoia.

I find it interesting that binary packages have existed for decades and yet `rpm etc` knowledge is rare. Why did curl sh become popular? Why doesn't every project have rpm|deb download links for every distro version? Why don't github projects have binary auto-builds hosted by github? I'd argue that it's too difficult. Binary packaging didn't succeed universally. For deployment, containers are (in the end) easier.

But the original article is conflating container concepts and user behavior (not wrongly). If docker hub does end up hosting malware-laden images, it would be interesting emergent behavior but it would be orthogonal to containers. Like toolbars. Toolbars probably aren't evil. A vector for evil maybe?

> I find it interesting that binary packages have existed for decades and yet `rpm etc` knowledge is rare

What makes you think the knowledge is rare? Among developers who actively target linux distributions I would imagine the opposite is true.

Even a number of the referenced curl|bash offenders are just using that as a "shortcut" to add their own apt/yum repos and calling apt-get/yum to install their binary package(s).

Because now your ability to install your mission-critical software is dependant upon https://whatever.io actually being up. Which it certainly won't be forever.

Or, you know, maybe someone updated the whatever.io installer to make it 'better'. But you are trying to debug some problem and you made one image last month and another one this month and you're pulling your hair out trying to figure out why they are different. Oh, it's because some text changed on some web site somewhere.

You've taken a mandatory step and put it outside your sphere of control.

Good point. I guess you could still wget the script though. It's maybe like ./configure over http? I guess even if you could do it, it's probably not culture. A Dockerfile would probably just curl sh the thing and not wget it. So the default culture probably does depend on whatever.io being up.

Outside of a development environment, you'd run that ./configure && make install step on a build slave that creates a nice RPM or Debian package of it for you which you can install without fear that the build scripts install backdoors, download obsolete software or wipe the filesystem.

With a good build system (eg. autotools) writing an RPM spec takes almost no time at all and if you have the proper infrastructure in place for building packages, you can have something workable in a very short time.

Self-packaged RPMs also don't need to be quite as high-quality as ones you might want to include in a distribution, so if it makes sense for your use case, it's perfectly okay have "bloat" (eg. an entire python virtualenv) in your package.

> With a good build system (eg. autotools)

Yikes. Have we sunk this far?

It's bad because `sh`, `bash`, etc. don't wait for the script that's being piped into it to finish downloading before it starts executing it. So, for example, if you're running a script with something like

    # remove the old version of our data
    sudo rm -rf /usr/local/share/some_data_folder

and the network connection cuts out for whatever reason in the middle of that statement (maybe you're on a bit of a spotty wireless network), the resulting partial command will still be run. If it were to cut off at `sudo rm -rf /usr`, then your system is in all likelihood going to be hosed.

You're first example allows for:

* Using checkinstall to create a local deb/rpm which can be easily installed/removed later instead of "make install". * What if installer.sh says "rm -rf /tmp/PACKAGE-build" and the connection is interrupted just after the first "/", you now have "rm -rf /". Oops. * configure will tell you what files it needs, and apt-file will tell you want dependencies to install. * I know what make install does. I know make. Who wrote installer.sh? Do they know anything about writing good software? Steam wiped out home directories, who knows what these people do

It's easy enough to download a given/checked version of the script at http://foo.com/ubuntu/install and have that copied and run inside your docker image... for that matter, it's usually adding a given repository to your repo manager, then installing a given package from that software's corporate sponsors.

I don't think the problem is as rampant as it's made out to be in TFA... that said, most people don't look at said script(s), so it's entirely possible something could have been slipped in. For that matter, I think the issues outlined in the article relate more to overly complicated Java solutions (the same happens in the .Net space) that are the result of throwing dozens of developers some with more or less experience than others at a project, and letting a lot of code that isn't very well integrated slide through whatever review process does or doesn't exist.

>[1] yes this is an exaggeration

No, it's not :(

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

Oh cool. So that works? I've already memorized:

    tar -xvvzf foo.tar.gz
    tar -xvvjf bar.tar.bz2
    tar -xvvf  baz.tar

Thanks!

That second one will create a tarbomb[1], which isn't necessarily wrong and maybe it's what's right for your application, but for more general usage this is friendlier:

    tar cf <mydir.tar> <mydir>

[1] http://www.linfo.org/tarbomb.html

And some of those switches are just for convenience, e.g.:

tar c . | gzip > /tmp/out.tar.gz

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.

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.

You don't have to be a sysadmin to be comfortable with command line tools. If you want to fully utilize your *NIX system you have to learn how to use that shit, it really isn't that hard.

(I'm a developer.)

I am comfortable with command line tools. I just don't remember every switch and flag I happen to use twice a year, and the fact that command line utilities are totally inconsistent in subtle but significant ways, coupled with the overall unreadability of man pages and lack of examples in them makes this process difficult.

I'm a very proficient user of command line tools, but I don't remember everything: my shell history is set to 50,000 lines, and it's the first thing I search if I've forgotten something.

Sequences of commands sometimes get pasted into a conveniently-located text file; if I find myself repeating the operation I might turn it into a script, a shell function for my .zshrc, or an alias.

Just 10 minutes ago: mysqldump [args] | nc -v w.x.y.z 1234 nc -v -l 1234 | pv | mysql [args] (after an initial test that showed adding "gzip -1" was slower than uncompressed gigabit ethernet.)

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.

> 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

Except with cp , -R is the safe one and -r is the dangerous one. And there are tons of little inconsistencies like this.

That's exactly my point.

As I said, generally. All human languages have inconsistencies, the command line is by far one of the most consistent ones any of us deal with.

It may be more consistent, but is not easier - humans are generous with regard to input, they can infer intentions from context. I could type in "please unbork this" to a human and he'd know precisely that he has to a) untargzip it, b) change the directory structure and c) upload it to a shared directory for our team.

Welcome to working with computers that can't think; easier is not an option, they can't infer your intentions, so your point is what? Consistency is what matters when working with machines and the command line is a damn consistent language relative to other available options.

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.

I agree with this. Despite my familiarity with so many command line tools, I do forget invocations. And so I have a wiki page I share with my coworkers to share particularly useful (or correct) invocations of dangerous tools.

On a Unix based system, tar is just used so frequently and for so many purposes, that not understanding it feels a bit like working in a shop and not knowing how to use a roll of tape.

One way to remember these commands without necessarily going "full sysadmin" is to use them on a daily basis. Whether I am developing, managing files, debugging, or really doing anything other than mindlessly browsing the web, I always have at least one (and often many) xterms open. The huge selection of tools and speed of invocation provided by a modern *nix command line is invaluable for many tasks that are not directly related to administrating a system.

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?

I think a lot of people would hate having it be recursive by 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.

Recursion is caused either by -R or -r on nearly all commands and is pretty standard, and r is virtually never the default on any command because that would be a bad idea. And yes, having to type regexsearch rather than grep would have been a bad idea; while grep isn't a great name it's far preferable to someone who types constantly. Search or find would have been better names, names need to be both short and descriptive on the command line, and short comes first.

Use the built-in search.

Edit: the rest of my comment (somehow submitted to soon!)

    man grep

    /recurs<enter>

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

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.

If it were up to me it would be called `find` and it would have flags to find files or text within files.

I often find that GNU man pages are heavy on explanation of options and light on purpose and practical usage (the latter is tucked away in info pages). That's not necessarily the wrong way to do manpages, but I much prefer OpenBSD-style manpages, which seem to be better at providing practical information.

I never use man pages, to be honest, and I'm quite comfortable on a command line. Reading long-ish things in a terminal kind of sucks, for me, and even if I end up reading a man page in Chrome it's nicely formatted and has readable serif fonts and is easily scrolled with the trackpad on my laptop.

Your terminal doesn't scroll with wheel/trackpad?

The wheel or trackpad scrolls the terminal's scrollback, not the pager program that happens to be running in it.

(I can imagine some sort of hackery that determines if less or something is running and scrolls that, but it sounds like a huge mess. Is that actually what you're doing? Does it send keypresses? What if you're in a mode where those keypresses do something besides scrolling?)

I just tried this on debian and my mouse wheel scrolls less inside of my terminal (and returns my previous line buffer when I type 'q').

No I'm talking about scrolling in the actual program running - it's most useful in a pager obviously, but it also works for editors, and it works both locally (OS X, built-in Terminal.app) and over SSH on Debian hosts.

I'll be honest - I have ~no idea~ (edit: apparently there are xterm control sequences for mouse scrolling) how it's actually implemented, but several tools have some reference to mouse support (tmux, vim, etc) in option/config files, so it's probably available for your distro/platform and just needs to be enabled.

Further edit: (or PS. or whatever):

`less` pager supports mouse scrolling. `more` pager does not!

It can do continuous scrolling of the terminal or line-by-line scrolling of the pager. Both are poor options for trying to actually read prose content inside the terminal, IMO, and opening a browser is easier.

What do you mean by "continuous" versus "line-by-line" scrolling? When I use the mousewheel to scroll a man page in xterm it behaves and appears the same as when I use the mousewheel to scroll a webpage in Chrome (the content moves smoothly up and down, disappearing at the top and bottom edges of the viewport).

I probably haven't read a man page "cover to cover" since high school. Usually I just need to read a couple lines about a specific flag or the location of some configuration file which I can find quickly with a simple search or by scanning the document with my eyes.

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.

Can you give an example of what you might turn to google for (and what you'd search for) that is more productive than checking a manpage/help output?

OK, recent simple example:

Google query: git display file at revision. Immediate answer (without even having to click any links, it's in the result description): `git show revision:file`

Total time: 5 seconds

Trying to reproduce with man and help:

  man git

search for display, finds nothing

start scrolling down

notice git-show (show various types of objects); sounds like a likely candidate

  git show <revision> <file>

..no output

  git show -h

  usage: git log [<options>] [<since>..<until>] [[--] <path>...]
     or: git show [options] <object>...

.. useful

  man git show
  man git-show

OPTIONS <object>... The names of objects to show. For a more complete list of ways to spell object names, see "SPECIFYING REVISIONS" section in git-rev-parse(1).

  man git-rev-parse

a lot about specifying revisions, nothing about how actually specify a file

Give up. Google it.

One reason to keep reading man pages is because you will likely discover new thing you did not expected. Also reading man pages help you to understand the tool philosophy/workflow, if the man page is well writen (which is often the case). This hold for any kind of documentation as well.

When I google something, I usually do not remember the answer to my question, the only thing I remember is the keyword to put in my futur query to get the same answer. You will get your answer quicker, but you wont learn much. So personally, I prefer reading man pages (when I can) than use google.

I too find it much easier to google for actual working examples of commands rather than the abstract documentation in the manual.

Rsync for example, where trailing slashes make a difference and it's not obvious from skipping over the manual.

Looking at working code/commands often works better than piecing it together from the manual imo.

some man pages are really obscure though. i am thinking of policy kit and find which can be as long and as arid.

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.

But it isn't all that hard to understand a clean Unix. I have never copied or typed a command that I don't understand.

One problem may be that most Unices these days is not as clean anymore as, say OpenBSD or NetBSD. E.g. the recent X stack, with D-BUS, various *Kits, etc. is quite opaque. This madness was primarily contained to the desktop and proprietary Unices, but seems to spread through server Linuxes these days as well (and no, this is not an anti-systemd rant).

> But it isn't all that hard to understand a clean Unix. I have never copied or typed a command that I don't understand.

Well, good for you. I can assure you that it's not the case for almost anyone who approached Linux after the likes of Mandrake were released and/or tried to make it work on anything different from a traditional server.

I'm all for trying to understand what one is doing (and I wholeheartedly agree with TFA's point), but the reality is that very few people in the world really understand all intricacies of one's operating system. This does not excuse poor security practices, but it explains their background.

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 on a par with developers.

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.

Whoops replied to wrong comment!

However yes the issue of a team that "doesn't make money" is very real. Maybe you it should be "marketed" like legal or accounting: it doesn't make money, it saves money caused by SNAFUBAR situations.

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.

That high school kid needs to install a web server. Is he going to hire someone? No. He's going to copy a curl command.

It's probably okay for him.

I expect her to say "How do I install software on this platform?" "Oh! /(apt|yum|dnf)/!"

One of the problems (as I tried to argue) is that most Unices have become far more complex. The question is if the extra complexity is warranted on a server system, especially if bare Unix (OpenBSD serves as a good example here) was not that hard to understand.

Of course, that doesn't necessarily mean that we should look back. Another possibility would be to deploy services as unikernels (see Mirage OS) that use a small, thin, well-understood library layer on top of e.g. Xen, so that there isn't really an exploitable operating system underneath.

> I have never copied or typed a command that I don't understand.

To note that it's trivial to change what goes into the clipboard too. Copying and pasting commands from potentially untrustworthy sites should be ruled out too, even if understood

What seems to be the source of this push is that some entity wants Windows Group Policy like control over what users can and can't do etc.

This because they want to retain their ability to shop for off the shelf hardware, while getting away from a platform that has proves less than functional for mission critical operations (never mind being locked to a single vendor).

What seems to be happening is that there is a growing disdain for power users and "admins". The only two classes that seems to count are developers and users, and the latter needs to be protected from themselves for their own good (and developer sanity).

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.

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.

A page of text? With Content-type: text? An example being a shell script?

Do you think the average user copying and pasting administrative commands into their shell will stop to check the content encoding of the document they are copying from? Do you trust your browser not to try rendering an ill-defined document with an ambiguous extension?

Do you check the Content-type: header of the response for text/plain before copying? If you do, you'd be in the minority.

Fair point.

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.

Copy-pasting from the internet can be just fine, for things like (for example) yum install <blah> 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.

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

> I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management"

I'm totally stealing this :)

I honestly don't see the issue.

I see the issue with doing it for the general public ala RVM, but internally where you control everything I don't see the issue with curl into sh.

It's also the recommended way to install Kubernetes.

Reply on news.ycombinator.com