Getting Started

Overview

Cortex gives you web based management of all of today’s most popular games. Game servers, called “engines” in Cortex are installed to a central location. Copies of these engines can be assigned to users you create or to the administrative user. These engine copies are called “instances”. When a user configures, stops, or starts a game server they’re working with game instances, not the engine itself. Cortex also has the ability to run system diagnostics, network diagnostics, create custom news posts, and skin its interface.

 

Logging In

Cortex is powered by a custom configured Apache distribution. As of version 1.13 Cortex listens for both HTTP and HTTP-SSL connections. To log into Cortex head to one of the following addresses in your web browser:

http://<your server IP address>:8365/
https://<your server’s IP address>:8366/

By default Cortex listens on all IP addresses on your server if you are running a multihomed system.

The Cortex Administrator’s username is “admin”. The administrative password should match your system administrator or root account’s password. Enter this username and password in the form provided then click the Login icon to get started using Cortex. There is a checkbox to save your login password if you choose to do so. If your password does not work on your first time logging in please contact Insomnia365 to verify your password was set correctly.

Changing your system root or Administrator password will not change your Cortex admin password. See the troubleshooting section of this manual for how to change your Cortex admin password.

 

The Cortex Layout

Upon logging in you will be brought to the news page. All messages from Insomnia365’s staff will appear here. Administrators can be kept up to speed on Cortex and game updates through the news page.

Cortex’s layout is divided into three main sections: The main menu, the status bar, and the main data area. The main menu shows all options available to the administrator to configure Cortex, the server it runs on, Cortex users, engines, and instances. The status bar shows your current position within Cortex as well as any status or error messages generated by Cortex.

Initial Setup

The first time you log in you’ll be brought to the System Configuration page. This page is described in detail in a later chapter, but two clustering settings and your email settings must be entered before you can begin using Cortex.

The server name and corresponding location will help you identify your server in a Cortex cluster. These are arbitrary names, although it's helpful that the server name corresponds to this system’s hostname. The location can be any value you choose, e.g.: “Dallas, TX”, or the name of the datacenter this server is located in. This information is required even if you do not plan on running a Cortex cluster. These values are used quite a bit throughout Cortex. More on clustering is explained in the clustering section. After entering your server's name and location click the Save icon next to these fields.

System events help notify you when certain functions are performed by Cortex. In order for outgoing email notifications to work you must enter a valid From: email address into the General Settings form. All messages that Cortex sends to you and your users will appear as from this address. Once entered hit the Save button and you're ready to start using Cortex!

Engines

How Engines Work

All game servers are installed to your server as engines before they can be assigned to users.

Engine management is handled on the engines page in Cortex. Click the “Engines” link in the main menu to access the engines page. This page allows you to install, remove, and update any game that Cortex supports on any server in your cluster. All games that Cortex supports are displayed in alphabetical order along with their current version, which server they’re installed on, a link to their homepage, and a small game description. The engines page is grouped with four parent engines plus their child engines per page. Use the previous and next buttons at the top of the engines list to scroll through the engines list.

Some games require that other games are installed before they may be installed. For instance Call of Duty: United Offensive requires Call of Duty installed and Counter-Strike requires Half-Life installed first. These engines are grouped together.

Engines are greyed out on this page until they are installed on one of your servers in your cluster.

 

If you want to host a game that is not supported by Cortex yet you can still install it the old-fashioned way via Remote Desktop or SSH. Check your game’s documentation for how to install a dedicated server. Contact Insomnia365 to see if we can add the game into Cortex!

 

Installing Engines

Click the install checkbox next to the server and engine you wish to add then click next. Cortex will redirect you to a page which displays real-time download and installation info. Engine packages, with some exceptions, are downloaded directly from the from the Cortex update server. The installation process displays how much it has downloaded and the approximate speed at which it’s downloading the game. Many of these games can be quite large, even approaching 4 gigabytes in size, so please be patient while it downloads. After your game downloads Cortex will extract it into its engines directory. If there are updates available for your game then Cortex will download and apply them as well. Once this is complete click the continue icon to return to the engines page.

Games based on the Half-Life and Half-Life 2 engines are downloaded from the Steam network, not the Cortex update server. It may take some time to download an hlds or srcds based server depending on the game you’re installing and the state of the steam network. The network can become rather congested if Valve has recently updated one of their games. Cortex will keep trying to connect to the Steam network until it makes a valid connection and can download your game engine.

 

Uninstalling Engines

On the Engines page click the uninstall checkbox next to the engine you wish to remove and click next. Cortex will remove the engine and return you to the engines page.

Removing an engine will delete all instances of that engine. Make sure you know what you’re doing before removing an engine!

 

Updating Engines

When a game update is released the Cortex developers will take it and repackage it for the Cortex update server. This process can take up to 3 days in some situations, but generally games updates are available in Cortex within 24 hours of their official release. Most times updates are ready within hours of their official release.

When a game update is available the Update checkbox for it in the engine list will be enabled. Select the update checkbox for your engine and click next. Cortex will download and process the update. The update process screen is akin to engine installation: a real-time download and extraction report. After the engine is updated Cortex will perform a file comparison with the engine and any installed instances of that engine and update instance files as needed to match the newly updated engine. Once the update is complete click the continue icon to go back to the engines page.

If any instances of an engine are running then Cortex will stop those instances during the engine update process.

 

