holland-discuss team mailing list archive

[Tim Soderstrom <tim@xxxxxxxxxxxxxxxxxxxxx>]

I ended up with weirdness when doing a simple offline backup of the LDAP DB. That could be lack of understanding and the need for additional testing. LVM isn't a bad thing though and I suspect we will end up using multiple methods there. Integrating LVM sounds like a bigger task though so I'll focus on slapcat first I think. I don't need anything more than that but I was thinking of comparing slapcat to ldapsearch (which can output in LDIF). The latter I had weirdness too for restoring data as well though (again, probably lack of understanding).

You are correct that slapcat can have problems on active servers, though I think when using BDB or HDB it should be ok. Part of my evaluation involves having to hammer some of this stuff out so if this plugin comes to fruition I'll be sure to document those exceptions (assuming it still ends up using slapcat I suppose).

I'll take a look at those code corrections ASAP, thanks as always Andy!

slapcat...what a funny name...


On Jan 12, 2011, at 2:51 PM, Andrew Garner wrote:

> I'm not too familiar with ldap, but I know some people will backup the
> bdb backend directly as an alternative to slapcat.  You may be able to
> leverage LVM for that (although I suspect that may not be an option in
> your environment), and I believe there is a hotbackup utility for bdb
> as well that could be used.   Other backends have other implications
> of course (and IIRC, even slapcat won't work consistently for some
> backends on an active server).
> 
> A few minor things on your code:
> 
> * Stylistically, you probably want to use list.append, rather than
> list.insert(-1, ..) here
> * You don't need to cast to int() here: int(self.config['compression']['level'])
>   The configspec/validate_config() part takes care of that for you.
> That's one of the reasons holland has configspecs - so you don't have
> to convert strings all throughout your plugin.   I see this was taken
> from sqlite, but I thought I'd mention it.
> * You should close the output stream at the end.  It's actually
> forking a command (e.g. gzip) in the background, and close() will
> collect it and check the status.  Otherwise the plugin won't report
> errors from compression.  stream.close() can raise an IOError - this
> is does when the compression command exits non-zero.
> * You probably don't want to use os.setsid for subprocess here.
> * You probably don't want to actually run the slapcat command if
> dry_run is set (Logging list2cmdline may be useful though).
> 
> I'm not sure what you mean by DEBUG.  If your debug statements aren't
> showing up you probably need to run holland with debug logging:
> holland --log-level debug backup ... (or set level = debug in the
> holland.conf).   This should work fine - I just ran it yesterday
> during testing.
> 
> On Wed, Jan 12, 2011 at 1:34 PM, Tim Soderstrom
> <tim@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> Howdy Folks!
>> 
>> After some Googling, I didn't see a really good backup tool for OpenLDAP. They probably exist and I just suck at Googling but it gave me a good chance to try using the Holland framework to do something both neat and actually useful for my job (which means I can work on it for my workey work time, yay!).
>> 
>> So I have created an OpenLDAP plugin that uses 'slapcat' to produce a backup. 'slapcat' is actually not very feature rich so I am wondering if other methods would be suitable (such as the OpenLDAP Python library) though documentation online seems to point to slapcat for a no frills get 'er down backup. In my testing I had to use it once or twice so it seems to do the trick.
>> 
>> Anyways, I have this in my Holland fork (https://github.com/m00dawg/holland). Any suggestions would be appreciated. My Python foo sort of went away pretty quickly after not using it for a few months so I ended up using the random and sqlite plugins as templates.
>> 
>> If you look at the source files, there not a lot of log debugging going on. I could not get log.DEBUG = ... working for some reason?
>> 
>> By the way, that virtual_env.py script freaking rocks!
>> _______________________________________________
>> Mailing list: https://launchpad.net/~holland-discuss
>> Post to     : holland-discuss@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~holland-discuss
>> More help   : https://help.launchpad.net/ListHelp
>> 
>