> inPilot Administration and Management
> This chapter provides information on administering and managing the inPilot application.
> This chapter describes the following topics:

> • | Launching the inPilot GUI

> • | Administration

> • | Operations and Management

> • | Troubleshooting inPilot

> Launching the inPilot GUI
> To launch the inPilot interface:

> 1. | In a Web browser, enter the following URL:

> http://<inPilot-server-hostname or IP address>:<apache port>
> For example, http://10.4.5.2:8080

> 2. | Enter your user name and password. The user name must be an alpha and/or numeric string of 3 through 16 characters in length. The only special character that a user name can include is underscore (_).

> The password must meet the following criteria:

> • | Must be a minimum of 8 characters long and a maximum of 32 characters long

> • | Must not be a repeat or reverse of the associated user name

> • | Must not be more than 3 of the same characters used consecutively

> • | Must contain at least 3 of the following combinations:

> • | English upper case characters (A through Z)

> • | English lower case characters (a through z)

> • | Numerical (0 through 9)

> • | Special characters (such as _, ., !, @, $, *, =, -, ?, etc)

> It is recommended to use the following browsers:

> • | Internet Explorer (v 7.0+)

> • | Mozilla Firefox (v 3.0.10+)

> Note that:

> • | No additional plug-in is required.

> • | The javascript is enabled by default on the intended browser.

> • | Suggested screen resolution is 1024 x 768 and above.

> Administration
> This section provides information on how to administer and manage the inPilot application.
> Managing User Accounts
> The inPilot application provides two levels of access privileges:

> • | Administrator: Users in this group have the following privileges:

> • | Create, edit, and delete other user accounts

> • | Edit configuration settings

> • | Activate, deactivate, and reset password for operator users

> • | Generate and view reports

> • | Operator: Users in this group can:

> • | Generate reports

> • | View module-level reports available to them

> Important: Only administrator with admin name can create user accounts.
> Managing Gateways
> The inPilot application supports configuring multiple gateways for which reports can be customized and generated. Gateways are the chassis from which EDR and bulkstat files are fetched to the reporting server.
> Important: Users with administrative privilege can only add and manage gateways.
> When a gateway is added through the GUI, a directory by the name of the gateway is created in the <inpilot_install_dir>/starbi/server/data directory.
> The gateway directory structure looks like the following:
> <data directory>
> |
> |--> <Gateway name>
> |
> |--> edr
> The inPilot application expects the EDR files in the directories that are created when adding the gateway.
> Configuring Logging
> The inPilot application facilitates logging to trace and debug problems identified within the reporting system.
> Important: Users with administrative privilege can only manage logging.
> Operations and Management
> This section provides information on the scripts that can be used to manage the inPilot components and the reports.
> Using the Maintenance Utility
> A shell script utility called serv is included with inPilot in the <inpilot_install_dir>/starbi/bin directory.
> This serv script can be used to manage the following inPilot processes:

> • | Process Monitor (PSMON) Application

> • | Scheduling Server

> • | Postgres Server

> • | Apache Server

> This utility can report the status of the inPilot processes on the system or it can be used to stop the inPilot process.
> Following are the options available with the serv script:
> ./serv { psmonitor | scheduler | postgres | apache } [ start | stop | status ]

> Keyword | Description
> psmonitor | This is an optional keyword used with the serv script. This represents the PSMON application.
> scheduler | This is an optional keyword representing the scheduling server.
> postgres | This is an optional keyword representing the postgres server.
> apache | This is an optional keyword representing the apache server.
> start | Starts each inPilot process.
> stop | Kills or stops the running inPilot process.
> status | Displays the status of each inPilot process.

