SConnector Howto

From SCInterface Wiki

Jump to: navigation, search

Contents

Intro

What is an SConnector you might ask? An SCInterface Connector (SConnector) is basically how we define the interactions between SCInterface and applications or devices of a given type. In the SConnector configuration, you will define commands that can be run on applications or devices of that type, the location of configuration files that SCInterface will let you access, command-line parameters that are typically used when spawning an instance as well as the alterconfigs, where you can define how to abstract the configuration of key parameters from config files.

Inheritance

The SConnectors are organized in a tree structure, where a given sconnector will be a child of some other sconnector , with one exception being the root node of our tree. This logical structure permits us to define generic stuff higher in the tree and let them be shared by all sub-types, such as generic start,status and stop commands for linux servers running in a screen and so on. The Macros will be inherited by name, meaning that to override or redefine a command, just create one with the same name, but for your subtype. Config file tokens will simply pile up, as well as alter configs and command-line parameters.

The following section describes how to write an SConnector with SCInterface. It is highly recommended to review this entire document before continuing in order to understand how an SConnector works.

Main SConnector Edit

In this screen, you will see a list of parameters that help SCInterface differentiate an sconnector from another.

  • Mandatory Fields
    • SConnector Name : Name as it will appear when browsing sconnectors or choosing one when adding a new instance/game/device
    • Version : Version info about this sconnector. Currently only used when displaying sconnector information
    • Default Executable : The path to the start script or binary relative to the installation path.
    • Category : Verbose information, displayed on sconnector information screens
    • Default Port : Default value for the 'port' parameter when adding a new instance.
    • Platform : Where this can run. This sconnector will only be available for install on SCs that support this platform. (windows sconnectors for windows hosts, etc..)
    • Parent: SConnector from which to inherit values. Counter-Strike would inherit from Half-Life which would inherit from linux game servers, or something similar.
    • Owner: Which user is allowed to manage this sconnector (in addition to any of his parent users and system administrators)
  • Optional Fields
    • Installer Path: name of archive to be used by installer for instances of this type. Do not include webserver url or file extension as the macro already takes care of adding in the appropriate file extension where necessary.
    • Scan Port: Extra port that can be used by 3rd-party game 'scanners', in this case qstat to fetch information about this server. Only put something here if it's different from the 'port'. Examples would be for Battlefield servers, where the server's main port is something like 14567 but the query/scan port be 23000.
    • Scan Command: If qstat can scan this app, qstat followed by the arguments used to scan it and <address>:<port>. If qstat is installed and runnable on the webserver hosting your interface, you will see runtime information in your game server status page as a result of running this command.
    • Private Pattern: currently not in use, but basically how to know if a server is private or public, by matching this string from the server rules output from the qstat command (normally something like ',password=')

Macros / Commands

Macros (also called 'commands') define how SCInterface invokes commands on your instances. It basically consists of a name, privileges required to run this action and a script to be run when invoking this action. This script will be invoked from the host of your game server or device, on your game server or device. Typical macros will be the start,status or stop ones that will define how to respectively start the server, check if it's running and stop it. It doesn't stop there, whatever your game server lets you do, SCInterface can do for you. These scripts can be written in whatever scripting language can run on your host, typically tcl,perl,python,sh,csh,php and wsh/vbs.

Your macros can be used to change the status of your device or simply poll your server or device for information, your choice! If you are polling, any text outputted by your script will be returned to SCInterface to either display when running in real-time mode or store when running from the scheduler or monitors section.

The following provides an overview for writing an SConnector macro on Linux or Windows within SCInterface.

The Installer Macro

The automatic installer is one of those things that make SCInterface a great product, as you can have it automatically download and install your game server or application prior to using it. You will see options to run the installer from the config/serverstatus page, from the server edit and add server pages as well as the commands section for your server. This is a macro like any others, which simply pulls down an installer for your sconnector and installs the server by extracting the contents of the archive. To help manage this, the installer needs to know which installer to use, and SCInterface will take care of feeding it a name unique to that sconnector (called installer_path in the sconnector add/edit sections).

If your archive for half-life is located at http://myserver.com/mygamearchives/linux/hl.tar.gz, then the installer_path would be 'hl' for that sconnector. Next you will need to configure the install macro to use your host as a download host. This is done by finding the 'Install' macro in your SConnector's macro section, going into the 'default parameters' section (look at the top of the window) and setting the 'downloadHosts' value to your list of urls. The url here would be everything up to but excluding /hl.tar.gz, so 'http://myserver.com/mygamearchives/linux'

