

Show HN: Perl-based server-management tool - stevekemp
http://www.steve.org.uk/Software/slaughter/guide/

======
zengargoyle
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.

~~~
mst
I didn't get the design quite right with that.

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.

------
gizzlon
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
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.

------
meaty
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
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.

------
jcmcken
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
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.

------
jamespitts
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
I think, after a bit of a google, that you're referring to this:

* <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.

------
Surio
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>

~~~
stevekemp
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/>

~~~
Surio
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>
(@robomartin's comments in the beginning)

------
jlsync
perl, templates, and rsync - here is my earlier solution for server
configuration management & installation tool: <http://www.jlsync.com/> and
<https://github.com/jlsync/jlsync>

And there is a bonus version in ruby:
<https://github.com/jlsync/jlsync/blob/master/jlsync.rb>

~~~
stevekemp
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.

------
BCM43
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
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.

------
keymone
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
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.

------
ionforce
Why is it called Slaughter? Seems not as inviting.

~~~
stevekemp
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
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
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
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
I'll update the documentation to be less .. heavy-handed.

Thanks for the comment.

~~~
mst
The tone you're probably aiming for is "well, it's a sysadmin tool, obviously
I wrote it in Perl" :)