> ‌
> For example, if you want to start only the PSMON, then enter the following command:
> ./serv start psmonitor
> or
> ./serv psmonitor start
> Important: If you stop the inPilot process, make sure that PSMON is not running. Otherwise PSMON will restart the inPilot application.
> The following is a sample output of the serv status command:
> ---------------------------------------------------
> --------------- inPilot Process Status ------------
> PID Process Status
> ---------------------------------------------------
> 4245 Process Monitor Running
> 4256 Scheduling server Running
> 4267 Postgres Server Running
> 4289 Apache Server Running
> ---------------------------------------------------
> Using the PSMON Script
> PSMON is a perl script that is used to monitor the Scheduling Server, Postgres Server, and Apache Server processes. This script can start or stop the processes based on certain thresholds specified in the inPilot configuration file. The PSMON respawns any dead processes using the set of rules defined in the configuration file.
> This script can also optionally send notifications to users via e-mail.
> Generating Reports in Excel Format
> To generate the reports in excel format, execute the following script from the <inpilot_install_dir>/starbi/bin directory.
> ./get_excel_report.sh -day <date for report generation> -f<path where report to be stored> -filter<filter for the report>
> The script takes three parameters, the date for which report is to be generated, the path where generated report is to be stored, and the filter for the reports. The date must be in mm-dd-yyyy format only, and the filter can be based on Type Allocation Code (TAC) or Access Point Name (APN).
> Using the unanonymize_msisdn.sh Script
> inPilot currently supports reporting of subscriber’s private data like Mobile Station Integrated Network (MSISDN) both in GUI and excel format. This particular subscriber data is visible only to users with administrator privilege. By default, the excel report will be presenting MSISDNs in an encrypted format in all subscribers based reports.
> A separate shell script utility, unanonymize_msisdn.sh, is available to decrypt the MSISDNs. This utility will check for user’s privilege before decrypting the MSISDNs list. It will prompt for the GUI administrator password.
> To decrypt the MSISDNs, execute the following script from the <inpilot_install_dir>/starbi/bin directory:
> ./unanonymize_msisdn.sh -u <username> -f <file containing list of encrypted MSISDNs -o <output file path>
> Important: Please note that the users require GUI administrator credentials to access this utility.
> Using the generate_dns_mapp_sql.sh Script
> To generate the DNS mapping for the specified list of IP addresses, execute the following script from the <inpilot_install_dir>/starbi/bin directory:
> ./generate_dns_mapp_sql.sh <input file for IP> <output file where mapping should be stored>

> Keyword/Variable | Description
> input file for IP | A file containing IP addresses. Each IP address must be present in a new line.
> output file where mapping should be stored | An output file for storing the DNS mappings in SQL format.

> ‌
> This script is used to perform Internet DNS lookup of the specified IP addresses. It uses the ‘nslookup’ system administration command to find the DNS name of the specified IP. Please note that the machine must be connected to Internet for successful execution.
> Using the getSupportDetails Script
> In the event additional troubleshooting assistance is required, debugging information can be collected using a script called getSupportDetails.pl. This script collects different log files and captures the output of certain system commands that aid in troubleshooting issues. This script is packaged with inPilot in the <inpilot_install_dir>/starbi/tools/supportdetails/ directory.
> This script refers to an XML file to get the list of logs. This XML file resides in the same directory as the script. Once executed, the script retrieves the contents of logs, files, folders, and output of certain commands and prepares a zipped file (inpilotsupportDetails.tar.gz), by default it is placed in /tmp/log directory.
> Requirements
> Perl 5.8.5 and above is required for running the script.
> Apart from standard Perl modules (which are included in default installation of Perl), some additional modules are required for running the script. The list is as follows:

> • | expat version 1.95.8

> • | XML::Parser version 2.34

> • | XML-Parser-EasyTree

> • | Devel-CoreStack version 1.3

> These modules are installed by default by the product. Please ensure that the above mentioned modules are installed when using a different installation of Perl.
> To run the script, change to the directory path where the script is present and type:
> ./getSupportDetails.pl [--level=...] [--xmlfile=...] [--help]

> Keyword/Variable | Description
> --level | Specifies the level of debug to run. It can have a maximum of 4 levels. The level 4 provides the most detailed information. Default: 1
> --xmlfile | Specifies the xml file name to be used for collecting the log. Default: getSupportDetails.xml
> --onlyrecentlogs | Collects only recent logs and skips detailed logs. Default: Collects detailed logs
> --collectFor | Collects problem specific logs and information which is not collected under normal levels. This can be combined with --level option. Default: Collects logs covered under '--level' option.
> --help | Displays the supported keywords/variables.

> ‌
> For example, ./getSupportDetails.pl --level=4 --xmlfile=/tmp/getSupportDetails.xml
> Supported Levels
> The logs that can be collected for different levels are as follows:

> • | Level 1:

> • | Recent Log files

> • | Current status (running / not running) of the product

> • | Current Config files of the product

> • | Level 2:

> • | Logs from Level 1

> • | Installation Logs

> • | Database Logs (if available)

> • | Web Server logs (if available)

> • | Information of Solaris version and current patch installed

> • | Output of the following commands:

> netstat -an
> ifconfig -a
> df -k
> etc..

> • | Level 3:

> • | Logs from level 2

> • | Syslog Configuration and log files

> • | Level 4:

> • | Logs from level 3

> • | All Log files (including old logs)

> • | Crontab entries

> • | Information of packages installed

> • | Stack trace of any crash files (if debugger is installed on local machine)

> • | System Libraries only if any core file present in crash directory

> • | Level of Solaris installed

> • | Output of the following commands:

> ipcs
> ps -eaf
> etc..
> Server script parameters
> The number of files being processed during each parsing interval for HTTP and non-HTTP EDRs can be controlled using the following parameters defined in settings.py file.
> EDR_TOTAL_NO_OF_FILES = 25
> EDR_MAX_NO_OF_PROCESSES = 5
> HTTP_TOTAL_NO_OF_FILES = 25
> HTTP_MAX_NO_OF_PROCESSES = 5
> With the above default configuration, if the number of files being accumulated are less than 25 and not in multiples of 5, then inPilot spawns one more process to parse the remaining files.
> Troubleshooting inPilot
> This section provides information on how to resolve situations you might encounter with using inPilot software. This section provides problem definitions, their likely cause(s), and solutions.