Creating or Modifying existing Macros

The following section describes how to create new macros and edit existing macros to run your very own custom commands within SCInterface.

CAUTION: It is highly recommended to make a backup of your SCM's PostgreSQL database prior to creating or modifying existing macros within SCInterface. Any changes to these macros cannot be un-done. If you need to update to the default SConnectors to reset your macros (in the event that they get messed up), you can update your SConnectors to the latest version.

Choose a Scripting Language

First you must choose a scripting language to write your macro. Here, you are only limited by the languages supported by your system. For hosts using the Java client (windows), this parameter will actually be used by spawning the proper interpreter at runtime, whereas clients using the C++ SC are free to write their scripts like they would unix-style, by putting the good ol' #! parameter on the first line of the script.

Some Linux examples : 

tcl/expect: #!/usr/bin/expect -f 
perl: #!/usr/bin/perl
bash: #!/bin/bash

Some Windows examples : 

Set WshShell = WScript.CreateObject("WScript.Shell")

tracesite = "~##sitetotraceroute##~"

toExec = "tracert " & tracesite
set oExec = WshShell.Exec(toExec)
errors = oExec.StdErr.ReadAll()
output = oExec.StdOut.ReadAll()

retCode = oExec.ExitCode

WScript.Echo output

The ~##sitetotraceroute##~ is an SCInterface macro parameter that the SCM and the UI use to define default values or pass optional parameters from the UI to the macro prior to the macro being invoked.

Macro Rules
  • The macro must exit with a return value. An exit 0 means success while an exit 1 means failure. This is necessary to report back whether or not the macro failed to execute properly.
  • Any output to the console during the execution of the macro will be gathered and returned.
  • A macro should define its proper return type (console output to expect)
Macro Parameters

To insert a parameter into a script, use the special syntax: ~##parametername##~

Macro parameters are populated in the following order:

  1. The special hardcoded ones that get pulled from the db are retrieved first
    1. these are: address, port, cwd, defaultExe, screenName and maxPlayers:
      • address : address parameter associated with this server (as seen when adding or modifying this server)
      • cwd : current working directory.
      • port : port associated with this server
      • defaultExe : start script or binary used to start this server, pulled from the sconnector configurations
      • screenName : unique identifier that can be use to name screens (for the 'screen' utility), or named services in windows. Typically 'app' followed by the internal SCInterface deviceID associated with this server or device.
      • maxPlayers : value associated 'max slots' for this server.
    2. you can use these knowing they'll be populated by the db value associated with the app you are running the macro on
  2. The parameters present in the default_params table are populated (Macros->Edit Macro->Default Parameters). The most specific of these four options is chosen for each parameter since there may be multiple entries:
    1. for any user on any device [least specific]
    2. per user on any device (globally for that macro)
    3. per device (for any user)
    4. per user on one device [most specific]
  3. params sent from the UI are populated

