Changes

Just as you can spontaneously introduce new configuration settings you can spontaneously introduce new properties as well.

Just as you can spontaneously introduce new configuration settings you can spontaneously introduce new properties as well.

 

{{Note box|msg=You should not create new options for existing properties. For example, if the server-manager can only set three possible values, you should not invent a fourth one. Use another property and raise a bug to suggest the required changes.}}

<div class="NOTE"><blockquote class="NOTE">

 

'''Note: ''' You should not create new options for existing properties. For example, if the server-manager can only set three possible values, you should not invent a fourth one. Use another property and raise a bug to suggest the required changes.

 

For example, let's say that your application needs a concept of <span class="emphasis">''cell phone number''</span> stored for each user account. This is not a standard property in the SME Server. Your application can simply choose a name for the new property, e.g. <tt class="FILENAME">CellNumber</tt>, and immediately start reading and writing that property for the various users - as though the property had always existed.

For example, let's say that your application needs a concept of <span class="emphasis">''cell phone number''</span> stored for each user account. This is not a standard property in the SME Server. Your application can simply choose a name for the new property, e.g. <tt class="FILENAME">CellNumber</tt>, and immediately start reading and writing that property for the various users - as though the property had always existed.

The SME Server supports two methods for data backup. For light-usage sites, end users can use their web browser to select a <span class="emphasis">''backup to desktop''</span> option; this creates a compressed file of the configuration databases and all user data on the server, and uploads it to the user's desktop via their web browser.

The SME Server supports two methods for data backup. For light-usage sites, end users can use their web browser to select a <span class="emphasis">''backup to desktop''</span> option; this creates a compressed file of the configuration databases and all user data on the server, and uploads it to the user's desktop via their web browser.

 

{{Note box|msg=The desktop backup is limited to 2GBytes of data on most operating systems.}}

<div class="NOTE"><blockquote class="NOTE">

 

'''Note: ''' The desktop backup is limited to 2GBytes of data on most operating systems.

 

For heavier-usage sites, automatic nightly tape backup can be configured.

For heavier-usage sites, automatic nightly tape backup can be configured.

A separate MySQL database and one or more database users should be created for each application. The database password should be stored in the configuration database and either retrieved from the configuration database by the application or passed to the application via an <tt class="FILENAME">httpd.conf</tt> fragment. The password should be automatically generated, unique to this server and this application, and stored as a property in the configuration database for later use in database scripts.

A separate MySQL database and one or more database users should be created for each application. The database password should be stored in the configuration database and either retrieved from the configuration database by the application or passed to the application via an <tt class="FILENAME">httpd.conf</tt> fragment. The password should be automatically generated, unique to this server and this application, and stored as a property in the configuration database for later use in database scripts.

 

{{Note box|msg=Database passwords required for application configuration files should be retrieved from the configuration database.}}

<div class="NOTE"><blockquote class="NOTE">

 

'''Note: ''' Database passwords required for application configuration files should be retrieved from the configuration database.

 

The MySQL root is automatically generated and configured for command-line MySQL use by the root system user. The MySQL root password should only be used for database maintenance such as creating and deleting databases and performing database backups.

The MySQL root is automatically generated and configured for command-line MySQL use by the root system user. The MySQL root password should only be used for database maintenance such as creating and deleting databases and performing database backups.

 

{{Warning box|msg=Applications should never use the MySQL root password for access to the database and it should never be entered into application configuration files.}}

<div class="NOTE"><blockquote class="NOTE">

 

'''Note: ''' <span class="emphasis">'' Applications should never use the MySQL root password for access to the database and it should never be entered into application configuration files. ''</span>

 

