Difference between revisions of "SME Server:Documentation:Developers Manual:Chapter2/de"

defaults

[root@gsxdev1 ~]# config show AccessType
AccessType=dedicated

[root@gsxdev1 ~]# config show ConsoleMode
ConsoleMode=login

[root@gsxdev1 ~]# config show TimeZone
TimeZone=Australia/NSW

[root@gsxdev1 ~]# config show atalk
atalk=service
   MaxClients=20
   status=enabled

[root@gsxdev1 ~]# config show dhcpd
dhcpd=service
   end=192.168.1.250
   start=192.168.1.65
   status=disabled

[root@gsxdev1 ~]# config show LocalIP
LocalIP=192.168.1.100

[root@gsxdev1 ~]# db configuration show LocalIP
LocalIP=192.168.1.100

[root@gsxdev1 ~]# db accounts show admin
admin=system
   EmailForward=local
   FirstName=Local
   ForwardAddress=
   LastName=Administrator
   Lockable=no
   PasswordSet=yes
   Removable=no
   Shell=/sbin/e-smith/console
   VPNClientAccess=no

[root@gsxdev1 ~]# db
usage:
   /sbin/e-smith/db dbfile keys
   /sbin/e-smith/db dbfile print [key]
   /sbin/e-smith/db dbfile show [key]
   /sbin/e-smith/db dbfile get key
   /sbin/e-smith/db dbfile set key type [prop1 val1] [prop2 val2] ...
   /sbin/e-smith/db dbfile setdefault key type [prop1 val1] [prop2 val2] ...
   /sbin/e-smith/db dbfile delete key
   /sbin/e-smith/db dbfile printtype [key]
   /sbin/e-smith/db dbfile gettype key
   /sbin/e-smith/db dbfile settype key type
   /sbin/e-smith/db dbfile printprop key [prop1] [prop2] [prop3] ...
   /sbin/e-smith/db dbfile getprop key prop
   /sbin/e-smith/db dbfile setprop key prop1 val1 [prop2 val2] [prop3 val3] ...
   /sbin/e-smith/db dbfile delprop key prop1 [prop2] [prop3] ...

use esmith::AccountsDB;
my $db = esmith::AccountsDB->open or die "Couldn't open AccountsDB\n";
my $admin = $db->get("admin") or die "admin account missing from AccountsDB\n";
print $admin->show();

admin
    EmailForward = local
       FirstName = Local
  ForwardAddress =
        LastName = Administrator
        Lockable = no
     PasswordSet = yes
       Removable = no
           Shell = /sbin/e-smith/console
 VPNClientAccess = no
            type = system

perldoc esmith::ConfigDB
perldoc esmith::AccountsDB
perldoc esmith::HostsDB
perldoc esmith::NetworksDB
perldoc esmith::DB

[root@gsxdev1 db]# cd /etc/e-smith/db
[root@gsxdev1 db]# ls
accounts       domains       networks       yum_installed
backups        hosts         spamassassin   yum_repositories
configuration  mailpatterns  yum_available  yum_updates

[root@gsxdev1 db]# ls configuration/
defaults  force  migrate

[root@gsxdev1 db]# cat configuration/defaults/sshd/status
disabled

