Home > Manual Pages > config

config

Table of Contents

NAME

config – command for configuration management

SYNOPSIS

config clone <filer> <remote_user>

config diff [-o <output_file>] <config_file1> [ <con_fig_file2> ]

config dump [-f] [-v] <config_file>

config restore [-v] <config_file>

DESCRIPTION

The config command is used for managing the configuration of a filer. It allows the user to backup, restore and clone the configuration of a filer.

The config clone <filer> <remote_user> command is used to clone the configuration of a filer, filer. Cloning operation reverts back the filer to the old configuration, if something goes wrong. Filer instance specific information like network interface info.(ip address, netmask etc.), /etc/rc file, license codes and serial number etc. are not cloned. The registry key "default.options.clone.exclude” lists the set of prefixes that are not cloned. At present, we are not cloning the keys, whose prefixes match one of the following prefixes: file.contents.rc, file.contents.hosts, options.if, options.hosts, options.license, options.system.hostname, options.vfconfig. We are also not cloning the volume specific configuration(keys in the options.vols.* namespace). After running this command, reboot the filer for the configuration changes to take effect.

The argument remote_user is specified in the following format : username:passwd, where username is the name of the remote user account and passwd is the password of the remote user account.

The config diff [-o <output_file>] <config_file1> [ <con_fig_file2> ] command finds out the differences between the specified configuration files config_file1 and con_fig_file2. It prints out all the key-value pair mismatches in alphabetical order. This command helps the administrators in configuration auditing. This is also useful to compare the configuration files of the partners in a cluster failover setup to detect configuration mismatches. Use -o option to redirect the output of this command to a file output_file.

The config dump [-f] [-v] <config_file> command backs up the filer configuration into the specified config_file. Configuration is stored as a set of name-value pairs in the backup file. By default, this command backs up only the filer specific (head-specific) configuration. Use -v option for backing up the volume specific configuration also. Use -f option for overriding an existing backup file forcefully.

The config restore [-v] <config_file> command restores the filer configuration information from a backup configuration file, config_file. By default, this command restores only the filer specific configuration available in the config_file. Use -v option, for restoring the volume specific configuration also. After running this command, reboot the filer for the configuration changes to take effect.

In some cases, restore operation may not succeed because the previously saved configuration information is no longer valid. For example, a previous configuration included information about a volume that no longer exists or specifies values (e.g., snapshot reserve) that can no longer be met. In these cases, restore operation reverts back the filer to the old configuration.

For this command, config_file can also be specified as a HTTP URL location, to restore the configuration from remote files. But, config dump command doesn’t support backing up the configurations to a remote location. This will be supported in future releases. HTTP URL location is specified in the following format:

http://[remote_user@]host_name[:port]/path_to_the_backup_file where

remote_user specifies the credentials for the basic http authentication and should be in the following form: user_name[:passwd]

hostname is the name of the http server, like www.mycompany.com.

port is the http port value. If this is not specified, default value 80 (default http port) is used.

path_to_the_backup_file specifies the location of the backup file on the http server.

Note: The configuration file argument {config_file} specified in all the above commands can be one of the following types:

a) A simple file name – this would get saved by default as a file in the /etc/configs directory.

b) A full-path file name.

