Have you seen 'The First Thing Tak Did'? http://www.youtube.com/watch?v=XUCrnR06oKc This talk by Matt S. Trout a while back discussed using Perl to control/configure machines in a way that the destination machines need nothing other than ssh and the perl binary, all the dependencies and code required are on demand loaded over the initial ssh connection. I would love to see this type of thing in a server-management tool.
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.
I haven't seen that before. Thanks, it brought a smile to my face. I made this a few years ago: https://github.com/axw/pushy
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.
Other than being written in Perl, does anyone know what differentiates slaughther from the other projects out there?
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.
I actually tripped over this a couple of days ago after getting frustrated with puppet's rubyness (I hate ruby with a passion). Looks rather nice. Will try it out next time I do any debian kit provisioning.
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 have to admit I'm not a huge fan of Puppet, though I've used it a little recently and I've been a regular CFEngine (2.x) user for the past few years.
I hope it is useful, but if you get stuck or have suggestions/comments feel free to mail me.
Puppet definitely has its own pains, but I feel like I'd quickly reach a block trying to use this tool, and end up either writing more outside of Slaughter than in it or just forking it outright. I think these are the killer Puppet features for 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
I agree entirely, as the author one of the goals was to be "serverless". That means there is no handling for TLS/certs - it is delegated to the transports.
(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?
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).
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:
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)
Wow, that is incredibly nonsensical even for Zed. Is he seriously under the impression that the GPL somehow forces venture capitalists to believe his software is as important as he believes it to be?
I re-read it. I still have no idea what he thinks the GPL would do to solve his "problem". The GPL does not contain a "you have to think Zed is great and hire him" clause.
The GPL does, however, prevent a company from forking your software and releasing closed versions without getting you (the copyright holder) involved. In some cases that simply means the software isn't used by that company. In others, it means they hire the developer or work out a license agreement that allows for software to be released under another license.
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.
>The GPL does, however, prevent a company from forking your software and releasing closed versions without getting you (the copyright holder) involved
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.
>> Who was releasing closed versions of mongrel again?
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.
The title is "Why I GPL", so one would expect the stuff in the article to explain why he's using GPL. But I agree with GP, much of it does not. To be clear, Zed Shaw creates a lot of cools stuff, and if it was up to me I would hire him in a second :) But that doesn't make this piece any good..
> 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.
Nothing you said even addresses my point. The entire pile of blathering nonsense about mongrel and RoR has literally nothing to do with licensing. The article is about why he uses the GPL now. He uses mongrel as an example, despite the fact that nothing he says about mongrel even tangentially relates to licensing in any way.
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.
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.
If I understand this correctly, it is more of an initial server setup tool, much like FAI, and less of a management engine along the lines of Puppet, Chef, or Cfengine?
It will let you write policies which are applied each time it runs. If you schedule it to run hourly it will do the same kind of work as puppet/cfengine/chef would do - providing you write the appropriate policies.
For my own hosts it does _everything_, from installing packages, applying security updates, and tweaking configuration files.
what is the reason behind inconsistencies like !PackageInstalled => InstallPackage but AppendIfMissing? Why not InstallIfMissing? Or !LinePresent => AddLine?
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.
Several of the primitives were directly inspired by CFEngine 2.x, these include "AppendIfMissing" and "CommentLinesMatching". On that basis the names were kept to ease migration(s).
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.
Is the fact that it's "Perl based" relevant? Perl is not a "hot technology" these days, so I'm not sure I'd use that as part of your advertising. If it does the job well, that's what counts.
Perl has traditionally been a sysadmin-glue language, so I think it is worth mentioning in that context.
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.
The mentions of Perl do seem pretty heavy-handed. I'm a Perl developer in the sysadmin space, too (working on Webmin, Virtualmin, and Cloudmin), and I think it's awesome to see new tools being written in Perl. And, I agree that Perl is still the best tool for the job for many sysadmin tasks. But, you probably don't need to mention it 20 times (yes, it's mentioned 20 times; a half dozen times in just the first few sentences) on one page.
Au contraire, it is precisely because of this -> Perl is not a "hot technology" these days <- that we need to emphasise the Perl aspect of this tool, to bring back some coolness ;-)
Right now I have about 100 users. If it gets to 200, and I get comments/suggestions/patches then I'll be happy.
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.
