Hacker News Reader

Comment by erlichmen | Hacker News Reader

You are doing it wrong:

  1. curl https://sdk.cloud.google.com | bash  
  2. gcloud auth login (one time thing)  
  3. gcloud sql instances create db-master-1

View on HN

> 2. gcloud auth login (one time thing)

That's a royal pain in the arse to automate with something like ansible... AWS nailed it with a token & secret (not some horrible expiring oauth2 object).

And that's not to mention gsutils sleeping for a second or two every time it tells you there's an update.

It's like these guys have never heard of devops.

Updates are my problem; I don't expect software to sleep whenever they're available... because you never know, I might be running it in a loop under cron and it might just piss me off when I start to lose performance...

'gcloud auth activate-service-account' will auth using a JWT, acquired from the Cloud Console.

Also, if you are running stuff in Google Compute Engine, no auth flow is needed at all: there is a metadata service that you can connect to (and gcloud connects to by default) that provides credentials associated with the machine you're on.

> It's like these guys have never heard of devops.

:\ yeah...I can't imagine trying to automate a web login flow with ansible...but no one would ever suggest you do that.

(disclosure: I wrote most of the client-side auth code for gcloud)

This was also frustrating on something like CircleCI

This is a bad practice:

  curl * | bash

and should be discouraged. It's easy but it's like saying, hey I'm logged in as root all the time - it's easier.

You don't need root to install gcloud

I think that was just an analogy.

And only it really does anyway is

  wget https://dl.google.com/dl/cloudsdk/release/install_google_cloud_sdk.bash
  chmod 775 install_google_cloud_sdk.bash
  ./install_google_cloud_sdk.bash

In this case, * is "https://sdk.cloud.google.com" and I don't see how it's worse than trusting a package from PyPi. If anything, the curl command offers some guarantee that you are running code endorsed by Google.

If the HTTP connection is interrupted during download (highly likely if you're doing this routinely) you'll end up with something in a broken state. Locally running a remote stream as it arrives as code is just a bad idea, unless you're talking about something like a webpage where a partial is potentially preferable to nothing at all.

Code which is meant to be piped into bash is generally written as:

    #!env bash
    f () {
      ...code
      ...code
      ...code
    }
    f

Hence a partial stream will do nothing (syntax error, missing brace to be precise).

This is a completely trivial problem to solve (wrap the logic in a function), which the script in question does solve.

Only if you don't trust the source (or it's http).

Otherwise you might as well give up on downloading any software from the internet. Ever.

It's no different from steps 2 and 3. At each step you're trusting that code you just downloaded from the web is doing what you want it to do.

You're also trusting that the Internet is going to stay up for the duration of the install script, which is an unreliable assumption. Imagine at some point the script does:

rm -rf ~/.config/google

and the connection gives out at

rm -rf ~/

Suddenly your script didn't install, and you've blown away your home directory. HTTP(S) is designed for reading documents, where it's OK if you can't read the document in its entirety.

This is easily solved by putting everything in a bash function and calling the function as the last thing in the script. If you look at the Cloud SDK setup script, that is exactly what it does.

I agree it's a trivial problem to solve, I just think the right way is to download the code and store it separately, so that it's easy to add checksum/signature validation later.

Have you ever run "./configure" on some open source code you downloaded? That's no more safe. In this case, curl | bash is probably more safe because at least it came over HTTPS.

> Have you ever run "./configure" on some open source code you downloaded? That's no more safe.

That is if you don't do a

    view ./configure

first and go through it. You do take a look at the configure scripts, don't you?

What's less readable, a ToS that you have to accept or a GNU autotools configure script?

Example: expat's autoconf script is over twenty two thousand lines long.

You could just as easily do 'curl someurl | less' before you run it, too.

Reply on news.ycombinator.com