Thanks for the suggestions. For the record, status 32 was an error on my part, I hadn’t quoted the bind DN so ldapsearch was actually complaining about the bind DN not being found, not the backup task. Noriko, I’ve searched “cn=backup,cn=tasks,cn=config” and can’t find nstaskstatus anywhere. I’m assuming that it also gets deleted once the task is complete...
Hi Rich, I appreciate your clarification. I did however mean that I was searching “cn=backup,cn=tasks,cn=config” with no additional filters which should have returned everything, nsTaskStatus included for any backup job? Exactly what search parameters (e.g. ldapsearch command line arguments) did you use? I might just be having a dumb moment but I couldn’t think of an efficient way to check the error log for a Backup Finished entry, anyone with suggestions?
I’m still having issues, $taskDN for example would be something like cn=backup_2012_4_5_13_36_23, cn=backup, cn=tasks, cn=config
while [ ${COUNT} -ne 0 ]; do # # OOPS: -b ${taskDN} # -b "cn=backup,cn=tasks,cn=config" "cn=<task>" # COUNT=$(ldapsearch -x -H ${HOST} -D "${BINDAS}" -y ${PWFILE} -b "cn=backup,cn=tasks,cn=config" "(${taskDN})" dn | grep -c '^dn') so this would expand to something like OK, search terms corrected. The command expands to and returns this: ldapsearch -x -H ldaps://<host fqdn>:636 -D "cn=Directory Manager" -y /root/.389ds-pw -s base -b "cn=backup_2012_4_11_7_28_40, cn=backup, cn=tasks, cn=config" # extended LDIF # # LDAPv3 # base <cn=backup_2012_4_11_7_28_40, cn=backup, cn=tasks, cn=config> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1
... $dn = "dn: cn=$taskname, cn=backup, cn=tasks, cn=config\n"; $misc = "changetype: add\nobjectclass: top\nobjectclass: extensibleObject\nttl: 600\n"; $cn = "cn: $taskname\n"; The entry gets added, but still disappears near instantaneously (db2bak.pl called standalone for output): Back up directory: /var/lib/dirsrv/slapd-<host>/bak/<host>-2012_4_11_7_42_4 ldap_initialize( <DEFAULT> ) add objectclass: top extensibleObject add ttl: 600 add cn: backup_2012_4_11_7_42_4 add nsArchiveDir: /var/lib/dirsrv/slapd-<host>/bak/<host>-2012_4_11_7_42_4 add nsDatabaseType: ldbm database adding new entry "cn=backup_2012_4_11_7_42_4, cn=backup, cn=tasks, cn=config" modify complete As you can see from the ls output below, tar is still being called before the task has completed: [root@<host> backup]# ls -ltr -rw-r--r--. 1 root root 6788 Apr 11 07:28 20120411072840-<host>.tgz drwx------. 5 nobody nobody 4096 Apr 11 07:28 20120411072840-<host> Thanks for your time.... if [ ${COUNT} -ne 0 ]; then sleep 5s fi done tar czf ${BACKUPPATH}${BKTSTAMP}-${INSTANCE}.tgz -C / ${DSBACKUPDIR#/*} However the tar file is incomplete, because (assumption) the backup has not finished writing to disk before tar starts.... For the time being I’ve settled on two scripts, one to start backups and another to archive yesterdays (or older) backups. Not ideal but workable Thanks again, Brett From: 389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:389-users-bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Noriko Hosoi You could search the task.with nstaskstatus attribute. [05/Apr/2012:09:32:09 -0700] - Backing up file 31 (/var/lib/dirsrv/slapd-totoro/bak/totoro-2012_4_5_9_32_8/DBVERSION) Thanks, Hi guys, I want to tar up the backup set once a db2bak.pl backup job has finished. however because it writes an entry to the LDAP and doesn’t wait for the backup to finish I was wondering what the best way to determine when the backup has actually finished? I was thinking that I could Ldapsearch at intervals for the backup cn entry, when it’s not there anymore backup has finished Ro maybe watch the audit log for a delete action on the backup cn entry.. Any thoughts appreciated. Cheers, Brett ------------------------------------------------------------------- GreeNRB NRB, daring to commit -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users ------------------------------------------------------------------- GreeNRB NRB, daring to commit -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users ------------------------------------------------------------------- GreeNRB NRB, daring to commit ------------------------------------------------------------------- GreeNRB NRB, daring to commit |
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
