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.

  </form>

  </form>

</nowiki>

</nowiki>

And the form implementation goes in <tt class="FILENAME">/usr/lib/perl5/site_perl/esmith/FormMagick/Panels/cellnumbers.pm</tt> :

And the form implementation goes in <tt class="FILENAME">/usr/lib/perl5/site_perl/esmith/FormMagick/Panels/cellnumbers.pm</tt> :

----

----

==Using the LDAP server==

===Using the LDAP server===

The SME Server automatically creates and maintains an LDAP <span class="emphasis">''address book''</span>. The LDAP server listens for requests on port 389, which is the standard TCP/IP port for LDAP. At this time, the LDAP server should be considered read-only as it is generated from the system configuration and accounts data. Changes to the LDAP schema will be backed up and restored, but major system reconfiguration may reset the LDAP database to the default schema.

The SME Server automatically creates and maintains an LDAP <span class="emphasis">''address book''</span>. The LDAP server listens for requests on port 389, which is the standard TCP/IP port for LDAP. At this time, the LDAP server should be considered read-only as it is generated from the system configuration and accounts data. Changes to the LDAP schema will be backed up and restored, but major system reconfiguration may reset the LDAP database to the default schema.

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:

     use MIME::Base64;

     use MIME::Base64;

   

   

     my $rand    = sprintf("%08d", int(1_000_000_000 * rand()));

     $rec->set_prop('DbPassword', sprintf("%15.0f", int( (1000000000000000) * rand() )));

    $rec->set_prop('DbPassword', $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:

  %post

  %post

  expand-template /etc/e-smith/sql/init/loggerdemo-create-schema.sql

  expand-template /etc/e-smith/sql/init/loggerdemo-create-schema.sql

  /etc/rc.d/init.d/mysql.init

  /etc/rc.d/init.d/mysql.init start

  true

  true

Installing this RPM will create the <tt class="FILENAME">/etc/e-smith/sql/loggerdemo-create-schema.sql</tt> templates (because it is part of the RPM), and the post-installation actions will expand the template and run the <tt class="FILENAME">mysql.init</tt> script, which will execute the schema creation commands and delete the generated file. When the RPM installation is finished, the database schema will have been created, and the MySQL database will be ready to process SQL commands from your application.

Installing this RPM will create the <tt class="FILENAME">/etc/e-smith/sql/loggerdemo-create-schema.sql</tt> templates (because it is part of the RPM), and the post-installation actions will expand the template and run the <tt class="FILENAME">mysql.init</tt> script, which will execute the schema creation commands and delete the generated file. When the RPM installation is finished, the database schema will have been created, and the MySQL database will be ready to process SQL commands from your application.

  signal-event remoteaccess-update

  signal-event remoteaccess-update

Note that a firewall hole is only opened if three things are true - the service has a TCPPort (or UDPPort) definition, the service is set to public access, and the service is enabled. Run the commands above, and then these ones:

Note that a firewall hole is only opened if three things are true - the service has a TCPPort (or UDPPort) definition, the service is set to public access, and the service is enabled.  

 

 

Run the commands above, and then these ones:

  cp /etc/rc.d/init.d/masq /tmp

  cp /etc/rc.d/init.d/masq /tmp

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.

If your package implements a server or daemon, you will probably want it to be started automatically when the system boots.

If your package implements a server or daemon, you will probably want it to be started automatically when the system boots.

The SME Server boots in runlevel 7, so you can get an idea of the startup processes by listing the contents of <tt class="FILENAME">/etc/rc.d/rc7.d</tt>.

The SME Server 8.1 boots in runlevel 7, SME Server 9.0 boots in runlevel 4, so you can get an idea of the startup processes by listing the contents of <tt class="FILENAME">/etc/rc.d/rc7.d</tt>. (or rc4.d for SME Server 9.0)

These are similar to the init scripts you may be familiar with from other Linux systems, with one important differnce. Instead of pointing to scripts within <tt class="FILENAME">/etc/rc.d/init.d</tt>, all of those init entries are links to <tt class="FILENAME">/etc/rc.d/init.d/e-smith-service</tt>. This is a wrapper which checks the configuration database to see if the service is supposed to be running and if so, starts the service from <tt class="FILENAME">/etc/rc.d/init.d/whatever</tt>.

These are similar to the init scripts you may be familiar with from other Linux systems, with one important differnce. Instead of pointing to scripts within <tt class="FILENAME">/etc/rc.d/init.d</tt>, all of those init entries are links to <tt class="FILENAME">/etc/rc.d/init.d/e-smith-service</tt>. This is a wrapper which checks the configuration database to see if the service is supposed to be running and if so, starts the service from <tt class="FILENAME">/etc/rc.d/init.d/whatever</tt>.

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: