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

,

 Vorsicht: Die SME Server Software löscht alle Daten von dem PC, auf dem sie installiert wird. 

   Note: Warning! The server-only mode is designed for LAN environments that already have a firewall/gateway. 

   Note: We strongly recommend against installing development tools, such as compilers, on any production servers, especially those which are accessible from the Internet.

 use esmith::AccountsDB;

 $adb = esmith::AccountsDB->open_ro;
 $adb->get_prop('admin', 'ForwardAddress') || 'admin';

   Note: Be careful with the placement of the braces in the example. We want two lines of output - the comment and the line starting with the asterisk. If you move the opening brace onto a new line, you will end up with three lines of output.

   Whitespace is not signifcant and the code within braces should be formatted "nicely". However, whitespace outside braces is significant and will be copied literally to the output file.

   my ($fm) = @_;
   my $q = $fm->{'cgi'};

   [...]

   my $admin_email = $q->param('AdminEmail');
   my $admin = $accounts->get('admin');
   if ($admin_email)
   {
       $admin->merge_props(
               EmailForward => 'forward',
               ForwardAddress => $admin_email,
               );
   }
   else
   {
       $admin->merge_props(
               EmailForward => 'local',
               ForwardAddress => ,
               );
   }

   [...]

   unless ( system( "/sbin/e-smith/signal-event", "email-update" ) == 0 )
   {
       $fm->error('ERROR_UPDATING');
       return undef;
   }
   $fm->success('SUCCESS');

   or die "Couldn't open ConfigDB\n";

   or die "Couldn't open AccountsDB\n";

# of all users. Process all accounts of type "user" (ignore groups,

   for my $user ($accounts->users)
   {
       my $key     = $user->key;
       my $first   = $user->prop('FirstName');
       my $last    = $user->prop('LastName');

       system ("/usr/bin/logger", "-t", "Demo3",
               "Initializing user $key ($first $last) in domain $domain");
   }

   exit 0;

   or die "User $id does not exist\n";

   system ("/usr/bin/logger", "-t", "Demo3",
           "Creating user $id ($first $last) in domain $domain");

   system ("/usr/bin/logger", "-t", "Demo3",
           "Changing user $id to ($first $last) in domain $domain");

   system ("/usr/bin/logger", "-t", "Demo3",
           "Deleting user $id in domain $domain");

   system ("/usr/bin/logger", "-t", "Demo3", "Ignoring $event event");

   Tip: It is almost always better to extend the existing accounts database with additional properties for your application than to maintain another database.

 use esmith::AccountsDB;

 $adb = esmith::AccountsDB->open_ro;
 $adb->get_prop('admin', 'ForwardAddress');

   Interval=20
   status=enabled

   Note: By convention, database keys are lower case, and property names are mixed case (e.g. Interval). The status property is an exception here, and is stored lower case.

   my $status = $loggerdemo{status} || "disabled";

   return "# loggerdemo service is disabled."
       unless ($status eq "enabled");

   use esmith::AccountsDB;

   $adb = esmith::AccountsDB->open_ro;
   my $admin_email = $adb->get_prop('admin', 'ForwardAddress')
                       || 'admin';

   my $interval = $loggerdemo{Interval} || 10;

   $OUT = "*/$interval * * * * root /usr/bin/logger";
   $OUT .= " -t \"Demo4\" \"... $admin_email ...\"\n";

   Note: The variable $OUT is a special variable used for output from a template. It is documented in the Text::Template documentation. For now, just think about it as the return value from the template, so set it to the value you want to print from this fragment. Note also that a template fragment can return static text without setting $OUT directly, as shown on the return line above.

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

   <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')" />
   </page>

   return $db->get_prop("loggerdemo", "status");

   return $db->get_prop("loggerdemo", "Interval");

   my $fm = shift;
   my $q = $fm->{'cgi'};

   $db->set_prop('loggerdemo', 'status', $q->param("loggerdemo_status"));
   $db->set_prop('loggerdemo', 'Interval', $q->param("loggerdemo_Interval"));

   unless ( system ("/sbin/e-smith/expand-template", "/etc/crontab") == 0 )
   {
       $fm->error('ERROR_UPDATING');
       return undef;
   }

   $fm->success('SUCCESS');

   Note: This code example calls expand-template. This is used for illustrative purposes only. All templates should be expanded by signalling events.

   cd /etc/e-smith/web/panels/manager/cgi-bin
   ln -s ../../../functions/loggerdemo loggerdemo

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

   <entry>
           <base>Demo</base>
           <trans>Demo</trans>
   </entry>

   <entry>
           <base>Logger</base>
           <trans>Logger</trans>
   </entry>

   <entry>
           <base>LABEL_LOGGERDEMO_STATUS</base>
           <trans>Status</trans>
   </entry>

   <entry>
           <base>ENABLED</base>
           <trans>Enabled</trans>
   </entry>

   <entry>
           <base>DISABLED</base>
           <trans>Disabled</trans>
   </entry>

   <entry>
           <base>SAVE</base>
           <trans>Save</trans>
   </entry>

   Note: The LABEL_LOGGERDEMO_INTERVAL tags has intentionally been left untranslated. Why don't you fix it now?

   Note: Panel implementation code should always signal events, and should never expand templates or modify files directly. These modifications should only be peformed in events.

   *

     You can create new configuration parameters.
   *

     You can add new configuration templates under /etc/e-smith/templates/.
   *

     You can add fragments to any of the existing templates under /etc/e-smith/templates/.
   *

     You can arrange for actions to be triggered upon package pre-install, post-install, pre-uninstall, or post-uninstall.
   *

     You can link new actions into the events listed in the Section called Standard events and their arguments in Chapter 7.
   *

     You can create new events to allow your feature set to be expanded. Do not create events for any other reason. They are not a replacement for function calls.
   *

     You can arrange for new server programs to be started up at boot time.
   *

     Typically you would expand a template at application post-install time, application post-uninstall time, and one or more of the other events.
   *

     You can add new web functions to the navigation bar. Remember, panels should only retrieve and modify database values, perform validation, and signal events.

   *

     Change the kernel or add new kernel modules.
   *

     Edit configuration files directly - templates must be used.
   *

     Link actions into any events other than the ones listed above or new events that you create. All built-in events other than the ones listed above are subject to change without notice in new SME Server releases.
   *

     Directly access the per-user email store (i.e. the Maildir and related subdirectories within each user's home directory). This access should be performed via the IMAP server as the location and format of a user's home directory may change between releases.
   *

     Take over the function of existing servers (i.e. shut down qmail and Apache and take over ports 25 and 80). The SME Server has features for proxying email and web requests to other servers on the system. 

  1.

     summary and description of the software
  2.

     package name
  3.

     version number
  4.

     copyright information
  5.

     category/group to which the software belongs
  6.

     name and email address of the packager
  7.

     pre-requisites to installing this package
  8.

     ... and more

  1.

     Software packages that are shipped as a standard part of the SME Server. You do not need to include any of these packages; they are always present in the runtime environment.
  2.

     Software packages that are not a standard part of the SME Server, but that are required by your software, and would also be of general use in the runtime environment. For example: a Java runtime environment, libraries that enable communication with devices, etc. If possible, these packages should be made into separate packages, rather than being included in your application. This makes it easier to share them with other applications and enforces version compatiblity.
  3.

     Software packages that are not a standard part of the SME Server, and that are specific to your software application (i.e. not generally useful in the runtime environment). This is the raw Linux version of your application without any specific SME Server integration code. For example, if your application is already available for Linux in the form of RPMs - these RPMs are what we are referring to. These are referred to as the application RPMs.
  4.

     Any new files that you have created specifically in order to integrate your application into the SME Server runtime environment - should be packaged into a single RPM, as explained in the next section. This is referred to as the integration RPM.

   Note: Shell/login access is disabled by default to enhance the security of the SME Server. Shell access should only be provided to users who require it and who can be trusted to maintain system security.

   The base material from which RPMs are built -- source code, tarballs, etc.

   Working area used by the rpmbuild program during RPM creation 

   Specification files for building RPMs

   Source RPMS (created by build process)

   Binary RPMS (created by build process). Has subdirectories noarch and i386 for architecture independent and x86 platforms respectively.

   Tip: As you start work on an RPM for version x.y.z of a package, create a subdirectory rpms/SOURCES/yourpackage-x.y.z/ to work in.

   mkdir rpms/SOURCES/yourpackage-x.y.z

   Under this directory there should be a subdirectory called root, under which is an image of the file hierarchy that will be installed by the RPM.

   mkdir rpms/SOURCES/yourpackage-x.y.z/root

  1.

     Choose a name and version number for your package. We are going to package the complete loggerdemo example and will use loggerdemo and 1.0.0 as the name and version number.
  2.

     Collect all of the files which have been created in the previous sections into the /tmp/ directory. There is one additional file createlinks which looks like this:

     #!/usr/bin/perl -w

     use esmith::Build::CreateLinks qw(:all);
     use File::Basename;

     my $panel = "manager";

     panel_link("loggerdemo", $panel);

  3.

     Create the directory hierarchy required for building the RPM. This is very close to the hierarchy on the installed system.

     # Change to the SOURCES directory
     cd ~/rpms/SOURCES

     # Remove old files (check that you don't need anything here!)
     rm -rf loggerdemo-1.0.0

     # Create new directory
     mkdir loggerdemo-1.0.0
     cd loggerdemo-1.0.0

     # The crontab template fragment
     mkdir -p root/etc/e-smith/templates/etc/crontab
     cp /tmp/25templatedemo root/etc/e-smith/templates/etc/crontab

     # The web panel description
     mkdir -p root/etc/e-smith/web/functions
     cp -p /tmp/loggerdemo !$

     # The web panel implementation
     mkdir -p root/usr/lib/perl5/site_perl/esmith/FormMagick/Panel
     cp -p /tmp/loggerdemo.pm !$

     # The web panel English localisation
     mkdir -p root/etc/e-smith/locale/en-us/etc/e-smith/web/functions
     cp -p /tmp/loggerdemo-en !$

     # The createlinks auxiliary file
     cp -p /tmp/createlinks .

     Your directory structure should now look like this:

     [gordonr@sevendev1 loggerdemo-1.0.0]$ find . -type f
     ./root/etc/e-smith/templates/etc/crontab/25templatedemo
     ./root/etc/e-smith/locale/en-us/etc/e-smith/web/functions/loggerdemo
     ./root/etc/e-smith/web/functions/loggerdemo
     ./root/usr/lib/perl5/site_perl/esmith/FormMagick/Panel/loggerdemo.pm
     ./createlinks

  4.

     Package the directory into a tarball:

     cd ~/rpms/SOURCES
     tar zcvf loggerdemo-1.0.0.tar.gz loggerdemo-1.0.0

  5.

     Create the RPM specification "SPEC" file ~/rpms/SPECS/loggerdemo.spec which looks like this:

     %define name loggerdemo
     %define version 1.0.0
     %define release 01

     Summary: SME Server logger demo
     Name: %{name}
     Version: %{version}
     Release: %{release}
     License: GPL
     Group: Networking/Daemons
     Source: %{name}-%{version}.tar.gz
     Packager: Fred Frog <red@example.com>
     BuildRoot: /var/tmp/%{name}-%{version}-%{release}-buildroot
     BuildArchitectures: noarch

     %description
     Logger Demo sample application.

     %changelog
     * Thu Feb 2 2006 Fred Frog <fred@example.com>
     - 1.0.0-01
     - Original version

     %prep
     %setup

     %build
     perl createlinks

     DEFAULTS=root/etc/e-smith/db/configuration/defaults/loggerdemo
     mkdir -p $DEFAULTS

     echo "service"  > $DEFAULTS/type
     echo "enabled"  > $DEFAULTS/status
     echo "10"       > $DEFAULTS/Interval

     %install
     rm -rf $RPM_BUILD_ROOT
     (cd root ; find . -depth -print | cpio -dump $RPM_BUILD_ROOT)
     rm -f %{name}-%{version}-filelist
     /sbin/e-smith/genfilelist $RPM_BUILD_ROOT > %{name}-%{version}-filelist

     %clean
     rm -rf $RPM_BUILD_ROOT

     %post
     /etc/e-smith/events/actions/initialize-default-databases
     /etc/e-smith/events/actions/navigation-conf
     /sbin/e-smith/expand-template /etc/crontab
     true

     %postun
     /sbin/e-smith/expand-template /etc/crontab
     true

     %files -f %{name}-%{version}-filelist
     %defattr(-,root,root)

     Note the %post (post-installation) and %postun (post-uninstallation) statements which expand the /etc/crontab template after installing or uninstalling the RPM.
  6.

     Check that your RPM will build OK with "build prepare":

     cd ~/rpms/SPECS
     rpmbuild -bp loggerdemo.spec

     The last line of output should be + exit 0 if rpmbuild is successful.
  7.

     Run the rpmbuild command again to actually create your RPM with the "build all" options:

     rpmbuild -ba loggerdemo.spec

     If everything was successful, the last line of output should again be + exit 0.
  8.

     The RPMs should have been generated and put into ~/rpms/RPMS/noarch/ as this program can run equally well on any platform. A source RPM should also exist in ~/rpms/SRPMS/.
  9.

     Test your RPM by installing it on an SME Server test box.

         Note: RPMs need to be installed as root, but you should not log in as the root user. Instead, you should create a normal user and provide them with 'root' privileges via the sudo command. To provide full sudo rights to the user joe, use the su - -c /usr/sbin/visudo and add the following line to the end of the file:

         joe    ALL=(ALL) ALL

         You can then use the sudo to run commands as root when required. You will be prompted for your password (not the root password) which ensures that someone else isn't using your terminal.

     [joe@sevendev1 SPECS]$ sudo rpm -Uvh \
         ~/rpms/RPMS/noarch/loggerdemo-1.0.0-01.noarch.rpm
     Preparing...                ########################################### [100%]
        1:loggerdemo             ########################################### [100%]
     Migrating existing database mailpatterns
     Migrating existing database hosts
     Migrating existing database configuration
     Migrating existing database yum_repositories
     Migrating existing database networks
     Migrating existing database yum_updates
     Migrating existing database yum_installed
     Migrating existing database spamassassin
     Migrating existing database accounts
     Migrating existing database backups
     Migrating existing database yum_available
     Migrating existing database domains

         Note: In almost all instances you should use the -U (upgrade) option to rpm instead of the -i (install) option. The -i option should be reserved for special operations, such as installing kernels.

     The customization should be fully installed, and the /etc/crontab file should show the customization. Then remove the customization:

     # remove the RPM
     sudo rpm -e loggerdemo

     The customization should be completely gone, and the /etc/crontab file should look the way it did before.

   email-update
   ldap-update
   network-create
   network-delete
   ))

   safe_symlink("sigusr1", "root/etc/e-smith/events/$event/services2adjust/imap");

   event_link("imap-relocate-maildirs", $event, "05");

   Note: Reminder: All files must be checked in using Unix text format.

   Note: You can view a complete list of the packages checked into SourceForge CVS http://smeserver.cvs.sourceforge.net/smeserver/. On rare occasions, the sources of particular packages may be slightly out of date as there is a small delay (typically only a few hours) between changes to the developer CVS and the anonymous CVS. In practice, this rarely matters and at worst it requires a merging of your changes with any other recent changes to the package.

   Note: Use mzgetsf if you have a SME Server developer account.

   *

     The SME Server project does not use the ChangeLog file as we maintain all of our changes in the %changelog section of the SPEC file.
   *

     The CVS directory contains CVS state information, such as the location of the CVS repository:

     [gordonr@smebuild smeserver-yum]$ ls CVS
     Entries  Entries.Log  Repository  Root

   *

     The F directory contains the SPEC for this package:

     [gordonr@smebuild smeserver-yum]$ ls F
     CVS  smeserver-yum.spec

   *

     The P directory contains any patches which are required to update the source in the tarball(s) to the current version:

     [gordonr@smebuild smeserver-yum]$ ls P
     CVS
     smeserver-yum-1.2.0-DisplayStatus.patch
     smeserver-yum-1.2.0-DisplayStatus.patch2
     smeserver-yum-1.2.0-ModifyUpdateDBs.patch

   *

     The S directory contains the source tarball(s):

     [gordonr@smebuild smeserver-yum]$ ls S
     CVS  smeserver-yum-1.2.0.tar.gz

   Note: The smeserver-yum subdirectory is a leftover from an incorrect package import. It can be ignored and will be removed when maintenance is next performed on the CVS repository.

   Tip: Ensure that you have copied any modified files out of your work tree prior to runing mzclean.