Just like when installing a Half-Life or Half-Life 2 based game all content comes from the Steam network. The Steam network tends to get overloaded after hlds and srcds updates are released. This will cause your update to progress slower than usual. Cortex will try to download the update up to three times before giving up. If the Steam network is too congested you may have to try applying the update again later.

 

Updating Cortex

If a Cortex update is available the engines page will only provide the option to update Cortex. Click the update icon to update Cortex to the most recent version. Once Cortex is updated you can continue working with your other engines. Check your Cortex home page for any new version release notes from the Insomnia365 development team.

Users

Users

Cortex allows server administrators to assign game instances to users created within Cortex. This will help keep your servers separated, and your users will only have control of the game instances you assign to them. Cortex users are local to Cortex only.

Use the Users page to create, edit, and delete your Cortex users. The Users page shows all users per server on the cluster. Clicking the expand (+) icon next to a user’s name will display that user’s info and forms to edit or delete that user. To prevent damage to the admin account you will not be able to edit the admin user from the Users page. Please use the admin user’s profile page to make changes to the admin account.

 

Users in Cortex do not have login privileges to the system itself, only the Cortex control panel. If you want to create system users you must create them from the OS itself. System users do not have login privileges to Cortex. Please consult your OS documentation for instructions on how to create a system user.

 

Adding Users

Click the add icon in the upper-right hand corner of the box for the server on the cluster that you want to add a user to. Fill out the next form with the following information:

Username	The login name for your new user.
Password Confirm Password	Your new user’s password. The password must match the password confirmation.
Email Address First Name Last Name Address Primary Number Secondary Number Aim Icq Msn	Your user's personal information. This is here for your records only and is not reported back to Insomnia365. You must enter a valid email address if this user will receive any event email from Cortex.
Comments	A note about the user. Eg: “clan =ABC= admin” or “Temporary account”.
Skin	The skin the user will see once they’re logged in.
Creation Mode	You have the ability to create the user on every server in your cluster or just the server you’re logged into. If you create a user across a cluster they will be able to log into all servers on the cluster, and you can create game instances for that user on any server on the cluster.
Admin Privileges	Check this box to give your user administrative permissions on the server/cluster. This will let the user execute any functions within Cortex with two exceptions: They will not be able to reset the admin account password, and they will not be able to view or edit game instances assigned to the admin user.
Display I365 News	If this is unchecked then this user will only see news local to the system on the Cortex home page. They will not see any news that comes from the Cortex update server.
Filter News Engines	Users with this option enabled will only see news on the Cortex home page that pertains to games they have installed. For example: if this is checked and the user has Counter-Strike and Enemy Territory instances they will only see news with the CS 1.6 and ET logos on the home page.

All fields marked with a * are required to continue. Click the add icon and Cortex will add the user and redirect you to the users page. Your new user will be inserted into a group with the same name as the login name of your user.

Editing Users

Click the expand (+) icon next to your user’s name. Next click the edit icon for the user to edit their profile. This form displays all options from the add user form with one addition: the option to make your user changes on the local server or across the entire cluster. Click the save icon to save your changes and return you to the users page.

 

Password Control

You can change a user’s password via the edit password form on the user’s page. Click the expand (+) icon next to the user’s username to get to this form. As with editing user information you can change this password for the local machine or across the cluster. Click the save icon to apply the new password and return to the users page.

 

User Access

Click the View Access icon next to an expanded user to view his or her access rights on the server. This is a view only form. If you want to change your user's access levels edit the group they belong to.

 

User Linking

If you are running a Cortex Cluster you have the option of linking two users’ instances together. This will give your user complete control over another user’s instances and your remote user control of your current user’s instances. It is possible to link more than two users together. Clicking the link icon for a user will load a page with available servers in your cluster to link to. Select a server in your cluster and hit next. Now select which user on that cluster to link to. Click the save icon to link your two users together.

Once two users are linked the link will show in the user’s details on the Users page. To remove the link, click the unlink icon to the right of the linked user’s name. This will separate the users back into two separate entities and each user will only have control over their own instances.

Removing Users

Click the delete icon next to an expanded user to remove the user form your Cortex system. This will remove the user, all of their instances, and unlink them from any users on the cluster.

 

You cannot undo this, so make sure you’re absolutely sure you want to remove your user before cli

 

Groups

Groups

Cortex allows server administrators to group users together to assign the same system permissions to more than one user. This is a great way to give a group of people control over the same instance, for example. Users are automatically assigned to their own group when they are created by the admin. A user's default group name matches the user's username. You can assign a single user to multiple groups, but each user must at least be assigned to it's original group.

Use the Groups page to create, edit, delete, and manage your Cortex user groups. The Groups page shows all groups per server on the cluster. Click the expand (+) icon next to a group’s name to display that groups’s members and forms to edit or delete that group.

 

Adding Groups

Click the add icon in the upper-right hand corner of the box for the server on the cluster that you want to add a group to. Fill out the next form with the following information:

 

Name	The name of your new group.
Details	A description of the group, eg. "Clan =ABC= Admins".

All fields are required to continue. Click the add icon and Cortex will add the group and redirect you to the groups page.

 

Editing Groups

Click the expand (+) icon next to your group’s name. Next click the edit icon to edit your group's information. This form displays all options on the add group form. Click the save icon to save your changes and return to the groups page.

 

Changing Access

Click the Edit Access icon next to an expanded group to set it's permission level on your server. Permission levels are quite extensive and are covered in their own page of the manual.

 

Adding Group Members