[root@gsxdev1 db]# cat configuration/force/sysconfig/ReleaseVersion
7.0rc2

   my $popd = $DB->get("popd") or return;

   my $pop3 = $DB->get("pop3") ||
       $DB->new_record("pop3", { type => "service" });

   $pop3->merge_props($popd->props);

   $popd->delete;

   *

     Please be careful with migrate fragments. Although they should only modify entries within the current database, there are no restrictions placed on what they can do. The ability to open and even modify other databases may be required to perform a migration.
   *

     Migrate fragments must be safe to run multiple times. They should migrate the value when required and do nothing in other cases.
   *

     Migrate fragments should never call croak or die. This will cause the database migration to stop. If an error is detected, call carp or warn to note the error in the logs.
   *

     Migrate fragments should be owned by the package requiring the migration so that the migration only occurs when that package is installed.
   *

     Migrate fragments should be self-contained and ideally perform only one migration per fragment.
   *

     It is also possible to initialize and migrate database values in action scripts, but creation of migrate fragments is strongly preferred. Creating defaults is a simple matter of creating text files and migrate fragments require far less code than action scripts.

   *

     migrate scripts are run first
   *

     then defaults are loaded
   *

     and finally any force files are loaded.

   Note: The console-save event is not a "reconfigure everything" event, and only changes items which can be configured from the text-mode console. It is convenient in this case as it performs database initialization and migration.

   It is an SME Server requirement that all database entries and configuration files must be correctly configured after a "reconfiguration reboot". This is available from the console and server manager and performs the post-upgrade and reboot events. Packages should also provide links in other events (e.g. "email-update" for email related changes) to provide reconfiguration without the reboot.

   *

     The configuration databases should only be modified using the tools and APIs provided.
   *

     The order of the entries and the order of properties is undefined.
   *

     The keys and property names are currently treated in a case-sensitive manner, though this may change in the future. Do not create keys or property names which differ only by their case.
   *

     Underscores and hyphens are valid in key and property names, but should normally be avoided.
   *

     Do not "overload" an existing property with a new value. If the existing values do not meet your requirements, discuss your implementation with the developers. Values which are not known by the base may cause serious issues on upgrade. If the existing panels have three choices, do not invent new choices without enhancing the panel to support them.
   *

     The type pseudo-property is used internally and is reserved.
   *

     By convention, database keys are lower case, and property names are stored in mixed case. The type, status and access properties are exceptions to this convention.
   *

     The storage location and internals of the databases is subject to change.
   *

     The configuration databases are currently stored as pipe-delimited flat text files in the /home/e-smith/db/ directory.

   *

     User accounts: These are accounts created for individual users at the local organization. Each account has a POP/IMAP mailbox and an area for storing files.
   *

     Groups: Groups of users, which can be used for configuring permissions on storage areas and automatically provide a group e-mail address.
   *

     Information bays: These accounts correspond to information bays defined in the system. These storage areas can be accessed via filesharing, FTP and the web.
   *

     System accounts: Linux system accounts which are reserved by installed software packages.
   *

     URL accounts: Portions of the Web namespace which are reserved for system use. For example, the server-manager account is reserved as it is used for redirecting web access to the server manager.
   *

     Pseudonyms: Alternate names for existing accounts. For example, fred.frog could be a pseudonym for the account ffrog, allowing email to be sent to either address.
   *

     Printers: Network shared printers share the same namespace as other accounts so that they can be made visible to the local network.

   Note: The two records exist due to an partial migration from simple to complex entries in the configuration database. Setting both values in this script avoids the need to perform database migration in the ip-change event.

   Note: The generic_template_expand action is currently run at S05 and adjust-services is run at S90. The order of action scripts within an event is subject to change between releases.

   Note: Reminder: action scripts should normally take at most two arguments. The first is always the event name. The second optional argument is a key into one of the databases. Events are not function calls.

   Events are not currently serialized. In most cases overlapping events will not cause issues, but caution should be exercised when events are signalled from programs.

   Note: Events which are not listed in this table are subject to change and may not appear in future releases of the SME Server.

   *

     Change the type of the entry to mark it as being in the process of being deleted e.g. a user entry becomes a user-deleted entry.
   *

     Signal the relevant deletion event - e.g. user-delete
   *

     Remove the entry from the database, but only if the event succeeds.

 S65sshd-conf=action|
 Event|remoteaccess-update|
 Action|S65sshd-conf|
 Start|1138846952 730480|
 End|1138846953 66768|
 Elapsed|0.336288

 S99false=action|
 Event|remoteaccess-update|
 Action|S99false|
 Start|1138857114 58910|
 End|1138857114 81920|
 Elapsed|0.02301|
 Status|256

   Note: It is also possible to store templates as single files, rather than as a directory of fragments. This method is preserved for backwards compatibility, but does not provide the extensibility of directory based templates. Directory templates should be used for all new templates, even if that directory only contains a single fragment. 

   $OUT = ;

   for my $item ( qw(bread milk bananas) )
   {
       $OUT .= "* $item\n";
   }

   $OUT .= "$LocalIP\t";
   $OUT .= " ${SystemName}.${DomainName}";
   $OUT .= " ${SystemName}";

   Note: You may also need a templates.metadata configuration file if your generated file needs to be executable.

   Note: The number of fragments and the order of those fragments within a template directory is subject to change between releases.

   Note: Never edit the standard templates. Your changes will be overwritten when packages are upgraded.

   Note: The template-custom trees should be reserved for local system overrides. Software should not install files in this tree.

   *

     If a fragment of the same name exists in both templates and templates-custom, the one from templates-custom is used, and the one from the standard templates tree is ignored.
   *

     If the fragments in templates-custom have different names from those in templates, they are merged into the template as if they were in the templates directory.
   *

     If the templates-custom entry is a file, rather than a directory, it completely overrides the standard template. 

   *

     template-begin from /etc/e-smith/templates-default
   *

     10intro from /etc/e-smith/templates/etc/book.conf
   *

     30chapter3 from /etc/e-smith/templates-custom/etc/book.conf
   *

     40chapter4 from /etc/e-smith/templates/etc/book.conf
   *

     50chapter5 from /etc/e-smith/templates-custom/etc/book.conf
   *

     80synopsis from /etc/e-smith/templates/etc/book.conf
   *

     template-end (empty), nominally from /etc/e-smith/templates-default

   *

     Create a templates-custom directory to match the existing one in the templates hierachy.
   *

     Copy the conflicting fragment, and only that fragment, to the templates-custom directory. The fragment should have the same name in both directories. At this point you have not changed the behaviour of the system as the templates-custom entry will be preferred, but will behave identically.
   *

     Modify the copy in templates-custom to suit your required behaviour.
   *

     Raise a New Feature Request here: http://bugs.contribs.org/. Please attach your modified template (or even better, a patch file) and provide details of why you think that the standard template should be changed.

   Note: You should not release RPMs which install templates in the templates-custom directories. If the behaviour of a base template needs to be changed, please raise a bug to discuss the change.

   Note: Configuration files should generally not be writable by any user other than root. In particular, configuration files should not normally be writable the www user as this poses a significant security risk. Installation advice which says "chmod 777" is almost invariably wrong.

   Note: expand-template is designed for testing, and not as the standard way to expand templates. The correct way to ensure that a template is expanded is to create the templates2expand files in the relevant events, along with any templates.metadata files which may be required.

   my $groupName = $group->key;

   [...]

   processTemplate(
           {
               CONFREF =>
                   {
                       Members => $members,
                   },

               TEMPLATE_PATH =>
                   "/var/qmail/alias/.qmail-group",

               OUTPUT_FILENAME => "/var/qmail/alias/.qmail-$groupName",
           }
       );

   [...]

   Note: Software which was written for SME Server before release 7 will have a number of scripts which call processTemplate. In almost all cases, these can be replaced with simple flag files in the templates2expand/ directory of the relevant events. The new method is far more efficient as a single invocation is perl is used to expand all template files.

   *

     Processes do occasionally fail through software errors, memory exhaustion and accidental finger poking by the system administrator.
   *

     Some startup scripts and processes do not gracefully handle server crashes, such as power outages. The startup scripts and processes often use process identifier (PID) files to determine whether the process is running. Reliable handling of PID files is impossible to achieve under all failure cases.
   *

     Many processes do not deal properly with rapid invocation of stop and start requests. This is often, but not always, due to "PID file race" conditions. 

   *

     runs each process under control of its own supervisor process
   *

     imposes process limits
   *

     restarts the process if it fails
   *

     provides a consistent mechanism for controlling the underlying process 

   Note: Gerrit Pape's runit came from previous work by Dan Bernstein on the supervise supervision environment. runit provides additional features, and has been released under a free software license.

    |-md1_raid1
    |-md2_raid1
    | ...
    |-runsvdir-+-runsv-+-multilog
    |          |       `-ulogd
    |          |-6*[runsv---multilog]
    |          |-runsv-+-multilog
    |          |       `-ntpd
    |          |-runsv-+-multilog
    |          |       `-tinydns
    |          |-runsv-+-cvm-unix
    |          |       `-multilog
    |          |-runsv-+-multilog
    |          |       `-mysqld
    |          |-5*[runsv-+-multilog]
    |          |          `-tcpsvd]
    |          |-runsv-+-multilog
    |          |       `-oidentd
    |          |-runsv-+-multilog
    |          |       `-smtp-auth-proxy
    |          |-runsv-+-multilog
    |          |       `-smbd---smbd
    |          |-runsv---httpd---10*[httpd]

   Note: For the curious, if init fails, the system reboots.

   *

     Checks the name of the link, e.g. S05syslog
   *

     Removes the S05 prefix, leaving syslog
   *

     Checks to see whether syslog is defined in the configuration database, and whether it has its status set to enabled.
   *

     If so, it runs the /etc/init.d/syslog script with the argument start.
   *

     If the service is not enabled, it exits without starting the service. 

   Note: If a script exists in the /etc/init.d/supervise/ directory, e-smith-service will use that in preference to the one in the /etc/init.d/ directory. This allows us to install our own supervised startup scripts without modifying the original package.

   title="FORM_TITLE"
   header="/etc/e-smith/web/common/head.tmpl"
   footer="/etc/e-smith/web/common/foot.tmpl">

   <entry>
       <base>FORM_TITLE</base>
       <trans>Logger demo</trans>
   </entry>

   <page name="First" pre-event="print_status_message()"
       post-event="change_settings">

       <field
           type="select"
           id="loggerdemo_Interval"
           options="10,20,30,40,50"
           value="get_interval()">
           <label>LABEL_LOGGERDEMO_INTERVAL</label>
       </field>

       <field
           type="select"
           id="loggerdemo_status"
           options="'disabled' => 'DISABLED', 'enabled' => 'ENABLED'"
           value="get_status()">
           <label>LABEL_LOGGERDEMO_STATUS</label>
       </field>

       <subroutine src="print_button('SAVE')" />

   Note: Buttons should be part of the FormMagick XML description, and hopefully will be in the future. The print_button routine is a workaround for the lack of a button widget.

   </page>

   Tip: When naming your script, use a name which closely resembles the description (and hence the name in the navigation panel). This makes it easier to correlate menu items to Perl scripts. Just take the descriptive name and remove capital letters, punctuation and spaces. For instance, "Advanced security" might become /etc/e-smith/web/functions/advancedsecurity

   Note: The word panel is also sometimes used to refer to an individual web manager web function.

@@ Line 150: / Line 150: @@
 würde einen Eintrag in der ''sshd''-Datenbank, seinen zugehörigen Status erzeugen und diesen auf ''disabled'' setzen, wenn dieser Eintrag noch nicht existiert.
-=====Force files=====
+=====Daten unter ''force''=====
-Force files are just like defaults files, except they overwrite the existing value. So, this file:
+Die Dateien unter ''force'' sind ähnlich wie diejenigen unter ''defaults'', sind aber dafür gedacht, existierende Einträge zu überschreiben. So würde die Datei
   [root@gsxdev1 db]# cat configuration/force/sysconfig/ReleaseVersion
-.1.3
+.0rc2
-would create the ReleaseVersion property of the sysconfig entry and unconditionally set its value to 7.0rc2
+die Eigenschaft ''ReleaseVersion'' im Eintrag von ''sysconfig'' ändern und den Wert auf ''7.0rc2'' setzen.
 =====Migrate fragments=====

Difference between revisions of "SME Server:Documentation:Developers Manual:Chapter2/de"

Revision as of 15:14, 25 May 2007

Contents

Kapitel 2: Der SME Server intern

Konfigurations-Datenbank

Überblick

Einfache Einträge

Komplexe Einträge

Zugriff von der Kommandozeile

Zugriff über die Perl API

Datenbank-Initialisierung

Dateien unter defaults

Daten unter force

Migrate fragments

Evaluation order: migrate, defaults, force

Forcing database initialization

Important notes about the configuration databases

Actions und Events

Vorlagen für Konfigurationsdateien

Prozesse starten, steuern und stoppen

Der Server-Manager als Web-Frontend

Navigation menu

Page actions

Page actions

Personal tools

Koozali SME Server

Recent activities

Koozali resources

Koozali SME Server wiki

Tools

Search