Bug 755935

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