The i365 User

All daemons powered by Cortex are executed on the system by the user i365 which belongs to the group i365. This user account exists only to run these services and is not given a login shell. The i365 user's password is randomly generated when Cortex is installed. Since Cortex handles low level tasks such as networking settings and rebooting the i365 user has root level access to certain commands:

• /sbin/mii-tool: used in determining network link speed
• /sbin/service: used to stop and start game instances
• /bin/hostname: used to determine the system hostname during network configuration
• /sbin/shutdown: used in Cortex's reboot function
• /sbin/ifup: used during network configuration
• /sbin/ifdown: used during network configuration
• /sbin/chkconfig: used to install and uninstall game instance services
• /bin/bash /usr/local/i365/bin/fix_init_dir.sh: used to reset the /etc/init.d/ directory permissions in the case that the initscripts package is updated by root

For security reasons it is best to avoid giving the i365 user a valid login shell or reset it's password. Doing so may open your system up to intrusion.

Additional Packages

The Linux version of Cortex installs additional packages onto the system that are required to keep it and it's game instances running:

• GNU Screen: All instances run under their own screen session. The name of each screen session closely matches the name of the directory for each instance; converting non-alphanumeric characters to underscores, changing all characters to lowercase, and adding "i365-" to the beginning of each session. For example, if the user "-=CTF|Bill=-" has an instance called "[CTF]Match" the sereen session name for it will be i365-__ctf_bill__-_ctf_match.
• Sudo: The i365 system user requires root level access to certain programs in order for Cortex to properly control the system. Sudo gives this low level access to the i365 user. Please note that this gives the i365 user certain liberties with the system, and the i365 user should not be given a valid login shell for security reasons.
• perl-DBI, perl-CGI: These packages are required for the RPM install of Cortex's web server.
• OpenSSL: This is likely already installed on the system, but Cortex verifies it's RPM is installed so it can create the SSL certificate for secure access to the Crotex web server.

Cortex services

The cortexd Service

Unlike the Windows version of Cortex, a single service called cortexd controlls all of the Cortex daemons. Use the service cortexd stop command to stop Cortex:

[root@host ~]# service cortexd stop
Stopping Cortex-httpd:                                     [  OK  ]
Stopping Cortex-MySQL:                                     [  OK  ]
Stopping Cortex-Clustering:                                [  OK  ]
Stopping Cortex-ftp:                                       [  OK  ]

Use the service cortexd start command to start Cortex:

[root@host ~]# service cortexd start
Starting Cortex-httpd:                                     [  OK  ]
Starting Cortex-MySQL:                                     [  OK  ]
Starting Cortex-Clustering:                                [  OK  ]
Starting Cortex-ftp:                                       [  OK  ]

The cortexd service also has a restart option to stop then restart Cortex. Cortex's service script also allows you to restart some of the individual daemons controlled by Cortex. Pass the dameons "ftp", "clustering", or "monitoring" to the start or stop commands to stop or start only one of these daemons.

[root@host ~]# service cortexd
Usage: /etc/init.d/cortexd { {start|stop{ftp|clustering|monitor} }|restart}

Instance Services

Game instances each have their own sevice installed by Cortex. The service name for each instance corresponds to it's screen session name; converting non-alphanumeric characters to underscores, changing all characters to lowercase, and adding "i365-" to the beginning of each session. For example, if the user "-=CTF|Bill=-" has an instance called "[CTF]Match" the service name for it will be i365-__ctf_bill__-_ctf_match. Cortex itself issues the /sbin/service command to start and stop these services. These services accept the stop, start, and restart options.

Each instance service is controlled by two shell scripts located in user directories in the bin/ directory. One script is responsible for keeping up the loop that auto-restarts your game servers and handles crash event reporting. The other manages the screen session per instance.

While it is possible to start and stop game servers driectly from the system console we recommend against it as Cortex is not notified when these services are stopped or started. This may cause problems if, for instance, in the case where Cortex has an instance as started, but was manually stopped via the command line.

Filesystem Differences

The Cortex root directory in Linux is /usr/local/i365. There are a number of files and directories specific to the Linux version of Cortex:

• The bin/ directory contains the php executable and a number of helper scripts that are described in detail in the next section.
• The etc/ directory contains the web server's configuration file and the Cortex license file.
• A mono/ directory exists in Linux so Cortex can run .NET based apps such as BF2CC in mono.
• A var/ directory exists to hold mySQL table data from Cortex's database server. Database errors are also collected here.
• The Zend/ directory contains the Linux version of the Zend Optimizer.

Maintenance in Linux

Setting the Admin Password

In times where you forget the Cortex admin user's password you can easily reset the password with the bin/set_admin_password.sh script.

[root@host ~]# /usr/local/i365/bin/set_admin_password.sh 

This scripts reset the local Cortex admin user's password. This should 
be used in the case that the local admin password is forgotten.

Usage: /usr/local/i365/bin/set_admin_password.sh <password>

  password The admin user's new password.

Resetting the Skin

If you or one of your users uploaded a bad skin and set it to the default skin, rendering Cortex unusable, it is possible to manually set it back to the default skin with the bin/reset_skin.sh script.

[root@host ~]# /usr/local/i365/bin/reset_skin.sh --help

Invalid option: --help
This script resets the local Cortex server to use the default skin.
This should be used in the case that the curent skin is broken and 
Cortex needs to be reset to regain access. The admin's skin is reset 
to the Cortex default skin as well.

Usage: /usr/local/i365/bin/reset_skin.sh [all]

  all   Reset all local user skins to the Cortex default skin as well.

Restarting the Clustering Daemon

If it appears that Clustering is not working right or giving errors you may want to restart the Clustering Daemon without restarting all of Cortex's services.

[root@host ~]# kill `ps -eo user,pid,cmd | grep ^i365 | grep "listen.php" | awk '{print $2}'`
[root@host ~]# su -c "/usr/local/i365/bin/start_clustering.sh" - i365

Fixing the Service Directory

If Cortex gives you errors about being unable to create, delete, stop, or stop services then the i365 user may not have necessary permissions to the /etc/init.d directory. Run the script /usr/local/i365/bin/fix_init_dir.sh to correct this. It is normal for this script to output nothing on success.

[root@host ~]# /usr/local/i365/bin/fix_init_dir.sh 
[root@host ~]#