Connection schedule modules allow the SQL Relay server to control when users are allowed to access the database.
The schedules section of the sqlrelay.conf file indicates which schedules modules to load and what parameters to use when executing them.
<?xml version="1.0"?>
<instances>
...
<instance ...>
...
<schedules>
<!-- allow these users during business hours -->
<schedule module="cron_userlist" default="deny">
<users>
<user user="dmuse"/>
<user user="kmuse"/>
<user user="imuse"/>
<user user="smuse"/>
</users>
<rules>
<allow when="* * * 2-5 8:00-11:59,13:00-16:59"/>
</rule>
</schedule>
</schedules>
...
</instance>
...
</instances>
The module attribute specifies which module to load.
Module configurations may have attributes and/or nested tags. How these elements are interpreted is module-specific.
Currently, all schedule modules have an enabled parameter, allowing the module to be temporarily disabled. If enabled="no" is configured, then the module is disabled. If set to any other value, or omitted, then the module is enabled.
Connection schedule modules can be "stacked". Multiple modules may be loaded and multiple instances of the same type of module, with different configurations, may also be loaded.
<?xml version="1.0"?>
<instances>
...
<instance ...>
...
<schedules>
<!-- allow these users during business hours -->
<schedule module="cron_userlist" default="deny">
<users>
<user user="imuse"/>
<user user="smuse"/>
</users>
<rules>
<allow when="* * * 2-5 8:00-11:59,13:00-16:59"/>
</rule>
</schedule>
<!-- allow these users at any time -->
<schedule module="cron_userlist" default="deny">
<users>
<user user="dmuse"/>
<user user="kmuse"/>
</users>
<rules>
<allow when="* * * * *"/>
</rule>
</schedule>
</schedules>
...
</instance>
...
</instances>
At startup, the SQL Relay server creates instances of the specified schedule modules and initializes them. When a client connects, the server passes the supplied credentials to each module, in the order that they were specified in the config file. Each module applies its rules to the specified user. If a module denies access to a user then the remaining modules are ignored. If the user makes it through all modules without being denies access, then the user is allowed access.
Currently, the following connection schedule modules are available:
The cron_userlist module allows you to define a connection schedule for a list of users, using a cron-like syntax.
Note though, that the time-and-date fields have different meanings from traditional cron.
An example configuration follows.
<?xml version="1.0"?>
<instances>
...
<instance ...>
...
<schedules>
<!-- allow these users during business hours -->
<schedule module="cron_userlist" default="deny">
<users>
<user user="dmuse"/>
<user user="kmuse"/>
<user user="imuse"/>
<user user="smuse"/>
</users>
<rules>
<allow when="* * * 2-5 8:00-11:59,13:00-16:59"/>
</rule>
</schedule>
</schedules>
...
</instance>
...
</instances>
In this example, the module denies access to all users by default, but then allows access to the dmuse, kmuse, imuse, and smuse users during business hours. In this case, business hours are defined as:
Another example configuration follows.
<?xml version="1.0"?>
<instances>
...
<instance ...>
...
<schedules>
<!-- deny these users during non-business hours -->
<schedule module="cron_userlist" default="allow">
<users>
<user user="dmuse"/>
<user user="kmuse"/>
<user user="imuse"/>
<user user="smuse"/>
</users>
<rules>
<deny when="* * * 2-5 00:00-7:59,12:00-12:59,17:00-23:59"/>
<deny when="* * * 1,7 *"/>
</rules>
</schedule>
</schedules>
...
</instance>
...
</instances>
In this example, the module allows access to all users by default, but then denies access to the dmuse, kmuse, imuse, and smuse users during non-business hours. In this case, non-business hours are defined as:
The users tag defines a list of users to apply the schedule to. It may contain any number of user tags.
The user tags support the following attributes:
If a user does not appear in this list then it is granted access at any time. If a user appears in the list then the schedule will be applied to that user.
The default attribute of the schedule tag defines the default rule.
The rules tag defines the list of rules that modify the default behavior. It may contain allow or deny tags.
The allow and deny tags support the following attributes:
The format of the when attribute is cron-like. There are 5 fields, separated by spaces.
Note again though, that the time-and-date fields have different meanings from traditional cron.
The fields represent, in order:
In each field, ranges may be specified with a dash, and sets may be separated by commas. A * means "all possible values".
For example:
All day, every day, at any time of day:
* * * * *
All day, every month, on the 1st, 3rd through 5th, 8th, and 10th through 12th of the month:
* * 1,3-5,8,10-12 * *
Every day from 8:00AM through 11:59AM and 1:00PM through 4:59PM:
* * * * 8:00-11:59,13:00-16:59
Every day from 1:00PM to 4:00PM:
* * * * 13:00-16:00
All day, every Saturday:
* * * 6 *
All day, every day, in February and March:
* 2,3 * * *
Every day in February and March, from noon to 3PM:
* 2,3 * * 12:00-15:00
...and so on.
In general, the module works as follows:
Custom modules may also be developed.
For more information, please contact David Muse at david.muse@firstworks.com.