Backup/restore

[javi]

Sorry, I'm telling you this without testing in  my machine . I think i forgot two extra steps.

1. In your new machine get the new ldap password stored in /var/lib/ebox/conf/ebox-ldap.passwd
2. Get the ldif file you will find within the eBox backup and change the userPassword line of dn: cn=admin,dc=ebox to userPassword: NEW_PASSWORD. Note that you must only leave one ':'
3. sudo /etc/init.d/slapd stop
4. sudo rm -rf /var/lib/ldap/*
5. sudo slapadd < ldap.ldif
6.  sudo chown -R openldap.openldap /var/lib/ldap <- New step
7. sudo /etc/init.d/slapd start

[kerridge0]

funilly enough i've actually been here before with openldap.. solution was to

sudo chown openldap.openldap /var/lib/ldap/*

now i'll be able to check if this was resolved when i pop into the office.

aha <edit> got your new reply.. will update password..

thanks!

[Javier Amor Garcia]

So if the eBox backup utility was changed with the correct level of backup for the computer accounts ( bit level ) than the problem is solved.

In previous version we copied the ldif file, as Javi has explained below, however sometimes we had ldap compabilities between eBox versions and to avoid those problems now we parse th ldap file and recreate the data.
However when I developed the restore process for users and computer accounts I forgot that some data must be copied verbatim because is introduced by the windows clients.

[kerridge0]

well i changed the password line to read:

userPassword: ebox****96841436164

and repeated the same process but now i get a new error,

to be honest I'm not sure whether I have introduced these problems via this procedure, i might have had it earlier, as i didn't test directly before or after the restore, (and the reason i am moving vm is because i was also running fog [fogproject.org] in this machine which had it's own web interface which seemed to break only images on ebox but that's all- but i'm not sure whether i'd had this problem..) when i try and edit the user/group via eg https://192.168.8.2/ebox/UsersAndGroups/Groups, i get the listing fine but as soon as i click the pencil to edit the group I get: An internal error has ocurred. This is most probably a bug, relevant information can be found in the logs.
An internal error related to a template has occurred. This is a bug, relevant information can be found in the logs.

the /var/log/ebox/error.log shows that for groups

this error is:

[Sat Feb 28 18:12:52 2009] [error] [client 10.10.0.2] File does not exist: /usr/share/ebox/www/images/thead-b.png, referer: https://192.168.8.2/ebox/UsersAndGroups/Groups

and for users:

Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/EBox/MailAliasLdap.pm line 291.
Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/EBox/MailAliasLdap.pm line 291.


creating a new user gives this error:

Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/HTML/Mason/Component/Subcomponent.pm line 34.
Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/HTML/Mason/Component/Subcomponent.pm line 34.


Hmmm.

 


<edit> given latest response I can see that maybe i'll need to re-run the restore officially due to version mismatches? should i do that and then maybe do a slightly different slapcat stripping out some windows client stuff? would that even be possible?

[kerridge0]

maybe i should load up the old ebox installation, update it to the latest, then save a backup, and then follow javi's 7 steps on the diff in there? Would that sort me out?

[javi]

Maybe it's better if you wait a few days till we fix this issue  and you go back to the old installation in the meanwhile?

We are going to be working on this real soon. It should be fixed during next week.

[kerridge0]

That's great, i'll watch the thread, thanks!

[kerridge0]

Hi is there any follow up to this/ has the script been updated? as i'm planning to migrate another server tonight if you've sorted it.

[javi]

Hi,

Hi is there any follow up to this/ has the script been updated? as i'm planning to migrate another server tonight if you've sorted it.

I've just uploaded a new version to our unstable repository. I've tested it with two windows machines I have here, and it has worked.

Note that those packages in our unstable repository will make it to stable very soon. It would be fantastic if you can try them and tell us if it restored your machine accounts successfully.

Please, don't install ebox-egroupware to do this for now. There's an issue with the backup we are fixing.

[kerridge0]

if i do this shall i backup/restore as normal and after that get the "unstable" ldap import script.

where iis the parse script? I had a search but couldn't find on the forum

I then need to run that on the ldif i extract from the backup tar, right, after deleting the ldap directory. and i can test after resetting permissions etc.

[Javier Amor Garcia]

if i do this shall i backup/restore as normal and after that get the "unstable" ldap import scrip

Javi (the other) has uploaded the new package, not a script. So if you want to give it a try you must install it and proceed as normal

Here you have the repository and the package is ebox-samba - 0.12.102-0ubuntu1~ppa1~hardy1

[kerridge0]

so install unstable on the new server, and restore backup to that.

These are production servers, but you're saying that they are very close to stable,

Can I then get back on to the stable track after that?

because if not i could just do it for a test and then wait for it to become stable.

[Javier Amor Garcia]

Well the fix was only in one source file so if you want to play it safr we could try to install only th file that has changed.

To do so,
1) make a backup copy of /usr/share/perl5/EBox/Samba/ImportFromLdif.pm
2) overwrite the file which this  one
3) restart ebox web server with: /etc/init.d/ebox apache restart

Try the resotre process now and if it fails you could alway undo the changes copyng back the old file and restarting apache

[kerridge0]

great, the new restore script worked perfectly!!! thanks for your work.

Also, I have a couple of interesting experiences i just had, to report:
* the first being that I for some reason assumed you could scp the backup tar to the backups folder and restore that. When that failed i assumed the installation was corrupt and proceeded to reinstall ebox. This was because I was trying to avoid crashing my browser waiting for it to upload a 1 gig file to the server - perhaps this second way of scp'ing the tar file behind the scenes could be allowed? anyway it's a user error but maybe you could do something there- perhaps warn that the backup seems to be from another installation and ask whether user wanted to restore from it anyway.
* to conveniently trim down the user profiles on the donor machine prior to backup/restore, I created a new share called "profiles". unfortunately, this overrode the standard "profiles" share which is used to enable user profiles in an MS network. For a minute on restoring i thought something new was broken because user profiles couldn't be loaded. then i remembered what i had done, and turned it off, and everything worked again.. So really this stupid behaviour needs to be forbidden i guess check while creating?

anyway i'm on my new hardware running as a kvm machine on a proxmox host and would like to thank again for support getting through this.

Kerry

[Javier Amor Garcia]

* about your backup from anothet installation... I had to see the error log to see what were wrong. We try to make the backups compatible between machines.

 * as for the profiles thing, in newer versions the porfiles will only be stored on 'full backups' to avoid space probelms and bz they are not essential to the configuration of the server

Thnks a lot for your comments