A web-based interface for dev-op tasks across remote servers using SSH

Let me make sure I understand this. I'm going to pay you to help you to develop a commercial software service that allows me to run scripts in written in my favorite open source programming language connecting over my open source SSH client to talk to my open source web server that makes connections to my open source database all which runs on my open source operating system?<p>I'll stick to shmux for these tasks thanks. It doesn't require me to hand you my SSH keys, runs on the command line, already supports parallell SSH execution, and is free both in terms of speech and beer.

So, tell me - what would this tool offer over, say, RunDeck or mcollective? Why only use SSH keys? (What if I'm using LDAP across all of my machines?)<p>I'm not trying to knock your product - I really do hope you get Kickstarter funding! But I just wanted to say that, to me, as a systems engineer, I only see a pretty interface, but not much value add over the other two products mentioned above<p>I also feel that comparing Commando.io to Puppet, Chef, or even Capistrano is disingenuous - Puppet and Chef are configuration management systems that are meant to keep your systems 'in policy', and Capistrano is meant for repeated tasks over SSH (mainly for deploying software, but it can be used for other things too.)

I can't help but think that for a tool like this you are trying to sell to a crowd of command like jockey's. For this crowd, there is no better interface than the command line.<p>There are cases where I do prefer web interfaces to command line. The AWS web console is an example of this, but for me this is a case of balancing control vs convenience. Installing the AWS libraries to use the command line is a greater PITA than the need to use the command line.<p>With Git, I prefer the power of the command line over a graphical client. However, in this case there is little or no convenience in the difference because I have to install Git either way.<p>The only usage I would be able to get out of this would be to give my non technical managers, clients, co-developers, etc a way to do deployments if I'm not available. One scenario would be for contractors to be able to setup their own dev servers. So, I can see a situation where I could use it, but it's a bit of an edge case.

&#62; The real power comes from creating more complicated recipes.<p>This is my sticking point: if the power comes from the recipes, how does having a web interface help any of that? I think this is a great piece of work, but I just can't see what the advantages are over any of its competitors given that all the actual work is still being done in the same way (e.g. shell scripts).<p>I would add that you bring up GitHub a number of times as a comparable service, but I think that the key difference is that a number of core git features are actually implemented by GitHub (e.g. fork, log, pull) and although this all looks great it isn't the reason (IMO) why it's successful, it's because it makes a common operation easier (i.e. git repository management). I think that you would need to make common dev-op "recipes" easy to generate before the GitHub comparison is correct.

This would be a better project if you sold a license to company and not a saas service. I don't want to put ssh-keys on my network from another machine I have no control over. If anyone ever got access to your service they could have a field day.<p>I would give it a run through if you offered it as software though.

OK one feature you should add and will make this stand out even more.<p>Two phase commit.<p>Admin enters commands, another had to enter same commands on another console and only then are they executed or passed to a third admin to approve actioning.<p>No more rm -f in root or other slip ups. No more silly mistakes. Added accountability and in that added security.<p>You would also get x10 the amount of backing from alot of institutions alone for that feature and even if you don't have it now, factor it in down the line as the quality of admins has gone down hill over the years and in that more mistakes get made. This will reduce that and the impact as well as protecting jobs as well as the machines from human shortcommings.<p>Logging aspect you have outlinesd is good. Get it robust by design and cater for remote logging servers and with all that you could go far.<p>Good luck

Neat idea. I'd definitely donate if the whole thing was going to be open sourced so I could run it on my own infrastructure.<p>Currently we use csshX for this sort of thing, and it does the job. It's an open source tool that opens a bunch of ssh sessions and sends each character you type to each session. You can launch it with command line args that specify the hosts you'd like to connect to and optionally the commands to run, so it's pretty easy to set up scripts that mimic the recipes in this video. If you're working with less that 20 servers at a time (about the limit of what you can read on screen at once) it's a great tool.<p><a href="http://code.google.com/p/csshx/" rel="nofollow">http://code.google.com/p/csshx/</a>

What is the difference to <a href="http://rundeck.org/" rel="nofollow">http://rundeck.org/</a> which can be integrated with foreman or puppet?<p>It also looks like (not sure if i am right) but your worker/server has to have direct ssh access to the server. This means you basically have root access as most configuration management tools need root to administrate the server.

Feedback from someone that's previously (long before the devops scene exploded) looked at commercializing a system like this:<p>Your UI should integrate monitoring and control using an actually visual interface detached from any underlying model used for state collection or implementation of state changes (because this stuff changes constantly, regardless of how much myopic VC money is thrown at it). This means instead of talking about "recipes" and suchlike, you talk explicitly about the objects being managed: services, servers, racks, PDUs, switches, routers, coolers, links, and so on.<p>Make it visual, like actually beautifully visual. Let me specify a floor diagram that colours each rack according to the mean health of the machines it contains. Clicking the rack should show an exploded view of each machine coloured by the mean health of each service they contain, and those services' dependencies. Provide instantly selectable overlays showing different kinds of topological relations (application/network/power/trust/routing/OAM/TCP connection state(!)) existing within the view (complete with colouring).<p>I want a tool that lets me study a floor diagram and instantly notice a set of racks are down because they are in a row supplied by a single PDU. I want to correlate crashes visually due to cooling hotspots, preferably even by relative colouring due to temperature sensors in the machines. I want to batch shutdown a set of machines connected to the NFS share I just found 0day on.<p>I want a generic visualization of a service that displays a set of vital metrics (error count, load, cpu usage) and a set of generic actions (restart, stop). I want a simple editor that allows me to assemble widgets ("CPU load gauage", "requests/sec gauge", "dependency health indicator") into some meaningful representation of a service using nothing but a mouse.<p>Don't bake any topology into it: make it useful for systems as small as 2 cores, or as large as having presence in every country. Racks aren't first class objects, they aren't containers, they're relations with some useful attributes. Don't bake implementation or buzz technologies into it: your codebase could be less than 10,000 lines JS+high level language backend.<p>Don't freeze out keyboard cowboys: there's no reason a highly visual UI need require a mouse. An idiom involving a handful of standard shortcuts ("object select", "object query", "object manipulate", "back", "bookmark", "assign shortcut") are all that's needed. I imagined a system involving keys 0-9 being redefinable (think Command &#38; Conquer, not Emacs) with a few letters preassigned (think Gmail/Google Reader)<p>I want a UI no less visually beautiful than Google's search globe ( <a href="http://data-arts.appspot.com/globe-search" rel="nofollow">http://data-arts.appspot.com/globe-search</a> ) for monitoring the state of my service. I want to notice the bandwidth spike occurring on the dark side of the earth.<p>Prior to a system like this that can be assembled with a minimum of fuss, and can be integrated with existing data sources and systems (most medium sized companies already have an asset database, etc.), I'm not going to be impressed by some crappy Ruby on Rails jammed together with a bit of JS as a fancy editor for some DSL.<p>Give us something with wow factor, not just another bland excuse of crap offering zero benefits over a command line, that'll end up lying dead in a Github repo in a few years.<p>[Footnote: for anyone with cash interested in systems like these, feel free to get in touch. I can barely enunciate correctly when talking about this stuff, my vision for what devops should look like is so far removed from the current popular state that it pains me to pay it much attention]

I'm not sure if I'd want anyone touching my servers who thought that fabric had a 'steep learning curve'. That just sounds irresponsible.

Did the creators of this use any of the tools in this domain? How does this compare to mcollective/capistrano/vlad the deployer/fabric/ssh and a for loop? It's a web app, how is that superior to something CLI based?<p>God, its Matriu AS (<a href="http://www.kickstarter.com/projects/naterockhold/matriu-as-lightweight-and-open-source-it-automatio" rel="nofollow">http://www.kickstarter.com/projects/naterockhold/matriu-as-l...</a>) all over again.

I like the idea of this but some visuals like graphs or meters would make it a lot more interesting.<p>I wrote a little monitoring tool like this for our servers. instead of the monitor using ssh command "recipes", it just hits API endpoints that return JSON. The monitor doesn't really care what the API is checking, it just expects that service to "neutralize" whatever metric it is checking into something that can be graphed. I think the same could be done if you have a specific data format that recipes are required to output. Those recipes that returned a common data format could then be graphed. Of course it takes a minor amount of programming to parse the output from "uptime" (for example) into formatted data, but once one person did it that could be available as a pre-buit recipe for all of your customers.<p>Our tool is pretty much hard-coded to our system but I had always thought it would be a cool thing to have. I've looked at other monitoring systems that seem to do that already but many of them are so complicated and none of us have the motivation to learn them. We're a typical team of programmers who have to be admins by default.

I would use this tool &#38; have backed it.<p>It looks like it runs very similarly to our current server management systems, but the web UI is a huge plus.<p>I agree that open sourcing it to run on your own infrastructure would be a big benefit - people tend to be a bit protective of where they put their root ssh keys :)

Sigh. Please actually use other tools in orchestration space before building another wheel.<p>A nice ui over pluggable backends is a great idea. Building (another) sub par orchestration tool seems like a waste of everyone's time. Mcollective has had the prototype REST bridge for what, 2.5 years?

Have you considered to develop this on the top of chef-server?<p>I think most features (and more) you mentioned in the video are already covered by the chef-server (recipes, role, ohai, search, provisioning etc), and they have large community and more thoroughly tested.<p>However, their webui is too simple, and in particularly not extensible - no plugin mechanism so it is difficult to add some minor feature on the top of their webui.<p>So I think there is a huge market for providing a better UI for chef-server, especially they are one of the leaders in the field?

Our company uses a combination of Capistrano and Puppet. It is actually pretty easy to get going with Capistrano and Puppet if you are comfortable with Ruby. Our Capfile specifies the server recipe which is propagated to Puppet using Environment Variables. The whole operation is easy to understand, and very little learning curve required.

dev-ops for me also includes provisioning - and based on " ... you can use shell, perl, ruby, node.js ..." I don't see a strict system for that in place.

All of your SSH keys in one place? SPOF much?

what is a devops task? I normally just call this work.

Why not fabric? In what universe does fabric have a deep-learning curve?<p>Good lord.

I'm sorry but you call this an automation?, imagine you have 200 nodes, lol.

&#62; However, once we get the node.js SSH workers polished and ready for prime-time, you may run workers on your own infrastructure.<p>Anyone who gives these people money is a fool.