> Problem: | The EDR files are generated and moved out from the input directory. However, there are no reports getting generated.
> Possible Cause(s): |
> • | The files may not be available in the archive directory i.e. <inpilot_install_dir>/starbi/archive.
> Action(s): |
> • | Check if the files are available in the archive directory.
> • | Check if they are marked invalid. If yes, check if there are any headers present in the files. If not, you need to configure ECS appropriately.
> • | If the headers are present, check if all the required headers are present in the files.

> ‌

> Problem: | inPilot reporting client cannot be started.
> Possible Cause(s): | The web browser cache might be full.
> Action(s): | The browser cache must be cleared. In the case of Firefox, follow these steps:
> • | On the Tools menu, click Clear Private Data.
> • | Select Cache check box.
> • | Click Clear Private Data Now.
> In the case of Internet Explorer, follow these steps:
> • | On the Tools menu, click Internet Options.
> • | Click Delete.
> • | Select Temporary Internet files check box.
> • | Click Delete.
> Important: The Firefox version supported for inPilot is 3.0.10 and later. For Internet Explorer, it is 7.0 and later.

> ‌

> Problem: | The bulkstats or KPI reports are not generated.
> Possible Cause(s): | The bulkstats file might not be parsed.
> Action(s): |
> • | On the ADMIN menu, check the bulkstats audit under AUDIT. The audit should indicate whether the bulkstats files are being parsed or not. For more information, refer to the inPilot Online Help.
> • | Check if FTP is enabled on the inPilot server.
> • | Check if the bulkstats are FTPed to correct location on the inPilot server from the gateway. The path should be as follows:
> $STARBI_HOME/server/data/$gwname/bs Where $STARBI_HOME = inPilot installation directory, $gwname = Gateway name
> • | Check if the naming convention of the bulkstat files matches with the following convention:
> bulkstat%date%%time%.txt Where, date format = yyyymmdd and Time format = hhmmss Example: bulkstat20100206150002.txt
> • | Check if the Bulkstats/KPIs UI show only one day data
> • | Check if the counters of same schemas are added in the formula while configuring KPIs. For example, if you are adding KPI in SGSN schema, then you should add counters of SGSN only in the formula.
> • | Check if the bulkstat files are always pushed from gateway to master inPilot and not to RDP.
> Important: If you do not have Web Element Manager (WEM) application installed, then you should refer to the configuration file in Sample Bulkstats Schema Configuration appendix of the inPilot Installation and Administration Guide. Important: inPilot is compatible with WEM 9.x. Therefore, you should use WEM 9.x to configure bulkstats on gateways.

> ‌

> Problem: | Parser is not handling data files properly.
> Possible Cause(s): | The file might be corrupted.
> Action(s): |
> • | File are marked as 'UNPROCESSED.<file>' and moved to archive directory if one of the following conditions are met:
> • | file is '.gz' and corrupted with CRC error.
> • | file is empty.
> • | file does not have a header.
> • | File are marked as 'CORRUPTED.<file>' and moved to archive directory if the file is '.gz' and corrupted (other than CRC error) like 'invalid compressed data--format violated'

> ‌

> Problem: | Unable to add / edit / delete gateways.
> Possible Cause(s): | The gateway configuration may be incorrect.
> Action(s): |
> • | Check if correct IP is provided while adding the gateway.
> • | Check if gateway host is reachable from inPilot.
> For more information, refer to the inPilot Online Help.

> ‌

> Problem: | Unable to add / edit / delete RDPs.
> Possible Cause(s): | The RDP configuration may be incorrect.
> Action(s): |
> • | Check if correct IP and port are provided while adding RDP.
> • | Check if RDP is actually running on remote machine.
> • | Check if RDP host is reachable from inPilot.
> For more information, refer to the inPilot Online Help.

> ‌

> Problem: | No reports are generated from RDP.
> Possible Cause(s): | The RDP configuration may be incorrect.
> Action(s): |
> • | Check if RDP is actually running on remote machine.
> • | Check if the user name and password configured are correct.
> For more information, refer to the inPilot Online Help.

> ‌

> Problem: | Duplicate reports are generated and/or the reports are incorrect.
> Possible Cause(s): | inPilot might have parsed half-cooked files.
> Action(s): | The chassis tags the EDR files with a prefix ‘prog.’ while transferring to inPilot. After the transfer is complete, the chassis removes the ‘prog.’ tag. The ‘prog.’ prefix indicates that the file is half cooked.
> • | Check if the EDR files with the prefix ‘prog.’ are ignored.
> • | Check if EDR file formats are configured properly.

> ‌

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883