Click the Add user to group link at the bottom of your group's member list to add a new user to that group. A form will load with a drop-down list of users on the system not already in that group. Select your user and click the Add icon to add it to your group. Once added your browser will reload the groups page.

 

Removing Groups

Click the delete icon next to an expanded group to remove it from your Cortex system.

 

You cannot undo this, so make sure you’re absolutely sure you want to remove your group before clicking the delete icon!

 

Permissions

In an effort to give your users finer control over the system and their game servers Cortex sports a robust permissions system. Using this system you can give access to nearly any part of Cortex's functionality to any user or group. If a user doesn't have permissions to perform a function then the icon or form object to that function is hidden in cortex. For example, if you disable a user's filebrowser to an instance then they won't see it's icon on the Instances page. Permissions are assigned on the Groups page, but are viewable per user on the Users page, and give you access to a wide range of functions:

Engine Permissions

The top of the permissions page shows the user or group's permissions per game engine. Click the expand icon next to an engine to access permissions for that engine. Users have the ability to do the following:

 

• Install: Install the engine.
• Uninstall: Uninstall the engine.
• Update: Update the engine:
• Add instances of the engine for him or herself.
• Add instances of the engine for anyone on the system.
• Set a ceiling on the maximum amount of players allowed on their instances of this engine. This is limited to the maximum player value of the engine.

 

News Permissions

Give users access to the following news functions:

 

• Add news articles.
• Add news articles under the "custom" engine. The custom engine is defined in your skin as the engine used in news posts for news articles related to your company, clan, or group.
• Edit any news article.
• Edit only news articles that were created by that user.
• Delete any news article.
• Delete only news articles that were created by that user.

 

Clustering Permissions

The following clustering options are supported for users:

 

• Add a server to to your cluster.
• Remove a server from your cluster.

 

User Administration Permissions

Your user can have control over the other users on the system.

 

• Add a user.
• Remove a user.
• Link users across your cluster.
• Unlink users on a cluster.
• Modify group permissions.
• Change a user's skin only.
• Modify others user's entire profiles.

 

Skin Permissions

If you choose your users or groups can work with the skins on the system as well:

 

• Add a skin to the server.
• Remove skins.
• Edit a skin.
• Set the system default skin.

 

System Settings Permissions

Nearly every system setting available in Cortex can be assigned to a user or group. Please give these permissions only to users that you trust.

Clustering Settings

• Update clustering name and location.
• Enable or disable the high-resolution timer.

Network Settings

• Change Server Hostname
• Add an IP address
• Remove IP addresses
• Change DNS resolvers.

Email Settings

• Change General Settings.
• Add an email template.
• Edit email templates.
• Remove email templates.
• Change event recipients.
• Change event templates.
• Enable or disable event messages.
• Change the email threshold. This affects how many messages per minute Cortex can send out.

System Restart

• Reboot the system. Be careful when assigning access to this.

 

System Status Permissions

Limit your users access to view your server's system state. You can choose to show or not show them the following options:

 

• CPU use
• RAM use
• Network use
• Disk Use
• Engine disk usage

 

Network Tools Permissions

By default all users can run all network diagnostics. If you choose you can limit what kind of tests they can run:

 

• Only allow the user to run tests against their own IP address.
• Allow ping testing
• Allow tracerouting
• Allow nslookup DNS resolution
• Allow whois lookups.

 

Miscellaneous Permissions

There are various restrictions you can also place on your users. You can:

 

• Allow or disallow FTP access.
• Allow the user to add instances to the "admin" user's account. Usually only the admin account can do this.
• Set a maximum number of instances the user can run at once. This is useful if you need to conserve system resources. Setting this to 0 disables the limit.
• Allow a user to view news posts made by Insomnia365's staff.
• Enable superadmin privileges. This gives your user the exact same privileges as the "admin" user. Be careful to assign this only to users that you trust.
• Enable subadmin priveleges. Subadmins have all administrative privileges on the system with the exception of viewing and editing the "admin" user's instances.
• Allow them to update their own profile.

 

Instance Permissions

Cortex lets you restrict access to nearly any instance function. Access is assigned per instance. Use the Select Instance drop down menu to select which instance you want to view or assign access to. The page will refresh showing the correct instance. Cortex lets you enable or limit access to the following instance functions. Actions marked with an asterisk (*) are usually admin only actions.

General Permissions

• Activate the instance.*
• Deactivate the instance.*
• Delete the instance.*
• Start the instance.
• Stop the instance.
• View the Event Log.
• Check the instance's history graphs.
• Use Cortex's remote console.
• View instance status. If this is disabled then your user or group cannot view the ip, port, current map, hostname, and number of players conencted to your instance on the instances page.
• Kick in-game users via the status page.
• Ban in-game users via the status page.

Map Permissions

• Apply a map rotation.
• Modify the current rotation's map order.
• Add a map to the rotation
• Remove a map from the rotation.
• Upload a map to the server.
• Remove custom maps from the server.
• Create new map rotations.
• Remove map rotations.
• Change map rotations.

Configuration Permissions

• View the RCON password.
• Edit the RCON password.
• Edit the instances max player value.*
• View the instance's command line.*
• Edit the instance's command line.*
• View instance comments.*
• Edit the instance's comment.*
• Transfer the instance to another server on your cluster.*
• Change the instance's IP address.*
• Change the instance's port.*
• Change the instance's processor affinity.*
• Create a new configuration.
• Change active configurations.
• Delete configurations.
• Export the current configuration to the browser.
• Save the current configuration to a local file.
• View the basic config form.
• Edit the basic config form.
• View the advanced config form.
• Edit the advanced config form.
• View admin level cvars in the config form.*
• Edit admin level cvars in the config form.*
• Import configs.