c) Just a `-’. In this case, it indicates either standard input or standard output. This value can only be used with config dump and config restore commands. When used with config dump command, the whole filer configuration is written on to the standard output. When used with config restore command, filer configuration information is read from the standard input.

EXAMPLES

Here are a few examples of the use of the config command.
  1. Filer> config clone foo1 root:xxxx   Clones the remote filer,  “foo1′s” configuration on to the   filer executing the clone command,  i.e. on to “Filer”.    2. Filer> config diff 11_30_2000   Compares the filer’s current configuration with the configuration   information available in the backup file /etc/configs/11_30_2000.    3. Filer> config diff 11_30_2000 12_04_2000   Compares the configuration information available in the backup   files /etc/configs/11_30_2000 and /etc/configs/12_04_2000.    4. Assume that test1.cfg and test2.cfg are two sample config files   with the contents shown below:         sample test1.cfg file:           options.auditlog.enable=on           options.autosupport.enable=off           file.contents.hosts.equiv=\\           #Auto-generated by setup Sun May 27 23:46:58 GMT 2001           testfiler1           \\         sample test2.cfg file:           options.autosupport.enable=on           options.sysconfig.boot_check=on           options.sysconfig.boot_errors=console, syslog, autosupport           file.contents.hosts.equiv=\\           #Auto-generated by setup Sun May 27 20:12:12 GMT 2001           testfiler2           \\     Following command displays the differences between the above   two config files.    Filer> config diff test1.cfg  test2.cfg   ## deleted   < options.auditlog.enable=on   ## changed   < options.autosupport.enable=off   ---   > options.autosupport.enable=on   ## new   > options.sysconfig.boot_check=on   ## new   > options.sysconfig.boot_errors=console, syslog, autosupport   ## changed   < file.contents.hosts.equiv=\\   #Auto-generated by setup Sun May 27 23:46:58 GMT 2001   testfiler1   \\   ---   > file.contents.hosts.equiv=\\   #Auto-generated by setup Sun May 27 20:12:12 GMT 2001   testfiler2   \\    5. Filer> config dump 11_30_2000   Backs up the filer specific configuration in /etc/configs/11_30_2000.    6. Filer> config dump /home/user/12_04_2000   Backs up the filer specific configuration in /home/user/12_04_2000.    7. Filer> config dump -v 12_12_2000   Backs up the entire filer (filer specific and volume specifc)   configuration in /etc/configs/12_12_2000.    8. Filer> config restore 11_30_2000   Restores the filer specific configuration from /etc/configs/11_30_2000.    9. Filer> config restore /home/user/12_04_2000   Restores the filer specific configuration from /home/user/12_04_2000.    10. Filer> config restore -v /home/user/12_04_2000   Restores the entire filer (filer specifc and volume specific)   configuration from /home/user/12_04_2000.    11. Filer> config restore http://root:hello@www.foo.com/backup_12_04_2000   Restores the filer specific configuration from a remote file,    backup_12_04_2000,  available on the http server www.foo.com. 


Table of Contents

Copyright © 1994-2008 NetApp, Inc. Legal Information

VN:F [1.9.11_1134]
Rate this post:
Rating: 0.0/10 (0 votes cast)

Manual Pages , , , ,

  1. Nico
    May 12th, 2011 at 13:01 | #1

    Hi,
    Im wandering if the config restore command could work after having changing the HDDs. We plan to change all hard drive on an IBM N3300 and exept the size of the Agregates, everything else will be the same.
    Regards,
    Nico

  2. May 12th, 2011 at 13:29 | #2

    It should do, in theory, but you’ll need to do some of the basic setup before hand, and I don’t believe the config restore command over-writes things like the /etc/rc file which defines some of the configuration options.

    I’ve recommend taking a copy of the /etc folder and giving it a try! Worst case you can still recover the file level configuration (things like /etc/rc, /etc/hosts, /etc/resolv.conf and so on). But in theory the config dump command stores all this!

    Please let us know how you get on!

  3. Nico
    May 17th, 2011 at 09:40 | #3

    Thanks for your feedback.
    Your answer confirm what i was thinking.
    I hope all the share and access will be restorable without issue.
    I’ll come back to you after the process (planned for next month)

    Nico

  4. May 18th, 2011 at 17:24 | #4

    There’s a cool PowerShell for recording and setting share access also, pretty straight forward too. get-acl and set-acl. Really good tools for recording or transfering CIFS shares and access, and it works between Windows or NetApp!

  5. Nico
    July 20th, 2011 at 08:37 | #5

    Hi,
    Migration done, but not as planned at first.
    We changed all the disk one by one but as espected the Aggregate didn’t size up. So i change the aggr from raid_dp to raid 4 to have some spare, create a new aggregate, new volume, copy all data from aggrOld to aggrNew, destroy aggrOld and rename new volume/aggregate to match old ones.
    It was a bit quicker than a full backup/restore procedure and i only needed to recreate the CIFS share (using the config dump file) and set the LUN online and recreate the mappings.

  1. No trackbacks yet.



This site is not affiliated or sponsored in anyway by NetApp or any other company mentioned within.

Bad Behavior has blocked 1098 access attempts in the last 7 days.

© 2009-2012 Chris Kranz All Rights Reserved
This site is not affiliated or sponsored in anyway by NetApp or any other company mentioned within.