Parameters defined on the latter steps will overwrite the former values, but as of right now, if you use a hardcoded db (#1) param in the macro, they are special in that they are not sent to the UI as required to run the macro, because they are typically only used in start/stop/status and so we don't want the UI to complain about a required param not being sent when a user initiates an action button such as start. In other words, if you aren't sure or if you need the ability to override these, make up your own param name and don't use these reserved ones.

Macro Permissions

The permissions you select for a macro will restrict certain users from gaining access to the macro. A user must have at least all of the permissions associated with the macro to actually run it.

Macro Timeout

The timeout value defines how long the SCM will wait for the macro to return before the socket closes.

Modifying the Admin Interface with Macros

Defining the following Macros on a particular SC will make the Admin area of the web UI render differently. These macros are:

  1. defaultAppDisabledFields - SC Macro
  2. generateAppUser - SC Macro
  3. defaultAppUser - SC Macro
  4. defaultExecPath - SC Macro

NOTE: All of these macros *must* belong to the SC and not the application. Otherwise, these macros will not be invoked when running the 'New App' wizard.

defaultAppDisabledFields - SC Macro

This macro affects the way the Admin area of the UI is rendered for the 'Adding' or 'Editing' an Application or Device. It supresses the fields within the HTML forms for those values that are returned.

defaultAppDisabledFields - Variables that can be set

This macro disables and enabled fields within the 'Application' area (i.e. 'Add New App', 'Edit App' and 'View App' under Admin):

Mandatory Fields that can be surpressed/disabled:

  • INSTALL_FILES_AND_DEFAULT_CONFIG_SETTINGS
  • MAXIMUM_SLOTS
  • STATUS_CACHE_INTERVAL
  • SERVER_TYPE
  • SYSTEM_USER
  • OWNER
  • EXEC_PATH
  • CREATE_DIR
  • PORT
  • ADDRESS
  • SERVERNAME

Optional Fields that can be surpressed/disabled:

  • CONFIG_DIR
  • MONITOR_SETTINGS
  • ABS_PATH_TO_EXE
  • ALTER_CONFIG
  • FORCED_PARAMS
  • STARTUP_PARAMATERS
  • MD5_CHECKSUM
  • SHELL
  • FTP_PASSWORD
  • SCAN_PORT
  • STARTUP_ACTION

Special disabling fields:

These fields will disnable certain areas within the admin interface as a whole when called from within this macro:

  • DISABLE_CONFIG_WITHIN_ADMIN - This will allow administrators to edit their application (v2.2.3 or later) from the configuration area only.
defaultAppDisabledFields - Example Macro

The following will tell the UI to disable the Scan Port and Startup Action fields. 

#!/bin/sh
 
 echo "SCAN_PORT,STARTUP_ACTION"
defaultAppDisabledFields - Example Return Values

SCAN_PORT,STARTUP_ACTION

generateAppUser - SC Macro

This macro affects the way the Admin area of the UI is rendered for the 'Adding' or 'Editing' an Application or Device. This macro will run only if defaultAppUser - SC Macro is not present or does not return anything. This will dynamically create a username when adding an application or device.

generateAppUser - Return Values

A string of 8 random characters.

The macro for this command is included by default within the Linux SC macro.

defaultAppUser - SC Macro

This macro overrides #generateAppUser - SC Macro. This macro affects the way the Admin area of the UI is rendered for the 'Adding' or 'Editing' an Application or Device. If present, this macro will define the default user for a macro.

defaultAppUser - Variables that can be set

<username>,<enable|disable>

  1. enable will check the 'create user' check box
  2. enable will deselect the 'create user' check box by default
defaultAppUser - Example Macro
#!/bin/sh
 
 echo "myuser,enable"
defaultAppUser - Example Return Values

myuser,enable

defaultExecPath - SC Macro

This macro affects the way the Admin area of the UI is rendered for the 'Adding' or 'Editing' an Application or Device. If present, this defines the default installation path for an application on a given SC type.

defaultExecPath - Variables that can be set

<directory>,<enable|disable>

  1. enable will check the 'create directory' check box
  2. enable will deselect the 'create directory' check box by default
defaultExecPath - Example Macro

This is an example macro that would run on Linux. 

#!/bin/sh
 
 echo "/tmp/mydirectory,enable"
defaultExecPath - Example Return Values

/tmp/mydirectory,enable

Special Cases and Status Condition

The special cases parameter lets you designate this macro for automatic integration into the at-a-glance page.

  • Include in status : This macro will be run whenever a status request is made for your server or device. The ui doesn't currently show this information, but we have plans for it in the future.
  • Default Status : like 'Include in Status', this macro will be run, but the results will be displayed and also used to determinate the 'suggested' action. I.e. if the status macros says that the server is down, then your suggested action (displayed on at-a-glance and most of the config pages) will be to invoke the start macro to start the server. There can only be one Default Status per sconnector. Inherited ones (with different names) will be seen as 'Include in status'.
  • Default Action + Status Condition : This condition will be evaluated against the return value of the default status macro and if there is a match, this macro would be the one displayed as the suggested action (usually 'start' or 'stop', but can be anything else).

Macro Return Type

A Macro should define its proper return type. This corresponds to the value that the macro puts out on the console. This is used to render certain things in the UI, such as graphs for the int return type.

  • string (default) : Text is outputted by the macro
  • int : A single integer is output from the macro (ie. temperature)
  • statusType : A more complex return value interpreted by SCInterface to report status as such:
    • 0 - started
    • 1 - stopped
    • 2 - disabled
    • 3 - n/a

Default Parameters

You might want to be able to have default parameters for given macros, so that when going into the commands area, they be autopopulated or if invoked otherwise from within scinterface, they wouldn't need user input. This is done by having 'Default Parameters', which can be assigned to any macro, and their scope can be on one or all servers, as well as one or all users. For instance, in the Install macro, the downloadHosts parameter is already populated with some file servers provided by SCInterface. If you want to have or add your own in there, simply modify the defaultParam configured for all hosts, or add a new one should you want one of your servers to use a different set of download servers.


Alter Configs

Alter Configs define the configuration settings that can be edited under the Configuration -> Alter Config section of the Config area for a given application or device.

The Configuration Alteration Engine is a way to define how to quickly change configurations on your server by associating an 'alterconfig' with a set of files and what to change in these files. Basically, you will provide which file(s) to parse and what to look for. For instance, if the servername is defined in configs/server.cfg on a line that looks like servername = 'myServer' , then the paramName would be serverName, the filename configs/server.cfg, the match servername = and the replacement be servername = '~##servername##~' . Just like with Macros, Alter Configs used the ~## syntax to do a replacement for a string that is defined. 99% of the time, more than one ~## variable should not be defined within a single Alter Config. This will confuse SCInterface and only one string will be searched for when the replacement takes place. Basically, any ~##paramName##~ will be displayed as a parameter when navigating to the alter-config area and offer the user a text box where they can see the current value in their configs and change it to whatever they want.

To summarize, an Alter Config takes the content of configuration files (such as .txt, .cfg, etc. files) and renders the Config section for an Application as a simple Input or dropdown box.

The required fields are:

  1. Parameter Name:
  2. Filename:
  3. Match:
  4. Replace:
  5. Database Option:

Alter Configs - Database Option

Also referred to as the DB, DB Option, or the Database Option, the Database Option for an Alter Config will invoke this alter config if one of the following fields in the Edit section of the SConnector is set:

  1. serverName (param: ~##serverName##~)
  2. numSlots (param: ~##numSlots##~)
  3. address (param: ~##address##~)
  4. port (param: ~##port##~)
  5. scanport (param: ~##port##~)
  6. Private (param: ~##setPrivate##~)
  7. Public (param: ~##setPublic##~)

Specifying one of these ~## variables within a given alter config will force the configuration file to be modified whenenver these properties for this application or device are modified.

Alter Configs - Database Option - Example
Filename Match Replace DB
System/server.ini NumberOfPlayers= NumberOfPlayers=~##numSlots##~ yes

Notice that DB is set to yes. Database Option enabled Alter Configs can only be edited by those individuals with Admin permissions.

Alter Configs - Single Input

Create a single Alter Config input box can be generated by filling in the fields for the Alter Config once.

Alter Configs - Single Input - Example
Filename Match Replace DB
System/server.ini TimeLimit= TimeLimit=~##TimeLimit##~ no
Alter Configs - Single Input and Modify More than One File - Example
Filename Match Replace DB
System/server.ini TimeLimit= TimeLimit=~##TimeLimit##~ no
System/file2.ini MyTimeLimit= MyTimeLimit=~##TimeLimit##~ no

Alter Configs - Dropdown

An Alter Configs dropdown menu can be created by defining multiple Match and Replace strings within a given Alter Config.

Alter Configs - Dropdown - Example
Filename Match Replace DB
System/server.ini TimeLimit= TimeLimit=5 no
System/server.ini TimeLimit= TimeLimit=40 no
System/server.ini TimeLimit= TimeLimit=45 no
System/server.ini TimeLimit= TimeLimit=60 no
System/server.ini TimeLimit= TimeLimit=35 no
System/server.ini TimeLimit= TimeLimit=10 no
System/server.ini TimeLimit= TimeLimit=15 no
System/server.ini TimeLimit= TimeLimit=20 no
System/server.ini TimeLimit= TimeLimit=25 no
System/server.ini TimeLimit= TimeLimit=30 no
System/server.ini TimeLimit= TimeLimit=~##TimeLimit##~ no

Startup Params

Startup Params define the startup parameters that can be edited under the Configuration -> Parameters section of the Config area for a given application or device. Startup Params are the default startup parameters that the user can select from the Config area of the application or device.

Startup parameters will let you define how the application will be launched by automatically providing a ~##parameters##~ value to the start macro when invoking it (see Startup Params - Hard coded variables). At runtime / when configuring your server, the user parameters (defined in this section) will be shown as a set of radio buttons or pull-downs and if the user has admin privs on the server, he will also be offered a text area to define 'forced parameters' where they can add any other unlisted command-line parameters.

When adding a parameter, you will be shown 4 fields : 'Parameter Type' , 'Value' , 'Description' and 'Order' .

  1. Parameter Type : This is the name that will be associated with your parameter. For a parameter to be seen as a choice between multiple values, you need to add multiple entries with the same parameter type. The pull-down below the text field will help you select an already-existing type should you simply want to add more options to an already existing parameter. Different parameters with the same type will thus be mutually exclusive.
  2. Value : What to actually add to the list of parameters when invoking your application via the command-line interface.
  3. Description : A Description of this value, simply for display.
  4. Order : Where to put the parameter when building the list of parameters, parameters with a lower value will be put first. This is typically for game servers or applications where the order of the arguments actually matters. One example could be for Counter-Strike where the '-game cstrike' must come before any '+exec configfile.cfg' statements.
  5. Notes:
    • No implicit blanks : There are no implicit blanks, so if you want your parameter to be optional, you must provide a blank parameter : just add a parameter with the same type but with no value.
    • Forced Parameters : Since there are no implicit blanks, you can force a parameter to always be used on all instances of this type. This is great if you want to automatically force something like '+ip_address ~##address##~' (see Startup Params - Hard coded variables), which would always invoke your instance with that parameter and the address field defined for that instance.

Startup Params - Hard coded variables

These special hardcoded ~##variables##~ that get pulled from the database are retrieved first and can be specified within a startup parameter. These are:

  • address : address parameter associated with this server (as seen when adding or modifying this server).
  • port : port associated with this server.
  • scanport : scan port associated with this server.
  • numSlots : value associated 'max slots' for this server.

Startup Params - Single Input

Create a single Startup Params input box can be generated by filling in the fields for the Startup Params once.

Startup Params - Single Input - Example
Value Description
log=server.log Name for the server status log file. This log file is erased and recreated every time the server is started.

Startup Params - Dropdown

A Startup Params dropdown menu can be created by defining multiple parameters within a given Startup Param.

Startup Params - Dropdown - Example
Value Description
GLOBAL Game server will show within the in-game browser
LAN Only appear on the LAN in-game browser

Config Tokens

Config Tokens define the files that can be edited under the Configuration section of the Config area for a given application or device.

Configuration file tokens tell SCInterface where the config files are located within a typical installation of this server. The syntax is similar to what is used when you run 'ls' or 'dir' from the base of your server installation on your filesystem. The '*' character can be used to symbolize 'anything'. Examples here can be : '*/*cfg' to mean any file whose name ends with 'cfg' located in any subfolder immediately below the base path. If your base path is /home/doodle and the config file would be in /home/doodle/configs/server.cfg, then 'configs/server.cfg', 'configs/*cfg', '*/*cfg' are all examples of tokens that would pick this file up. These results are used in the config area of your instances.

Config Token - Example

Configuration Tokens Viewable By
System/server.ini Everyone
System/*.txt Admin

Status Page

The Status Page is responsible for how the Config page for the SConnector is render. This includes the (1) tabs that are displayed and (2) the content of what goes on the page of the Config -> Overview tab.

The following provides an overview of modifying the Config interface of the PHP UI using XML that is defined within the SConnector's Status Page. This XML string defines:

  1. The Tabs that are rendered on the Config page.
  2. The content of the overview page.

Each SConnector has an XML Status page that renders the tabs and content of the Config section of the PHP UI. This is to allow the Config area to dyanmically render based on the application type. This feature is available as of SCInterface 2.2. To modify this XML string:

  1. Login to the PHP UI.
  2. Click Admin -> SConnectors tab.
  3. Edit the SConnector that you wish to modify for the configuration page.
  4. Click on the Status Page tab.

Displaying Monitor Graphs

To enable or disable the displaying of the monitor graphs in the overview page, a special tag called showwhich has to be set within the XML.

In the infopage tag where id="overview", add showwhich="value" where value => one of 'NONE', 'ACTIVE', 'INACTIVE' or 'ALL'

Only SCs or applications that have a Monitor enabled with actual data will be able to display these values.

Status Page Example #1 - All Tabs

The following is the default status page that SCInterface will render if no XML is placed within the Status Page. Placing the following XML within the Status Page for the SConnector will have the same affect as leaving the Status Page blank. 

<sconnectorInfo>
 <infopage name="constant(OVERVIEW)" title="constant(OVERVIEW_TITLE)" id="overview" url="serverdetail.php?appid=$serverID" showwhich="All"/>
 <infopage name="constant(CONFIGURATION)" title="constant(CONFIG_TITLE)" id="config" url="serverdetail-config.php?appID=$serverID"/>
 <infopage name="constant(FILE_TRANSFER)" title="constant(FILE_TRANSFER_TITLE)" id="ftp" url="serverdetail-ftp.php?appID=$serverID"/>
 <infopage name="constant(MACROS)" title="constant(MACROS_TITLE)" id="macros" url="macros.php?appID=$serverID"/>
 <infopage name="constant(CONSOLE)" title="constant(CONSOLE_TITLE)" id="console" url="console.php?appID=$serverID"/>
 <infopage name="constant(LOGS)" title="constant(LOGS_TITLE)" id="log" url="serverdetail-log.php?appID=$serverID"/>
</sconnectorInfo>

Status Page Example #2 - Remove a Tab

The following is an example of ommitting the file manager from the configuration section. 

<sconnectorInfo>
 <infopage name="constant(OVERVIEW)" title="constant(OVERVIEW_TITLE)" id="overview" url="serverdetail.php?appid=$serverID" showwhich="All"/>
 <infopage name="constant(CONFIGURATION)" title="constant(CONFIG_TITLE)" id="config" url="serverdetail-config.php?appID=$serverID"/>
 <infopage name="constant(MACROS)" title="constant(MACROS_TITLE)" id="macros" url="macros.php?appID=$serverID"/>
 <infopage name="constant(CONSOLE)" title="constant(CONSOLE_TITLE)" id="console" url="console.php?appID=$serverID"/>
 <infopage name="constant(LOGS)" title="constant(LOGS_TITLE)" id="log" url="serverdetail-log.php?appID=$serverID"/>
</sconnectorInfo>

Notice that the following string is missing: 

<infopage name="constant(FILE_TRANSFER)" title="constant(FILE_TRANSFER_TITLE)" id="file_transfer" url="serverdetail-ftp.php?appID=$serverID"/>

This is what prevents the File Transfer tab from being displayed.

Status Page Example #3 - Teamspeak Status Page

This is a more advanced version of the configuration page that also renders macros within the user interface for an application called Teamspeak 2.

  • This status page will render additional tables within the Overview area of the Teamspeak 2 server.
  • Notice that the File Transfer tab section is missing. 
<sconnectorInfo>
 <infopage name="constant(OVERVIEW)" title="constant(OVERVIEW_TITLE)" id="overview" url="serverdetail.php?appid=$serverID" showwhich="All">
  <table name="Server Passwords" title="Server Passwords">
   <info title="" type="macrooutput" macroname="My passwords"/>
  </table>
  <table name="Settings" title="Settings">
   <info title="Superadmin password" type="macro" macroname="setsadminpword">
    <param type="text" title="" name="password">
     <initValue type="macro" macroname="getsadminpword"/>
    </param>
  </info>
   <info setprivs="admin" type="alterconfig" name="BoundToIp" title="Server Address"/>
   <info type="alterconfig" name="HTTPServer Enabled" title="HTTPServerEnabled"/>
  </table>
 </infopage>
 <infopage name="constant(CONFIGURATION)" title="constant(CONFIG_TITLE)" id="config" url="serverdetail-config.php?appID=$serverID"/>
 <infopage name="constant(MACROS)" title="constant(MACROS_TITLE)" id="macros" url="macros.php?appID=$serverID"/>
 <infopage name="constant(CONSOLE)" title="constant(CONSOLE_TITLE)" id="console" url="console.php?appID=$serverID"/>
 <infopage name="constant(LOGS)" title="constant(LOGS_TITLE)" id="log" url="serverdetail-log.php?appID=$serverID"/>
</sconnectorInfo>

Notice that the File Transfer tab is ommited from this page as well.

Windows Services

The basic macros should already exist under the 'windows services' sconnector, so as long as you create your sconnector below this type, most of the work is already done. The only things left are to define the alterconfigs, configuration tokens and startup parameters.

If you can't configure your game server as a service or don't want it to run as such, then you can simply have your server be a subtype of 'windows applications'. The start,stop and status macros in there should work in most cases, but in some situations, the start macro will need to be rewritten as different applications have different requirements. As long as your macro exports the pid of the newly-created processes into the same pid container file (~##screenName##~.pid), then the status and stop macros won't need to be rewritten.

Linux / FreeBSD

Since most applications run in interactive mode by default on linux, the default start/stop/status macros have been written to use the 'screen' utility to house this console. If your subtype already has a control script and is configured to run as a daemon (like Teamspeak2(tm)), then you will need to rewrite the start,status and stop macros to interact with your service's control script.

Additional References

Retrieved from "http://wiki.scinterface.com/index.php/SConnector_Howto"
Personal tools