File Browser Permissions

• Enable or disable the filebrowser.* If you disable the filebrowser then your user won't see this instance on the FTP server.
• Create .zip archives.
• Create directories.
• Download files.
• Extract .zip files.
• Create text files.
• Copy files.
• Delete files.
• Edit text files within Cortex.
• Move files.
• Rename files.
• View files within Cortex.
• Upload files.

Plugin Permissions

• Activate plugins.
• Deactivate plugins.
• Install plugins.*
• Remove plugins.*

 

Instances

How Instances Work

Once an engine is installed you can start assigning copies of it to you or your admin users. These instances are what you and your clients will actually play on. Cortex gives many options to customize and manage these instances for you.

Click the Instances link in the main menu to bring up the instances page. When logged in as the admin this page will show every game instance set up on your cluster. Regular users will only see the instances the admin has assigned to them. Users with admin privileges can see and configure any instance on the cluster except those belonging to the admin user.

This page is sectioned off by user on the cluster. Beneath each user is a tally of how many instances each user has installed, how many are activated, and how many are running. All deactivated instances will be greyed out on this page. Each instance on this page shows the game logo on the left, current runtime information in the middle, and options per instance on the right. The current runtime information is queried from the server itself and shows the following:

 

Address	The IP and port the server is listening on. This is the address your clients will use when they want to connect to thier game servers.
Web Administration	If the server has a built in web based configuration system, like TeamSpeak's web administration, then this link will direct you to that administration page.
Players online	The number of players currently on the server. This will read "N/A" if the server is not running.
Hostname	The hostname of the server set in it's configuration file. This will read "N/A" if the server is not running.
Map	The map currently running on the server. This will read "N/A" if the server is not running.
Memory Use	The amount of RAM the server is currently using. This is measured in megabytes and will read "N/A" if the server is not running.

The options per instance allow you to customize and manage your game instance to your liking. These options are described in detail below and in the Cortex User Manual.

Adding Instances

Click the add image in the top-right hand corner of the user you want to add an instance for. This opens a multi-step form. Fill out each of the following fields. The form should reload itself to the next step, but if it doesn't click the next button to continue.

 

Engine	The engine of the game or voice server you want to install for your user. This list includes every engine installed on your cluster. If you don't see your engine in this list check the engines page to make sure it's installed.
Server	Select which server in your cluster you want this instance to go on. This list shows the server name, how many instances are currently running on that server, and how many instances are installed on that server.
IP Address	The next list shows which IP addresses are available on your server to put this instance on.
Port	A list of ports available to put the game on. Cortex reserves 5 ports in sequence form the default game port per IP per game. If no ports are available go back one step and select another IP address.
Disk	The disk or volume you want to install this server onto. If your server has multiple disk drives you can configure them for use in Cortex on the System Configuration page.
Name	The name of your server. This is not the server hostname, but merely a name to identify it to Cortex.
Rcon Password	The rcon password for your server. This will be the admin login password if you're installing a Teamspeak instance.
Max Players	The maximum amount of players you want this instance to support. There are limits to this number. For instance F.E.A.R. supports up to 16 players, while Battlefield 2 can run up to 64 players.
Comments	General comments on this server for your use. This has no effect on gameplay.

Note that the name, rcon password, max players, and comments are filled out in the same step. Once the form is complete click the next icon. Cortex will verify that the resources for this game exist on the system and then prompt you continue making the instance. Click the continue icon to create the instance.

Cortex goes through a process to convert an engine into an instance. Depending on your server's operating system and the game file that's transferred Cortex may do one of four things to the file:

 

• Copy the file: many files that contain game data need to be copied from the engine's directory to your instance's directory in order to function.
• Hardlink the file: Many data files don't need a specific copy in the instance to run. Windows servers hardlink these files to save disk space.
• Symlink the file: This is the default file action for Linux servers. Symlinking the file can preserve a great deal of file space.
• Ignore the file: Certain files that are controlled by Cortex, such as config files, are best left ignored and created by Cortex itself.

Once the instance is done installing click the continue button to return to the instances page. The new instance will now be on the system in a deactivated state.

Activating and Deactivating Instances

An instance can be disabled or enabled through the use of the activate and deactivate buttons. A deactivated instance cannot be configured or used by any users on the system and must be activated before it can be used. These functions tie into the operating systems that control the instances. Activating an instance activates the OS service that powers that instance, allowing it to run as a daemon and start on system boot.

 

Disabling an instance does not remove any custom configuration or files from the instance.

 

Instance Editing for Admins

Admin level users have more instance editing options than standard users. Click the edit config button for your instance to see them. They are located at the top of the next form. Check the instances chapter of the Cortex User Manual for information on the standard instance editing options. Admins have the ability to edit the following:

 

• Change the max amount of players that the server can handle
• Customize the game server's startup command line. Use the command line additions to add extra directives into your instance's command line. These options get added in front of the standard command line options. So for instance if your command line is:

Quake4Ded.exe +exec server.cfg +si_gametype 'DM' +si_map mp/q4dm8 +spawnServer +set net_serverDedicated 1 +set net_ip 10.5.1.207 +set net_port 28004 +set fs_savepath C:\i365\instances\admin\quake4_server +set fs_basepath C:\i365\instances\admin\quake4_server