First choose a name for your database, as well as a username to access the data. For example, let's say your database is called '''loggerdemo''', the username is '''loguser''' and the password is '''$loggerdemo{DbPassword}'''. A migrate fragment like this might be used to create the password:

First choose a name for your database, as well as a username to access the data. For example, let's say your database is called '''loggerdemo''', the username is '''loguser''' and the password is '''$loggerdemo{DbPassword}'''. A migrate fragment like this might be used to create the password:

Include the migrate fragment and your template in your RPM. Note that the password generated in this way is unique to this server and this application and automatically stored in the configuration database for later use. This means that it is backed up and restored through the normal server operations.

Include the migrate fragment and your template in your RPM. Note that the password generated in this way is unique to this server and this application and automatically stored in the configuration database for later use. This means that it is backed up and restored through the normal server operations.

 

{{Note box|msg=For more documentation on MySQL schema creation commands, see: http://www.mysql.com/documentation/mysql/bychapter/}}

<div class="NOTE"><blockquote class="NOTE">

 

'''Note: '''For more documentation on MySQL schema creation commands, see: http://www.mysql.com/documentation/mysql/bychapter/

 

In the post-installation section of your RPM, expand the template, and run the <tt class="FILENAME">/etc/rc.d/init.d/mysql.init</tt> script. For example the post-installation section of your RPM SPEC file might look like this:

In the post-installation section of your RPM, expand the template, and run the <tt class="FILENAME">/etc/rc.d/init.d/mysql.init</tt> script. For example the post-installation section of your RPM SPEC file might look like this:

The firewall rulesets are automatically changed so that instead of allowing access from all hosts <var class="LITERAL">0.0.0.0/0</var>, they now two specific rules to allow the host and network specified, and a new <var class="LITERAL">--jump denylog</var> rule which blocks and logs any others.

The firewall rulesets are automatically changed so that instead of allowing access from all hosts <var class="LITERAL">0.0.0.0/0</var>, they now two specific rules to allow the host and network specified, and a new <var class="LITERAL">--jump denylog</var> rule which blocks and logs any others.

 

{{Note box|msg=Hosts which are not listed in <var class="LITERAL">AllowHosts</var> are denied, if this property is configured.}}

<div class="NOTE"><blockquote class="NOTE">

 

'''Note: ''' Hosts which are not listed in <var class="LITERAL">AllowHosts</var> are denied, if this property is configured.

 

There is also a <var class="LITERAL">DenyHosts</var> property which generates rules to block specific hosts, if this is required. If there is a specific reason to limit access to a service, you should normally use <var class="LITERAL">AllowHosts</var> to list the ones which do require access. The DenyHosts property is provided for completeness and can be useful in specific situations, for example to block mail from a misbehaving mail server while allowing it from all other sites.

There is also a <var class="LITERAL">DenyHosts</var> property which generates rules to block specific hosts, if this is required. If there is a specific reason to limit access to a service, you should normally use <var class="LITERAL">AllowHosts</var> to list the ones which do require access. The DenyHosts property is provided for completeness and can be useful in specific situations, for example to block mail from a misbehaving mail server while allowing it from all other sites.

Here is the step-by-step procedure for making your package start up a program called <tt class="FILENAME">myserver</tt> at boot time.

Here is the step-by-step procedure for making your package start up a program called <tt class="FILENAME">myserver</tt> at boot time.

# First, create the traditional init script <tt class="FILENAME">/etc/rc.d/init.d/myserver</tt> which can be run with the command-line arguments "start" or "stop" to perform the appropriate action on the server. Look at other init scripts in the same directory for examples. This script should be included in your RPM.<div class="NOTE"><blockquote class="NOTE">'''Note: ''' If your service is managed by runit, all you need is a link to the '''daemontools''' script.</blockquote></div>

# First, create the traditional init script <tt class="FILENAME">/etc/rc.d/init.d/myserver</tt> which can be run with the command-line arguments "start" or "stop" to perform the appropriate action on the server. Look at other init scripts in the same directory for examples. This script should be included in your RPM.

{{Note box|msg=If your service is managed by runit, all you need is a link to the '''daemontools''' script.}}

# Second, create a symbolic link as shown below, choosing the two-digit number after the letter S to control the startup order of the server programs. Include this symbolic link in your RPM. /etc/rc.d/rc7.d/S55myserver -> /etc/rc.d/init.d/e-smith-serviceThese two steps are typical for any Linux/Unix server application, except that the symbolic link traditionally points directly to the init script, rather than to <tt class="FILENAME">e-smith-service</tt>. Remember, we want to link to <tt class="FILENAME">e-smith-service</tt> to ensure that a <var class="LITERAL">disabled</var> service does <span class="emphasis">''not''</span> start at boot time.

# Second, create a symbolic link as shown below, choosing the two-digit number after the letter S to control the startup order of the server programs. Include this symbolic link in your RPM. /etc/rc.d/rc7.d/S55myserver -> /etc/rc.d/init.d/e-smith-serviceThese two steps are typical for any Linux/Unix server application, except that the symbolic link traditionally points directly to the init script, rather than to <tt class="FILENAME">e-smith-service</tt>. Remember, we want to link to <tt class="FILENAME">e-smith-service</tt> to ensure that a <var class="LITERAL">disabled</var> service does <span class="emphasis">''not''</span> start at boot time.

# Third, let's assume for now that <var class="LITERAL">myserver</var> should be enabled by default, and so start at boot time. You just need to create some properties in the configuration database to make that happen:

# Third, let's assume for now that <var class="LITERAL">myserver</var> should be enabled by default, and so start at boot time. You just need to create some properties in the configuration database to make that happen: