Feedback
Table Of Contents
Administering the MARS Appliance
Performing Command Line Administration Tasks
Log In to the Appliance via the Console
Reset the Appliance Administrator Password
Shut Down the Appliance via the Console
Log Off the Appliance via the Console
Reboot the Appliance via the Console
Determine the Status of Appliance Services via the Console
Stop Appliance Services via the Console
Start Appliance Services via the Console
View System Logs via the Console
Checklist for Upgrading the Appliance Software
Prepare the Internal Upgrade Server
Determine the Required Upgrade Path
Download the Upgrade Package from Cisco.com
Specify the Proxy Settings for the Global Controller or Local Controller
Upgrade Global Controller or Local Controller from its User Interface
Upgrading a Local Controller from the Global Controller
Specify the Proxy Settings in the Global Controller
Upgrade Local Controller from the Global Controller User Interface
Configuring and Performing Appliance Data Backups
Typical Uses of the Archived Data
Format of the Archive Share Files
Archive Intervals By Data Type
Configure the NFS Server on Windows
Install Windows Services for UNIX 3.5
Configure a Share using Windows Services for UNIX 3.5
Configure the NFS Server on Linux
Configure the NetApp NFS Server
Configure Lookup Information for the NFS Server
Configure the Data Archive Setting for the MARS Appliance
Access the Data Within an Archived File
Troubleshooting Data Archiving
Recovering a Lost Administrative Password
Downloading and Burning a Recovery DVD
Recovery the MARS Operating System
Re-Imaging a Global Controller
Restoring Archived Data after Re-Imaging a MARS Appliance
Configuring a Standby or Secondary MARS Appliance
Administering the MARS Appliance
Revised: November 7, 2008, OL-14672-01This chapter describes a core set of maintenance tasks for Cisco Security Monitoring, Analysis, and Response System (MARS). Because these tasks affect the overall health and accuracy of the MARS system, you should develop an operational strategy and process for performing them. This chapter contains the following sections:
•
Performing Command Line Administration Tasks
•
•
•
For all other MARS Appliance configuration and administration tasks, see either the User Guide for Cisco Security MARS Global Controller or the User Guide for Cisco Security MARS Local Controller, depending on which product you own.
Performing Command Line Administration Tasks
This section details basic administrative tasks that you perform using a console connection to the MARS Appliance. This section contains the following procedures:
•
•
•
•
•
•
•
•
•
Log In to the Appliance via the Console
After the MARS Appliance boots, the console service starts and prompts the user to log in. Successful login launches a command line application (shell) that operates the CLI.
To log in to the MARS Appliance via a console connection, follow these steps:
Step 1
Step 2
Step 3
Result: The system prompt appears in the following form:
Last login: Tue Jul 5 05:57:31 2005 from <host>.<domain>.comCisco Security MARS - Mitigation and Response System? for list of commands[pnadmin]$
Note
Tip
Reset the Appliance Administrator Password
There is always a single set of MARS Appliance administrator credentials consisting of the administrator name pnadmin and a corresponding password. Unlike other MARS administrative accounts, this unique administrative account is granted all privileges and cannot be deleted.
This procedure details how to reset the password after you log in with the existing credentials. If you do not have the existing MARS Appliance administrator login credentials with which to log in, the only method of recovery is to re-image the appliance, which resets the password to the factory defaults. For information on resetting the administrator login and password without first logging in, see Recovery Management.
To reset the MARS Appliance administrator login credentials, follow these steps:
Step 1
Step 2
Result: The MARS Appliance displays the following prompt:
New password:Step 3
Note
The MARS Appliance displays the following prompt:
Retype new passwordStep 4
Result: The MARS Appliance displays the command prompt, and the password is changed.
Shut Down the Appliance via the Console
You can shut down an appliance remotely via a console connection. However, to power up the appliance, you must have physical access to the device. For more information on powering up the appliance, see Powering on the Appliance and Verifying Hardware Operation, page 4-8.
Caution
To use the console to shut down the MARS Appliance, follow these steps:
Step 1
Step 2
Step 3
Result: The MARS Appliance powers off.
Log Off the Appliance via the Console
Logging off via the console closes the administrative session at the applause. Good security practices recommend logging off when you are not using the console.
To log off the MARS Appliance via the console, follow these steps:
Step 1
Step 2
Result: The console connection closes, and the login: prompt reappears.
Reboot the Appliance via the Console
From time to time, you may need to manually reboot the appliance. For example, if a service seems to be hung, rebooting may resolve the issue. Rebooting ensures that the services are shut down safely before the appliance restarts.
To reboot the MARS Appliance via the console, follow these steps:
Step 1
Step 2
Result: The MARS Appliance displays the following message:
Are you sure you want to reboot? (Y/N)Step 3
Result: The MARS Appliance reboots. When the reboot is finished, the login: prompt reappears.
Determine the Status of Appliance Services via the Console
You can use the console connection to obtain system and service status information.
To determine the status of the MARS Appliance's services, follow these steps:
Step 1
Step 2
The system displays the following status information:
Module State UptimeDbIncidentLoaderSrv RUNNING 01:12:18KeywordQuerySrv RUNNING 01:12:18csdam RUNNING 01:12:18csiosips RUNNING 01:12:18csips RUNNING 01:12:18cswin RUNNING 01:12:18device_monitor RUNNING 01:12:18discover RUNNING 01:12:18graphgen RUNNING 01:12:18pnarchiver RUNNING 01:12:18pndbpurger RUNNING 01:12:18pnesloader RUNNING 01:12:18pnmac RUNNING 01:12:18pnparser RUNNING 01:12:19process_event_srv RUNNING 01:12:19process_inlinerep_srv RUNNING 01:12:19process_postfire_srv RUNNING 01:12:19process_query_srv RUNNING 01:12:19superV RUNNING 01:12:20Possible states are:
•
•
Note
Stop Appliance Services via the Console
You can stop all MARS Appliance services from the console. To list the services and their status, you can use the pnstatus command. For more information, see Determine the Status of Appliance Services via the Console.
To stop all services on the MARS Appliance, follow these steps:
Step 1
Step 2
Step 3
Result: The system immediately shows the message:
Please Wait . . .Followed by the return of the prompt, indicating the command has completed.
Step 4
The superV service does not stop. This service monitors and restarts the other services as needed.
Start Appliance Services via the Console
If the services are stopped, you can manually start all MARS Appliance services from the console. To list the services and their status, you can use the pnstatus command. For more information, see Determine the Status of Appliance Services via the Console.
To start all stopped MARS services, follow these steps:
Step 1
Step 2
Step 3
Result: The system prompt disappears and then returns, indicating the services are restarted.
Step 4
View System Logs via the Console
This section details the procedure for running the pnlog show command. This command displays the log status and can be used by support personnel for analysis.
For more information on the pnlog command, see pnlog, of Appendix A, "Command Reference." The syntax for the pnlog show command is as follows:.
pnlog show <gui|backend|cpdebug>These options do a running output of a particular log file in the backend. There are three different logs that you can view: the web interface logs, the backend logs (shows logs for processes that the pnstatus command reports on), and CheckPoint debug logs. Use Ctrl+C or ^C to stop this command.
When using cpdebug, you should have pnlog setlevel set to more than 0, which is the default value and turns off the CPE Debug messages.
To generate a .cab file of log and system Registry information, follow these steps:
Step 1
Step 2
Step 3
Result: The console begins scrolling the output of the executed command.
Step 4
Result: The system returns to the system prompt.
Checklist for Upgrading the Appliance Software
MARS upgrade packages are the primary vehicle for major, minor, and patch software releases. As administrator of the MARS Appliance, you should check the upgrade site weekly for patch upgrades. In addition to addressing high-priority caveats, patch upgrade packages update system inspection rules, event types, and provide the most recent signature support.
Caution
The following checklist describes the steps required to upgrade your MARS Appliance to the most recent version. Each task might contain several steps; the tasks and steps within should be performed in order. The checklist contains references to the specific procedures used to perform each task.
1.
Two scenarios exist for bringing your MARS Appliance in line with the current software release: upgrade versus reimage. The method required to get to the current release can differ greatly between these two scenarios.
•
•
Result: You determine whether you will upgrade or reimage your MARS Appliance.
2.
Before you upgrade your appliance, you must determine what version you are running. You can determine this in one of two ways:
•
•
The format of the version appears as x.y.z (build_number), for example, 3.4.1 (1922).
Note
Result: You have identified the version running on your appliance and know whether you must contact Cisco support or continue with this checklist.
3.
Before upgrading your appliance, you must determine what medium to use. Your choice of medium determines whether you must upgrade from the CLI.
•
•
Note
Result: You have determined which medium to use for your upgrade. If you chose the Internal Upgrade Server option, you have identified and prepared your server, and you have verified that the server can be reached by each standalone Local Controller or Global Controller that you intend to upgrade. If a proxy server resides between the Internal Upgrade Server and the appliance, you must provide those settings before upgrading.
For more information, see:
4.
Upgrading from one version of the appliance software to the next must follow a cumulative upgrade path; you must apply each upgrade package in the order it was made available between the version running on the appliance and the version you want to run.
Also, a limitation exists between a Global Controller and any Local Controllers that it monitors. The Global Controller can only monitor Local Controllers that are running the same version it is. If you are attempting to monitor a Local Controller that is running an earlier software version, the Local Controller will appear offline to the Global Controller. However, MARS includes an upgrade option where the Global Controller pushes the same upgrade version to the Local Controllers that it is monitoring, allowing you to manage the upgrade process from within the Global Controller user interface.
You have identified the complete list of upgrade packages that you must download.
For more information, see:
5.
After you have identified the upgrade packages to download, log in to Cisco.com using your Cisco.com account and download the various packages. To download upgrade packages, you must have a valid SMARTnet support contract for the MARS Appliance.
Depending on your selection in Step 3., you will either store these files on the Internal Upgrade Server or burn a CD-ROM image.
Result: All upgrade packages that are required to upgrade from the version you are running to the most recent version are located in a known path on either the Internal Upgrade Server or a CD-ROM.
For more information, see:
6.
Select from the following upgrade options:
Note
•
•
•
•
Result: You have determined the appropriate upgrade approach to use based on your selected medium and currently running version.
7.
If your appliance runs on a network that is separated from the Internal Upgrade Server by a proxy server, you must identify the proxy server settings. If you are using the HTML interface to upgrade, you can specify these settings using the Admin > System Parameters > Proxy Settings page. Otherwise, make note of the settings so that you can provide them at the command line during upgrade.
Note
Result: You have either specified the proxy server settings in the web interface, or you have noted the settings for later use.
For more information, see:
•
8.
From the appliance, use the method you chose in Step 6. to upgrade incrementally, as determined in Step 5., to the desired version.
Result: You have applied each required upgrade package.
For more information, see:
•
Burn an Upgrade CD-ROM
Burning an upgrade CD-ROM does not have any special requirements. If you require more than one upgrade package, you can include three upgrade packages per CD, as packages are typically around 200 MB.
Note
Prepare the Internal Upgrade Server
The Internal Upgrade Server requirements vary based on the upgrade option you selected and the version running on your appliance.
Note
For CLI-based upgrades of version 2.5.1 or later, the Internal Upgrade Server must be configured to meet the following requirements:
•
•
•
•
For web interface-based upgrades of releases 3.4.1 or later, the Internal Upgrade Server must be configured to meet the following requirements:
•
•
•
•
Important Upgrade Notes
To ensure that the upgrade from earlier versions is trouble free, this section contains the notes provided in previous releases according the release number. Please refer to the notes that pertain to the release you are upgrading from and any releases following that one.
General Notes
The MARS Appliance performs a file system consistency check (fsck) on all disks when either of the following conditions is met:
•
•
The fsck operation takes a long time to complete, which can result in significant unplanned downtime when rebooting the system after meeting a condition above. For example, a MARS 50 appliance can take up to 90 minutes to perform the operation.
Upgrade to 5.3.6
No important notes exist for the 5.3.6 upgrade.
Upgrade to 5.3.5
No important notes exist for the 5.3.5 upgrade.
Upgrade to 5.3.4
No important notes exist for the 5.3.4 upgrade.
In addressing CSCsm57453: Incident not created for some of same events, the behavior now differs between 4.3.4 and 5.3.4. In the x.3.3 releases, incident firing was throttled at 100 incidents for event bursts from a vulnerability assessment (VA) reporting device. In 5.3.4, incidents firing throttles at over 430 incidents, and in 4.3.4, the incidents firing throttles at just over 220 incidents.
Upgrade to 5.3.3
No important notes exist for the 5.3.3 upgrade.
Upgrade to 5.3.2
The upgrade is from 5.3.1 to 5.3.2. The following important notes exist for this upgrade:
•
If you've edited a system rule on a Global Controller, you may enounter one of two conditions where the rules on the Global Controller are out of sync with those on the Local Controller.
Symptom: The edited rule in the Global Controller disappears from the list of rules on the Local Controller. (CSCsk12130)
Condition: The user edited a rule on the Global Controller and then upgraded to a different version of the MARS system software and then added of a new Local Controller to the Global Controller.
Symptom: A rule that was edited in the Global Controller looks as if it is an empty rule in the Local Controller and be inactive. (CSCsk19730)
Condition: This occurs under in some cases where a Local Controller is added to a newly upgraded Global Controller.
Work Arounds: If the Local Controller is deleted from and re-added to the Global Controller under x.3.2, the issue should resolve itself. However, in conditions with a large topology or many custom rules, we recommend contacting technical support for a work around that avoids the need to delete and re-add the Local Controller.
Another possible work around if the number of edited rules are small is to edit and make further changes to the rule and activate. In this case, the issue should be resolved for that rule.
•
For example, an IOS 12.4 device is added to MARS 5.3.1 as 12.2 and after the upgrade to 5.3.2, when the discovery occurs for that device, the device type is automatically updated to IOS 12.4. The same is true for devices that are running IOS 12.3. However, if you have not enabled device discovery, use the Change Version feature to change between IOS 12.2, 12.3, and 12.4.
•
•
•
Upgrade to 5.3.1
Beginning with the 4.3.1 and 5.3.1 releases, the dynamic IPS signature updates (if enabled) is an aspect of the version of software running on a MARS Appliance. Therefore, in addition to running the same MARS software versions on the Global Controller and Local Controller, the IPS signature version must match or the communications fail.
In a Global Controller-Local Controller deployment, configure the dynamic signature URL and all relevant settings on the Global Controller. When the Global Controller pulls the new signatures from CCO, all managed Local Controllers download the new signatures from the Global Controller.
Upgrade to 5.2.8
The upgrade is from 5.2.7 to 5.2.8. No important notes exist for this release.
Upgrade to 5.2.7
The upgrade is from 5.2.4 to 5.2.7; no 5.2.5 or 5.2.6 releases exist.
Determine the Required Upgrade Path
When upgrading from one software version to another, a prerequisite version is always required. This prerequisite version is the minimum level required to be running on the appliance before you can upgrade to the most recent version.
Download the Upgrade Package from Cisco.com
Upgrade images and supporting software are found on the CCO software download pages dedicated to MARS. You can access these pages at the following URLs, assuming you have a valid CCO account and that you have registered your SMARTnet contract number for your MARS Appliance.
Top-level page:
And then click the Download Software link in the Support box on the right side of the MARS product home page.
Result; The Download Software page loads.
From this top-level page, you can select one of the following options:
•
•
•
•
•
Note
For information on obtaining a CCO account, see the following URL:
•
Specify the Proxy Settings for the Global Controller or Local Controller
If you know that your appliance cannot directly access the Internal Upgrade Server, you can specify the proxy settings. This procedure describes how to specify the proxy settings with the assumption that you will upgrade the appliance from the user interface associated with that appliance. For information on upgrading a Local Controller from within the Global Controller user interface, see Upgrading a Local Controller from the Global Controller.
To specify proxy settings, follow these steps:
Step 1
Step 2
Step 3
Step 4
Note
Step 5
Step 6
Upgrade Global Controller or Local Controller from its User Interface
Note
To upgrade the appliance from the user interface, follow these steps:
Step 1
Step 2
Step 3
Step 4
Note
Step 5
Step 6
You can download the install package using either HTTPS or FTP.
Step 7
Step 8
Result: Depending on the size of the package, this download can take some time. After the download is complete, the Install button becomes active.
Step 9
Result: After you click Install, the system needs some time to process the upgrade. After the upgrade is complete, the system reboots. During the upgrade, the user interface is also restarted.
Upgrade from the CLI
You can connect to the Internal Upgrade Server and complete the upgrade using HTTP or HTTPS, or you can download the upgrade package onto an FTP server and perform the upgrade. For more information on the upgrade command, see pnupgrade, page A-50.
To upgrade using the CLI, follow these steps:
Step 1
Step 2
Step 3
version
The appliance must be running the supported prerequisite version. If it is not, you must follow the upgrade path to reach that version.
Step 4
Note
•
pnupgrade cdrom://package/pn-ver.pkgWhere package is the path on the CD where you have stored the *.pkg file and where [ver] is the version number of the package file to which you want to upgrade, such as 3.3.4.
•
pnupgrade https://upgrade.myhttpserver.com/upgrade/packages/ pn-ver.pkg [user] [password]— or —
pnupgrade http://upgrade.myhttpserver.com/upgrade/packages/ pn-ver.pkg [user] [password]Where upgrade.myttpserver.com/upgrade/packages is the server name and path where you have downloaded the other *.pkg file, and where ver is the version number, such as 3.3.4, and [user] and [password] are your Internal Upgrade Server login name and password.
•
pnupgrade ftp://upgrade.myftpserver.com/upgrade/packages/ pn-ver.pkg [user] [password]Where upgrade.myftpserver.com/upgrade/packages is the server name and path where you have downloaded the other *.pkg file, and where [ver] is the version number, such as 3.3.4, [user] and [password] are your Internal Upgrade Server login name and password.
•
pnupgrade proxyServerIP:proxyServerPort [proxyUser:proxyPassword] https://upgrade.myhttpserver.com/upgrade/packages/pn-ver.pkg [user] [password]Where the variables are defined as follows:
•
•
•
•
•
Result: A progress bar indicates the download percentage. After download is complete, the system takes some time to process the upgrade. After the upgrade is complete, the system reboots.
Upgrading a Local Controller from the Global Controller
When upgrading a Local Controller from within the Global Controller user interface, you need to determine whether the Local Controller resides behind a proxy server. If so, you must configure the proxy settings for the Local Controller within the Global Controller user interface. After you have specified the settings, you can upgrade the Local Controller as you normally would.
Note
When you upgrade a Global Controller and its monitored Local Controllers, you first upgrade Global Controller, which requires that you identify the Internal Upgrade Server information. The Global Controller then pushes this server information to all its selected Local Controllers, which allows the Local Controller to locate the Internal Upgrade Server and start the download and upgrade process. The Local Controller does not retrieve the upgrade package from the Global Controller.
Before You Begin
•
•
Note
If you notice that the Local Controller appears offline, verify that at least 10 minutes have passed since the appliances rebooted. Alternatively, you can jump start the communication by navigating to Admin > Local Controller Management in the Global Controller user interface.
Specify the Proxy Settings in the Global Controller
To specify the proxy settings for a Local Controller in the Global Controller user interface, follow these steps:
Step 1
Step 2
Step 3
Result: The Global Controller user interface loads the Proxy Information page (Admin > System Parameters > Proxy Settings) on the selected Local Controller.
Step 4
Step 5
Note
Step 6
Step 7
Upgrade Local Controller from the Global Controller User Interface
You can upgrade any Local Controllers that are managed by a Global Controller from within the Global Controller user interface. This enables you to work your way through the list of Local Controllers without connecting to each appliance individually.
Step 1
Step 2
Result: The list of Local Controllers that can be selected to upgrade appears.
Step 3
Note
Step 4
If you have specified proxy settings for the selected appliance, a popup window prompts you to verify the settings. After you verify the information, click OK. If you have forgotten to enter proxy information, click Cancel and then enter the proxy information for that Local Controller as described in Specify the Proxy Settings in the Global Controller.
Result: Depending on the size of the package, this download can take some time. After the download is complete, the Install button becomes active.
Step 5
Result: After you click Install, the remote system needs some time to process the upgrade. After the upgrade is complete, the remote system reboots. During the upgrade, the user interface is also restarted.
Configuring and Performing Appliance Data Backups
You can archive data from a MARS Appliance and use that data to restore the operating system (OS), system configuration settings, dynamic data (event data), or the complete system. The appliance archives and restores data to and from an external network-attached storage (NAS) system using the network file system (NFS) protocol. While you cannot schedule when the data backup occurs, the MARS Appliance performs a configuration backup every morning at 2:00 a.m. and events are archived every hour. The configuration backup can take several hours to complete.
When archiving is enabled, dynamic data is written twice: once to the local database and once to the NFS archive. As such, the dynamic data that is archived includes only the data that is received or generated after you enable the data archive setting. Therefore, we recommend that you enable archiving before configuring your appliance to receive audit events from reporting devices.
You can use the same NFS server to archive the data for more than one MARS Appliance; however, you must specify a unique directory in the NFS path for each appliance that you want archive. If you use the same base directory, the appliances overwrite each others' data, effectively corrupting the images.
Note
Each MARS Appliance seamlessly archives data using an expiration date that you specify. When the MARS internal storage reaches capacity, it automatically purges the data in the oldest partition of the local database, roughly 10% of the stored event and session data. The data in the NFS file share has a life span specified in days. Therefore, to keep a year's worth of data, you would specify 365 days as the value for the Remote Storage Capacity (in Days) field. All data older than 365 days is purged from the archive file.
When planning for space requirements, use the following guidance: Estimate 6 GB of storage space for one year's worth of data, received at a sustained 10 events/second. This estimate assumes an average of 200 Bytes/event and a compression factor of 10, both realistic mean values. In addition to capacity planning, plan the placement of your NFS server to ensure a reliable network connection that can transmit 10 MB/second exists between the NFS server and the MARS Appliance. You should consider using the eth1 interface to avoid high-traffic networks that might introduce latency and to ensure that the backup operation is not competing with other operations in the MARS Appliance. Also, define a default route to the NFS server on the MARS Appliance and that you verify any intermediate routers and firewalls allow for multi-hour NFS connections to prevent session timeouts during the backup operation.
Note
For more information on the uses and format of the archived data, see the following topics:
•
•
•
To configure data archiving, you must perform the following procedures:
1.
–
–
–
2.
3.
Typical Uses of the Archived Data
While the primary use of an archive is to restore the appliance in response to a catastrophic software failure, the archived data provides the following alternate uses:
•
•
•
Format of the Archive Share Files
The MARS archive process runs daily at 2:00 a.m., and it creates a dated directory for its data. You cannot specify a different time to archive the data.
The pnos directory is where the operating system backup is stored.
06/12/2005 11:32p <DIR> .06/12/2005 11:32p <DIR> ..07/09/2005 01:30a <DIR> pnos <-- OS Backup Directory07/08/2005 04:49p <DIR> 2005-07-08 <-- Daily Data Backup Directory07/10/2005 12:09a <DIR> 2005-07-1007/11/2005 12:12a <DIR> 2005-07-1107/12/2005 12:12a <DIR> 2005-07-1207/13/2005 12:16a <DIR> 2005-07-1307/14/2005 02:02a <DIR> 2005-07-1407/15/2005 02:02a <DIR> 2005-07-1507/16/2005 02:02a <DIR> 2005-07-1607/17/2005 02:02a <DIR> 2005-07-1707/18/2005 02:02a <DIR> 2005-07-1807/19/2005 02:02a <DIR> 2005-07-1907/19/2005 09:46p <DIR> 2005-05-2607/20/2005 07:16a <DIR> 2005-05-2707/20/2005 07:17a <DIR> 2005-07-2007/22/2005 12:13a <DIR> 2005-07-2207/21/2005 12:09a <DIR> 2005-07-2107/23/2005 12:15a <DIR> 2005-07-230 File(s) 0 bytes58 Dir(s) 4,664,180,736 bytes freeWithin each daily directory, subdirectories are created for each data type. The following example identifies the directory type in the comments.
Directory of D:\MARSBackups\2005-07-0807/08/2005 04:49p <DIR> .07/08/2005 04:49p <DIR> ..07/08/2005 04:49p <DIR> CF <-- Configuration Data07/08/2005 05:00p <DIR> IN <-- Incident Data07/08/2005 05:16p <DIR> AL <-- Audit Logs07/08/2005 05:16p <DIR> ST <-- Statistics Data07/08/2005 05:16p <DIR> RR <-- Report Results07/08/2005 05:49p <DIR> ES <-- Raw Event Data0 File(s) 0 bytes8 Dir(s) 4,664,180,736 bytes freeThe .gz filename in the raw event data directory identifies the period of time that the archived data spans in a YYYY-MM-DD-HH-MM-SS format. The filename includes the following data [dbversion]-[productversion]-[serialno]_[StartTime]_[EndTime].gz. The following examples illustrate this format:
ix-5248-524-1171238692_2007-02-12-00-04-46_2007-02-12-01-04-51.gzrm-5248-524-1171238692_2007-02-12-00-04-46_2007-02-12-01-04-51.gz
Note
Directory of D:\MARSBackups\2005-07-08\ES07/08/2005 05:49p <DIR> .07/08/2005 05:49p <DIR> ..07/08/2005 05:49p 34,861 es-3412-342_2005-07-08-16-49-52_2005-07-08-17-49-47.gz07/08/2005 05:49p 31,828 rm-3412-342_2005-07-08-16-49-52_2005-07-08-17-49-47.gz07/08/2005 06:49p 49,757 es-3412-342_2005-07-08-17-49-49_2005-07-08-18-49-40.gz07/08/2005 06:49p 48,154 rm-3412-342_2005-07-08-17-49-49_2005-07-08-18-49-40.gz07/08/2005 07:49p 24,420 es-3412-342_2005-07-08-18-49-45_2005-07-08-19-49-52.gz07/08/2005 07:49p 22,346 rm-3412-342_2005-07-08-18-49-45_2005-07-08-19-49-52.gz07/08/2005 08:50p 44,839 es-3412-342_2005-07-08-19-49-47_2005-07-08-20-50-04.gz07/08/2005 08:50p 41,534 rm-3412-342_2005-07-08-19-49-47_2005-07-08-20-50-04.gz07/08/2005 09:50p 58,988 es-3412-342_2005-07-08-20-49-55_2005-07-08-21-50-06.gz07/08/2005 09:50p 54,463 rm-3412-342_2005-07-08-20-49-55_2005-07-08-21-50-06.gz07/08/2005 10:50p 130,604 es-3412-342_2005-07-08-21-49-58_2005-07-08-22-50-08.gz07/08/2005 10:50p 85,437 rm-3412-342_2005-07-08-21-49-58_2005-07-08-22-50-08.gz07/08/2005 11:50p 114,445 es-3412-342_2005-07-08-22-49-55_2005-07-08-23-50-10.gz07/08/2005 11:50p 58,240 rm-3412-342_2005-07-08-22-49-55_2005-07-08-23-50-10.gz07/09/2005 12:50a 110,556 es-3412-342_2005-07-08-23-50-02_2005-07-09-00-50-14.gz07/09/2005 12:50a 53,977 rm-3412-342_2005-07-08-23-50-02_2005-07-09-00-50-14.gz16 File(s) 964,449 bytes2 Dir(s) 4,664,164,352 bytes freeThe following is an example of the data found in the configuration data directory.
Directory of D:\MARSBackups\2005-07-08\CF07/08/2005 04:49p <DIR> .07/08/2005 04:49p <DIR> ..07/08/2005 02:02a 2,575,471 cf_2005-07-08-02-02-02.pna1 File(s) 2,575,471 bytes2 Dir(s) 4,664,164,352 bytes freeArchive Intervals By Data Type
MARS archives data either daily or in near real time based on the type of data. Therefore, all the data in the MARS internal storage (local database) should be in the NFS storage as well, give or take a day's worth of specific types of data.
MARS data consists of four types:
1.
2.
3.
4.
Configuration data, audit trails, and statical data is written to database first. During archival time, data is written to local files and archived from those files. However, dynamic and event data is written in parallel to both the database and to local files. Therefore, even if the data has been archived, it is likely to still be in the database.
In other words, dynamic and event data is initially stored in two locations: the NFS archive and MARS database. Later, when the MARS database partition becomes full, the database purge operation occurs to make room for new events—but those events and incidents were archived prior to the purge operation.
Note
To account for temporarily unavailable NFS servers, the files for all data types are stored locally on the MARS Appliance for one day before they are purged. When you enable archiving in the web interface, you must also define the parameters for retaining the data in the NFS archive. As a result, MARS performs simple data maintenance on the NFS server by purging data outside the range specified in the Remote storage capacity in Days field of the Data Archiving page. For example, the storage capacity value is 365 days, then all data older than one year is purged from the NFS server.
Refer to Table 6-2 for the archive interval for each type of data.
Table 6-2 Archive Interval Description(4.3.1 and 5.2.4 and later)
AL: Audit log information
Once per day at 2:00 a.m.
n/a
Daily at
2 a.m.CF: Configuration information
Once per day at 2:00 a.m.
n/a
Daily at
2 a.m.ES: Events, sessions, and raw messages
Every 10 minutes or when 3 MB (compressed) file size is reached, whichever threshold is met first.
10 minutes
n/a
IN: Incidents
Immediately
1 minute1
n/a
RR: Report results
Once per day at 2:00 a.m.
n/a
ST: Statistical data/counters information
Hourly.
n/a
1 If event rate is higher, archive interval for real time can be shorter than Max Interval.
Configure the NFS Server on Windows
Windows Services for UNIX (WSU) allows an NFS mount to be created on a Windows file server. This option is convenient and is often useful in a lab environments or when UNIX expertise is unavailable. The following URLs support the configuration of this complimentary download from Microsoft Corporation:
Windows Services for UNIX 3.5 Download and Resources (System Requirements, Reviewer's Guide, etc.)
Performance Tuning Guidelines for Microsoft Services for Network File System
http://technet.microsoft.com/en-us/library/bb463205.aspx
To install and configure the WSU 3.5 to operate with a MARS Appliance, perform the following tasks:
•
•
Install Windows Services for UNIX 3.5
To configure the NFS server on a Windows server, follow these steps:
Step 1
Note
Step 2
Step 3
Step 4
We recommend defining a new folder, not using the temp folder under the local profile. The unzip process can take several minutes.
Step 5
Step 6
The Customer Information panel appears.
Step 7
The License and Support Information panel appears.
Step 8
Step 9
Step 10
•
•
Note
The Security Settings panel appears.
Step 11
As the MARS Appliance does not use a special account for NFS authentication, you do not need to change the default settings.
Step 12
Step 13
A second User Name Mapping panel appears.
Step 14
•
•
•
The Installation Location panel appears.
Step 15
The Installing panel appears, presenting the progress of the installation. When the installation completes, the Completing the Microsoft Windows Services for UNIX Setup Wizard panel appears.
Step 16
Step 17
You have successfully installed the required NFS components. Now you must define and configure a share to be used by the MARS Appliance for backups and archiving. For more information, see Configure a Share using Windows Services for UNIX 3.5.
Configure a Share using Windows Services for UNIX 3.5
Configuring the share involves identifying the folder to share and specifying the correct permissions and access.
To configure WSU 3.5 as an NFS server for a MARS Appliance, follow these steps:
Step 1
Step 2
An example folder is C:\MARSBackups.
Step 3
Step 4
An example share name can be the same as the folder name, MARSBackups.
Step 5
As the Windows server cannot directly authenticate the MARS Appliance, you must select this option.
Step 6
The NFS Share Permissions dialog box appears.
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Note
Step 13
cd <PathToParentOfShareFolder>
cacls <ShareFolderName> /E /G everyone:F
These commands modify the shared folder the permissions so that Everyone has local filesystem access to the folder. Example usage:
cd C:\archivecacls MARSBackups /E /G everyone:FStep 14
Step 15
This option equates the Anonymous user to the Everyone user.
Step 16
You have completed the NFS configuration settings for the Windows server. To enable logging for debug purposes, continue with Enable Logging of NFS Events. Otherwise, continue with Configure the Data Archive Setting for the MARS Appliance.
Enable Logging of NFS Events
For troubleshooting purposes, you can enable NFS Server logging on a Windows host that is running the Microsoft Windows Services for UNIX 3.5.
To enable NFS server logging on the Windows host, follow these steps:
Step 1
Step 2
Step 3
By default the log file appears in C:\SFU\log directory.
Step 4
Step 5
Step 6
Configure the NFS Server on Linux
NFS is supported natively on Linux file systems, which requires that you have a Linux box. Because a Linux file server can be built inexpensively, it is highly recommended that a file server be built and dedicated for MARS archived data.
This section presents an example configuration as guidance for configuring your NFS to archive the data for a MARS Appliance. For each MARS Appliance that you want to archive for a given NFS server, you must set up a directory on the NFS server to which the appliance can read and write. The following procedure identifies the steps required to accomplish this task.
To prepare a Linux NFS Server for archiving from a MARS Appliance, follow these steps:
Step 1
Step 2
For example:
mkdir -p /archive/nameOfYourMARSBoxHerechown -R nobody.nobody /archivechmod -R 775 /archive
Note
Step 3
/archive/nameOfYourMARSBoxHere MARS_IP_Address(rw)Step 4
/etc/init.d/nfs restart
Configure the NetApp NFS Server
The NetApp NFS server differs from other Linux/UNIX NFS servers in that NetApp restricts the functionaliy of the shell environment running on the server. As such, you must use an external UNIX/Linux admininstrative host to change the permissions and ownership of the exported NFS directory.
Before You Begin
•
To prepare the NetApp NFS server so that the MARS Appliance can archive to it, follow these step:
Step 1
a.
a.
b.
c.
–
–
–
The NFS Export Wizard - Path page appears.
Note
d.
The NFS Export Wizard - Read-Write Access page appears.
e.
f.
The NFS Export Wizard - Root Access page appears.
g.
The NFS Export Wizard - Security page appears.
h.
The NFS Export Wizard - Commit page appears.
i.
Step 2
mount NetAppIP:/PathToExport /mnt/YourMountPoint
chown nobody.nobody /mnt/YourMountPoint
chmod 775 /mnt/YourMountPoint
Note
Step 3
ls -l /mnt
Step 4
umount /mnt/YourMountPoint
Step 5
Configure Lookup Information for the NFS Server
Note
Many services in the current Linux system, such as ssh and the NFS server, use nslookup to obtain the hostname of the client. If the nslookup operation fails, the connection may fail or take a long time to finish the negotiation.
For the pnarchive and pnrestore operations to succeed, the NFS server must obtain the hostname of the MARS Appliance using its IP address. You can ensure that it obtains this information by doing one of the following:
•
•
During a typical restore process, the MARS Appliance is first re-imaged from the DVD, upgraded to the correct version of software, and then the restore operation is performed. During the DVD re-image process, the name of the appliance is changed to the factory default, which is pnmars. If you do not wish to change the name of the appliance before you attempt to restore it from the NFS server, you must ensure add an entry for pnmars to the DNS server or in the /etc/hosts file on the NFS server so that during the restore operation, the NFS server can perform an IP address-to-hostname lookup for the MARS Appliance.
After the restore operation completes, the MARS Appliance will be restored to the name saved in the archived OS package. You should have included this name already in the DNS server or /etc/host file of the NFS server. Otherwise, this archive/restore operations may not function properly.
Configure the Data Archive Setting for the MARS Appliance
You can archive the data and the system software that is running on a MARS Appliance to a remote server. This data archival includes operating system (OS) and upgrade/patch data, system configuration settings, and dynamic data, such as system logs, incidents, generated reports, and the audit events received by the appliance. The feature provides a snapshot image of the appliance.
Note
Using archived data, you can restore your appliance in the event of a failure, as long as the data is not corrupted. In this capacity, data archiving provides an alternative to re-imaging your appliance with the Recovery DVD.
Before You Begin
You must set up the NFS server correctly to archive the appliance's data. See Configure the NFS Server on Windows or Configure the NFS Server on Linux.
You must configure the basic network settings for the appliance.
To configure the data archive settings for a given MARS Appliance, follow these steps:
Step 1
Step 2
Step 3
For example, /MARSBackups would be a valid value for a Windows host with an NFS share named MARSBackups. The forward slash is required to resolve the UNC share name.
Step 4
No other options are available.
Step 5
•
•
Step 6
Note
Result: A status page appears. Click Back to return to the Data Archiving page.
Step 7
Tip
Access the Data Within an Archived File
You can access the event data in an archived file allows to review the events contained therein. You may want to perform this task to look at a particular time range of events or to perform post processing on the data.
Tip
To access the data within an archived file, follow these steps:
Step 1
cd <achive_path>
where archive_path is the remote path value specified in Configure the Data Archive Setting for the MARS Appliance.
Step 2
cd <YYYY-MM-DD>
where YYYY-MM-DD is the date that the archive file was created.
Step 3
cd ES ls -l
Step 4
gunzip <filename>
where filename is the name of the file to extract. The list of available files are based on a timestamp for when they were created.
Step 5
vi <filename>
You can use any text editor or run scripts against the data in these files. However, you should not change the contents of these zipped files or leave extracted data or additional files in the archive folders. MARS cannot process new or extracted files when performing a restore operation.
Troubleshooting Data Archiving
Table 6-3 identifies possible errors and likely causes and solutions.
Recovery Management
MARS Appliance functionality includes two procedures that you can perform using the MARS Appliance Recovery DVD-ROM. The approach you should take to recover your appliance depends upon whether or not you have archived data that you want to recover as well. Two decisions affect how you will recover your MARS Appliance:
•
•
Caution
The procedures, detailed in this section, are as follows:
•
•
•
•
•
•
Recovering a Lost Administrative Password
If you lose the password associated with the pnadmin account, you cannot recover the password. You must re-image the appliance, which resets the password to the factory defaults, as described in Re-Imaging a Local Controller, and Re-Imaging a Global Controller. If you have configured the MARS Appliance to archive data, as described in Configuring and Performing Appliance Data Backups, you can also recover the configuration and event data using the procedure in Restoring Archived Data after Re-Imaging a MARS Appliance.
Downloading and Burning a Recovery DVD
If you do not have the MARS Appliance Recovery DVD-ROM that shipped with your MARS Appliance or you want to use a new image to expedite the post recovery upgrade process, you can download the current recovery image from the Cisco.com software download pages dedicated to MARS. You can access these pages at the following URLs, assuming you have a valid Cisco.com account and that you have registered your SMARTnet contract number for your MARS Appliance.
Top-level download page:
And then click the Download Software link in the Support box on the right side of the MARS product home page.
Result: The Download Software page loads.
From this top-level page, you can select CS-MARS Recovery Software.
After you download the ISO image, for example, csmars-4.1.1.iso, you must burn that file on to a DVD-ROM. The files are typically 1.42 GB or larger.
The following guidelines are defined:
•
•
•
Recovery the MARS Operating System
For MARS 110, 210, GC2, and their variant models, the MARS operating system (OS) is stored separate from the MARS application and event data. It is stored on a flash disk-on-module (DOM) drive in the appliance. With the OS and application separation, if the MARS application hangs due to a RAID failure, you can login from a remote host and still retrieve log and trace data to assist in identifying the root cause of the failure.
The flash drive corrupts when, for example, system libraries or executable files are missing or are the wrong sizes as reported during a consistency checks or when the previous configuration is lost. When a corruption occurs, you will see symptoms like a failure to boot or to deploy the previous configuration, not able to execute certain commands, failures during the file system consistency check, or errors reporting missing files.
If the flash becomes corrupted, you can restore the OS using a Recovery DVD. For information on creating a Recovery DVD, see Downloading and Burning a Recovery DVD. The recovery operation restores the MARS OS without prompting for installation option information, such as the model or role (Global Controller vs. Local Controller). The flash drive is also stores the system configuration data (IP addresses, DNS configuration settings, host name, and license file). During an OS recovery, the daily backup of the configuration data is copied from the hard drive to the flash drive so you configuration can be reapplied, eliminating any appliance configuration or licensing.
Before You Begin
•
•
•
To recovery the operating system for your MARS Appliance, follow these steps:
Step 1
Step 2
Step 3
Step 4
•
•
Result: The following message displays on the console:
Please Choose A MARS Model To Install...1. Distributed Mars - Local Controller2. Distributed Mars - Global Controller3. Mars Operating System Recovery4. QuitStep 5
Result: The OS binary download to the appliance begins. This process takes approximately 15 minutes. After the image download is complete, the Recovery DVD is ejected and the following message appears on the console:
Please remove the installation CD and press Reboot to finish the installation.Step 6
Step 7
Result: The MARS Appliance reboots and synchronizes the configuration information between the flash drive and the hard drive.
Step 8
Because the OS recovery does not affect configuration data or event data, the system should be accessible with no further configuration requirements.
Re-Imaging a Local Controller
Use the MARS Appliance Recovery DVD-ROM to re-image the Local Controller if necessary. This operation destroys all data and installs a new image. In addition to preparing the device and later restoring any archived date, you must also perform three time-consuming appliance recovery phases:
•
•
•
Caution
Before You Begin
You must provide the license file during the initial configuration following the re-image operation.
To re-image your Local Controller, follow these steps:
Step 1
Step 2
Step 3
Step 4
•
•
Result: The following message displays on the console:
Please Choose A MARS Model To Install...1. Distributed Mars - Local Controller2. Distributed Mars - Global Controller3. Mars Operating System Recovery4. QuitStep 5
a.
Please Choose Which MARS 110 Model To Install...1. MARS1102. MARS110R3. Quitb.
Result: The image download to the appliance begins. This process takes approximately 15 minutes. After the image download is complete, the Recovery DVD is ejected and the following message appears on the console:
Please remove the installation CD and press Reboot to finish the installation.Step 6
Step 7
Result: The MARS Appliance reboots, performs some configurations, including building the Oracle database. The configurations that occur after the first reboot take a significant amount of time (between an hour and an hour and a half), during which there is no feedback; this is normal system behavior.
Step 8
Note
Step 9
•
•
Re-Imaging a Global Controller
Use the MARS Appliance Recovery DVD ROM to re-image the Global Controller if necessary. This operation destroys all data and installs a new image. In addition to preparing the device and later restoring any archived date, you must also perform four time-consuming appliance recovery phases:
•
•
•
•
To re-image your Global Controller, follow these steps:
Caution
Before You Begin
•
•
pnreset -gThis command clears the global inspection rules and user accounts from the Local Controller, which prepares it to be managed by the re-imaged Global Controller. However, it does not remove the global user groups; instead they are renamed (appended with a date) and converted to local user groups. You can edit or delete these empty groups after the reset. Because user groups are often used as recipients for rule notifications, they are not deleted to avoid invalidating the Action definition of such rules.
Step 1
Step 2
Step 3
Step 4
•
•
Result: The following message displays on the console:
Please Choose A MARS Model To Install...1. Distributed Mars - Local Controller3. Mars Operating System Recovery4. QuitStep 5
Result: The image download to the appliance begins. After the image download is complete, the Recovery DVD is ejected and the following message appears on the console:
Please remove the installation DVD and press Reboot to finish the installation.Step 6
Step 7
Result: The MARS Appliance reboots, performs some configurations, including building the Oracle database. The configurations that occur after the first reboot take a significant amount of time, during which there is no feedback; this is normal system behavior.
Step 8
Note
Step 9
Note
•
•
Restoring Archived Data after Re-Imaging a MARS Appliance
When you restore a MARS Appliance using archived data, you are restoring the system to match the data and configuration settings found in the archive. The configuration data includes the operating system, MARS software, license key, user accounts, passwords, and device list in effect at the time the archive was performed.
Caution
For additional information on how the archives are restored, see Guidelines for Restoring.
Note
If you have archived your data and you have recovered your MARS Appliance as described in either Re-Imaging a Local Controller, or Re-Imaging a Global Controller, perform the following steps:
Step 1
pnrestore -p <NFSServerIP>:/<archive_path>Where NFSServerIP is the value specified in the Remote Host IP field and archive_path is the value specified in the Remote Path field in the settings found in the web interface at Admin > System Maintenance > Data Archiving. You must identify the NFS server by IP address, separated by a :/ and then the pathname NFSServerIP:/archive_path. For more information on these settings, see Configure the Data Archive Setting for the MARS Appliance.
Step 2
Upsizing a MARS Appliance
You can migrate, or upsize, to a different appliance model by following the same process and restrictions as configuring a standby or secondary appliance. The technique involves restoring a backup from the original, source appliance on the replacement appliance.
To restore to a different replacement appliance, you must restore to an appliance of the same model or higher. For example, you can restore an image from a MARS 20 to a MARS 20, MARS 50, MARS 100, or MARS 100e; however, you cannot restore a MARS 50 to a MARS 20. Restoring to a replacement appliance differs from restoring to the actual appliance that performed the archive.
Note
The following issues must be addressed when restoring to a replacement appliance:
•
•
•
Because a single image of the complete system configuration data is archived and updated daily, no matter what period you select from an archive, the system configuration data includes the most recent changes. In other words, selecting a period that is 365 days old affects only the event data. The system configuration that is restored mirrors that of the most current archive.
For more guidance, see Guidelines for Restoring.
Configuring a Standby or Secondary MARS Appliance
You cannot run queries and reports or perform incident investigation over archived data directly. To perform any kind of investigation using archived data, you must restore that data to a MARS Appliance. Therefore, we recommend that you configure a secondary appliance for this purpose. The reason to use a separate appliance to study old data is that you must restore the period data to the appliance, and the restore re-images all configuration and event data based on the archive settings for the defined period.
To restore to a secondary appliance, you must restore to an appliance of the same model or higher. For example, you can restore an image from a MARS 20 to a MARS 20, MARS 50, MARS 100, or MARS 100e; however, you cannot restore a MARS 50 to a MARS 20. Restoring to a secondary appliance differs from restoring to the actual appliance that performed the archive. The following issues must be addressed when restoring to a secondary appliance:
•
•
•
Because a single image of the complete system configuration data is archived and updated daily, no matter what period you select from an archive, the system configuration data includes the most recent changes. In other words, selecting a period that is 365 days old affects only the event data. The system configuration that is restored mirrors that of the most current archive.
For more guidance, see Guidelines for Restoring.
Guidelines for Restoring
When you do restore to an appliance, keep in mind the following guidelines:
•
Caution
•
•
•
•
•
•
•
•
•
•
•
–
–
–
–