and you want to add the variable "+set fs_game q4max" to load the Q4Max mod, add it to the command line additions field. The resulting command line will look like this:

Quake4Ded.exe +set fs_game q4max +exec server.cfg +si_gametype 'DM' +si_map mp/q4dm8 +spawnServer +set net_serverDedicated 1 +set net_ip 10.5.1.207 +set net_port 28004 +set fs_savepath C:\i365\instances\admin\quake4_server +set fs_basepath C:\i365\instances\admin\quake4_server

Click the save icon when editing either of the three above options. Bear in mind that saving any of these options will restart your instance.

 

• Enable or disable the filebrowser in case you don't want your users to have direct access to the instance's files through Cortex
• Change the internal comment for the server
• Transfer the instance to another server on your cluster. Clicking next after selecting your new server will load up a form for which IP address to place your server on. Clicking next after that will load a form to choose your port. Click next one last time to transfer the instance to your other server. You can only transfer instances to servers that have a user linked to the instance's current owner. Check the users chapter for more information on user linking. A real time page displays the instance transfer status. Once the instance is transferred click continue to return to the instances page.
• Change the server's IP address. Select your new IP address and click next. A new port form will load next with ports available for this game on your new IP address. Select your new port and hit next to save your new IP address and port.
• Change the server's port on the current IP address. Select your new port and click the next button to save the new port.
• Set the server's processor affinity. Systems with dual-core, multi-processor, or processors that use Intel's Hyper-Threading technology report more than one processor to your Operating System. The OS is usually responsible for choosing which CPU will run your game server, but it's possible to choose which processor, or set affinity, per instance in Cortex. Click the checkbox next to the CPUs that you want the instance to run on. By default all CPU's are checked, which means that the OS will choose wich CPU to run the game server on from all processors. If you only check one CPU then the instance will only run on that CPU. If you check more than one then the server's OS will run the instance on one of the checked processors. After selecting your CPU affinity click the save button to return to the edit config page. You need to restart your instance after making these changes.

Admin users also have the ability to install 3rd party Plugins on an instance if they are available. If plugins are available for an instance an Edit Plugins icon will appear next to it on the instances page. Click that button to bring up that instance's plugin page. Click the Install button for the plugin you wish to install, and your user will be able to enable, disable, and configure them on their server.

 

Removing Instances

Click the delete icon for the server you wish to delete and click the OK button to confirm the deletion. Your instance including all configs, custom data, and custom maps will be removed from the server.

 

You cannot undo this, so please be certain you want to remove your instance when you delete it!

 

Clustering

How Clustering Works

Once you get enough game servers going you can exceed the resources of a single server and need another server to keep going. To help game administrators manage multiple physical servers Cortex sports a clustering feature. Clustering is how Cortex servers communicate amongst each other. Once two or more servers are clustered Cortex can set up any engine, instance, news post, skin, user, or anything else Cortex controls on any server in that cluster. This gives the administrator the ability to manage multiple Cortex servers from a single web interface on any of the servers in his cluster. Clustering is a web style of communication as opposed to a series of master-slaves relationships. If one server goes down the cluster will still function, and once the downed server comes back up it will naturally re-integrate itself into the cluster.

Clustering is handled by the clustering page. It's meant to give you a quick rundown of the servers in your cluster and the state of your cluster. Each server is marked with an icon representing whether it is running the Windows or RedHat Linux operating systems. The name and location of the server matches what you entered when you first set up Cortex on your server. Simple hardware and instance states are listed on each server. If you need to log into Cortex on that server itself then a link is provided for you.

 

Cortex adds the word "Localhost" to the name of the server in the cluster that you're currently logged into.

 

Creating a Cluster

The bottom of the clustering page contains the form to add a server into your cluster. Simply enter the IP address of the system and the Cortex admin account password for that server and click the Link button. The servers will contact each other and add themselves into each others cluster.

This feature can be used to merge two Cortex clusters together. Add the IP of any server on your remote cluster into the form on a server in your local cluster and click Link to have the two clusters merge into one larger cluster.

 

 

Removing Servers From Your Cluster

Click the Unlink icon next to the server you want to remove from the cluster. Cortex will break the clustering link and return the server to a standalone state.

 

Removing a server from the cluster only drops the communications link between that server and the Cortex cluster. All remote instances, users, skins, news posts, etc still exist on the server.

 

Skins

Skins

Changing the Cortex interface is a convenient way to rearrange the layout or rebrand the Cortex look and feel to your liking. Skinning and skin packaging is explained in much greater detail in the skinning guide.

The skins page displays all skins installed on your Cortex cluster along with forms to edit, delete them, or set them as the system default skin along with a list of servers in the cluster that the skin is installed on. Skins marked with an asterisk are the default skin for that server.

Cortex ships with two default skins. One called “Cortex”, which is the default skin. The other is a debranded version of the default skin which does not contain the Insomnia365 logo.

 

While it is possible to edit the default Cortex skins directly on the server we highly recommend against it. The Cortex and debranded skins are frequently changed when a Cortex update is released. Any changes made to these skins are overwritten after an update. Please copy, package, and install your custom skin through the skin utilities to keep them safe.

 

Adding Skins

Underneath the skin list on the skins page is the form to add a skin to your server or cluster. Fill out the following information:

 

