> GTPP Storage Server Administration
> This chapter provides information for the administration of the GSS; specifically maintenance and operation procedures and troubleshooting procedures. In most cases, the maintenance and troubleshooting procedures for a cluster node are the same or similar to those for a stand-alone node - when there are differences there will be separate procedures for stand-alone and cluster.
> Important: The GSS is not configured or managed through network management interface(s).
> This chapter includes procedures for maintaining and troubleshooting the GSS software application.

> • | Maintaining the GSS

> • | Troubleshooting the GSS

> Maintaining the GSS
> This section provides the procedures on how to maintain the GSS application and how to use the GSS configuration and log files.
> Periodic Removal of Processed Data Files
> The GSS can be configured to remove the processed CDR data files. The removal can be done periodically and automatically through a clean-up script (/<install_dir>/gss/bin/cleanup.sh) which can be run as a cron job.
> The cron job is a crontab command. It is used to schedule commands to be executed periodically. It reads a series of commands from standard input and collects them into a file known as crontab file which is later read and whose instructions are carried out.
> The following procedure adds a clean-up entry to the crontab file.

> Step 1 | Login to the server with root privileges.

> Step 2 | Enter the editing mode for the crontab with the following command:

> crontab -e

> Step 3 | Add the job execution frequency values as required.

> 00 03 * * * * /<install_dir>/gss/bin/cleanup.sh -ext .p -dirpath <install_dir>/gss/data/extradata -clnintvl 7 >> /gss/log/cleanup.log 2>&1
> Adding the above entry to the crontab table instructs the system to execute the clean-up script every day at 3:00 AM and to delete all the files with a .p file extension that are older than the maximum storage period, 7 days.
> 00 03 * * * * /<install_dir>/gss/bin/cleanup.sh -ext .p -dirpath /sharedgss/gss/clustgss1_log/gss/ -clnintvl 7 >> /sharedgss/gss/clustgss1_log/cleanup.log 2>&1
> Add the above entry to a crontab instructs the system to execute the clean-up script to remove processed data files in the /sharedgss/gss/data directory after the expiration of the storage period of 7 day(s).

> Step 4 | Save and close the crontab file by entering the following command:

> :wq
> Important: The command suggested for this step assumes that you have the vi editor set as the system’s default text editor, if not then use the appropriate exit command.

> Step 5 | View the changes in the crontab file by entering the following command:

> crontab -l
> Using Log Files for Monitoring
> Each component and most processes generate their own log files to track activity, errors and warning messages. Use the less command or a a text editor to view the appropriate log.
> Important: Information inside angle brackets denotes a variable that you defined during the installation process.
> GSS System Logs

> Application or Process | Log File Location
> Installation | Location: /<packages>/gss_<version>/ Log name format: installation_log_<install_dir>_<server_name> Log name example: installation_log_install8071_LondonGSS1
> GSS server - Stand-alone mode | Location: / <install_dir>/gss/log/GSS_SERVER_LOG_<YYYYMMDD> _<HHMMSS>/GSS_SERVER_LOG Log directory name example: GSS_SERVER_LOG_20081124_020635 Log name: GSS_SERVER_LOG
> GSS server - Cluster mode | Location: /sharedgss/gss/<node_name>_log/GSS_SERVER_LOG_<YYYYMMDD>_<HHMMSS>/GSS_SERVER_LOG Log directory name example: GSS_SERVER_LOG_20081124_030851 Log name: GSS_SERVER_LOG
> PostgreSQL | <install_dir>/postgres/logfile
> PSMON | <install_dir>/gss/log/psmon.log
> FileGen - Stand-alone mode | FileGen logs are stored in the same directory as the GSS application logs. They are distinguishable by the log name. Important: The FileGen adds an audit message in syslog file located in /var/adm/messages directory for every CDR file being generated. Log level user.notice should be turned on in /etc/syslog.conf file for syslogd to log these messages. Location: / <install_dir>/gss/log/GSS_SERVER_LOG_<YYYYMMDD> _<HHMMSS>/GSS_FILEGEN_LOG Log directory name example: GSS_SERVER_LOG_20081124_020635 Log name: GSS_FILEGEN_LOG
> FileGen - Cluster mode | FileGen logs are stored in the shared location. Important: The FileGen adds an audit message in syslog file located in /var/adm/messages directory for every CDR file being generated. Log level user.notice should be turned on in /etc/syslog.conf file for syslogd to log these messages. Location: /sharedgss/gss/<node_name>_log/GSS_SERVER_LOG_<YYYYMMDD>_<HHMMSS>/GSS_FILEGEN_LOG Log directory name example: GSS_SERVER_LOG_20090525_130248 Log name: GSS_FILEGEN_LOG

> ‌
> Accessing GSS Commands
> There are several console commands available at the command line. Access is gained by moving to the /gss directory where the GSS files were installed.
> # cd /<install_dir>/gss
> Depending upon the version of the GSS software, the root command will vary. For all versions with an extension number of 70 or lower (e.g., 7.1.67 or 8.0.70) the command is
> # ./GSS
> For all versions of GSS with an extension number of 71 or higher, the command is
> # ./serv
> Command Arguments

> Action | Meaning
> start | Starts the GSS, Process Monitor (PSMON) Tool, PostgreSQL server and FileGen using parameters listed in gss.cfg file.
> stop | Stops the GSS, PSMON Tool, PostgreSQL server and FileGen utility.
> restart | Stops and restarts the GSS, PSMON Tool, PostgreSQL server and FileGen utility. While restarting the GSS, a confirmation message appears both in the case of stand-alone and cluster modes.
> switch | Switchover resource group from one node to another. Important: The switch option can only be used in a cluster mode installation.
> status | Displays the current status of each process/resource. In case of stand-alone/backup mode, this command displays the status of the following processes:
> • | Process monitor application
> • | PostgresGSS server
> • | GSS filegen
> In case of cluster mode, this command displays the status of the following resources:
> • | GSS resource group
> • | Failover Dataservice resource
> • | Logical hostname resource
> • | CRNP resource
> start_backup | Starts the GSS in backup mode. Important: The start_backup option can only be used in a backup mode installation.
> stop_backup | Stops the GSS in backup mode. Important: The stop_backup option can only be used in a backup mode installation.
> --version | Displays the version of the GSS software. Only used with GSS command.
> version | Displays the version of the GSS software. Only used with serv command.
> help | Prints this help message.

> ‌
> The commands are used in the following manner:
> # ./serv switch
> # ./serv start
> # ./GSS --version
> In the stand-alone mode, the status of individual process can be identified with serv script by entering the following command:
> # ./serv status <psmon | postgres | gss | gssfilegen>
> or
> # ./serv <psmon | postgres | gss | gssfilegen> status
> In the cluster mode, the status of individual resource and resource group can be identified with serv script by entering the following command:
> # ./serv status [ <resource_name> |<resourcegroup_name> | <process_name> ]
> or
> # ./serv [ <resource_name> | <resourcegroup_name> | <process_name> ] status
> For example, if you want to start only the PSMON using serv script, then enter the following command:
> # ./serv psmon status
> or
> # ./serv status psmon
> Modifying a GSS Configuration
> The GSS configuration file (gss.cfg) is stored in the /<install_dir>/gss/etc directory.
> The gss.cfg file can be modified with any text editor but for the modifications to take affect, the server must be rebooted.
> Caution: Before making changes to a gss.cfg, ensure that there is a write-protected copy of the gss.cfg stored in a separate directory on each node. It is recommended to store the copy in the /<packages>/<gss_version> directory.
> The following are the copies of gss.cfg. Besides providing the default GSS configuration values, this information can be copied to replace a damaged gss.cfg.
> To view a gss.cfg, use the following command:
> cat /<install_dir>/gss/etc/gss.cfg
> GSS Configuration File - Stand-alone Node
> #Filename: gss.cfg
> #Config file containing configuration values for the GTPP Storage Server (GSS) and Filegen process organised with a Section header and Key = Value data format.
> #Section header [Tag string in sqr bracket] is for internal use.
> #User can update the Value part and restart the process making it effective.
> #All numerical values have Range and Default.
> #Section: Server_Param
> #Contains config values for Server like address, port, exec-mode etc.
> [Server_Param]
> #Key: Addr
> #A valid existing host-interface address.
> #Default: 0.0.0.0
> Addr = 10.4.4.132
> #Key: Port
> #A valid udp-port value for Server process.
> #Filgen process uses Port + 1 value.
> #Range : 1024 - 65535
> #Default: 50000
> Port = 50000
> #Key: DB_Init_Tables
> #Clean up all tables while starting the server.
> #Caution: This will delete all the records from database!!!
> #Value : yes / no
> #Default: no
> DB_Init_Tables = no
> #Key: Socket_RX_Buffer_Size
> #Socket Rx Buffer Size in Bytes.
> #Consider increasing Socket buffer size at system kernel level and then at #application level for GSS if netstat -s (udpInOverflows) shows non zero incremental values for large messages.
> #To increase overall kernel limit use (as root):
> #ndd -set /dev/udp udp_max_buf 8388608/16777216 or higher:limited by system RAM
> #And then set the same value with Socket_RX_Buffer_Size for Server.
> #Note :This is applicable only for GSS Process. Filegen uses default value.
> #Range : 32768 - 268435456
> #Default: 16777216 Bytes
> Socket_RX_Buffer_Size = 16777216
> #Key: DB_Connections
> #GSS process Database Connections count.
> #Range : 12 - 32
> #Default: 20
> DB_Connections = 20
> #Key:Archive_Mode
> #Run Server and Filegen in archive mode where each data request is archived directly after Store w/o Update (Ack) from CGF.
> #To be used if GSN is configured without any CGF but uses Storage Server as the only backup storage node.
> #Value : yes/no
> #Default: yes
> Archive_Mode = yes
> #Section: Filegen_Param
> #Contains config values for Filegen parameters.
> [Filegen_Param]
> #Key: Start_Seq_Num
> #Starting seq num of the Ist CDR file.
> #Uses this number for the first file or
> #if Use_Start_Seq_Num is set.
> #Range : 1 - ULONG_MAX
> #Default: 1
> Start_Seq_Num = 1
> #Key: Use_Start_Seq_Num
> #Flag to indicate whether to use the Start_Seq_Num parameter for the Ist CDR file.
> #If yes, the Start_Seq_Num value is used for the Ist CDR file on restart.
> #Value : yes/no
> #Default: no
> Use_Start_Seq_Num = no
> #Key: Start_Lrsn_Num
> #Starting lrsn num of the Ist CDR file.
> #Uses this number for the first file or
> #if Use_Start_Lrsn_Num is set.
> #Range : 1 - ULONG_MAX
> #Default: 1
> Start_Lrsn_Num = 1
> #Key: Use_Start_Lrsn_Num
> #Flag to indicate whether to use the Start_Lrsn_Num parameter for the Ist CDR file.
> #If yes, the Start_Lrsn_Num value is used for the Ist CDR file on restart.
> #Value : yes/no
> #Default: no
> Use_Start_Lrsn_Num = no
> #Key: Max_CDR_Per_File
> #Max count of CDR in a data file
> #Range : 1000 - 100000
> #Default: 10000
> #Note : Generated data file may contain 1 to 254 CDRs more in addition to Max_CDR_Per_File
> Max_CDR_Per_File = 10000
> #Key: Max_File_Gen_Period
> #Maximum idle period in hours after which a new file shall be generated without waiting for Maximum CDRs per file
> #This timer is reset on receiving CDRs or writing a new file.
> #Range : 1 - 24 hours
> #Default: 1 hour
> Max_File_Gen_Period = 1
> #Key: Hard_File_Gen_Period
> #Hard limit interval in mins after which a new file shall be generated without waiting for Maximum CDRs per file.
> #Setting this hard limit also enables writing a new file of 0 CDRs on timer expiry.
> #This timer is reset on writing a new file.
> #Overrides Max_File_Gen_Period if configured.
> #Range : 1 - 24*60 mins
> #Default: 0 (disable)
> #Description: Hard Limit Interval for File Generation
> Hard_File_Gen_Period = 0
> #Key: Max_Req_Per_Fetch
> #Maximum number of data records to be fetched per db request.
> #Range : 10 - 1000
> #Default: 50
> Max_Req_Per_Fetch = 50
> #Key: File_Format
> #Encoding format for CDR files
> #Values : starent/custom1/custom2/custom3/custom4/custom5/custom6/custom7
> #Note : File format custom6 is reserved for HDD GSS on GSN side and not supported for external GSS
> #Default : starent
> File_Format = custom3
> #Key: GGSN_Location
> #File name format string for identifing CDR files for a node/location.
> #Note : This is applicable only for custom2, custom3 and custom4 file format.
> #Even though name of this parameter contains GGSN, this parameter is equally applicable to all type of GSNs supported by GSS.
> #Values : GSN Location String
> #Default : GSN
> GGSN_Location = GSN
> #Key: Data_File_Path
> #Path to generated CDR data files.
> #This has to be valid path with write permission to the directory.
> #Note : For custom7 file format 3 types of files #(Processed,Filtered,Rejected) gets generated in <gss_dir>/data, #<gss_dir>/data/filtered and <gss_dir>/data/rejected respectively and #which are mapped to /cdr/work/proc, /cdr/work/proc/filtered, #/cdr/work/proc/rejected respectively through symbolic link
> #Value : Dir path string. For example <gss_dir>/data
> #Default: No default
> Data_File_Path = /TEST_GSS/cvserver/gss/data
> #Key: Enable_Redundant_File
> #Flag to indicate whether to enable redundant file creation in path parallel to primary data path. For example <gss_dir>/data_redundant
> #Note : This is applicable only for starent/custom1/custom2/custom3/custom4/custom5 file format
> #This is not applicable for custom6 and custom7 file format
> #Value : yes/no
> #Default: no
> Enable_Redundant_File = n
> #Key: GTPP_Dict
> #GTPP Dictionary to be used to decode and encode CDRs.
> #The GTPP Dictionary should be same as used on GSN.
> #Note : This is applicable only for custom2, custom3 and custom4 file format.
> #Value : starent,custom1-custom20.
> #Default: custom1
> GTPP_Dict = custom1
> #Key: Use_Binary_Addr_Format
> #Flag to encode IP Address fields in binary format for the CDR.
> #Note : This is applicable only for custom2, custom3 and custom4 file format.
> #Value : yes/no
> #Default: no
> Use_Binary_Addr_Format = n
> #Key: Enable_Unique_LRSN
> #Flag to encode unique incremental LRSN in the CDR.
> #Note : This is applicable only for custom2, custom3 and custom4 file format.
> #Value : yes/no
> #Default: no
> Enable_Unique_LRSN = n
> #Key: Node_ID
> #Node ID string to be encoded in CDR.
> #Note : This is applicable only for custom2, custom3 and custom4 file format.
> #Value : No default value. To be encoded if user gives a Node ID string.
> #Range : 0 - 16 characters
> #Default : No default
> Node_ID =
> #Key:Backup_Sequence_File_Path
> #Path for filegen file sequence used in backup mode
> #Note : This is applicable only for starent/custom1/custom2/custom3/custom4/custom5 file format
> #This is not applicable for custom6 and custom7 file format
> #Value : dir path string
> #Default:
> Backup_Sequence_File_Path =
> #Section: Archive_Param
> #Contains config values for archive parameters.
> [Archive_Param]
> #Key: Archive_Cdr
> #Used for normal execution mode (GSN with CGF+GSS) to enable/disable archiving CGF acked data requests (CDRs) to database.
> #yes : GSS shall archive all Acknowledged requests to Archive DB.
> #no : GSS shall delete all Acknowledged requests from Active DB without saving them to Archive DB.
> #Value : yes /no
> #Default: yes
> Archive_Cdr = yes
> #Key: Req_Buffer_Length
> #In memory internal data request buffer length maintained by server process.
> #The count indicates number of data request in multiples of 512 data request blocks.
> #Range : 1 - 200
> #Default: 2 (2*512=1024 data requests)
> Req_Buffer_Length = 2
> #Key: Max_Archive_Period
> #Used for normal execution mode (GSN with CGF+GSS)
> #Max archive period (hours) for which archived data
> #requests (CDRs) are maintained with system's Archive DB.
> #Range : 1 - 168 hours
> #Default: 168 hours
> Max_Archive_Period = 168
> #Key: Max_Storage_Period
> #Used for normal execution mode (GSN with CGF+GSS)
> #Maximum storage period (mins) for which unacked data requests are maintained with system after which are #transferred to Unacked Archive DB.
> #A value of 0 indicates no such limitation and can be maintained forever.
> #Range : 1 - 30 mins
> #Default: 0 (Disable)
> Max_Storage_Period = 0
> #Key: Max_Storage_Count
> #Used for normal execution mode (GSN with CGF+GSS)
> #Maximum number of latest unacked data requests maintained by system in memory internal data request buffer after which are transferred to Unacked Archive DB.
> #Size in multiple of Req_Buffer_Length
> #A value of 0 indicates no max value.
> #Range : 1 - 1000
> #Default: 10
> Max_Storage_Count = 10
> #Key: Vacuumize_DB
> #Vacuumize database periodically.
> #Value : yes / no
> #Default: yes (Vacuumize database periodcally)
> Vacuumize_DB = yes
> #Section: DB_Param
> #Contains config values for db parameters.
> [DB_Param]
> #Key: DB_Host_Name
> #DB server name or address string
> #Default : No default
> DB_Host_Name = 127.0.0.1
> #Key: DB_User_Name
> #User name for connection with database
> #Value : User name string
> #Default: postgres
> #Description : PostgreSQL login
> DB_User_Name = gsspg
> #Key: DB_Password
> #Password for connection with database
> #Value : User name string
> #Default: postgres
> #Description :PostgreSQL passwd
> DB_Password = gsspg
> #Key: DB_Host_Addr
> #DB server address.
> #Default : No Default, if given overrides DB_Host_Name
> DB_Host_Addr =
> #Key: DB_Port
> #DB server udp port value
> #Range : 1 - 65535
> #Default: 5432
> #Description :PostgreSQL port
> DB_Port = 5499
> #Key: DB_Retry_Count
> #Retry count to perform reconnection with DB server
> #Range : 10 - 100
> #Default: 20
> DB_Retry_Count = 20
> #Key: DB_Retry_Interval
> #Retry Interval (secs) to perform reconnection with DB server
> #Range : 1 - 10 secs
> #Default: 2 secs
> DB_Retry_Interval = 2
> #Section: Notif_Param
> #Contains config values for resource notification parameters.
> [Notif_Param]
> #Key: Notif_Type
> #Value : Alarm / Alert
> #Alarm : Generates notification once for each threshold cross over for the monitored entity.
> #Alert : Generates notification on each polling interval for the monitored entity only if above threshold mark.
> #Default: Alarm
> Notif_Type = Alarm
> #Key: Notif_Poll_Interval
> #Notification poll interval (mins) to examine the state of the monitored entity.
> #Range : 1 - 1440 mins
> #If threshold configuration is disabled then default: 0 (Disable: No notification)
> #If threshold configuration is enabled then default: 1
> Notif_Poll_Interval = 1
> #Key: Notif_Retry_Interval
> #Notification retry interval (secs)
> #Range : 1 - 60 secs
> #Default: 20 secs
> Notif_Retry_Interval = 20
> #Key: Notif_Retry_Count
> #Notification retry count
> #Range : 1 - 5
> #Default: 3
> Notif_Retry_Count = 3
> #Key: Notif_GCDR_File_Period
> #Enables Alarm / Alert to be sent for files older than given period in mins
> #Note : Even though name of this parameter contains GCDR, this parameter is equally applicable to all type of CDRs supported by GSS.
> #Range : 1 - 7*24*60 mins
> #Default: 15
> Notif_GCDR_File_Period = 15
> #Key: Notif_CPU_Usage
> #Enables Alarm / Alert to be sent for system cpu usage in %.
> #Range : 0 - 100 %
> #Default: 60
> Notif_CPU_Usage = 60
> #Key: Notif_Mem_Usage
> #Enables Alarm / Alert to be sent for system swap usage in MB.
> #Range : 0 - ULONG_MAX (MB)
> #Default: 9500
> Notif_Mem_Usage = 9500
> #Key: Notif_Disk_Usage
> #Enables Alarm / Alert to be sent if available disk size(GB) falls below configured limit.
> #Range : 0 - ULONG_MAX (GB)
> #Default: 199
> Notif_Disk_Usage = 199
> #Section: Log_Param
> #Contains config values for logging and status.
> [Log_Param]
> #Key Show_Status
> #Show status periodically (secs)
> #Range : 0 - ULONG_MAX secs
> #Default: 300 secs
> #0 - Disables
> Show_Status = 300
> #Key: Print_IO_Msg
> #Prints I/O messages to log
> #Value : yes /no
> #Default: no
> Print_IO_Msg = no
> #Key: Audit_File_Size
> #Audit log file size
> #minimum 2500 kbytes
> #default 2500 kbytes
> Audit_File_Size = 2500
> GSS Configuration File - Cluster Nodes
> These files are the same for each node in a cluster.
> #Filename: gss.cfg
> #Config file containing configuration values for the GTPP Storage Server (GSS) and Filegen process organised with a Section header and Key = Value data format.
> #Section header [Tag string in sqr bracket] is for internal use.
> #User can update the Value part and restart the process making it effective.
> #All numerical values have Range and Default.
> #Section: Server_Param
> #Contains config values for Server like address, port, exec-mode etc.
> [Server_Param]
> #Key: Addr
> #A valid existing host-interface address.
> #Default: 0.0.0.0
> Addr = 10.4.4.129
> #Key: Port
> #A valid udp-port value for Server process.
> #Filgen process uses Port + 1 value.
> #Range : 1024 - 65535
> #Default: 50000
> Port = 50000
> #Key: DB_Init_Tables
> #Clean up all tables while starting the server.
> #Caution: This will delete all the records from database!!!
> #Value : yes / no
> #Default: no
> DB_Init_Tables = no
> #Key: Socket_RX_Buffer_Size
> #Socket Rx Buffer Size in Bytes.
> #Consider increasing Socket buffer size at system kernel level and then at application level for GSS if netstat -s (udpInOverflows) shows non zero incremental values for large messages.
> #To increase overall kernel limit use (as root):
> #ndd -set /dev/udp udp_max_buf 8388608/16777216 or higher:limited by system RAM
> #And then set the same value with Socket_RX_Buffer_Size for Server.
> #Note :This is applicable only for GSS Process. Filegen uses default value.
> #Range : 32768 - 268435456
> #Default: 16777216 Bytes
> Socket_RX_Buffer_Size = 16777216
> #Key: DB_Connections
> #GSS process Database Connections count.
> #Range : 12 - 32
> #Default: 20
> DB_Connections = 20
> #Key:Archive_Mode
> #Run Server and Filegen in archive mode where each data request is archived directly after Store w/o Update (Ack) from CGF.
> #To be used if GSN is configured without any CGF but uses Storage Server as the only backup storage node.
> #Value : yes/no
> #Default: yes
> Archive_Mode = yes
> #Section: Filegen_Param
> #Contains config values for Filegen parameters.
> [Filegen_Param]
> #Key: Start_Seq_Num
> #Starting seq num of the Ist CDR file.
> #Uses this number for the first file or
> #if Use_Start_Seq_Num is set.
> #Range : 1 - ULONG_MAX
> #Default: 1
> Start_Seq_Num = 1
> #Key: Use_Start_Seq_Num
> #Flag to indicate whether to use the Start_Seq_Num parameter for the Ist CDR file.
> #If yes, the Start_Seq_Num value is used for the Ist CDR file on restart.
> #Value : yes/no
> #Default: no
> Use_Start_Seq_Num = no
> #Key: Start_Lrsn_Num
> #Starting lrsn num of the Ist CDR file.
> #Uses this number for the first file or
> #if Use_Start_Lrsn_Num is set.
> #Range : 1 - ULONG_MAX
> #Default: 1
> Start_Lrsn_Num = 1
> #Key: Use_Start_Lrsn_Num
> #Flag to indicate whether to use the Start_Lrsn_Num parameter for the Ist CDR file.
> #If yes, the Start_Lrsn_Num value is used for the Ist CDR file on restart.
> #Value : yes/no
> #Default: no
> Use_Start_Lrsn_Num = no
> #Key: Max_CDR_Per_File
> #Max count of CDR in a data file
> #Range : 1000 - 100000
> #Default: 10000
> #Note : Generated data file may contain 1 to 254 CDRs more in addition to Max_CDR_Per_File
> Max_CDR_Per_File = 10000
> #Key: Max_File_Gen_Period
> #Maximum idle period in hours after which a new file shall be generated without waiting for Maximum CDRs per file
> #This timer is reset on receiving CDRs or writing a new file.
> #Range : 1 - 24 hours
> #Default: 1 hour
> Max_File_Gen_Period = 1
> #Key: Hard_File_Gen_Period
> #Hard limit interval in mins after which a new file shall be generated without waiting for Maximum CDRs per file.
> #Setting this hard limit also enables writing a new file of 0 CDRs on timer expiry.
> #This timer is reset on writing a new file.
> #Overrides
> Max_File_Gen_Period if configured.
> #Range : 1 - 24*60 mins
> #Default: 0 (disable)
> #Description: Hard Limit Interval for File Generation
> Hard_File_Gen_Period = 2
> #Key: Max_Req_Per_Fetch
> #Maximum number of data records to be fetched per db request.
> #Range : 10 - 1000
> #Default: 50
> Max_Req_Per_Fetch = 50
> #Key: File_Format
> #Encoding format for CDR files
> #Values : starent/custom1/custom2/custom3/custom4/custom5/custom6/custom7
> #Note : File format custom6 is reserved for HDD GSS on GSN side and not supported for external GSS
> #Default : starent
> File_Format = custom3
> #Key: GGSN_Location
> #File name format string for identifing CDR files for a node/location.
> #Note : This is applicable only for custom2, custom3 and custom4 file format.
> #Even though name of this parameter contains GGSN, this parameter is equally applicable to all type of GSNs supported by GSS.
> #Values : GSN Location String
> #Default : GSN
> GGSN_Location = GSN
> #Key: Data_File_Path
> #Path to generated CDR data files.
> #This has to be valid path with write permission to the directory.
> #Note : For custom7 file format 3 types of files #(Processed,Filtered,Rejected) gets generated in <gss_dir>/data, #<gss_dir>/data/filtered and <gss_dir>/data/rejected respectively and #which are mapped to /cdr/work/proc, /cdr/work/proc/filtered, #/cdr/work/proc/rejected respectively through symbolic link
> #Value : Dir path string. For example <gss_dir>/data
> #Default: No default
> Data_File_Path = /sharedgss/gss/data
> #Key: Enable_Redundant_File
> #Flag to indicate whether to enable redundant file creation in path parallel to primary data path. For example <gss_dir>/data_redundant
> #Note : This is applicable only for starent/custom1/custom2/custom3/custom4/custom5 file format
> #This is not applicable for custom6 and custom7 file format
> #Value : yes/no
> #Default: no
> Enable_Redundant_File = n
> #Key: GTPP_Dict
> #GTPP Dictionary to be used to decode and encode CDRs.
> #The GTPP Dictionary should be same as used on GSN.
> #Note : This is applicable only for custom2, custom3 and custom4 file format.
> #Value : starent,custom1-custom20.
> #Default: custom1
> GTPP_Dict = custom1
> #Key: Use_Binary_Addr_Format
> #Flag to encode IP Address fields in binary format for the CDR.
> #Note : This is applicable only for custom2, custom3 and custom4 file format.
> #Value : yes/no
> #Default: no
> Use_Binary_Addr_Format = n
> #Key: Enable_Unique_LRSN
> #Flag to encode unique incremental LRSN in the CDR.
> #Note : This is applicable only for custom2, custom3 and custom4 file format.
> #Value : yes/no
> #Default: no
> Enable_Unique_LRSN = n
> #Key: Node_ID
> #Node ID string to be encoded in CDR.
> #Note : This
> is applicable only for custom2 and custom3 file format.
> #Value : No default value. To be encoded if user gives a Node ID string.
> #Range : 0 - 16 characters
> #Default : No default
> Node_ID =
> #Key:Backup_Sequence_File_Path
> #Path for filegen file sequence used in backup mode
> #Note : This is applicable only for starent/custom1/custom2/custom3/custom4/custom5 file format
> #This is not applicable for custom6 and custom7 file format
> #Value : dir path string
> #Default:
> Backup_Sequence_File_Path =
> #Section: Archive_Param
> #Contains config values for archive parameters.
> [Archive_Param]
> #Key: Archive_Cdr
> #Used for normal execution mode (GSN with CGF+GSS)
> #to enable/disable archiving CGF acked data requests (CDRs) to database.
> #yes : GSS shall archive all Acknowledged requests to Archive DB.
> #no : GSS shall delete all Acknowledged requests from Active DB without saving them to Archive DB.
> #Value : yes /no
> #Default: yes
> Archive_Cdr = yes
> #Key: Req_Buffer_Length
> #In memory internal data request buffer length maintained by server process.
> #The count indicates number of data request in multiples of 512 data request blocks.
> #Range : 1 - 200
> #Default: 2 (2*512=1024 data requests)
> Req_Buffer_Length = 2
> #Key: Max_Archive_Period
> #Used for normal execution mode (GSN with CGF+GSS)
> #Max archive period (hours) for which archived data
> #requests (CDRs) are maintained with system's Archive DB.
> #Range : 1 - 168 hours
> #Default: 168 hours
> Max_Archive_Period = 168
> #Key: Max_Storage_Period
> #Used for normal execution mode (GSN with CGF+GSS)
> #Maximum storage period (mins) for which unacked data requests are maintained with system after which are transferred to Unacked Archive DB.
> #A value of 0 indicates no such limitation and can be maintained forever.
> #Range : 1 - 30 mins
> #Default: 0 (Disable)
> Max_Storage_Period = 0
> #Key: Max_Storage_Count
> #Used for normal execution mode (GSN with CGF+GSS)
> #Maximum number of latest unacked data requests maintained by system in memory internal data request buffer after which are transferred to Unacked Archive DB.
> #Size in multiple of Req_Buffer_Length
> #A value of 0 indicates no max value.
> #Range : 1 - 1000
> #Default: 10
> Max_Storage_Count = 10
> #Key: Vacuumize_DB
> #Vacuumize database periodically.
> #Value : yes / no
> #Default: yes (Vacuumize database periodcally)
> Vacuumize_DB = yes
> #Section: DB_Param
> #Contains config values for db parameters.
> [DB_Param]
> #Key: DB_Host_Name
> #DB server name or address string
> #Default : No default
> DB_Host_Name = 127.0.0.1
> #Key: DB_User_Name
> #User name for connection with database
> #Value : User name string
> #Default: postgres
> #Description : PostgreSQL login
> DB_User_Name = gsspg
> #Key: DB_Password
> #Password for connection with database
> #Value : User name string
> #Default: postgres
> #Description :PostgreSQL passwd
> DB_Password = gsspg
> #Key: DB_Host_Addr
> #DB server address.
> #Default : No Default, if given overrides DB_Host_Name
> DB_Host_Addr =
> #Key: DB_Port
> #DB server udp port value
> #Range : 1 - 65535
> #Default: 5432
> #Description :PostgreSQL port
> DB_Port = 5499
> #Key: DB_Retry_Count
> #Retry count to perform reconnection with DB server
> #Range : 10 - 100
> #Default: 20
> DB_Retry_Count = 20
> #Key: DB_Retry_Interval
> #Retry Interval (secs) to perform reconnection with DB server
> #Range : 1 - 10 secs
> #Default: 2 secs
> DB_Retry_Interval = 2
> #Section: Notif_Param
> #Contains config values for resource notification parameters.
> [Notif_Param]
> #Key: Notif_Type
> #Value : Alarm / Alert
> #Alarm : Generates notification once for each threshold cross over for the monitored entity.
> #Alert : Generates notification on each polling interval for the monitored entity only if above threshold mark.
> #Default: Alarm
> Notif_Type = Alarm
> #Key: Notif_Poll_Interval
> #Notification poll interval (mins) to examine the state of the monitored entity.
> #Range : 1 - 1440 mins
> #If threshold configuration is disabled then default: 0 (Disable: No notification)
> #If threshold configuration is enabled then default: 1
> Notif_Poll_Interval = 1
> #Key: Notif_Retry_Interval
> #Notification retry interval (secs)
> #Range : 1 - 60 secs
> #Default: 20 secs
> Notif_Retry_Interval = 20
> #Key:Notif_Retry_Count
> #Notification retry count
> #Range : 1 - 5
> #Default: 3
> Notif_Retry_Count = 3
> #Key: Notif_GCDR_File_Period
> #Enables Alarm / Alert to be sent for files older than given period in mins
> #Note : Even though name of this parameter contains GCDR, this parameter is equally applicable to all type of CDRs supported by GSS
> #Range : 1 - 7*24*60 mins
> #Default: 15
> Notif_GCDR_File_Period = 15
> #Key: Notif_CPU_Usage
> #Enables Alarm / Alert to be sent for system cpu usage in %.
> #Range : 0 - 100 %
> #Default: 60
> Notif_CPU_Usage = 60
> #Key: Notif_Mem_Usage
> #Enables Alarm / Alert to be sent for system swap usage in MB.
> #Range : 0 - ULONG_MAX (MB)
> #Default: 9500
> Notif_Mem_Usage = 9500
> #Key: Enable_Cluster_Alarms
> #Flag to indicate whether to enable cluster notifications.
> #Value : yes/no
> #Default: no
> Enable_Cluster_Alarms = y
> #Key: Cluster_Path
> #Path to installed cluster components.
> #This has to be valid path.
> #Value : Cluster path string
> #Default: /usr/cluster/bin
> Cluster_Path = /usr/cluster/bin
> Key: Cluster_Name
> #Cluster name string set during installation. Please do not edit this field.
> #Default : No default
> Cluster_Name = GSS_HA
> #Key: Cluster_Node_List
> #Cluster nodes list string set during installation. Please do not edit this field.
> #Default : No default
> Cluster_Node_List = clustems2,clustems1
> #Key: Cluster_Node_Count
> #Cluster node count.
> #Default : 0
> Cluster_Node_Count = 2
> #Key: Notif_Disk_Usage
> #Enables Alarm / Alert to be sent
> #if available disk size(GB) falls below configured limit.
> #Range : 0 - ULONG_MAX (GB)
> #Default: 199
> Notif_Disk_Usage = 199
> #Section: Log_Param
> #Contains config values for logging and status.
> [Log_Param]
> #Key Show_Status
> #Show status periodically (secs)
> #Range : 0 - ULONG_MAX secs
> #Default: 300 secs
> #0 - Disables
> Show_Status = 300
> #Key: Print_IO_Msg
> #Prints I/O messages to log
> #Value : yes /no
> #Default: no
> Print_IO_Msg = no
> #Key: Audit_File_Size
> #Audit log file size
> #minimum 2500 kbytes
> #default 2500 kbytes
> Audit_File_Size = 2500
> Troubleshooting the GSS
> This section provides some basic troubleshooting tips that can be referred to in the event of any failure of the GSS application.
> Problems During Installation
> During the installation process, if you receive error messages such as:
> syntax error near unexpected token

> Step 1 | Check the version of the OS by entering the following command:

> uname - a

> Step 2 | Check the version of the bash by entering the following command:

> /bin/bash -version
> The OS must be greater than or equal to Solaris 9 and the bash version should be 3 or higher.
> If you do not have the correct server operating system software, contact your sales representative.
> Problems Managing a Cluster Node
> These following commands can only be issued from the console on a cluster node and the user must have root privileges.
> Cluster console commands are accessed from the /<clus_install_dir>/gss directory.
> Check Status of Node in Cluster
> There are several commands that can confirm node status. The first lists the resource group, the nodes within the group and the status of the nodes. The second command provides a more detailed display of the cluster resource group.
> clresourcegroup status
> scstat
> Change to Stand-alone Mode - Cluster Console Command
> This command MUST be entered from the console. It terminates GSS operations and switches the node from Cluster mode to Stand-alone mode:
> shutdown
> At the ‘ok’ prompt, enter:
> boot -x
> GSS/FileGen/PostgreSQL Not Running
> Begin by confirming what processes are running on the server.
> GSS/FileGen Status
> ps -ef | grep gss
> Minimally, the resulting display should include information similar to the following:
> 0 15052 07:23:25 TS 59 0:00 /<install_dir>/gss/bin/gssfilegen
> 0 15062 07:23:25 TS 59 0:00 /<install_dir>/gss/bin/gss
> The above information indicates that both GSS and FileGen are running.
> If you do not receive similar information, then you need to start GSS which will automatically start GSS, FileGen, PostgreSQL, and PSMON.

> • | Stand-alone Node - enter the following command:

> cd /<install_dir>/gss
> ./GSS start
> If GSS fails to start, then contact your sales representative.

> • | GSS Node in Cluster - enter the following command:

> cd /<install_dir>/gss
> clresourcegroup manage <Resource Group>
> clresourcegroup online -n <nodename> -eM <Resource Group>
> If GSS fails to start, then contact your sales representative.
> PostgreSQL Status
> ps -ef | grep postgres
> Minimally, the resulting display should include information similar to the following:
> postgres 15080 14972 0 07:23:25 ? 0:00 /<install_dir>/ postgres/bin/postgres -D
> The above information indicates that PostgreSQL is running.

> • | Stand-alone Node - If you do not receive similar information, then you need to restart the GSS stand-alone node which will automatically start the GSS, FileGen, PostgreSQL, and PSMON. To restart GSS on stand-alone node, refer to Accessing GSS Commands section.

> • | GSS Node in Cluster - If you do not receive similar information, then you need to restart the GSS node which will automatically stop all processes and then start the GSS, FileGen, PostgreSQL, and PSMON. To restart GSS on a cluster node, refer to Accessing GSS Commands section.

> Support Detail Logs for Debugging
> If you encounter problems with GSS and need to seek assistance from customer support, you may be asked to send them support detail logs which are generated with the SupportDetail utility script. This script runs system commands and captures the output and resulting logs in an XML file.
> The SupportDetails utility is found in the <gss_install_dir>/gss/tools/supportdetails directory. There is also a README file that provides details about the use of the script.

> Step 1 | From the root directory, change to the /<gss_install_dir>/gss/tools/supportdetails directory.

> Step 2 | Check the command syntax:

> ./getSupportDetails.pl --help

> Step 3 | Run the script:

> ./getSupportDetails.pl --level=<number>
> <number> specifies the level of debug actions to run. There are four levels:

> • | Level 1 generates a simple status log and collects the GSS configuration file.

> • | Level 2 collects Level 1 information plus

> • | any available database logs

> • | information about current the Solaris version and installed patches

> • | information about the hard disk partitioning

> • | Level 3 collects Level 1 and 2 information plus the system configuration file and messages files stored in /var/adm.

> • | Level 4 is the most comprehensive and includes all Level 1, 2, and 3 information and all logs of the current node, plus

> • | information about all packages installed

> • | traces of any crash files (if debugger installed)

> • | output of the following commands: ipcs, ps -eaf, scstat, prtdiag

> The README file provides a complete description of the levels.
> The script generates a zipped file, gsssupportDetails.tar.gz and puts it in /tmp/log directory. You can e-mail this gzip to customer support for debugging purposes. This information will provide them with a quick but fairly complete view of the status of your system and the configuration.

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