for my $key ( grep {!/^\./} readdir(DIR) )
{
    warn "Importing key $key\n";

    system("rpm", "--import", $key) == 0 or
       warn "Couldn't rpm --import $key\n";

   Note: Always run mzpatch from the top-level directory of your package (e.g. ~/smeserver/smeserver-yum/).

for my $key ( grep {!/^\./} readdir(DIR) )
{
    warn "Importing key $key\n";

    system("rpm", "--import", $key) == 0 or
       warn "Couldn't rpm --import $key\n";

   *

     Does the built package have your initials in the release tag? We never want to have two packages with the same name and version number.

     [gordonr@smebuild smeserver-yum]$ ls *.rpm
     smeserver-yum-1.2.0-05ff01.noarch.rpm  smeserver-yum-1.2.0-05ff01.src.rpm

   *

     Did you update the changelog? It's easy to forget, but vital to do.

     [gordonr@smebuild smeserver-yum]$ rpm -qp --changelog \
       smeserver-yum-1.2.0-05ff01.noarch.rpm | head -8

     * Mon May 22 2006 Fred Frog <fred@example.com> 1.2.0-05ff01

     - Initial work on avoiding duplicate RPM keys [SME: 1174]

     * Mon May 01 2006 Charlie Brady <charlieb@e-smith.com> 1.2.0-05

     - Remove stray yum.pm.orig file. [SME: 1350]

   *

     Did you remember to apply the patch? It happens, and leads to head scratching "I knew I made that change".

     [gordonr@smebuild smeserver-yum]$ mzbuild | grep patch
     + echo 'Patch #0 (smeserver-yum-1.2.0-DisplayStatus.patch):'
     Patch #0 (smeserver-yum-1.2.0-DisplayStatus.patch):
     + patch -p1 -s
     + echo 'Patch #1 (smeserver-yum-1.2.0-ModifyUpdateDBs.patch):'
     Patch #1 (smeserver-yum-1.2.0-ModifyUpdateDBs.patch):
     + patch -p1 -s
     + echo 'Patch #2 (smeserver-yum-1.2.0-DisplayStatus.patch2):'
     Patch #2 (smeserver-yum-1.2.0-DisplayStatus.patch2):
     + patch -p1 -s
     + echo 'Patch #3 (smeserver-yum-1.2.0-ImportKeysComment.patch):'
     Patch #3 (smeserver-yum-1.2.0-ImportKeysComment.patch):
     + patch -p1 -s

  1:smeserver-yum          ########################################### [100%]

   Note: Actually fixing bug 1174 is left as an exercise for the reader. Fame and fortune (or at least thanks) await the person who does.

   *

     Create a SourceForge user id
   *

     Contact the Development Manager (or one of the other project admins) listed on the SourceForge project page, detailing the packages you would like to work on
   *

     The project admin will add you as a developer
   *

     Upload an SSH2 key to SourceForge, following the SourceForge documentation: https://sourceforge.net/docs/F02/en/#key_posting
   *

     You will also need to generate another SSH2 key for access to the smebuild build server 

@@ Line 9: / Line 9: @@
 Wenn Du mehrere Computer in einem Home-Netzwerk, einen Internetanschluss durch DSL, Kabelmodem oder eine andere Internetverbindung hast, dann verwende einfach einen alten Computer (Pentium III aufwärts) und installiere darauf die SME Server software; Du kannst die alte Maschine dann als Server, Gateway/Router und Firewall verwenden.
-    Vorsicht: Die SME Server Software löscht alle Daten von dem PC, auf dem sie installiert wird. Der PC wird dadurch zu einem Server, der 24x7 Stunden läuft. Einen Installation sollte nur auf einem PC durchgeführt werden, der komplett gelöscht werden kann.
+  Vorsicht: Die SME Server Software löscht alle Daten von dem PC, auf dem sie installiert wird.
+Der PC wird dadurch zu einem Server, der 24x7 Stunden läuft. Einen Installation sollte nur auf einem PC durchgeführt werden, der komplett gelöscht werden kann.
 Alternatively, you can install the SME Server on a corporate LAN in server/gateway mode (creating a small private network behind a firewall that occupies a single IP address on the Internet) or in server-only mode - in which the SME Server provides network services to other computers as a peer on the network.

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

Revision as of 09:36, 25 December 2007

Contents

Kapitel 3: SME Server Pakete erstellen - Schritt für Schritt

Beginn

Customizing des SME Servers

Eigene RPM-Pakete erstellen

Die SME-Entwicklungsumgebung

Navigation menu

Page actions

Page actions

Personal tools

Koozali SME Server

Recent activities

Koozali resources

Koozali SME Server wiki

Tools

Search