...
We have some options that you can set by directly editing the script. These might be settable on the command line in future. They are below.
| name | default value | what it does |
|---|---|---|
| conf_file | /usr/local/omk/conf/opCommon.nmis | The full path to the Opmantek configuration file. Used to retrieve the UUID. |
| debug | 0 | 0 - Summary output only 1 - Commands run 2 - Command outputs (usually file contents). A lot of information is dumped, use for troubleshooting only. |
| filename | cisco.csv | The filename to be imported. If it's not in the default directory, the full path including name is OK to use. |
| last_date_of_support | 2019-01-01 | The date in YYYYYYY-MM-DD format. Devices with a column value for 'Last Date of Support' that's older than this date will not be imported. |
| user | admin | The name of the Open-AudIT user performing the action. Admin 'admin' is the default user and fine to use. |
...
You may see lines beginning with DEBUG, INFO, WARNING or ERROR. Generally only ERRORs ERROR lines are bad and will immediately halt the script execution.
...
Below are the columns from our current Cisco spreadsheet. If your order of these columns differs, it shouldn't matter, however your spreadsheet should contain all the columns used in the mappings below.
The dates we are assuming have a format of D/M/YYYY. These will be reformatted to YYYY-MM-DD for Open-AudIT.
| Serial Number / PAK number | Coverage | Covered Line Status | Business Entity | Sub Business Entity | Product Family | Product ID | Product Description | Asset Type | Product Type | Item Quantity | Covered Line Start Date | Covered Line End Date | Covered Line End Date FY-FQ | Contract Type | Service Brand Code | Contract Number | Subscription Reference ID | Ship Date | End of Product Sale Date | End of Software Maintenance Date | Last Date of Support | LDOS FY-FQ | End Of Life Product Bulletin | Warranty Type | Warranty End Date | Install Site Customer Registry GU Name | Install Site Customer Registry Party Name | Install Site Customer Registry Party ID | Install Site Name | Install Site ID | Install Site Address 1 | Install Site City | Install Site State | Install Site Country | Install Site Postal Code | Product Bill to ID | Product Bill-to Partner Name | Product Partner BE GEO ID | POS Partner BE GEO ID | POS Partner BE GEO Name | Service Bill to ID | Service Bill-to Partner Name | Service Partner BE GEO ID | Product List Price $ | Default Service List Price $ | Default Service Level | Existing Coverage Level List Price $ | Instance ID | Parent Instance ID | Product SO | Product PO | Service SO | Service PO | Web Order ID | Mapped to SWSS (Y/N) | Mapped to C1 (Y/N) | Auto-renewal flag | Configuration |
...
So you may already have some of these devices in Open-AudIT, you may not. How does Open-AudIT know what to do here? It all depends on the serial number. The spreadsheet doesn't contain the usual items we need to match devices (think hostname, ip, type, UUID, etc), but it does contain the device serial number. So you'll need to ensure your configuration item named 'match_serial' is set to 'y' (which is the default). As long as that is set, you can import and run discoveries in whichever order you like. Obviously discovery must be working and able to retrieve the serial from the device to perform the match. If you don't have working discovery (usually SNMP based for Cisco network equipment), you'll likely end up with duplicate devices - you have been warned! Just remember, Bulk Edit is your friend.
If you import a device, then run a discovery some fields may be overwritten. Model is likely the first one you'll notice. This is expected. Two screenshots are below of a device after import, then after discovery.
After import.
After Discovery.
