I would never in my life allow an external machine to run arbitrary commands on my server. This is like giving root to some person I don't know.
Even if I could read all these scripts the service is going to execute, nobody tells me that the script I'm seeing on the web service is the script that actually gets executed.
Now. I don't insinuate that the OP is trying to take over servers, but we all know about bugs and/or the famous disgruntled employee.
If I could install this service in my own network, having full control over the scripts and the service itself, this could be useful, but giving root to some server not under my control?
This actually begins at the very first start of your video.
You want me to execute a script that I download using wget from a non-https-site. As root.
It will be an HTTPS site, and maybe even if you wouldn't run the scripts, would you consider contributing on the other end, writing them and sharing with less experienced users?
I can't comment on the technical parts of what you're offering as I don't know Rails, but it might be a good idea to use full sentences in your introductory text:
"For example, deploying full rails environment to your server for your new app. Or as simple as installing and configuring iptables on your existing live server. "
I notice that the web site doesn't tell me what StackFu is. I don't want to have to watch a video just to find out if the concept is interesting enough to warrant the time it takes to watch a video.
Anyway, it looks like a cool idea and I wish you the best of luck. And I've signed up for the beta. I still haven't watched the video.
This looks like a great idea but I have a few concerns/questions about it:
1) As others have mentioned, there needs to be transparency on what each script does to make sure that it is not malicious. Is there a way to inspect the code without running it?
2) How do you protect the communication between stackfu and the user's servers? I saw in the video that you provide some keys, but is the connection thoroughly secured to prevent any potential spoofing? What about a potential attack that would come through the site itself and potentially access all users' activated servers? I would be very cautious to have stackfu installed as a daemon on a production server without knowing it's secure inside out -- even if I only enable it when I need it.
3) Did you consider developing a stackfu shell client? Using the command line client, you could provide some basic features like searching and running scripts. Since the scripts are started from the server itself this might be more secure. Although, you still need to make sure that the scripts are actually coming from stackfu (in case it was somehow spoofed), similar to package distribution systems (yum, apt, etc.). Another utility for the client could be to allow/disallow queued scripts sent from stackfu and maybe even a monitoring tool (see the output, previous logs, etc.).
4) How do you handle different *nix configurations? Do script authors need to make different scripts for each distribution? Do you provide a facility to only search for scripts that are compatible with your server(s)?
5) Aside from the number of deployments, do you have a rating system? Script failure and success rates? The number of deployments is hardly enough for me to choose from say 20 different Wordpress installation scripts.
1) Yes, there will be many ways to do it. One is online, clicking the scripts. We'll provide a lightbox with the code. Another way is "cloning" the script to your account (no git clone in this case, just a hard copy). You can then make changes and publish it back to your account.
2) The connections between your server and StackFu's will be done using HTTPS. We also offer the option to run the service as a daemon or as a standalone, where you have to manually confirm each installation request;
3) I am not sure I understand your concept of shell. We already have a REST API and a Ruby Gem that enables you to do things like publishing a new script, listing servers and scripts, deploy scripts, all from the command line.
4) This won't be available in beta, but we have planned as one of the possible requirements of the script to be the operating system, and that would involve doing some server side checking to make sure the proper OS is installed. Once we have that, I agree that we need to make that searchable;
5) We don't, currently, have a rating system nor rates, however they are interesting concepts. We may do a upvoting/downvoting system similar to what Reddit or StackOverflow does.
Thanks for your feedback. Keep them coming, please!
what is the "social" part? I'm not entirely sure I get what the product is. is it the sort of thing where if you don't get what it is, you probably don't need it?
I believe it's social because it's a community where people can share their own scripts and improve on existing scripts. As well as deploy them easily, of course.
The social part is, imagine like a github, where people put up code and you can see it? Same thing with stackfu. People can put up stacks and you can deploy them to your server.
Example: A user made a stack for Rails, you need rails, you go and deploy the guy's Rails stack. You'll be able to make a copy of it, edit it, review it, and make it yours if you want, fix it update and push your own version so other people can deploy it.
Are there any measures in place to deal with people who upload malicious stacks? Would they just receive negative reviews? Do you think you need to warn users to not blindly trust a stack?
With Chef you provision and manage your server's configuration, while StackFu is a social place for people to share "recipes" or stacks to be installed on your server.
Ideally, this will be the place for linux savvy folks to share their scripts. And for people who just wants to get something installed (like WordPress) to go, search and easily get it up and running.
Do you have plans for how scripts will be reviewed/flagged? I see from the video that one can see who else has deployed the script (with the assumption that a script deployed many times is most likely "safe"), but I would still feel a bit nervous about running a script blindly -- can one see the script code prior to hitting deploy?
Edit to add: I'm certain you don't want to be liable for people hosing their server with a malicious script -- I hope you have plastered all over the place that these scripts are not reviewed for quality nor mal intent (unless of course, they are?).
Another edit to add: I think this is a great idea! I could see myself using this -- I didn't mean to be such a negative nancy.
This is a great point. Let me address your concerns:
About being able to see the code: most definitely. Every "script" consist of zero or more requirements, one or more executions and zero or more validations. Each one is, in the end, a shell script with placeholders. You will be able see the scripts source code online and also "clone" the script to your account (not a git clone but an actual hard copy) and dump it locally using our ruby gem that talks to our API.
We will record another screencast soon about how we create new scripts and how we upload them.
About flagging scripts: we don't want to enforce any formal approval process, but we want the community to be able to flag scripts for malicious code. Another indication of quality may be the number of people who deployed it and/or watched it. We're open to suggestions and feedback on how we could improve it without making it an administrative burden. In the end, you're responsible for what you're installing in your server -- being it manually or through a script.
Thanks for such a quality feedback. Please keep'em coming.
thegyppo, no. this idea came from Webbynode's Readystack system which we developed about 2 years before linode decided to launch their version (they launched it February 9, 2010, we did 2008). (Yes, we're the guys behind Webbynode)
This is our original concept, back from 2008, they launched theirs in 2009.
