(from a ticket response): The LINODE_* namespace is reserved for variables that are passed to every StackScript upon its invocation. Of these, "LINODE_ID" is already included.

I would love a list of these handy variables. Please add to http://www.linode.com/stackscripts/ when you get a chance.

Thanks!

I was wondering the same thing, I ran a stack script recorded the output of "export -p". Here's what I found:

declare -x LINODE_DATACENTERID="2"
declare -x LINODE_ID="47714"
declare -x LINODE_LISHUSERNAME="linode47714"
declare -x LINODE_RAM="360"

Nothing very useful....

I intended to go back and do something like this myself, but I was too busy (or lazy). These are all useful for me, for example to automatically tune the deployment based on linode size.

Thanks AggieScott!

What else do you need?

_________________
Disclaimer: I am no longer employed by Linode; opinions are my own alone.

You shouldn't need anything else. You have the linode_id, so you can easily perform an API call to find additional information, such as IP addresses, kernel, or distribution. Everything that you should need from the host is available from the API. If I am wrong, what else would you need?

I don't need anything.... But it would be usefull to be able to access the networking information for the zone. I typically have several IPs for various SSL websites, I'd like to have the stack script be able to set up the networking for the machine.

Right now I have a UDF field that is able to pass the information into the stack script. But that requires me to first setup a boot profile to find out what the IP address/netmask/gateway are, then copy that information and deploy with stackscripts. It's a bit out of the way, and seems like this should be information that is available when the stack scripts are starting.

AggieScott--

Isn't that the whole point of the API? Your initial interface will use DHCP, thus the system will have networking. Then you use scripts to pull the information from the API. All of the information is already there and shouldn't be needed as a Stackscript variable.

Sure, you can do that, though it doesn't look like there are any public stackscripts that do. Not exactly a surprise, since grabbing things out of an environment variable in a bash script is simpler than parsing a JSON or XML response.

Ok, so I'm in the process of writing my Stackscript to grab information from the API.

I was wondering, is there a way to automatically find/generate/magic the API key? At the moment, I have it as a UDF with the correct key set as the default, but it's not as elegant as I would like. Am I missing a better way to do it?

Not yet. It was suggested to me that we include an option to the stackscript settings that "This StackScript will ask permission for the user deploying to pass along their API key" and require that the user acknowledge this during deploy - and when done so, the key would be passed in as one of the env vars... What do you think?

-Chris

That would be excellent.

You need to also point out the theoretical consequences of passing on the API key; what does this allow the script to do? Could it auto-build 10 more linode instances ($$$ cost)? Could it destroy all your DNS settings? What happens if the script surreptitiously copies the key elsewhere. And so on.

People need to understand the risk before they can make an informed decision as to whether to allow the script access to the API key or not.

Otherwise you need a more granular security model; script wants to use your API key to do action X, Y and Z; OK? And then the script is sandbox'd so it can only perform those actions.

But then I'm a little bit paranoid

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

I'd have to disagree on that one. The whole theory of unmanaged VPS is that you're responsible for your own server, for what you run on it, etc.

There is no giant flashing warning if I ssh in and punch in "rm -r *". I might agree if Stackscripts were only listed by name and description. But the entire stackscript source is right below it, without even having to download a file. So it's not like it's an unreasonable effort to check the script to see how it uses the API key. Considering that 0 current public scripts make use of the API key, it's not like every time a user deploys a LAMP stack from the script they'd be expected to triple check the source.

As far as I'm concerned, a sufficient warning would be:

"This StackScript requests permission to use your API key, which grants complete access to the Linode Manager. Only grant this permission to scripts which you understand and trust."

It's not quite that black and white. And the risk isn't all one-way, either. The risk analysis needs to be performed for both the customer and linode.

Linode are responsible for the base builds, not the customer. If linode add their own software that has a massive backdoor then they'd be responsible. Of course linode don't do that; their images are pretty close to what comes out of the vendor installation process. Backdoors and bugs in the vendor product are reasonably pushed onto the customer; that's part of what "unmanaged" means.

However stackscripts are not part of the unmanaged environment. These are a linode mediated automation tool, especially if the script is allowed access to the API key. Thus far the risk exposure of stackscripts would be to backdoor or break your OS build. By allowing access to the API key the risk exposure is massively greater.

And this is where the "not one way" concept comes in. If a stackscript causes $$$ charges on a customer's credit card and the customer disputes the charges, causing a charge-back to linode then linode are out of pocket. Linode can't assume customers will be reasonable and discuss it with linode and get the money credited; I know I'd reject unauthorised charges. If I was linode then from a pure business risk analysis position I would want to make it damn clear to the customer the consequences of their actions to minimize this risk. And who knows what impact this would have to their reputation; linode would end up having to police and certify every stack script... and I know this is impossible (it's hard enough to follow some scripts even when they're not deliberately trying to hide bad behaviour!)



Highlight and emphasise the "complete". Have a default "N" response. Potentially double-validate.

To go into the "risk mitigation" aspect further, we've seen non-experts setting up linodes. Linode makes it very easy (it's a big selling point; if someone wants an unmanaged VPS then linode is one of the best for setting it up). These people can not validate the libraries, the scripts. A new customer may not even know what "access to the linode manager" means. They may work on the assumption "it's part of the build process; it must be OK". And they will be mightily pissed off if they see $$$ on their card. Even if there's no actual linode liability, there's a reputational risk.

Life is never black or white. If I was linode I'd want to protect myself by explaining the risk to the customer who is making the decision. "Cover Your Arse". At least that's what I'd tell my management at work if such a proposal came across my desk

_________________
Rgds

Stephen

(Linux user since kernel version 0.11)

Granted. I hadn't considered the backlash to Linode like that. However, perhaps a more realistic solution, rather than having each script granted permission for a subset of the API, would be to sandbox an API key. For instance, API Key #1 has full access, but API Key #2 is denied access to the linode.create and linode.delete.




Also granted. That warning, with a selection defaulting to no, and having to confirm API access, makes sense to me.