Description of problem: Man page for RHEL5 luci_admin states the following: restore [<backup_file>] Restore luci’s configuration using data from a luci backup. If no backup file is specified, the default location (/var/lib/luci/var/luci_backup.xml) is used. This is however highly misleading. The parametr that "luci_admin restore [<backup_file>]" takes is used as a name of the destination database filename (defaults to Data.fs) and not as a name of the source xml backup file (defaults to luci_backup.xml). How to reproduce? Passing a name of the file with freshly created backup generates this error: *************** # luci_admin restore luci_backup.xml Restoring the luci server... Unable to open the luci database "luci_backup.xml": luci_backup.xml The luci restore failed. Try reinstalling luci, then restoring again. "luci_backup.xml" is definitely not a luci database. *************** Passing a destination database filename instead works (what a surprise!): *************** # luci_admin restore Data.fs Restoring the luci server... The luci restore was successful. You must restart the luci server for changes to take effect. Run "service luci restart" to do so *************** Version-Release number of selected component (if applicable): luci-0.12.2-38.el5 How reproducible: Always Steps to Reproduce: 1. Install and initialize luci: "luci_admin init" 2. Create a backup using "luci_admin backup" (saves a backup to luci_backup.xml) 3. Try to restore the database using that backup filename as stated in man page: "luci_admin restore luci_backup.xml" Actual results: Man page for "restore [<backup_file>]" description states that the optional parameter is used for source backup filename. Expected results: - Man page should say correctly what is "restore [<backup_file>]" parameter really used for. - Fix luci_admin to use the parameter for what man page says (however this would be a major change in behavior and could break any customer-made backup scripts) Additional info:
Created attachment 535040 [details] Proposed change to luci_admin script. As stated by Radek, this slightly changes the behavior, but I don't think the impact will be noticable -- provided that "luci_admin restore singlearg" was unusable till now. Let's have a look what is being changed: [ Old state ] * luci_admin restore - default _target_: /var/lib/luci/var/Data.fs - default _source_: /var/lib/luci/var/luci_backup.xml * luci_admin restore singlearg - "singlearg" considered as the _target_ (this was contrary to the man pages as subjected in this bug report) * luci_admin restore firstarg secondarg - "firstarg" considered as the _target_, "secondarg" as the _source_ [ Changes made ] * luci_admin restore singlearg - "singlearg" considered as the _source_
See bug 755941 comment 8.
First step is to make a backup of the current luci database: # luci_admin backup Backing up the luci server... The luci backup was successful. The backup data is contained in the file "/var/lib/luci/var/luci_backup.xml" Now let's try to use 'luci_admin restore -r singlearg'(*) specifying the source filename: # luci_admin restore -r luci_backup.xml Restoring the luci server... The luci restore was successful. You must restart the luci server for changes to take effect. Run "service luci restart" to do so # echo $? 0 # luci_admin restore has succesfully taken a single parameter as a backup source filename and restored the database. This is what we need. Now, let's try the two-parameter notation: # luci_admin restore -r Data.fs luci_backup.xml Restoring the luci server... The luci restore was successful. You must restart the luci server for changes to take effect. Run "service luci restart" to do so # echo $? 0 # This is working as expected. According to man page we may omit the parameter completely and luci_backup.xml file should be read by default in such case: # luci_admin restore -r Restoring the luci server... The luci restore was successful. You must restart the luci server for changes to take effect. Run "service luci restart" to do so # echo $? 0 # This is fine as well. (*) For '-r' parameter see bug 755941 Looking at the built-in help the parameters, the description is fine. However, man page is missing this information
Jan, could you please update the man page to reflect the changes?
Created attachment 544666 [details] reiterated patch (includes man page changes as per Radek's suggestion) Let's have a look what is being changed: [ Old state ] * luci_admin backup - default _source_: /var/lib/luci/var/Data.fs - default _target_: /var/lib/luci/var/luci_backup.xml * luci_admin backup singlearg - "singlearg" considered as the _source_ * luci_admin restore - default _target_: /var/lib/luci/var/Data.fs - default _source_: /var/lib/luci/var/luci_backup.xml * luci_admin restore singlearg - "singlearg" considered as the _target_ (this was contrary to the man pages as subjected in this bug report) * luci_admin restore firstarg secondarg - "firstarg" considered as the _target_, "secondarg" as the _source_ [ Changes made ] * luci_admin backup singlearg - "singlearg" considered as the _target_ - backup will fail if "singlearg" file already exists (contrary to using implicit _target_ which is facilitated by automatic numbered backups to avoid this problem) * luci_admin restore singlearg - "singlearg" considered as the _source_ * luci_admin restore firstarg secondarg <-- not supported (does not make sense
Marking as VERIFIED in luci-0.12.2-42.el5. Backing up with new luci_admin build passes fine when no additional argument is given: # luci_admin backup Backing up the luci server... The luci backup was successful. The backup data is contained in the file "/var/lib/luci/var/luci_backup.xml" Running multiple backups without specifying a filename results in numbered backups to be written: # ls luci*backup*.xml luci_backup.xml luci-backup-1.xml luci-backup-2.xml Passing a file name as 'singlearg' argument works fine as well: # luci_admin backup test.xml Backing up the luci server... The luci backup was successful. The backup data is contained in the file "test.xml" When a file already exists, it is not rewritten, exactly as Jan stated: # luci_admin backup test.xml Backing up the luci server... User-specified backup file "test.xml" already exists (will not be overwritten Any other arguments are omitted. luci_admin --help output correctly describes the new functionality: <...> backup: backup the luci's configuration to an XML file backup [backup-file] restore: restore luci's configuration from a backup restore [-u|--update|-r|--replace] [backup-file] -u,--update: keep existing configuration (try to merge); default -r,--replace: remove existing configuration first </...> New man page content is sufficient as well: <...> backup [backup-file] Create a backup of luci’s configuration to backup-file (default is /var/lib/luci/var/luci_backup.xml. Managed clusters, storage systems, local users, user permissions, and SSL certificates will be stored as part of the backup. restore [-u|--update|-r|--replace] [backup-file] Restore luci’s configuration using data from backup-file previously created using backup (default is /var/lib/luci/var/luci_backup.xml). Switches -u (--update) and -r (--replace) controls the semantics of the command: keep (default) or remove existing configuration respectively. The latter has probably the expected effect, but has to be specified explicitly (backward compatibility). </...>
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0151.html