DataONTAP does not include an editor such as 'vi' in most standard UNIX like distributions. In DataONTAP, to edit any file from the console you need to use "wrfile" command, but this command can either overwrite or with -a option can append to a file. Hence, in order to edit/modify the file you need a workaround. However, if you have setup CIFS/NFS then you can easily edit any files using your favorite editor such as word.
Following example shows steps to edit the file from the DataONTAP console.
1. Open telnet/rsh Or ssh to the filer console (with putty for example)
2. Type
Filer>rdfile /etc/rc (For example)
Or whatever file you want to edit. It will print out the current contents of the file.
Note: To be on the safer side, make a copy of the file before editing the current one. (Use CIFS/NFS or ndmpcopy to to create a backup)
3. Copy the content of the rdfile output to a Notepad or other text editor.
To do that: Click the the telnet/putty's top left side corner. Menu will drop down: Edit > Mark and then Edit > copy & paste to the notepad.
4. Edit/change anything you want in the notepad.
5. When you're done, type
Filer>wrfile /etc/rc
6. press enter
7. Then QUICKLY copy/paste your modified text into the telnet/SSH console
8. Press CTRL-C to save the file and you're done.
Try "rdfile" again to ensure the changes were correctly saved.
Note: If you forget to do CTRL-C at the end you will remain in "wrfile" mode and everything you type will end up in the file you tried to edit. Therefore make sure you press CTRL-C at the end.
Warning:
Any time you make significant changes to your systems, you should be making a config dump file (and using the logger command to record the changes). Some customers schedule a weekly config dump and copy the files to an external system. In the event of an issue with the root volume or corruption of the system configuration, the controller can be restored back to its last known good state. Enterprise customers who order multiple storage controllers clone entire systems by copying and editing the dump file with a text editor. What a config restore will not do is create aggregates and volumes or tell you their size. Refer to a recent AutoSupport message for this information.
Config command:
filer> config dump -v 26Oct2012.cfg (you can use any filename you want, e.g., Initial_setup.config)
filer> config restore 26Oct2012.cfg
Logger command:
The logger command can insert text comments into the system log file /etc/messages
Example:
The logger command accepts either a text string or a stream of text to standard input terminated by a period (.)
filer> logger *** Making changes to /etc/rc file, backup is made – Username * * *
filer> logger *** Starting shelf firmware upgrade – Username * * *
filer> logger----- > System going down for UPS system maintenance < ----System is expected to halt ungracefully while we test battery duration- >
Basically whenever you make changes, do these:
1. config dump (Backup the system configuration before you start and when you finish)
2. Logger command (At a minimum, add comments to the system log when you start and finish the maintenance)
3. Save the console output to a file. (Forensic evidence of what you did, or did not do, and how the system responded)
4. Trigger AutoSupports (Send an ASUP message at the start and end of your maintenance)
.
Following example shows steps to edit the file from the DataONTAP console.
1. Open telnet/rsh Or ssh to the filer console (with putty for example)
2. Type
Filer>rdfile /etc/rc (For example)
Or whatever file you want to edit. It will print out the current contents of the file.
Note: To be on the safer side, make a copy of the file before editing the current one. (Use CIFS/NFS or ndmpcopy to to create a backup)
3. Copy the content of the rdfile output to a Notepad or other text editor.
To do that: Click the the telnet/putty's top left side corner. Menu will drop down: Edit > Mark and then Edit > copy & paste to the notepad.
4. Edit/change anything you want in the notepad.
5. When you're done, type
Filer>wrfile /etc/rc
6. press enter
7. Then QUICKLY copy/paste your modified text into the telnet/SSH console
8. Press CTRL-C to save the file and you're done.
Try "rdfile" again to ensure the changes were correctly saved.
Note: If you forget to do CTRL-C at the end you will remain in "wrfile" mode and everything you type will end up in the file you tried to edit. Therefore make sure you press CTRL-C at the end.
Warning:
Any time you make significant changes to your systems, you should be making a config dump file (and using the logger command to record the changes). Some customers schedule a weekly config dump and copy the files to an external system. In the event of an issue with the root volume or corruption of the system configuration, the controller can be restored back to its last known good state. Enterprise customers who order multiple storage controllers clone entire systems by copying and editing the dump file with a text editor. What a config restore will not do is create aggregates and volumes or tell you their size. Refer to a recent AutoSupport message for this information.
Config command:
filer> config dump -v 26Oct2012.cfg (you can use any filename you want, e.g., Initial_setup.config)
filer> config restore 26Oct2012.cfg
Logger command:
The logger command can insert text comments into the system log file /etc/messages
Example:
The logger command accepts either a text string or a stream of text to standard input terminated by a period (.)
filer> logger *** Making changes to /etc/rc file, backup is made – Username * * *
filer> logger *** Starting shelf firmware upgrade – Username * * *
filer> logger----- > System going down for UPS system maintenance < ----System is expected to halt ungracefully while we test battery duration- >
Basically whenever you make changes, do these:
1. config dump (Backup the system configuration before you start and when you finish)
2. Logger command (At a minimum, add comments to the system log when you start and finish the maintenance)
3. Save the console output to a file. (Forensic evidence of what you did, or did not do, and how the system responded)
4. Trigger AutoSupports (Send an ASUP message at the start and end of your maintenance)
.
