dafjt~êéåïáêíëåü~ñí=okm péêîéêjfåëí~ää~íáçå=ìåíéê=pìpb=iáåìñ

Transkript

1 :-)) dafjt~êéåïáêíëåü~ñí=okm péêîéêjfåëí~ää~íáçå=ìåíéê=pìpb=iáåìñ Diese Anleitung kann frei verwendet werden, sofern der Hinweis auf die Urheber unverändert bleibt und die Information frei verfügbar gemacht wird. Aktualisierte Versionen finden Sie ggf. auf der unten genannten Webseite. Änderungen, Erweiterungen und Korrekturen an diesem Dokument sind dem Autor vor der Veröffentlichung mitzuteilen. Hierzu können Sie auch offene Daten dieses Dokuments anfordern. Ich übernehme keine Gewähr für die Vollständigkeit und Richtigkeit der hier gemachten Angaben. Sie verwenden diese Informationen auf eigene Gefahr. Sven Hamel Johannisstraße Köln Tel.: (0221) Fax: (089)

2 wáéä Wir setzen, wie vermutlich zahlreiche mittelständische Unternehmen in der IT, Linux-Server ein. Bereits die GDIline Auftrag & Warenwirtschaft 1.8 wurde auf einem SuSE Linux Server betrieben, weshalb auch die Version 2.x dort laufen soll. Es sollen die Lizenzkosten für den Windows Server eingespart werden, wofür wir Mehraufwand für die Installation in Kauf nehmen. Als Grundlage habe ich auf das HOW-TO: GDI Warenwirtschaft und Fibu unter SoL 18.0, Version 0.1 (2004) [multitask] der Firma multitask ( ) zurückgegriffen. Es bildet daher die geistige Grundlage zu dieser Beschreibung. Vielen Dank dafür! bêñçêçéêåáëëé 2 von 6 Die Hardware sollte ausreichend stark bemessen sein, um eine aktuelle Linux Distribution betreiben zu können. Ein Pentium III Prozessor mit 800MHz und 512MB RAM zusammen mit einer Festplatte ab 10GB sollten aber schon zahlreiche Benutzer vertragen. Es kommt die SuSE Linux 9.2 Professional bzw. SuSE Linux Enterprise Server 9 (SLES9) Distribution [SuSE] zum Einsatz. Es wird ein Minimales System benötigt. YaST2 als Konfigurationssystem und eine graphische Oberfläche (z.b. KDE oder Gnome) erleichtern die Systemverwaltung, sind aber nicht unbedingt nötig. Zur Bereitstellung der Dateidienste kommt das mitgelieferte Samba 3 [Samba] zum Einsatz. Außerdem wird der Datenbank-Server Firebird (ehem. InterBase) [FireBird] eingesetzt. Natürlich benötigen Sie auch eine Version der GDI Auftrag & Warenwirtschaft 2.x [GDI], das Kernstück der Installation. Auf Möglichkeiten, den Server aus der ferne zu verwalten, gehe ich nicht weiter ein. sçêäéêéáíìåö Der Server muss über das Netz erreichbar sein. Z. B. ping <ip-adresse> _ÉåìíòÉê= Für die Zugriffsteuerung auf die Daten von GDI verwenden wir die Gruppe gdi im Linux- System. Diese legen wir per YaST an. Anschließend legen wir mit YaST einen Benutzer gdiadm an, der als Testaccount für den Zugriff benutzt wird. Er gehört der Gruppe users und zusätzlich der Gruppe gdi an. Später muss entsprechend dem verwendeten Samba Modus, eventuell ein Eintrag für jeden Benutzer angelegt werden. In diesem konkreten Fall kommt eine Domänen-Authentifizierung über einen NT-Server durch winbind zum Einsatz. Die Konfiguration wird in der Samba Dokumentation ausführlich beschrieben. Außerdem muss der angelegte Benutzer in die Samba Benutzerverwaltung aufgenommen werden. Der Befehl smbpasswd -a gdiadm

3 3 von 6 erledigt dies. Das Passwort wird auf gdiadm festgelegt. mñ~çé Die Daten sollen im Pfad /srv/samba/gdi abgelegt werden. Dazu wird dieses angelegt mit cd /srv mkdir samba mkdir samba/gdi und erhält über chown gdiadm:gdi /srv/samba/gdi -R chmod 770 /srv/samba/gdi -R die richtigen Rechte gesetzt. p~ãä~ Samba wird installiert und die Konfiguration wird um folgende Einträge erweitert: [gdi] path = /srv/samba/gdi comment = GDI valid users force group = gdi read only = no guest ok = no create mask = 0770 directory mask = 0770 Damit steht nach einem Neustart der Samba-Prozesse rcsmb restart;rcnmb restart und ggf. rcwinbind restart eine neue Freigabe für die Rechner im Netzwerk unter dem Namen gdi zur Verfügung. Über die Netzwerkumgebung kann man sich von der Existenz überzeugen. Eventuell braucht das Browsing aber noch eine Weile (bis zu 15 Minuten), bis die Freigabe auftaucht. a~íéåä~åâ Die Firebird Datenbank wird in der FirebirdSS-Version heruntergeladen und über rpm -i <rpmname> (hier: rpm -i FirebirdSS i686.rpm bzw. rpm -i FirebirdSS i686.rpm unter SLES9) installiert. Dabei werden die Daten in das Verzeichnis /opt/firebird installiert. Anschließend werden einige Anpassungen für GDI vorgenommen. Die firebird.conf im Verzeichnis /opt/firebird wird ergänzt durch die Einträge: RemoteServiceName=gdi_db RemoteServicePort=23050 DefaultDbCachePages=8192 Eventuell muss der Benutzer root Schreibrecht auf die Datei erhalten mit