Name	The name of the skin.
Background color	The skin controls all pages served by Cortex except for the real-time pages such as engine installation, network tools and the like. The background color is a hexadecimal #RRGGBB color for these real-time pages.
Skin File	Click browse and locate the skin file on your local computer to upload. Under the add form are a series of guidelines the skin file must follow. This is explained in further detail in the Cortex skinning guide.
Server	Select which server to add the skin to, or choose to add it to all servers.

Click the add icon to upload the skin to your Cortex server. If you choose to add it on a remote cluster node Cortex will transfer the file to the other nodes. Once this is complete the skins page will refresh with the new skin in the skin list.

 

Editing Skins

Click the edit skin icon next to the skin you wish to edit to bring up the edit skin form. This form is identical to the add skin form with the exception that any skin changes you make will replicated across your Cortex cluster. If you have made any changes to the skin files themselves you will need to re upload your skin package here. Click save to update the skin on the cluster and return to the skins page.

The skin edit form is not available for the default Cortex skin.

 

Setting the Default Skin

If you have more than one skin installed on the server you can assign one of them to be the default system skin. If a user has their own skin assigned to them they will see that skin after logging into Cortex. Cortex chooses which skin to display for the user by first checking the user's default skin. If no user default skin is set then it will display the system default, which is set here.

To set a default system skin, click the set default icon next to your desired skin. On the next page check which servers you want to assign the skin to and click continue. Cortex will set your default skin then return you to the skins page

 

If your new default skin has a bug in it and renders Cortex unusable check our troubleshooting section for how to reset your skin!

 

Removing Skins

Click the delete icon next to the skin you want to remove. Cortex will bring you to a page asking which server you want to remove the skin from. Check the appropriate boxes and hit continue. Cortex will then remove the skin from your selected servers and reassign user skins to the default skin for any users that used this skin. Once this is complete you’ll be brought back to the skinning page.

The delete icon is grayed out and unusable for the default Cortex skin.

News and Announcements

How News Works

The Cortex home page contains news items collected from the Cortex update server. These news posts are usually written by the Cortex development staff. Administrators can add their own posts to the home pages of their Cortex servers via the News Administration system.

Click the News Admin link in the main menu to bring up the news administration page. This page shows a history of custom news posts on servers across your Cortex cluster along with the form to add a new post and a quick settings form for post formatting. Only the admin or users with administrative privileges may access the news administration page.

 

Creating a News Post

The middle of the news administration page contains the form to add your own news post. Fill out the form with the following information:

 

Subject	The title of your news post.
Body	Your news post. This can either be plain text, BBCode, or HTML if you are allowing HTML in your news posts. Note that it may be possible to break Cortex's home page with malformed HTML, so use it sparingly.
Engine	If your post pertains to a particular game engine you can select it in this dropdown box to have your news post marked with that engine's picture. Selecting "Cortex" will show the Cortex logo in your news post. The "Custom" option in this list will add your custom logo to the news post. The custom logo is explained further in the Skinning Manual.
Servers	Select which server or servers in your cluster you want this news post to appear on. You can select any number of servers in this list or all of them, but you must select at least one server.

Click the Add button to create the news post across your server and cluster.

 

Editing a Post

At the top of the News Administration page, find your news posting in the list and click the Edit link next to it to make changes. Cortex will then reload the admin page and allow you to edit the post. You can edit the subject, body and/or engine logo. Click on Save to save your changes.

 

Note that if you created the same post accross a cluster you will not be able to edit that post on the whole cluster, but on individual servers within the cluster.

 

Deleting a Post

At the top of the News Administration page, find your news posting in the list and click the Delete link next to it to delete the post. Cortex will then ask you to confirm the deletion. When you click OK, the post will be removed from the server.

 

As with editing posts if you created the same post accross a cluster you will not be able to edit that post on the whole cluster, but on individual servers within the cluster. You cannot undo post deletions, so be sure you're absolutely sure you want to delete your post before clicking Delete!

 

News Settings

The form at the bottom of the news administration page instructs Cortex how to interpret news posts. Set your preference on Cortex interpreting HTML in your posts here. Click the Save button to write your changes into the Cortex database.

 

The Cortex RSS Feed

News posts from Cortex's upgate server are also available as an RSS feed. Point your RSS reader to the url feed://update.insomnia365.com/rss.php to keep in touch with all news coming from the update server. It's possible to filter the feed based on engine by adding the ?engine variable to the URL. Right now the engine variable can be set to the following:

 

aa	Americas Army
bf1942	Battlefield 1942
bf2	Battlefield 2
bfvietnam	Battlefield Vietnam
cod	Call of Duty
cod_uo	Call of Duty: United Offensive
cod2	Call of Duty 2
cortex	Cortex
cstrike	Counter-Strike
cstrikes	Counter-Strike: Source
czero	Condition Zero
dc_final	Desert Combat Final
dod	Day of Defeat
fear	F.E.A.R.
halo	Halo
hlds	Half-Life
mohaa	Medal of Honor: Allied Assault
mohbt	Medal of Honor Allied Assault: Breakthrough
mohpa	Medal of Honor: Pacific Assault
mohsh	Medal of Honor Allied Assault: Spearhead
ns	Natural-Selection
rtcw	Return to Castle Wolfenstein
rtcw_et	RTCW: Enemy Territory
sof2	Soldier of Fortune II
srcds	Half-Life 2
tfc	Team Fortress Classic
ts	Teamspeak
ut2003	Unreal Tournament 2003
ut2004	Unreal Tournament 2004
xpack	BF2: Special Forces
XPack1	The Road to Rome
XPack2	Secret Weapons of WWII

For example the URL to view only news related to Cortex is feed://update.insomnia365.com/rss.php?engine=cortex while the URL to view only Battlefield 2 related news is feed://update.insomnia365.com/rss.php?engine=bf2.

Changing System Settings

Clustering Settings

The clustering daemon controls how Cortex servers communicate with each other. There isn't much to set in order for clustering to run, and this should have been set during your initial setup, but you can change these fields at any time after installing.

 

Server Name	Your server's name on the cluster. This is an arbitrary name and doesn't need to match the system hostname, although it helps.
Server Location	Where this server is located. Again this is arbitrary and can be anything you want, but if you have multiple servers in many locations it will be quite helpful to identify them by where they are located.

Click the save button to commit your changes. Changes happen on the fly, and you do not need to restart the clustering daemon after saving.

 

The High Resolution Timer

Servers running Microsoft Windows have the option to enable use of the Windows high resolution timer within the clustering daemon. The high resolution timer is a piece of the Windows OS that handles high performance I/O from multimedia applications such as Windows Media Player and the Macromedia Flash Player. Game servers based on the Half-Life and Source engines also utilize the high resolution timer. Enabling the high resolution timer can give you up to a 500% increase in game server performance at the expense of overall CPU usage. Enable this if you run a small handful of Half-Life or Source based games. If you do not run hlds or srcds servers or host a large amount of games in a mixed environment it's best to leave this disabled.

 

Network Settings

Cortex gives you rudimentary control over your server's network settings.

 

Setting the Hostname

Your server identifies itself internally and on its local network by it's hostname. Cortex lets you change the system hostname at your leisure. This is the equivalent of editing the necessary lines of /etc/sysconfig/network file in RedHat Linux or by changing the computer name in Microsoft Windows. Fill out the form with the following information:

 

Hostname

Your server's hostname. This defaults to the name chosen when ordering the server.

Click the save icon to save your system hostname. If your server runs the Microsoft Windows operating system then you must reboot it for the change to take effect.

 

IP Addressing

In the middle of the Network Settings tab is a list of IP addresses currently bound to the system and in use by Cortex. If you order more IP addresses from Insomnia365 or your reseller you can add them one by one on this form. You may also delete unused IP addresses as well, though it's recommended you don't remove IPs unless there is a compelling and necessary reason to do so.

IP addresses and their subnet masks must be added to the system in dotted quad format (aa.bb.cc.dd). Cortex will return an error message if it detects an invalid IP address. Adding new IP addresses inserts the IP into the Cortex backend database and binds the new address to your server's network interface and restarts your server's networking stack. You may see a few seconds of lost connectivity when adding new IP addresses to the system.

 

In order to prevent the administrator from harming the system Cortex will not let you delete the first IP address assigned to your network interface. Please contact Insomnia365 if you need this address changed or removed.

 

System Monitoring

If your server has more than one network interface you may need to select one to use to monitor instance network usage. Network usage is calculated on these interfaces to display on your instance's history graphs. Click the Enabled checkbox next to the interfaces you want to monitor on and click the Save button to enable monitoring on a network interface.

If you recently added, removed, or changed network interfaces in your server you will need to update Cortex with the changes. Click the button next to Check for network changes to update your interface list.

 

DNS Resolvers

Though not essential for game server operation working DNS servers in your server's network configuration can ease overall system operation. These DNS addresses are what your server use for local name resolution. They default to The Planet's addresses, but you can change them to whatever you like. Note that entering invalid DNS server addresses can cause unexpected system problems, so be sure you're adding the right addresses before hitting the add button.

 

As with adding IP addresses, changing DNS servers requires that Cortex restarts your server's networking stack. You may see a few seconds of network loss to the server after changing DNS addresses.

Email Settings

Cortex has the ability to notify you and your users via email when certain events are triggered by you, your users, or the game instances running on your system. The Email Settings tab of the System Configuration page is where you can customize these emails. These settings apply to the local server only and are not sent accross your cluster. There is a dropdown box in the top-right hand corner of this window for you to change email settings on a remote server.

 

General Settings

This form applies to all email that Cortex sends when an event is triggered:

 

From:	The email address that all Cortex event messages are sent from. You must set this when you first use Cortex. Note that error messages may display in Cortex when events are triggered and an invalid From address is given.
Reply-To:	Optional: An address to use when users reply to Cortex generated messages.
Cc:	Optional: Who to carbon copy the event mail in every Cortex generated message. This must be a properly formatted email address.
Bcc:	Optional:Who to blind carbon copy the event mail in every Cortex generated message. This must be a properly formatted email address.
Signature	Optional: A bit of text appended to the bottom of every message sent by Cortex.
Enabled	If unchecked, then Cortex will not send any email when an event is triggered. Uncheck this if you want to disable event messaging.

Click the save icon to save these settings.

 

Message Templates

Message templates are the text of the email messages along with the intended recipients to send to when an event triggers. Cortex comes with a number of templates by default which you are unable to edit, but you can add your own to get your custom templates going. Select any template in the select template to load it into the edit templates form or select "Add new template" to create a new template. The page reloads with the following form:

 

Name	The name of the template. You'll use this name when you select your template for an event.
Subject	The subject of the email sent when messages using this template are sent.
Contents	The body of the email sent when messages using this template are sent.

Click the save icon to add or save your template into Cortex.

 

Events

Once your templates are created you need to assign them to events. Events are actions triggered when Cortex performs a function, such as updating an engine or adding a new user. When an event is triggered Cortex sends an email to the addresses specified in the event with the text of the template selected for the event, and if applicable creates a log event for the instance the event applies to. Cortex generates events for the following actions:

 

• When a new user is created.
• When a user's information is edited by the admin.
• When a user is deleted.
• When an instance is created.
• When an instance is activated.
• When an instance is deactivated.
• When an instance is deleted.
• When an instance is started.
• When an instance is stopped.
• When an instance crashes or shuts down unexpectedly. This is handled by the script that restarts game instances after they crash.
• When an engine is updated.
• When the system is rebooted by the reboot function.

Select an event to configure in the Events drop down field on the events form to load that event into the configuration page. The event form has the following options:

 

Events	The event you're configuring.
Template	The template to use when sending email for this event.
To:	Who to send the event mail to. This must be a properly formatted email address.
Cc:	Optional: Who to carbon copy the event mail to. This must be a properly formatted email address.
Bcc:	Optional:Who to blind carbon copy the event mail to. This must be a properly formatted email address.
Enabled	Check this to enable the event. If the event is disabled then no email message nor Instance log will be generated when this event is triggered.
Message wait time	In order to prevent Cortex from flooding you and your users' inboxes with event messages you can limit the amount of time that must pass before two event emails are sent. This value defaults to 5 minutes for each event.

Click the save icon to save your event changes in Cortex.

 

Template and Event Objects

Templates and events employ a special syntax to help you customize an event email to specific users, engines, instances, and much more. Enter the following text into your template subject, template body or event To:, Cc:, or Bcc: fields and cortex will replace them with their corresponding equivalents. The following objects are specific to message templates:

 

• {USER_NAME}: The username of the user affected by the event. This refers to the instance owner if the event is instance related.
• {USER_EMAIL}: The email address of the user affected by the event. This refers to the instance owner if the event is instance related.
• {USER_FNAME}: The first name of the user affected by the event. This refers to the instance owner if the event is instance related.
• {USER_LNAME}: The last name of the user affected by the event. This refers to the instance owner if the event is instance related.
• {USER_PASSWORD}: The password of the user affected by the event. This sends a user password in plain text via email, which is inherently very insecure. Know these risks when emailing a user their password.
• {ADMIN_EMAIL}: The email address of the admin user.
• {INSTANCE_NAME}: The name of the affected instance, if applicable.
• {INSTANCE_IP}: The IP address of the affected instance, if applicable.
• {INSTANCE_PORT}: The port the affected instance is bound to, if applicable.
• {SERVER_IP}: The primary IP address of your Cortex server.
• {DATE_Ymd}: The current date and time. The text "Ymd" in this object can be replaced with any string that works with the PHP date() function's format parameter.

The following objects relate to events. Note that they pertain to who an event gets emailed to:

 

• {USER_EMAIL}: The email address of the user affected by the event. This refers to the instance owner if the event is instance related.
• {ADMIN_EMAIL}: The email address of the admin user.
• {ALL_USERS}: All Cortex users on the local system. This does not email all users on the cluster.
• {AFFECTED_USERS}: All users affected by an event,
• {SERVER_ADMINS}: The addresses of all users on the system with admin level accounts.

 

Disk Settings

Cortex lets you install game instances on any of your server's hard drives or disk partitions. By default only the primary drive is set up in Cortex. To allow Cortex to install game servers onto your other drives fill out the form on Disk Settings tab of the System Configuration page.

 

Label	The name of the drive as reported to the Operating System, for example "C:", "D:", or "/".
Utilization	The amount of space in use on the disk followed by the total space on the disk and disk usage percentage.
Name	A name to assign to the disk in Cortex. This will make it easier to determine which disk is which when adding instances to the system.
Path	The path on the disk to install instances on. Instances are installed to the instances/username/instrance directory on the disk. For example, if drive D: is set up on the system and has the path "cortex" then instances on D: will be installed to D:\cortex\instances\username\instancename.
Enabled	If checked then Cortex will allow you to install game instances on this drive or partition. Leave this unchecked for partitions like /boot and /tmp.

Click the save icon to save your drive changes. If you have added a new drive or changed drive letters or mountpoints on your hard drives click the button next to Check for disk changes to have Cortex resync it's database with your current drive structure.

 

Rebooting the System

A reboot can be beneficial when you've exhausted all of your options when troubleshooting a server issue. The reboot function in Cortex will reboot the system one minute after you click the reboot button. The server may take a few minutes to shut down and boot, and Cortex and your game instances will be inaccessible while it is down. Remember that Cortex will auto restart your running game servers when it comes back up, so you don't need to restart every instance on the system.

Checking System Status

When troubleshooting a problem it helps to have a real-time view of the state of your server. Click the System Status link on the main menu to load a page showing the current status of your Cortex server.

Select which server in your cluster you want to check status on and click the Continue icon to get started. The page may take a few seconds to load. Once loaded the page will display the following:

 

• CPU usage
• RAM usage
• Hard drive/mountpoint usage
• Disk usage of each engine installed
• Network usage

 

Systems using Intel processors with Hyper-Threading enabled will show up as one physical and one virtual processor to the Operating system. This means single processor Pentium 4 systems will show two processors and dual Xeon based systems will show four processors on the CPU graph if HT is enabled.