Hacker News Reader

Comment by imroot | Hacker News Reader

Before I would deploy this, I'd have to really understand what you're doing with your chef recipies -- I would be concerned that your use of chef might throw my system into a unknown state -- specifically, what are you doing in chef? Are you adding SSH keys in your recipe (I'm not saying you are -- I'm just saying there's a severe lack of transparency as to what's going on behind the scenes, and that could put me at risk if I were managing that type of thing).

Other than that -- cool stuff.

View on HN

I definitely understand that there's a level of trust needed before you allow anyone get access to your system (or be it's provider). And it should be that way.

While I could describe what's going (and will right below), there's also the risk that what I'm saying doesn't match up with what's really going on. The best way to personally check what's going on is to set up a throwaway system and see if everything checks out. (You'll see that it does.)

So what is the process?

1. Install necessary os distribution packages to be able to build dependencies for the rayburst client 2. Download and build ruby from source 3. Install rayburst client (which includes chef) 4. Run the install for your server configuration 5. Report back success/failure of the install

You're able to see the install script that's downloaded via the wget command and as well as the recipes that are cached locally on your system (check the install output for the locations).

And the only way to be sure in the future that it remains this way is to have a trusted outside entity perform regular audits. It's a bit too early in the stage of this project for that. But it's one of the things I've thought about.

If your target audience for this is the individuals who don't have the skills or time to really settle down and do the install by hand, do you honestly think that they have the time (or skills) to set up a throwaway system and then audit the changes that your log files say versus what really happened on their system?

I'm not trying to bust your chops -- I think this is a great implementation that is geared for developers who might not have sysadmin experience -- I'm just saying that there seems to be a fair amount of risk opening up and running remote bash scripts based off of anything on the internet; chef and other system configuration tools require you to implicitly trust your sources, because they can change at any time. What happens if your system gets broken into? What happens when the service no longer exists? As I've mentioned, this would be a great service for developers who don't want to mess with managing their own test and development environments, but, I'd never push this to a production server.

There's a fair amount of risk in everything: Do you trust the admins of you hosting provider? Are you sure about the source code or binaries for all the pieces of your runtime stack? Did you audit every piece of your own source code for security issues?

But right now I'm not asking people to drop everything and use rayburst to set up their production servers no questions asked. Just to try it out and see if it does what they need.

If someone then decides to use it for production setup, we can talk about how to guarantee security and stability in the configuration for their setup. BTW this is why you enter into contracts, pay for services, etc.

There's elevated risk because the downloadable scripts use `sudo`. I think the concept is great, but asking users to allow `sudo` permissions to a foreign script site unseen is naturally bound to raise suspicisons. That said, I am thrilled that the site is protected by HTTPS, especially the install scripts themselves. You have obviously put a lot of thought into this product, and I see several ways to monetize it. The only problem for me is that I'm currently using a (cheap) webhost with restricted accounts and I cannot use `sudo`, but in the future I'll come back to see how your site performs.

"sudo" is unavoidable since the installs are designed to go into /usr/local. The other option would be to require you to run as root/privileged which leads to the same issue of running an unseen script and just adds an extra step to the process.

It's possible to design the process to allow installs into other locations but that would require a fair bit of extra configuration (picking up the libraries, etc.) and testing. And you'd lose the service startups. It's something to think about if there's enough demand (and probably required for supporting Macs)

Perhaps custom installs could be a premium feature?

What the generated rayburst.sh script does:

1. Writes out configuration for the chef client.

2. Generates a node on the chef server with the specified "run list" (recipes selected in the rayburst site).

3. Install Ruby and Chef RubyGem

4. Runs Chef with the node that was created on the chef server.

You can download and preview everything before it runs as root on your system.

For example, if you choose the normal stack, you get this run list:

recipe[nginx], recipe[passenger], recipe[postgresql::server], recipe[rails], recipe[ruby]

When you run this on a system, like a throwaway VM or EC2 instance, it will download the cookbooks required for this run list, which you can review what they're going to do after the synchronization step of Chef is complete. With rayburst, the cookbooks will be synchronized into /var/cache/rayburst.

Reply on news.ycombinator.com