You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Anpassungen an der Hardware

Im Gegensatz zu den anderen Maschinen, muss die Maschine die diese Rolle einnimmt eine weitere (virtuelle) Festplatte erhalten, die dem Zwecke dient, die Daten beherbergen zu können. Bevor also die virtuelle Maschine gestartet wird, muss dieser Maschine eine weitere virtuelle Festplatte mit einer vorher auf der Basis der Anforderungen festgelegte Größe hinzugefügt werden (üblicherweise zwischen 160 GB und 1 TB). Nach einem Neustart, wird die Festplatte vom Betriebssystem-Kern erkannt und die Installation kann nun fortgesetzt werden.

Einbinden der Datenplatte

Hinweis

Im nachfolgenden Abschnitt werden abweichend vom Standard dieser Dokumentation in den Code-Blöcken nicht nur die Befehle angegeben, sondern ein Mitschnitt der gesamten Operation, um auch die Ausgaben der Befehle exemplarisch zu zeigen, da diese von einiger Relevanz sind. Die einzugebenden Befehle befinden sich immer hinter dem Systemprompt [root@acd-lb ~]#

Damit die neue Festplatte genutzt werden kann, muss sie entsprechend initialisiert werden. Dafür muss erst mal festgestellt werden, unter welchem Gerätenamen die Platte im System erkannt wurde:

Auflisten der Festplatten-Gerätenamen
[root@acd-lb ~]# ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sda2  /dev/sdb
[root@acd-lb ~]#

Durch die Eingabe des Befehls ls /dev/sd* werden alle Gerätenamen bezüglich der aktuellen Festplatten aufgelistet. Der Befehl zeigt uns folgende Gerätenamen:

  1. /dev/sda => Erste Festplatte
  2. /dev/sda1 => Erste Partition der ersten Festplatte
  3. /dev/sda2 => Zweite Partition der ersten Festplatte
  4. /dev/sdb => Zweite Festplatte

Da die zweite Festplatte offensichtlich noch keine Partitionen hat, ist nun davon auszugehen, dass es sich hier um die neu hinzugefügte Festplatte handelt. Es wird nun das Partitionierungs-Programm gestartet, welches uns unter anderem auch anzeigt, ob wir mit dieser Platte die richtige ausgewählt haben:

Partitionierung - Teil 1
[root@acd-lb ~]# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x877ae737.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Command (m for help): p

Disk /dev/sdb: 171.8 GB, 171798691840 bytes
255 heads, 63 sectors/track, 20886 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x877ae737

   Device Boot      Start         End      Blocks   Id  System

Command (m for help):

Nach dem Starten des Partitionierungs-Programmes kann man sich durch Eingabe des Befehls p die Partitionierungstabelle der Festplatte anschauen. Die ist erwartungsgemäß leer - aber die wichtige Information ist, dass die Platte mit dem Gerätenamen /dev/sdb 171.8 GB groß ist. Da dies der erzeugten Größe entspricht, wissen wir, dass es sich um die richtige Platte handelt (das Tool rechnet übrigens mit 10er Potenzen. Aus diesem Grunde wird die Platte, die im vSphere Client, der in 2er Potenzen rechnet mit 160GB angelegt wurde als 171.8 GB angezeigt).

Hinweis

Wenn die Maschine auch über ein CD/DVD Laufwerk (egal ob virtuell oder physisch) verfügt, so wird dieses höchstwahrscheinlich auch als Massenspeichergerät ohne Partitionstabelle in der Liste auftauchen (z.B. /dev/sdc). Versucht man dieses mit dem Partitionierungstool zu bearbeiten, wird es eine entsprechende Fehlermeldung geben. Die Anzeige des Befehls p wird auch keine ensprechenden Informationen anzeigen. Letztendlich muss man ausprobieren, welcher Gerätenamen nun der Festplatte entspricht.

 

Es wird nun eine Partition angelegt, die die ganze Platte umfasst und vom Typen 83 ist. Die Partitionstabelle wird geschrieben und das Tool beendet:

Partitionierung - Teil 2
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-20886, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-20886, default 20886):
Using default value 20886

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 83

Command (m for help): p

Disk /dev/sdb: 171.8 GB, 171798691840 bytes
255 heads, 63 sectors/track, 20886 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x877ae737

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       20886   167766763+  83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
[root@acd-lb ~]#

Ein erneuter Aufruf des Befehls ls /dev/sd* zeigt nun, dass die neue Partition vom Kernel erkannt wurde:

Erneutes Auflisten der Festplatten-Gerätenamen
[root@acd-lb ~]# ls /dev/sd*
/dev/sda  /dev/sda1  /dev/sda2  /dev/sdb  /dev/sdb1
[root@acd-lb ~]#

Die Partition kann nun mit dem Gerätenamen /dev/sdb1 angesprochen werden. Auf der Partition muss nun ein Filesystem erzeugt werden (Formatieren). Da diese Partition extrem viele kleine und große Dateien beherbergen soll, wird hierfür ein für die Aufgabe optimiertes Filesystem genommen, und zwar XFS. Das erzeugen des Filesystems erfolgt durch die Eingabe folgenden Befehls:

Erzeugen des Filesystems
[root@acd-lb ~]# mkfs.xfs -L data /dev/sdb1
meta-data=/dev/sdb1              isize=256    agcount=4, agsize=10485423 blks
         =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=4096   blocks=41941690, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=20479, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

Falls der Befehl nicht gefunden wird, muss das Packet nachinstalliert werden.

  rpm -qa |grep xfsprogs

  yum -y install xfsprogs

Nachdem das Filesystem nun erzeugt wurde, muss es noch im globalen Namensraum eingehängt werden, und zwar so, dass es auch nach einem Neustart des Systems wieder zur Verfügung steht. Da alle Prozesse des jtel-Systems im Kontext des Benutzers jtel laufen, bietet es sich an, den Zweig /home komplett in das neue Filesystem unterzubringen. Ein kurzer Aufruf auf den Ordner zeigt allerdings, dass in diesem schon Dateien vorhanden sind:

Prüfung des Inhalts von /home
[root@acd-lb ~]# ls -la /home
total 12
drwxr-xr-x.  3 root root 4096 Jun  9 09:04 .
dr-xr-xr-x. 23 root root 4096 Jun  9 19:01 ..
drwx------.  3 jtel jtel 4096 Jun  9 09:05 jtel
[root@acd-lb ~]#

Wie man sehen kann, befindet sich unter /home bereits das Home-Verzeichnis vom Benutzer jtel. Würde man nun auf /home die neue Platte einhängen, würden die bereits vorhandenen Daten nicht mehr sichtbar sein, da sie sich ja nicht auf dem neuen Volumen befinden. Diese müssen also erst mal irgendwo anders untergebracht werden. Da sich dort noch sehr sehr wenige Daten befinden, kann das Home-Verzeichnis vom Benutzer jtel kurz mal ins Home-Verzeichnis vom Benutzer root bewegt werden:

Sichern der Daten auf /home
[root@acd-lb ~]# ls -la /home
total 12
drwxr-xr-x.  3 root root 4096 Jun  9 09:04 .
dr-xr-xr-x. 23 root root 4096 Jun  9 19:01 ..
drwx------.  3 jtel jtel 4096 Jun  9 09:05 jtel
[root@acd-lb ~]# mkdir /root/backup
[root@acd-lb ~]# mv /home/* /root/backup
[root@acd-lb ~]#

Es wurde nun ein neues Verzeichnis backup im Home-Verzeichnis des Benutzers root angelegt. Mit dem zweiten Befehl wurde der gesamte Inhalt des Verzeichnis /home ins Verzeichnis /root/backup bewegt. Das neue Volumen wird nun in die Tabelle der automatisch eingehängten Volumen eingetragen, so dass es automatisch beim Start eingehängt wird. Dafür wird eine folgende Zeile ans Ende der Datei /etc/fstab eingefügt:

Neuer Eintrag in /etc/fstab
/dev/sdb1	        /home	                xfs	noatime,nodiratime	0	0

Jede Zeile besteht aus 6 Werten, die entweder mit Leerstellen oder Tabs getrennt werden. Diese Bedeuten im Spezifischen Fall:

  1. Das Volumen mit dem Gerätenamen /dev/sdb1
  2. wird im globalen Namensraum unter /home eingehängt
  3. unter Benutzung des Filesystem-Treibers für XFS
  4. mit den Attributen noatime und nodiratime (wobei nodiratime in noatime enthalten ist, so dass nicht beides definiert werden muss)
  5. Intervallzähler für "dump"-Operationen, falls das Filesystem das unterstützt
  6. Reihenfolge für die Integritätsprüfung beim Systemstart

Damit das Volumen sofort eingehängt wird, muss nun noch folgender Befehl eingegeben werden:

Sofortiges Einhängen
[root@acd-lb ~]# mount /home
[root@acd-lb ~]#

Das Fehlen einer jeglichen Ausgabe ist die üblich sachliche Art von Unix darauf hinzuweisen, dass der Befehl erfolgreich ausgeführt wurde (Unix "spricht" in der Regel nur, wenn was schief gegangen ist). Um sich des Erfolges zu versichern, kann man sich mal die Auslastung des Filesystems mit folgendem Befehl anschauen:

Test
[root@acd-lb ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_centos6-lv_root
                       14G  1.1G   12G   8% /
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/sda1             477M   81M  371M  18% /boot
/dev/sdb1             160G   33M  160G   1% /home

Hier kann man deutlich sehen, dass der Zweig /home 160GB umfasst, was der beweis ist, dass das neue Volumen erfolgreich eingehängt wurde.

Nun ist es an der Zeit, die Dateien wieder an ihrem angestammten Ort zu befördern:

Zurückspeichern der Daten auf /home
[root@acd-lb ~]# mv /root/backup/* /home
[root@acd-lb ~]# restorecon -R -v /home
restorecon reset /home context system_u:object_r:file_t:s0->system_u:object_r:home_root_t:s0
restorecon reset /home/jtel/.inputrc context unconfined_u:object_r:admin_home_t:s0->unconfined_u:object_r:user_home_t:s0
[root@acd-lb ~]# rmdir /root/backup
[root@acd-lb ~]#

Der erste Befehl bewegt die Daten zurück. Damit ist es aber noch nicht gemacht, denn bei dieser Operation sind die SELINUX-Security-Labels der Dateien abhanden gekommen. Um dieser wieder herzustellen, dient der zweite Befehl. Der dritte Befehl löscht dann das übrig gebliebene Sicherungsverzeichnis /root/backup.

Es kann nun mit der Installation und Konfiguration der benötigten Software fortgefahren werden.

Installation der benötigten Softwarepakete

Für den Betrieb der Rolle STORE muss lediglich das Softwarepaket samba installiert werden, welches den geteilten Dateibereich mittels des SMB/CIFS Protokoll zur Verfügung stellt. Dies wird durch Ausführung des folgenden Befehls erreicht:

Installieren von Samba
yum -y install samba

Nach der Installation kann mit der Konfiguration der Software fortgefahren werden.

Konfiguration der Software

Als erstes wird das geteilte Verzeichnis angelegt, und dem Benutzer jtel als Besitzer zugewiesen:

Anlegen des geteilten Verzeichnisses
mkdir /srv/jtel
mkdir /srv/jtel/shared
chown jtel:jtel /srv/jtel/shared
sudo -u jtel ln -s /srv/jtel/shared /home/jtel/shared

Die Samba Konfigurationsdatei wird gesichert, und ein neues angelegt:

/etc/samba/smb.conf
cp -a /etc/samba/smb.conf /etc/samba/smb.conf.orig
cat <<EOFF > /etc/samba/smb.conf
[global]
        workgroup = SAMBA
        security = user
 
        passdb backend = tdbsam
        printing = cups
        printcap name = cups
        load printers = yes
        cups options = raw
        min protocol = NT1
        ntlm auth = yes

[homes]
        comment = Home Directories
        valid users = %S, %D%w%S
        browseable = No
        read only = No
        inherit acls = Yes

[printers]
        comment = All Printers
        path = /var/tmp
        printable = Yes
        create mask = 0600
        browseable = No

[print$]
        comment = Printer Drivers
        path = /var/lib/samba/drivers
        write list = root
        create mask = 0664
        directory mask = 0775
EOFF
 
cat <<EOFF | sudo tee -a /etc/samba/smb.conf
[shared]
    comment = jtel ACD Shared Directory
    read only = no
    public = yes
    writable = yes
    locking = yes
    path = /srv/jtel/shared
    guest ok = yes
    create mask = 0644
    directory mask = 0755
    force user = jtel
    force group = jtel
EOFF
 
if (grep -q "VERSION_ID.*7" /etc/centos-release); then
cat <<EOFF | sudo tee -a /etc/samba/smb.conf
    acl allow execute always = True
EOFF
 
fi

Die Einträge ("force user" und "force group" stellen sicher, dass alle Dateien die über die Freigabe erzeugt, kopiert oder geändert werden, im Filesystem immer unter dem Benutzer jtel angelegt bzw. angesprochen werden, unabhängig davon, welcher Benutzer sich auf die Freigabe anmeldet. Dies stellt sicher, dass auch bei abweichenden Windows-Login-Namen die Berechtigungen im Filesystem intakt bleiben. Die Optionen "create maske" und "directory mask" werden gesetzt, damit alle Dateien und Verzeichnisse, die angelegt werden, die Berechtigung von Linux erhalten, selbst wenn sie von Windows aus angelegt werden. Es werden die Rechte über Bist vergeben, so bedeuten die Werte 0644 und 0755 folgende Biteinstellungen: 0755 = -rwxr-xr-x. und 0644 = -rw-r--r–.

Damit samba auch Zugriff auf Dateien im /home Bereich erhält, müssen noch einige Variablen des SELINUX Security Frameworks konfiguriert werden:

Hinweis

Der nachfolgende Befehl dauert relativ lange, da die betroffenen Sicherheitsregelwerke dadurch neu kompiliert werden.

SELINUX Konfiguration
setsebool -P samba_enable_home_dirs=on samba_export_all_rw=on use_samba_home_dirs=on use_nfs_home_dirs=on

Sollte SELinux deaktiviert sein, so kann es in der Datei /etc/sysconfig/selinux entsprechend umgestellt werden. Hier den Eintrag mit "SELINUX=disabled" suchen und durch den Wert "SELINUX=permissive" ersetzen. Der Server muss dann neu gestartet werden.

In der Samba-Benutzerdatenbank müssen nun die für das CIFS-Protokoll zusätzlich benötigten Benutzerattribute erzeugt werden. Da im System bereits der Benutzer jtel für alle Prozesse und Netzwerkzugriffe vorgesehen ist, erfolgt dies erst mal für diesen Benutzer so dass alle Maschinen sich als Benutzer jtel an die Freigabe anmelden können:

Samba Benutzer anlegen
(echo fireball; echo fireball) | smbpasswd -a jtel -s

Das Programm verlangt dann die zweimalige Eingabe des Passwort, was der Benutzer jtel für Netzzugriffe über das CIFS-Protokoll erhalten soll. Damit die Benutzung der Freigabe unter Windows ohne eine gesonderte Anmeldung erfolgen soll, ist hier das Passwort einzugeben, welches der lokale Benutzer jtel auf den Windows-Maschinen erhalten hat. Im Falle unserer Musterinstallation wäre dies der Benutzer jtel mit dem Passwort F1r3ball.

Im Falle, dass auf den Windows-Maschinen hingegen ein anderer Benutzername angelegt wurde, oder gar die Maschinen in einer Domäne angemeldet wurden, und die jtel Programme unter einem dafür spezifisch angelegten Domänen-Benutzer laufen sollen, so muss ein gleichnamiger Benutzer angelegt werden. Dies muss erst mal auf Systemebene erfolgen und danach können dann die Zusatzdaten in die Samba-Benutzerdatenbank erzeugt werden. Das Nachfolgende Beispiel zeigt dies an Hand des Benutzers robot5.

Anlegen weiterer Benutzer
useradd -m robot5
(echo fireball; echo fireball) | smbpasswd -a robot5 -s

Es können so beliebige weitere Benutzer angelegt werden. Unabhängig davon, welcher dieser Benutzer für die Anmeldung zur Freigabe benutzt wird, werden alle Dateien im zentralen Datenverzeichnis durch die spezielle Konfiguration der Freigabe dem Benutzer jtel zugewiesen.

Als nächstes müssen in der Firewall die Port-Freigaben für den Samba-Dienst eingetragen und persistent gespeichert werden (ggf. muss der Index 4 auf 1, 2 oder 3 gesetzt werden, je nachdem, wie viele Firewall-Regeln vorhanden sind; Fehler: iptables: Index of insertion too big.):

Firewall konfigurieren
iptables -I INPUT 4 -p tcp -m tcp --dport 445 -j ACCEPT
iptables -I INPUT 4 -p tcp -m tcp --dport 139 -j ACCEPT
iptables -I INPUT 4 -p udp -m udp --dport 138 -j ACCEPT
iptables -I INPUT 4 -p udp -m udp --dport 137 -j ACCEPT
service iptables save

Zum Abschluss müssen nun die Samba-Dienste nur noch für den automatischen Start konfiguriert werden, und gestartet werden:

Samba Dienste Registrieren und Starten
chkconfig nmb on
chkconfig smb on
service nmb start
service smb start

Abschließende Tests

Um zu verifizieren, dass die Rolle STORE korrekt installiert wurde, sollte erst mal ein grundsätzlicher Funktionstest ausgeführt werden. Der einfachste Test, kann z.B: von einer Windows-Maschine ausgefürt werden, in dem einfach versucht wird, auf die Freigabe zuzugreifen. Dies kann z.B. aus dem Windows-Explorer erfolgen in dem der UNC ( \\ACD-LB\shared ) der Freigabe in die Pfadzeile eingegeben wird:

Im Idealfall wird sich das freigegebene Verzeichnis ohne weitere Nachfragen öffnen. Abschließend sollte noch geprüft werden, dass die WIndows Maschine im Verzeichnis schreiben kann, und dass die erzeugten Dateien mit den korrekten Attributen ins Zielverzeichnis gelangen. Dafür reicht es im Explorer mittels Rechtsklick ein Verzeichnis und eine Textdatei anzulegen.

Aus Sicht der Linux-Maschine sollten sich die erzeugten Dateien folgendermaßen zeigen:

Testdateien im Linux-Filesystem
[root@acd-lb ~]# ls -la /home/jtel/shared/
total 4
drwxr-xr-x. 3 jtel jtel   51 Jun 12 15:44 .
drwx------. 4 jtel jtel 4096 Jun  9 20:31 ..
drwxr-xr-x. 2 jtel jtel    6 Jun 12 15:44 New folder
-rw-r--r--. 1 jtel jtel    0 Jun 12 15:44 New Text Document.txt

Wie man hier sehen kann, sind sowohl die Testdatei als auch das Testverzeichnis vorhanden und mit den korrekten Berechtigungen (Dateien => 644 => rw,r,r Verzeichnisse => 755 => rwx,rx,rx) erzeugt wurden. Die Testdateien können nun gelöscht werden:

Löschen der Testdateien
rm -rf /home/jtel/shared/*

Installation der Meta-Rolle Software

In einem Standard-Installations-Szenario wird in der Zentral-Freigabe der Rolle STORE auch eine Kopie der Software-Repositories abgelegt. Diese ist demnach von allen Maschinen des jtel Systems erreichbar. Der Zugriff auf die Software-Repositories dient verschiedenen Zwecken:

  1. Alle Maschinen der Rolle TEL können die Telefonie-Applikationen (R5-Skripte) direkt von dieser zentralen Freigabe heraus ausführen. Alternativ können diese Komponenten der Software auch von der zentralen Freigabe lokal auf die Windows-Maschinen kopiert werden um den Netzwerkverkehr im laufenden Betrieb zu reduzieren. Dies erfordert allerdings zusätzliche Sorgfalt beim aktualisieren des Systems, da in diesem Fall nach dem Aktualisieren des Repositories die entsprechenden Verzeichnisse mit den R5-Skripten auf allen Windows-Maschinen kopiert werden müssen.
  2. Im Falle der Erstinstallation oder späteren Aktualisierungen, werden von hier die Datenbank-Initialisierungs- bzw. Datenbank-Aktualisierung-Skripte ausgeführt.
  3. Weitere Software-Komponenten die auf verschiedenen Maschinen lokal installiert werden (z.B. Konnektoren, Plugins, UDP Listener) werden von hier kopiert und aktualisiert

Installation benötigter Zusatzsoftware

Für die Bereitstellung und Aktualisierung des jtel Software-Repositories muss zusätzliche Software installiert werden. Da diese nicht nur aus den offiziellen CentOS Paketquellen bezogen werden kann, müssen noch weitere Software-Quellen konfiguriert werden:

Installieren zusätzlicher Softwarequellen
yum -y install http://dev.mysql.com/get/mysql-community-release-el6-5.noarch.rpm
yum -y install http://mirror1.hs-esslingen.de/repoforge/redhat/el6/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el6.rf.x86_64.rpm

yum -y install yum-utils
yum-config-manager --enable rpmforge-extras


Diese Befehle konfigurieren im Paketmanager zusätzliche Paketquellen (Offizielles Oracle MySQL Repository und das RPMforge Repository). Für die Installation des benötigten Tools git muss noch eine weitere Softwarequelle händisch aktiviert werden. Dies erfolgt durch Editieren der Datei /etc/yum.repos.d/rpmforge.repo in der der Wert enabled im Abschnitt rpmforge-extras auf 1 zu setzen ist: 

Aktivieren des rpmforge-extras Repositories
[rpmforge-extras]
...
enabled = 1

Anschließend kann die benötigte Software installiert und konfiguriert werden:

GIT installieren und konfigurieren
yum -y install git mysql-community-client
git config --global user.name "jtel Support"
git config --global user.email "support@jtel.de"
cp ~/.gitconfig /home/jtel
chown jtel:jtel /home/jtel/.gitconfig

Erstmaliges Herunterladen der jtel Software

Die folgenden Operationen erfolgen nicht mehr im Kontext des Benutzers root sondern müssen im Kontext des Benutzers jtel ausgeführt werden. Dafür kann man sich entweder in einer separaten SSH Sitzung als Benutzer jtel anmelden oder, wenn man bereits als Benutzer root angemeldet ist, in den Kontext des Benutzers jtel wechseln. Dies erfolgt durch folgenden Befehl:

Benutzerkontext wechseln
su jtel
cd

Nach Eingabe dieser Befehle erkennt man den Benutzerwechsel am Systemprompt, welches nun [jtel@acd-lb ~]$ lautet (Das Systemprompt setzt sich zusammen aus benutzername@hostname aktuelles Verzeichnis) Als nächstes werden nun die beiden Software-Repositories mit der jtel Standardsoftware heruntergeladen.

Dies erfolgt durch Eingabe folgender Befehle:

!!! MOMENTAN NUR DIE ENTWICKLUNGSREPOSITORIES ZIEHEN !!!

Herunterladen der Standard-Repositories
cd /home/jtel/shared
git clone https://git.jtel.de/scm/jtel/distribute-2.git JTEL
git clone https://git.jtel.de/scm/jtel/distribute-1.git JTELCarrierPortal

Alternativ kann die Software auch von den Entwicklungs-Repositories inklusive Quellcode bezogen werden. Hier ist allerdings die Wahrscheinlichkeit sehr hoch, dass die beiliegenden Binärdateien nicht aktuell sind. Installiert man von den Entwickler-Repositories, empfiehlt es sich die Binärdateien ad-hoc herzustellen. Das Herunterladen aus den Entwicklungs-Repositories erfolgt mit folgenden Befehlen:

 

Herunterladen der Entwicklungs-Repositories
cd /home/jtel/shared
git clone https://git.jtel.de/scm/jtel/jtel.git JTEL
git clone https://git.jtel.de/scm/jtel/carrierportal_jtel.git JTELCarrierPortal

Hinweis - wenn man ein Proxy für GIT braucht:

Proxy für GIT
sudo git config --global http.proxy http://<proxy_server>:<port>

Hinweis

Beide Befehle erfordern die Kenntnis gültiger Zugangsberechtigungen zum zentralen jtel Software-Server.

Im Falle dass für den Kunden noch spezifische Anpassungen oder Erweiterungen programmiert wurden, muss zusätzlich das Kundenspezifische Software-Repository heruntergeladen werden. Dies erfolgt exemplarisch durch einen Befehl der folgendermaßen aufgebaut ist:

Herunterladen eines kundenspezifischen Repositories
cd /home/jtel/shared
git clone https://git.jtel.de/scm/cacme/software.git acme

Sowohl die Ursprungs-URL als auch das Zielverzeichnis sind in diesem Fall kundenspezifisch und von Fall zu Fall verschieden.

In den Heruntergeladenen Software-Repositories muss nun noch das beim Kunden zu installierende Software-Release ausgewählt werden. In diesem Fall ist es das Release 3.06:

Gewünschtes Release auswählen
cd /home/jtel/shared/JTELCarrierPortal
git checkout release/stable-3.10
cd /home/jtel/shared/JTEL
git checkout release/stable-3.10
cd /home/jtel/shared


Als letzter Schritt werden nun noch die Verzeichnisse für die zentrale Protokollierung, den Standard-Datenimport und das zentrale Datenverzeichnis angelegt:

Datenverzeichnisse vorbereiten
cd /home/jtel/shared
mkdir -p LogFiles LogFilesCall Import/{Clients,ServiceNumbers}/{Done,In,Problems}
cp -a JTELCarrierPortal/Data .
cp -a JTEL/Data/system/gui Data/system

Alte Installationen mit Windows Share

Bei alten Installationen, die ein Windows Share haben, wird bei ein Windows Update das SMBv1 Protokoll deaktiviert. Dies muss wieder aktiviert werden, im Powershell als administrator:

SMB Share v1 auf Windows ermöglichen
Set-SmbServerConfiguration -EnableSMB1Protocol $true
  • No labels