12 ms·

Show HN: Perl-based server-management tool

63 points by stevekemp 14y ago

jamespitts 14y ago
Awesome work... What are your impressions of rex? 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?
- stevekemp 14y ago
  I think, after a bit of a google, that you're referring to this: * https://github.com/krimdomu/Rex 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.
ionforce 14y ago
Why is it called Slaughter? Seems not as inviting.
- stevekemp 14y ago
  At the time the project was envisaged the name was chosen because it sorta-rhymed with the word "auto" - as in "automation". (It helps if you have a Scottish accent.)
davidw 14y ago
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.
- stevekemp 14y ago
  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.
  - SwellJoe 14y ago
    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.
    - stevekemp 14y ago
      I'll update the documentation to be less .. heavy-handed. Thanks for the comment.
      - mst 14y ago
        The tone you're probably aiming for is "well, it's a sysadmin tool, obviously I wrote it in Perl" :)
- Surio 14y ago
  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 ;-) You go, Steve!
  - davidw 14y ago
    You lot downvoting me are not going to make the language popular again by doing so. Is he trying to make a useful and widely used tool or promote a language? Those things might not necessarily go hand in hand.
Surio 14y ago
Superfluous question, perhaps. 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) ;-) http://zedshaw.com/essays/why_i_gpl.html http://zedshaw.com/essays/why_i_gpl.html
- stevekemp 14y ago
  Either the Perl artistic license, or the GPL. 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: https://github.com/skx/slaughter-policies/ https://github.com/skx/slaughter-policies/
  - Surio 14y ago
    Okay. > 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 http://news.ycombinator.com/item?id=5316093 (@robomartin's comments in the beginning)
- papsosouid 14y ago
  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?
  - Surio 14y ago
    >> GPL somehow forces venture capitalists to believe his software is as important as he believes it to be 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.
BCM43 14y ago
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?
- stevekemp 14y ago
  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.
zengargoyle 14y ago
Have you seen 'The First Thing Tak Did'? http://www.youtube.com/watch?v=XUCrnR06oKc 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.
- stevekemp 14y ago
  There are tools out there that will configure remote machines, using nothing more than SSH. http://ansible.cc/ http://ansible.cc/ is probably the most popular.
- mst 14y ago
  I didn't get the design quite right with that. My subsequent http://p3rl.org/Object::Remote 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.
- axw 14y ago
  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 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.
meaty 14y ago
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.
- stevekemp 14y ago
  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.
keymone 14y ago
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.
- stevekemp 14y ago
  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.
jlsync 14y ago
perl, templates, and rsync - here is my earlier solution for server configuration management & installation tool: http://www.jlsync.com/ http://www.jlsync.com/ and https://github.com/jlsync/jlsync https://github.com/jlsync/jlsync And there is a bonus version in ruby: https://github.com/jlsync/jlsync/blob/master/jlsync.rb https://github.com/jlsync/jlsync/blob/master/jlsync.rb
- stevekemp 14y ago
  Looks interesting. 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.
gizzlon 14y ago
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. Does this sound about right?
- stevekemp 14y ago
  Reasonably good summary. 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.
jcmcken 14y ago
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 EDIT: Forgot to mention the various REST APIs
- stevekemp 14y ago
  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.

63 points by stevekemp 14y ago

Awesome work... What are your impressions of rex? 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?

stevekemp 14y ago
I think, after a bit of a google, that you're referring to this: * https://github.com/krimdomu/Rex 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.

ionforce 14y ago

Why is it called Slaughter? Seems not as inviting.

stevekemp 14y ago
At the time the project was envisaged the name was chosen because it sorta-rhymed with the word "auto" - as in "automation". (It helps if you have a Scottish accent.)

davidw 14y ago

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.

stevekemp 14y ago
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.
- SwellJoe 14y ago
  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.
  - stevekemp 14y ago
    I'll update the documentation to be less .. heavy-handed. Thanks for the comment.
    - mst 14y ago
      The tone you're probably aiming for is "well, it's a sysadmin tool, obviously I wrote it in Perl" :)
Surio 14y ago
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 ;-) You go, Steve!
- davidw 14y ago
  You lot downvoting me are not going to make the language popular again by doing so. Is he trying to make a useful and widely used tool or promote a language? Those things might not necessarily go hand in hand.

Surio 14y ago

Superfluous question, perhaps. 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) ;-) http://zedshaw.com/essays/why_i_gpl.html http://zedshaw.com/essays/why_i_gpl.html

stevekemp 14y ago
Either the Perl artistic license, or the GPL. 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: https://github.com/skx/slaughter-policies/ https://github.com/skx/slaughter-policies/
- Surio 14y ago
  Okay. > 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 http://news.ycombinator.com/item?id=5316093 (@robomartin's comments in the beginning)
papsosouid 14y ago
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?
- Surio 14y ago
  >> GPL somehow forces venture capitalists to believe his software is as important as he believes it to be 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.

BCM43 14y ago

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?

stevekemp 14y ago
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.

zengargoyle 14y ago

Have you seen 'The First Thing Tak Did'? http://www.youtube.com/watch?v=XUCrnR06oKc 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.

stevekemp 14y ago
There are tools out there that will configure remote machines, using nothing more than SSH. http://ansible.cc/ http://ansible.cc/ is probably the most popular.
mst 14y ago
I didn't get the design quite right with that. My subsequent http://p3rl.org/Object::Remote 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.
axw 14y ago
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 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.

meaty 14y ago

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.

stevekemp 14y ago
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.

keymone 14y ago

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.

stevekemp 14y ago
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.

jlsync 14y ago

perl, templates, and rsync - here is my earlier solution for server configuration management & installation tool: http://www.jlsync.com/ http://www.jlsync.com/ and https://github.com/jlsync/jlsync https://github.com/jlsync/jlsync And there is a bonus version in ruby: https://github.com/jlsync/jlsync/blob/master/jlsync.rb https://github.com/jlsync/jlsync/blob/master/jlsync.rb

stevekemp 14y ago
Looks interesting. 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.

gizzlon 14y ago

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. Does this sound about right?

stevekemp 14y ago
Reasonably good summary. 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.

jcmcken 14y ago

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 EDIT: Forgot to mention the various REST APIs

stevekemp 14y ago
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.