Show HN: Perl-based server-management tool
steve.org.uk
steve.org.uk
http://ansible.cc/ is probably the most popular.
My subsequent http://p3rl.org/Object::Remote module makes a much better job of encapsulating just that part of the work.
(and, yes, I wrote it for server introspection and management code to go on top)
There was another talk called Distributed Daemon Discovery I gave about a codebase called System::Introspector that the sponsoring client loves but we still haven't got round to packaging and releasing.
Pushy is Python-based, not PERL-based, but otherwise it's similar what you/Matt describe. It never really made much ground, though I recently became aware that Ceph is using it in their ceph-deploy deployment program.
Haven't used any of them, but my guess would be:
- It's less advanced, but also less complex and easier to understand
- It's younger so it's less "set in it's ways" and could take another direction
- A fresh take on some things (?)
- Fewer users probably means less pre-made "recipes" etc.
I'd say the transport-flexibility is a fresh-take, the supplied primitives are directly inspired by CFEngine 2.x, so in terms of complexity available to get things done it is good enough.
The lack of pre-made recipes is probably a killer right now.
Perhaps it's just I'm getting old and set in my ways, but I still find perl very useful on a daily basis.
I was forced by employer to learn powershell recently and it made me appreciate perl a lot more as well.
I hope it is useful, but if you get stuck or have suggestions/comments feel free to mail me.
* Ability to define resources and their dependencies declaratively
* Facter and its API, the ability to add custom facts that get deployed with my modules
* TLS encryption and certificate management for client communications
* Reporting/metrics for each run
* Exported resources
(So you can get security by using SSL-protected git repository which allows the SSL to prevent MITM attacks, and git itself to avoid corruption.)
The metrics and exported things are almost certainly never going to get done, but having custom facts on a per-host basis is something that is minimally available right now, and will probably be expanded in the future.
The declarative notion is interesting but down that path lies madness - as an implementor - I don't want to go down the DSL route which makes procedural style definitions the simplest option.
Slaughter occupies a different part of the ecosystem (specifically that slaughter has policies) but do you see possible incorporation of rex into what you have here?
* https://github.com/krimdomu/Rex
I've not sure there's too much overlap, as my initial understanding makes me think that rex carries out scripts over SSH, in a similar fashion to fabric.
I assume that slaughter will be scheduled and will revert changes made manually, for example, it looks like rex will just do its magic at the single point in time you run the script(s).
I'll dig deeper to see if I've misunderstood.
What licence are you releasing it on? I read Zed Shaw's essays (rants?) on GPL a while ago. Given that your tool occupies the Server space (as did his) I recommend a read^H^H^H^H butchers (keeping with the spirit of things) ;-)
I figure the license doesn't matter too much, so long as I see feedback & patches - as I do - the real utility is the policies you write to control your servers, and I don't expect those to be distributed often. Although mine are, FWIW:
> I figure the license doesn't matter too much
Read Zed's essay ;-) If nothing else, it reinforces "street cred" :-)
>> the real utility is the policies you write to control your servers
+1 for that point.... especially in the context of the discussions in the recent thread on HN: http://news.ycombinator.com/item?id=5316093 (@robomartin's comments in the beginning)
No, I don't think that is what he says in the essay.
Re-Read from the "I Don’t Want To Be Ignored Again" section of the essay for GPL and venture capitalists.
I've made licensing deals like this in the past for code under the GPL. It's probably better to be the person or company that expands upon the GPL work and monetizes it...but, I definitely understand where Zed is coming from. Licensing under the GPL doesn't guarantee that everyone who uses your code gives you money...it simply helps make sure you don't find yourself developing code for a bunch of companies who aren't sharing their local changes.
Which is relevant how? Who was releasing closed versions of mongrel again?
I know what the GPL does, that's the point. His blathering is entirely unrelated to licensing at all. He is saying "RoR was famous, and mongrel wasn't, and I don't like that", as a reason to use the GPL. Not only is that entirely nonsensical, but RoR is MIT licensed, so it wouldn't even make sense if you did hit your head and somehow think licensing determined whether or not your software was famous.
He is not saying there were closed versions being released. He simply wanted to point that people were using mongrel very blithely, but not crediting the hard-work, effort and innovation of Zed's work, (which they were using for their own monetary gain!). I don't think he was interested in "naming-and-shaming", flame-baiting, etc., (I suppose).
>> He is saying "RoR was famous, and mongrel wasn't, and I don't like that", as a reason to use the GPL
No. He's not saying that. Here's some paras where the mongrel and ruby discussion takes place. I'll leave it at that.
Even though everyone was using my software, the vast majority of firms using Mongrel were startups. The last thing a startup wants to admit is that they don’t own their intellectual property. They want everyone, especially the VCs and investors, to believe that they’re all geniuses who “innovated” everything they run.
When I looked around, companies had no problem admitting they used Ruby on Rails, hell that probably got them their funding. What I didn’t see was them saying they used anything else, which meant that when I would try to get work, it was impossible for me to explain the magnitude of Mongrel’s impact. To them it was just some simple web server that their system administrator had to use
After Mongrel I almost need companies to have to admit they use my software. I would actually rather nobody use my software than be in a situation where everyone is using my gear and nobody is admitting it. Or worse, everyone is using it, and at the same time saying I can’t code.
> Even though everyone was using my software, the vast majority of firms using Mongrel were startups
GPL is not going to fix that, it might actually make it worse as many companies don't like the GPL
> The last thing a startup wants to admit is that they don’t own their intellectual property
Maybe, but GPL is not going to fix that
> They want everyone, especially the VCs and investors, to believe that they’re all geniuses who “innovated” everything they run
GPL is not going to fix that
> When I looked around, companies had no problem admitting they used Ruby on Rails, hell that probably got them their funding
GPL is not going to change that
> What I didn’t see was them saying they used anything else, which meant that when I would try to get work, it was impossible for me to explain the magnitude of Mongrel’s impact
GPL is not going to change that, as you can still use it without telling anyone..
> To them it was just some simple web server that their system administrator had to use
GPL is not going to fix that
> After Mongrel I almost need companies to have to admit they use my software
GPL is not going to fix that
> I would actually rather nobody use my software than be in a situation where everyone is using my gear and nobody is admitting it
GPL could make this worse, but probably not.
> Or worse, everyone is using it, and at the same time saying I can’t code
What? who's saying that? :'(
Honestly, it looks like Zed should hook up with someone that could help him monetize his awesome work.
Read the paragraphs you quoted. Which one of them is a reason to use the GPL? The answer (quite obviously) is none of them, which is my point.
And there is a bonus version in ruby: https://github.com/jlsync/jlsync/blob/master/jlsync.rb
80% of server automation can be solved by "copy master file and restart the service that uses it". I don't see anything obvious about restarting services in jlsync, but the copying seems well thought out.
For my own hosts it does _everything_, from installing packages, applying security updates, and tweaking configuration files.
i don't care about the language you use but if your API/DSL is so inconsistent even in such a brief example i fear any large installation will be a maintenance hell.
I choose to believe the current additional primitives make sense as-is, so there inconsistency isn't so glaring. Whether that is true of course is a matter of familiarity.
(It helps if you have a Scottish accent.)
Sure it might not be the new-shiny, but it still works, and thanks to CPAN there is a hell of a lot of Perl code out there, neatly packaged and available for use.
Thanks for the comment.
You go, Steve!
Is he trying to make a useful and widely used tool or promote a language? Those things might not necessarily go hand in hand.
Beyond that the idea of being popular/widely-used are things I've not considered. I find perl the language to be installed almost everywhere, and still very much in use, albeit not often promoted as such.