4 chmod u+w /opt/firebird/firebird.conf. Diese Änderung sollte nach der Änderung rückgängig gemacht werden (...u-w...). 4 von 6 Die zusätzlichen Datei gdi_udf.so wird in das Verzeichnis /opt/firebird/udf kopiert. Diese erhalten Sie von Ihrem GDI Servicepartner! In diesem Fall die Alternaiv GmbH [Alternaiv] aus Polheim bei Gießen. Die Rechte werden den anderen _udf.so Dateien angeglichen: chmod ugo+x /opt/firebird/udf/gdi_udf.so Die Datei libgdi_udf.so wird in /usr/lib abgelegt und die Rechte entsprechend angepasst. Jetzt müsse wir den Firebird Server neu starten, damit er die Konfigurationsänderungen berücksichtigt. Da der Firebird SuperServer über einen Wachhund verfügt, der den Prozess beim Beenden direkt neu startet, müssen wir einen etwas weniger schönen Weg gehen. Zuerst schauen wir uns die Prozesse an und beenden dann zunächst den fbguard-prozess und danach den fbserver Prozess mit: ps axu grep fb werden die Prozesse mit Ihrer Prozessnummer und weiteren Informationen in der Form: firebird pts/2 S 14:30 0:00 /opt/firebird/bin/fbguard -forever firebird ? S1 14:30 0:00 /opt/firebird/bin/fbserver angezeigt. Die ersten Zahlenangaben, hier 6845/6846, sind die Prozessnummern (PID), die wir über den Befehl: kill <PID fbguard> (hier: kill 6845) kill <PID fbserver> (hier: kill 6846) beenden. Danach starten wir die Dienste über das Startskript rcfirebird wieder. Jetzt prüfen wir noch, ob der Dienst auch im Netzwerk sichtbar ist. Der Befehl netstat -an grep 3050 liefert alle Dienste, deren Zeile die Zeichenfolge 3050 enthalten. Wir hoffen auf (mindestens) eine Zeile mit dem Inhalt: tcp : :* LISTEN die uns verrät, dass hier ein Dienst auf Port auf Anfragen aus dem Netz lauscht. Der Datenbank-Server läuft, ist aber für GDI noch nicht nutzbar, da wir das Kennwort noch auf einen Standardwert setzen müssen. Bei der Installation per Redhat Packet Manager (RPM) wird automatische ein Zufallspasswort für SYSDBA vergeben. Dieses notieren wir uns aus der Datei /opt/firebird/sysdba.password. Mit dem Kommando cat /opt/firebird/sysdba.password sehen wir uns die Inhalte an. Die Zeile ISC_PASSWD= interessiert uns am meisten. GDI greift allerdings mit dem Passwort masterkey auf den Server zu, da dies in der Standardinstallation unter Windows so ist. Daher müssen wir auch hier das Passwort auf diesen Standard ändern.

5 5 von 6 Das Kommando /opt/firebird/bin/changedbapassword.sh ruft den Änderungsdialog auf. Ist der Versuch von Erfolg gekrönt keine Fehlermeldungen aber die Warnung, dass nur acht Zeichen des Passwortes verwendet wurden müssen wir den Datenbankserver wieder neu starten. Die Datenbank läuft und funktioniert für GDI! ^åïéåçìåö=dafjt~êéåïáêíëåü~ñí=áåëí~ääáéêéå Jetzt kopieren wir eine neue Installation von einem Windows-Rechner in das Verzeichnis GDI auf dem Server. Die Dateieigenschaften und -berechtigungen für die Datenbank GDI.GDB setzen wir mit chmod u+rw g+rw o-rwx GDI.GDB; chown firebird:gdi GDI.GDB auf den Eigentümer firebird, die Gruppe gdi und die Berechtigungen rw- rw Diese Gruppen-Schreibrechte werden ggf. für Rücksicherungen durch berechtigte Mitarbeiter benötigt. Wichtig: Auch auf das Verzeichnis, in dem die Datenbank liegt, muss der Benutzer firebird Zugriffsrechte haben. Ich Übereigne ihm das Verzeichnis mit chown firebird:gdi <MandantenVerzeichnis>. Beim starten der Anwendung GDI.EXE vom Netzlaufwerk wird falls erforderlich im Login Feld der Benutzer admin mit dem gesetzten Passwort eingegeben. Danach auf den Button Auswahl klicken. Vorhandene Mandanteneinträge werden mit <Strg><Entf> gelöscht und über den Button Neuanlage wird ein neuer Mandant angelegt oder der DemoMandant ausgewählt und die Datei GDI.GDB neu erstellt bzw. aktualisiert. Wenn Sie mit einer Maske zur Eingabe der Mandanteninformationen begrüßt werden, sind sie am Ziel eine lauffähige GDI Warenwirtschaft. Gratulation!

6 Literaturverzeichnis multitask: multitask, HOW-TO: GDI Warenwirtschaft und Fibu unter SoL 18.0, 2004 SuSE:,,, Samba:, Samba Projekt,, FireBird:,,, GDI:,,, Alternaiv:,,, 6 von 6 Änderungen: : Dateiberechtigungen GDI.GDB angepasst : Dateiberechtigungen GDI.GDB für Rücksicherung angepasst : SuSE Linux Enterprise Server 9 und Fehlerbereinigungen hinzugefügt