Howto:Hosting with V10

From innovaphone wiki
Jump to navigation Jump to search

Dieses Dokument beschäftigt sich mit der prinzipiellen Funktionsweise der Hosting-Komponenten Ala Cloudkom. Konkrete Konfigurationsdaten finden sich dagegen in Abschnitt Globe Installation.

Gesamtübersicht

Für jeden Kunden wird eine dedizierte PBX (IPVA) aufgebaut. Jeder Kunde hat genau eine solche PBX (also keine Slaves). Weitere Dienste werden durch mandantenfähige Anwendungen bereitgestellt (Shared Services). Jede dieser shared services bedient eine Anzahl von Kunden. Im ersten Ansatz sind das für jeden der Dienste genau gleich viel (was die Verwaltung bzw. Zuordnung vereinfachen sollte). Wie viele Kunden ein shared service bedienen ist for further study.

Den Management Server gibt es je Hoster nur genau ein mal.

Cloudkom-grobuebersicht1.png

Grundsätzlich sind die Kunden-PBXen und die shared services im privaten Netz des Hosters. Somit sind sie von aussen und damit auch aus dem Kundennetz nicht erreichbar. Zwischen Kunde und Hoster wird kein VPN aufgebaut. Um nun den notwendigen Zugriff des Kunden auf PBX und Dienste zu ermöglichen gibt es 2 Dienste, die auch über eine öffentlich zugängliche IP Adresse verfügen (dual homed). Dies sind der SBC und die Media-PBX.

Der SBC leistet zweierlei:

  • Proxy Registrierung der Endgeräte des Kunden
Die Endgeräte registrieren sich am SBC, der wiederum eine Proxy-Registrierung zur Kunden-PBX unterhält
  • NAT eingehend mit Portmaps für ausgewählte Protokolle (HTTPS/443 und LDAPS/636,714)

Die Media-PBX

  • stellt dem Kunden einen öffentlich erreichbaren Übergabepunkt für zentral generierte oder verarbeitete Mediendaten zur Verfügung
Dazu gehören z.B. music on hold, lokal erzeugte Ruftöne, Voicemail, Konferenzen und Faxempfang

Durch die Aufteilung bleibt die Netztopologie des Hosters unsichtbar. Der Hoster benötigt insgesamt nur 2*n+1 öffentliche IP Addressen (wobei n die Anzahl an shared service Gruppen ist).

Cloudkom-netzuebersicht1.png


Kennwörter

Im gesamten Hosting System werden an den verschiedensten Stellen Kennwörter vergeben/verwendet. Um hier die Übersicht zu behalten gilt folgendes:

  • Admin Kennwörter
Die Authentifizierung der Admins erfolgt über Kerberos. Admins können daher individuelle Kennwörter haben (im Folgenden als individuelles Admin Kennwort bezeichnet)
alle Boxen haben als Fallback ein supergeheimes "local admin" Kennwort, dass man in der Regel aber nicht benutzt (im Folgenden als systemweites Admin Kennwort bezeichnet)
  • PBX Kennwörter
Die PBX Kennwörter müssen auf allen PBXen im gesamten Verbund gleich sein (und müssen niemals irgendwo eingegeben werden nach der Grundkonfiguration) (im Folgenden als PBX Kennwort bezeichnet)
  • Objektkennwörter. Hier gibt es zwei Arten:
    • Kennwörter, die dem Kunden bekannt gemacht werden. Das sind z.b. Registrierungskennwörter für Endgeräte (im Folgenden als Kunden-Registrier-Kennwort bezeichnet) und Initialkennwörter für myPBX (also Userkennwörter, im Folgenden als Kunden-Login-Kennwort bezeichnet). Für jeden Kunden wird ein eigenes Kunden-Registrier-Kennwort festgelegt, dass in der Regel nie geändert wird. Ebenso wird ein anderes Kunden-Login-Kennwort generiert, das für alle User Objekte als Initialwert verwendet wird, von den Nutzern aber verändert werden kann
    • Kennwörter, die dem Kunden nicht bekannt gemacht werden. Für z.B. interne Objektregistrierungen (z.B. ein lokales GWxx an ein PBX-Objekt) wird immer das PBX Kennwort verwendet
  • Kerberos Kennwort
Hier wird das PBX Kennwort verwendet (es macht wenig Sinn, da etwas anderes als das PBX Kennwort zu verwenden)

Die Linux AP hat keine Kerberos Unterstützung. Es werden hier also eigene Kennwörter benötigt. Dabei wird unterschieden, ob es sich um Kennwörter handelt, die im normalen Betrieb benötigt werden oder nicht

  • Linux Admin Kennwort
das ist das Kennwort, dass im normalen Betrieb verwendet wird (im folgenden Linux Admin Kennwort genannt). Findet Verwendung als web server credentials, webdav access credentials, application access credentials, 'innovaphone Reporting access credentials, innovaphone Fax access credentials etc.
  • Linux System Kennwort
das ist das Kennwort, dass im normalen Betrieb nicht verwendet wird. Hier wird das PBX Kennwort verwendet. Findet Verwendung als root credentials
Die Datenbank Kennwörter bleiben wie sie im Standard jeweils sind (z.b. postgresql admin password, da man auf den DB Server eh nur von 127.0.0.1 kommt

NTP

Alle Geräte benötigen eine korrekte Zeit (alleine schon wegen Kerberos). Es muss also überall ein korrekter SNTP Server (und am besten auch ein zweiter) eingetragen sein.

Die dual-homed Geräte verwenden zwei als zuverlässig bekannte externe (beim Hoster oder im Internet) NTP Server. Alle anderen Geräte verwenden "ihren" SBC als NTP Server (ein Backup NTP ist hier nicht nötig, da diese Geräte bei Ausfall des SBC eh nicht nutzbar sind).

Zertifikate

Der gesamte HTTP und LDAP Verkehr zum Kunden hin ist verschlüsselt. Dies betrifft einen eventuellen Admin Zugang zur Kunden-PBX (durch den Reseller z.B.) und den Reporting und myPBX Zugang des Endkunden. Um hier die Benutzung durch den Endnutzer zu ermöglichen, werden auf den Geräten in jeder Hinsicht "passende" Zertifikate benötigt (also Hostname und Authority Trust). Die eingebauten Zertifikate können nicht verwendet werden, da sie zum einen nur auf den NetBIOS Namen ausgestellt sind (z.b. IPVA-a8-5a-38) und zum anderen im Falle der IPVA self-signed, also nicht von einem gemeinsamen Stammzertifikat abgeleitet sind.

Dazu wird je Hoster ein signierfähiges Zertifikat benötigt (RootCA) von dem die jeweiligen Device-Certificates abgeleitet werden. Als RootCA wird eine dedizierte IPVA verwendet, auf der eine RootCA generiert wurde (General/Certificates/RootCA). Die Geräte-Zertifikate werden immer auf dieser IPVA generiert und dann von der CF Karte (/DRIVE/CF0/CA/certs/) auf die Geräte exportiert.

RootCA

Als RootCA wird eine zentrale IPVA verwendet, die auch das zentrale Kerberos realisiert. Die Erzeugung der Device-Certificates auf der RootCA hat mit aktueller Firmware den Seiteneffekt, dass das Gerätezertifkat des generierenden Gerätes überschrieben wird. Das ist zwtr unschön aber auch nicht tragisch und beeinflusst die Funktion des Kerberos Servers nicht.

In der RootCA-VM generiert man zunächst eine eben solche (general/kerberos). Sie wird mit folgenden Daten angelegt:

C=Germany, O=hoster, CN=hoster Device Certification Authority, Key-length 4096, Lebensdauer 20 Jahre

Dieses neue RootCA zertifikat trusted man dann auf der Box selber.

Device Certificates

Individuelle Gerätezertifikate erzeugt man dann mit dieser RootCA wie folgt:

Key 4096, Common Name=NetBIOS Name des Geräts, Organization=hoster, Country=Germany, DNS Name 1=externe IP des Gerätes, DNS Name 2=interne IP des Gerätes, IP Address 1=externe IP des Gerätes, IP Address 2=interne IP des Gerätes

Hat das Gerät nur eine interne IP Adresse, muss man unbedingt als externe IP Adresse die IP Adresse des Gerätes angeben, über den der NAT Zugriff erfolgt (also z.B. bei einer Kunden-IPVA den zugehörigen SBC). Man gibt nur die IP Adresse, nicht das Port Mapping an.

Wenn man für die Geräte auch noch DNS Namen vergibt, kann man natürlich auch diesen als DNS Name 3 mit angeben.

Man muss das Häkchen Backup on CF setzen, da das die einzige Möglichkeit ist, ein Zertifikatsdatei mit dem private Key zu bekommen.

Das Erzeugen des Zertifikates bewirkt zum einen, dass es auf der CF-Karte als serialno.pem abgespeichert wird und zum anderen das aktuelle Device Certificate der VM die als RootCA verwendet wird ersetzt. Letzteres ist nur verblüffend, aber nicht weiter schlimm. Beim Zugriff auf diese VM per HTTPS wird in der Folge de Browser immer wieder darüber klagen, dass das zertifikat nicht für diesen Host ausgestellt wurde. Da auf dieses Gerät aber niemals ein Kunde zugreifen wird, kann man das ertragen. Um das Zertifikat aber auf das Zielgerät zu bekommen, muss man es sich zunächst von der CF Karte herunterladen. Man schaut also, was für eine Seriennummer gerade erzeugt wurde und lädt dann die Datei /DRIVE/CF0/CA/certs/serialno.pem von der CF-Karter herunter (und speichert es sich zweckmäßig als NetBIOS Name des Geräts.pem. Von dort kann man es dann als neues Device Certificate auf das Zielgerät laden (General / Certificates / Device certificate / Upload).

Installation der Zertifikate im Client

Firefox

  • Das Stammzertifikat (nicht das individuelle Gerätezertifikat) im PEM Format runterladen
  • Extras / Einstellungen / Erweitert / Zertifikate anzeigen / Zertifizierungsstellen / Importieren
  • die .crt Datei importieren
  • Dieser CA vertrauen, um Websites zu identifizieren

Internet Explorer

  • Extras / Internetoptionen / Inhalte / Zertifikate / Beabsichtigter Zweck Clientauthentifizierung / Vertrauenswürdige Stammzertifizierungsstellen / Importieren
  • die .crt Datei importieren

Kerberos

Die Authentifikation aller Admins auf den Geräten, die zur Hoster-Infrastruktur gehören (also auch die Endgeräte der Kunden) erfolgt über Kerberos. Daher muss jedes dieser Geräte eingebucht sein in die Realm. Als Realm soll die DNS-Domain des Hosters (z.b. hoster.tld) verwendet werden. Dadurch wird es möglich, die Kerberos Server über den DNS zu finden.

Die zentrale IPVA die auch die RootCA realisiert stellt ebenso die zentrale Kerberos Instanz zur Verfügung.

Es wird ein eigenständiger Kerberos Server (also der im Gateway Level verwendet). Die (mutmaßlich überschaubaren) Admins werden dort von Hand eingetragen.

Eine Doppelung des Servers ist über den üblichen Mechanismus möglich (Replikation auf einen zweiten). Ob das allerdings so besonders sinnig ist bleibt dahin gestellt, da die Ausfallsicherheit an sich durch den Hoster (auf VMWare Level) gewährleistet werden sollte. Fällt der Kerberos Server aus gibt es eine gewisse Wahrscheinlichkeit, dass der Backup-Server (der ja auf der gleichen Infrastruktur laufen dürfte) auch ausfällt. Da die VM des Kerberos Servers aber auch als zentrale Lizenzserver fungiert und man den gerne redundant hat, hat man somit auch gleich einen redundanten Kerberos Server.

Trust Relationships sind nicht erforderlich. Werden doch welche gewünscht (z.B. zur Unterstützung weitere Realms) so wird als shared secret für die Vertrauensstellung das systemweite Admin Kennwort verwendet.

Die Clients (also die Geräte, deren Zugriff per Kerberos abgesichert wird) finden Ihre Kerberos Server per DNS. Die Geräte innerhalb des privaten Hoster Netzes verwenden dazu die interne Adresse, die beim Kunden ihren jeweiligen SBC. Dieser hat daher ein UDP NAT Mapping (udp/7088 -> kerberos-intern-ip:88 und udp/7089 -> secondary-kerberos-intern-ip:88). Dazu müssen im autoritativen DNS der Hoster Domain (die auch als Keberos Realm Name fungiert, s.o.) Einträge erstellt werden: 

# hoster.tld is the hosters domain used as kerberos realm name
A kerberos1i.hoster.tld x.x.x.x (interne Adresse des primären Kerberos)
A kerberos2i.hoster.tld y.y.y.y (interne Adresse des sekundären Kerberos)
A sbc1.hoster.tld x.x.x.x (externe Adresse des SBC1)
A sbcn.hoster.tld x.x.x.x (externe Adresse des SBCn, n ist Sequenznummer des SBC)

SRV _kerberos._udp.hoster.tld
    priority       = 0
    weight         = 0
    port           = 88
    svr hostname   = kerberos1i.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 5
    weight         = 0
    port           = 88
    svr hostname   = kerberos2i.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 10
    weight         = 0
    port           = 7088
    svr hostname   = sbc1.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 15
    weight         = 0
    port           = 7089
    svr hostname   = sbc1.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 10
    weight         = 0
    port           = 7088
    svr hostname   = sbcn.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 15
    weight         = 0
    port           = 7089
    svr hostname   = sbcn.hoster.tld

Dieses Setup führt bei mehreren SBCs dazu, dass sich die Kerberos Clients bevorzugt über die internen Adressen arbeiten. Bei den Geräten des Kunden (wo das nicht geht), wird irgendein SBC verwendet. Dies funktioniert, da alle SBCs letztlich auf die selben Kerberos Server verweisen.

Anstatt vom DNS abzuhängen können diese DNS Einträge auch im Staging in die Geräte geschrieben werden. Dann kann man es sich etwas einfacher machen und nur A und SRV records für den jeweils "richtigen" SBC machen: 

config change DNS0 
   /srv-name _kerberos._udp.hoster.tld/srv-target kerberos1i.hoster.tld /srv-port 88 /srv-prio 0 /srv-weight 0 
   /srv-name _kerberos._udp.hoster.tld /srv-target kerberos2i.hoster.tld /srv-port 88 /srv-prio 5 /srv-weight 0
   /srv-name _kerberos._udp.hoster.tld /srv-target sbcn.hoster.tld /srv-port 7088 /srv-prio 10 /srv-weight 0 
   /srv-name _kerberos._udp.hoster.tld /srv-target sbcndup.hoster.tld /srv-port 7089 /srv-prio 15 /srv-weight 0
   /a-name kerberos1i.hoster.tld /a-addr i.i.i.i
   /a-name kerberos2i.hoster.tld /a-addr i.i.i.i
   /a-name sbcn.hoster.tld /a-addr x.x.x.x
   /a-name sbcndup.hoster.tld /a-addr x.x.x.x

NB: die seltsame Konfiguration mit sbcndup.hoster.tld (was in Wirklichkeit identisch ist mit sbcn.hoster.tld) liegt daran, dass die Firmware vor V10 beta6 keine ansonsten gleichen SRV Einträge mit verschiedenen Portnummern erlaubt.

Lizenzen

Der Hoster hat ein Interesse daran, eine zentrale Lizenzverwaltung zu machen. Es braucht also eine zentrale Lizenzserver Instanz für die gesamte Hoster-Infrastruktur.

Dazu werden die beiden zentralen Kerberos Server verwendet. Alle Lizenzen des Hosters werden hier installiert. Darauf laufen eine PBX nebst Standby die einzig den Zweck haben, Lizenzen an die SBCs und Medias zu vergeben (die als License only Slaves daran registriert sind).

Die Kunden-PBXen wiederum sind als License only Slaves an ihren jeweiligen Media-PBXen registriert.

Die Lizenzmaster PBXen haben als System Name die Domäne des Hoster (z.b. cloudkom.de) und als PBX Name ..

SBC

Der SBC

  • nimmt externe Registrierungen der Kunden-Endgeräte entgegen
  • stellt die zentrale CF-Karten-Instanz für nicht-sensitive Daten (speziell Firmware für den Firmware Update) zur Verfügung
  • leisten auch das HTTP (und LDAP) inbound NAT um den Zugriff auf die IPVAs im privaten Netz zu ermöglichen. Jede IPVA nutzt "ihren" SBC eben auch als NAT Server

Ein SBC versorgt mehrere Kunden (aktuelle Arbeitshypothese: 200). Die SBCs werden einfach durchnummeriert (sbc1, sbc2 usw.).

PBX

  • System Name ist der Domänenname des Hosters (z.b. cloudkom.de)
  • PBX Name ist sbcn
  • ist als Slave PBX an der zentralen Lizenz-PBX (mit deren Standby) registriert (als License Only)
  • erhält daher die Lizenzen vom zentralen Kerberos/CA/Lizenzserver
Kundenkonfiguration
  • Für jede Registrierung eines Endgerät eines Kunden ein Session Border Objekt (SBC)
  • als Long Name und Registration to internal PBX/Name verwendet man die Endgeräte-ID
  • als Password das Kunden-Registrier-Kennwort
  • als Registration from external/Name die Hardware-ID des Endgerätes sowie PBX Password

Siehe auch #Konfiguration der Kunden-Objekte in der Kunde-PBX und im SBC

Medienserver

  • Lizenzmaster für alle Kunden PBXen. Port9 und IPVA9 Lizenzen
  • PBX Objekt für jeden Kunden (Long Name, Name: Name des Kunden, Nummer 90+<Port im NAT Mapping>)
  • Gateway Objekte mit Name <Kunden Name>-media. Daran können sich die Kunden PBXen registrieren für Media Daten
  • Objekt MOH mit Nummer ###10. Dort kann sich die MOH Quelle registrieren
  • Objekt TONE mit Nummer ###11. Dort kann sich eine Tone interface registrieren
  • Objekt HTTP-OUT mit Nummer ###12. To offload the announcements of WQ and VM object.


Kunden PBX

Jede Kunden-PBX bekommt eine eigene ID logische Kunden-ID, die zur Benennung von Objekten herangezogen wird. Sie besteht aus einem Namenskürzel (irgendwie aus dem Kundennamen) sowie einer fortlaufenden Nummer. Die fortlaufende Nummer ist die Kundennummer bei Cloudkom. So ein Name könnte also wie Künkel00001 aussehen.

Die Kunden-PBX steht im privaten Hoster Netz. Sie kann daher keine Medien zum Endkunden spielen. Dazu wird die ihr zugeordnete Media-n PBX verwendet, die dual-homed ist.

  • SBC als Time Server (Zeit notwendig für Kerberos), denn wenn der weg ist, dann geht ex nix mehr mit dieser Kunden-PBX

Konfiguration der Kunden-Objekte in der Kunden-PBX und im SBC

Auf der Kundenseite sollte zur Konfiguration der Endgeräteregistrierung keine Geräteindividuelle Einstellung nötig sein. Daher wird hier als Registrierungsname der NetBIOS Name (z.B. IP232-01-02-03) verwendet. Damit ist dies auch der korrekte Wert für Registration from external im dazugehörigen SBC Objekt.

Als Registrierungskennwort vom Endgerät und damit als Wert für wird Password im SBC Objekt wird das Kunden-Registrier-Kennwort für den Kunden verwendet.

Als Long Name sowie Name für Registration to internal PBX im SBC Objekt (und damit als Registriername in der Kunden-PBX) wird eine Kombination aus Kunden-ID und einer fortlaufenden Endgeräte-ID des Kunden benutzt (z.B. Künkel00001-001). Der fortlaufende Teil der Endgeräte-ID beginnt für jeden Kunden bei 0. Dies dient dazu, beim Tracen/Debuggen/Konfigurieren eine bessere Übersicht zu haben. Zusätzlich kann man dann auf dem SBC schön nach der Kunden-ID filtern. Ansonsten könnten man genauso gut den NetBIOS Namen verwenden. Der lässt aber außer auf der Kunden-PBX keine Rückschlüsse auf den Kunden zu.

Als Kennwort zur Registrierung vom SBC zur Kunden-PBX wird das globale PBX Kennwort verwendet, also die PBX Kennwort Häkchen im SBC-Objekt bei Registration to internal PBX und am entsprechenden Device im User Objekt auf der Kunden-PBX.

Update Server

Aufgaben:

  • Staging (z.b. aufspielen geeigneter Trust Lists)
  • Update der Firmware auf den Kundengeräten und der Kunden-PBX
  • Sicherung der Configs von allen Kundengeräten und der Kunden-PBX

Die Sicherung findet auf die CF der Kunden-PBX statt. Das macht Sinn, da es hier nicht um Desaster Recovery geht (die wird vom Hoster gewährleistet), sondern um das Recovery nach Fehlkonfigurationen. Es gibt ein optionales kundenspezifisches Update Script (local.txt), das befindet sich ebenso auf der Kunden-CF. Es gibt kein gerätespezifisches Update-Script.

Struktur auf der Kunden-PBX 

/DRIVE/CF0/
  update/
    backup/
      backup-mac-datum.txt

Damit die Backups geschrieben werden können, muss das Backup Verzeichnis (/DRIVE/CF0/update/backup/) auf der Kunden-PBX unter Services/HTTP/Public compact flash access zum Schreiben (und nur zum Schreiben) frei gegeben werden.

Die Firmware liegt auf einem zentralen Verzeichnis des jeweiligen SBC. Damit muss man zwar die Firmware auf jedem SBC vorhalten, dafür wird die dadurch erzeugte Last verteilt.

Soll die Firmware aller Kunden eines SBCs aktualisiert werden, dann muss das update.txt des SBC angepasst werden. Ebenso wenn generelle Config Eigenschaften geändert werden sollen.

Das Staging erfolgt in 3 Stufen:

das ist ein Web Dienst sein, der anhand der Seriennummer des Gerätes den Hoster und den (End)Kunden uas my.innovaphone.com und das update script schlussendlich auf das Staging Script auf dem richtigen SBC des Hosters ändert
  • das Endgerät wird auf das SBC-weite staging script (staging.txt) umgeleitet, wo generelle einmalige Einstellungen gemacht werden können
  • das Endgerät wird auf das SBC-weite update script (update.txt) umgeleitet, wo Einstellungen gemacht werden können, die im laufenden Betrieb geändert werden könnten

Struktur auf dem SBC 

/DRIVE/CF0/
    update/
      staging.txt         - spezielles staging script
      global.txt          - settings die für den hoster global gelten
      local.txt           - settings, die für dieses SBCn/Median Set gelten
      set-customerid.txt  - settings, die für den speziellen Kunden gelten
      dev-IPxxx.txt       - settings für einen bestimmten Gerätetyp
      cfg-phone.txt       - settings für eine bestimmte Geräteklasse
      cfg-gateway.txt     - dito
      update.txt          - dauerhaftes update script nach dem staging
      firm/               - firmware
        nnnnnn/
          bootxxx.bin
          ipxxx.bin

Damit die Firmware gelesen werden kann, muss das Firmware Verzeichnis (/DRIVE/CF0/update/firm/) auf dem SBC unter Services/HTTP/Public compact flash access zum Lesen (und nur zum Lesen) frei gegeben werden. Damit die Update Scripte gelesen werden können, muss das update Verzeichnis (/DRIVE/CF0/update) lesbar (und nur lesbar) sein. Es kann also für beides /DRIVE/CF0/update/ zum Lesen freigegeben werden.


Die Zuweisung der initialen Update URL kann nicht über die normalen Mechanismen (DHCP) erfolgen (da man den DHCP Server des Kunden nicht beeinflussen kann). Die langfristige Idee ist, dass man in der inno Logisitik weiß, welches Telefon zu welchem Hoster geht. Geräte, die überhaupt zu einem Hoster-Kunden gehen bekommen eine spezielle manufacturer-id die wiederum eine spezielle update URL in der config hat: http://config.innovaphone.com/staging.txt. Dahinter steckt eine Anwendung, die aus der Seriennummer ermittelt, zu welchem Hoster das geht und ersetzt die URL durch ein http://config.hoster.com/staging.txt (oder was immer für den Hoster bekannt gegeben wurde). Bei dem Hoster wiederum kann entweder ein statisches Staging Script dahinter stehen (unlikely) oder eine Hosterspezifische Anwendung, die das Staging für den Kunden (den dann die Anwendung vom Kunden wissen muss) macht.

Bis dahin muss allerdings jemand (Hoster oder Kunde) die passende URL nach einem langem Reset ins Kundengerät eingeben.

Update Skripte

Sind in vault:$web/hosting/ (inno Seite) und vault:$web/hosting/cloudkom (Hoster Seite).

  • redirect.php
    1. Zertifikat des Hosters in die Trustlist (damit das Update Script per HTTPS gelesen werden kann)
    2. individuelle Geräteinfos (kommen aus den #-Replacements des Update Clients) in VARs übertragen zur späteren Nutzung in den Hoster Scripten
  • staging.txt
    1. firmware update
    2. DNS für Kerberos richtig einrichten
    3. der Kerberos Domain beitreten. Damit kann sich ein Hoster Admin, wenn er denn überhaupt Zugriff auf die Geräte des Kunden hat (über VPN oder TeamViewer), auf den Geräten authentifizieren
    4. Zentralisierung von Logs, Alarm&Events (auf die Kunden-PBX). Damit hat der Hoster einen Einblick in den Funktionszustand der Geräte
    5. Verzweigen ins Geräteklassen-Staging (cfg-xxx.txt)
  • cfg-phone.txt
    1. Anmeldung der primären Registrierung an der richtigen PBX. In den Beispielscripten wird das Telefon
  • cfg-gateway.txt
    1. Anmeldung der Schnittstellen an der richtigen PBX
  • update.txt
    1. Datensicherung (auf die Kunden-PBX)

Support / debugging von Kundenproblemen

  • Alarms & Events Zentralisierung
    • wie, was kann man daraus erkennen
  • syslog
    • wie, wo, was sichern
  • wer macht support
  • zusammenarbeit mit toplink bei SIP-Trunk Probleme
  • mantis <mantis-issue id=95379/>

Reporting (Multiple PBX)

VM sollte von Anfang an eine Plattengröße von 50GB haben!

V10 Linux Image und Reporting Files von der linux-10 (also der neuen ) Version werden benötigt, nur die enthalten die Mandantenfähigkeit. Gebraucht wird die Linux-AP und das Reporting. Eine solche Linux-AP kann mehrere (viele) Kunde bezüglich der Ruflisten und des Reportings bedienen.

<dfslink>\\inno-sifi\dfs\build\linux-10</dfslink>

Konfiguration PBX

  • CDR0: Remote-AP-S, 10.30.100.2, 443
  • Call List Service myPBX: Remote-AP-S, 212.124.38.120:8102, user:innovaphone-reporting, pass: reporting

Konfiguration Reporting

  • PBX-Name
  • Filter für PBX VM9 und VM10 erstellt
  • User angelegt die diesen Filter verwenden
  • Reportin Login Page
  • Mit user/passwd:ckl_report/callme38 anmelden, dann sieht man nur calls aus PBX VM10
  • Mit user/passwd:inno_report/callme38 anmelden, dann nur calls aus PBX VM9 sichtbar

Fax Server

VM sollte von Anfang an eine Plattengröße von 50MB haben!

Da das FAX-Interface im Öffentlichen Netz stehen muss, um T.38 Pakete empfangen zu können, wird dieses von der CustomerPBX auf Media1 Gateway ausgelagert. Die SOAP-Verbindung wird trotzdem auf die CustomerPBX aufgebaut.

Routing fax.png

Mail to Fax Gateway

Für Kunden, auf deren POP3 Server aus Cloudkom Netz nicht zugegriffen werden kann, wird ein SMTP Server auf Basis von IP-AP aufgestellt. Dort können die Kunden dann per E-Mail die Faxe anliefern. (<mantis-issue id=89710/>)

Use Case "Fax verschicken":

  • Kunde schickt aus dem E-Mail Programm ein Mail mit PDF-Anhang an z.B. +497031730099@fax.cloudkom.com
  • Rufnummer für Zielfax muss im User Part der To: Mailadresse stehen (im Beispiel ist es +497031730099)
  • Das passende Postfach für Fax Server des jeweiligen Kunden wird anhand der From: Mailadresse bestimmt.

Damit die From: Adresse nicht gefaked werden kann, werden nur authentifizierte SMTP-Verbindungen zugelassen. Der Kunde muss dazu bei sich im Exchange einen "SMTP Send Connector" für die Domäne fax.cloudkom.com einrichten ([1]) mit Basic Auth over TLS.

Als SMTP-Server kann man ein Postfix mit Postgresql Erweiterung nehmen, damit man die Kunden Daten (Domains, Postfächer, Logins) direkt aus der Fax Server Datenbank lesen kann.

Als POP3-Server (damit Fax Server die Mails lesen kann) wird dann Dovecot eingesetzt.


Beschreibung der Implementierung: E-Mail_Fax_Server_Gateway_(Project_Cloudkom).

Adressbücher

Directories - PBX

  • pro Kunde wird im SBC ein NAT-Port-Map für LDAP zur entsprechenden Kunden-IPVA konfiguriert. Das Telefon hat die Möglichkeit ein Port in der PBX-Directories anzugeben und benutzt daudrch den LDAP-Server der PBX(und nicht den des SBC).
  • Es wird LDAPS verwenden, das Zertifikat der Kunden-IPVA muss jedoch nicht extra in der Trustlist des Telefons aufgenommen werden. Das Telefon überprüft nicht ob das SSL - Zertifikat gültig ist(cn, Ablaufdatum, etc) sondern verwendet einfach das erhaltene Zertifikat nur zur Verschlüsselung.

Directories - External LDAP Server

  • pro Kunde gibt es einen LDAP-Knoten (dc=kundennr.), ein Replikator. Es wird LDAPS verwendet.
    • Replikator:
      • Kunde exportiert seine Outlook - Kontakte in eine CSV Datei (Kommagetrennte Werte(Windows)). Die CSV Datei sollte nur folgende Spalten/Felder enthalten: "Nachname","Vorname","Firma","Telefon geschäftlich","Mobiltelefon". Die Telefonnummern sollten im E164 Format vorliegen, also +49703173009123. Als Dateiname immer Kontakte.csv verwenden, damit der Replikator immer relativ einheitlich konfiguriert werden kann.
      • die CSV Datei wird via https über eine Webseite hochgeladen, die Syntax(Kommagetrennte Werte, korrekte Spaltenreihenfolge) der CSV-Datei wird geprüft und falls die Datei ok ist - local auf dem Metadir - Server abgelegt. Diese Webseite für den CSV-Upload muss zusätzlich programmiert werden.
      • der Estos Metadir Server greift lokal auf die csv-Datei zu. Der Replikator kann per cmd-line gestartet werden und kann selber vor und nach dem Replizieren der csv-Datei weitere Anwendungen ausführen. Dadurch kann man den Replikator nicht nur zeitgesteuert starten, sondern auch beim Hochladen neuer Daten - über die (noch zu programmierende) Web-Seite. Das der Replikator seinerseits Anwendungen vor dem eigentlichen Replizieren ausführen kann, kann evtl. dazu verwendet werden um via HTTP-GET die CSV - Datei zu lesen(falls diese doch nicht lokal sondern auf einem Webserver abgespeichert werden soll)
    • LDAP-Knoten:
      • Authentifizierung für den Zugriff auf LDAP-Knoten erfolgt per Username/Passwort, keine Einschränkung auf IP-Netze.
      • als Profil wird immer das "Default"(bei der Installation des Metadir Servers erstelltes Profil, ohne Rufnummerinfo) Profil verwendet. Man braucht durch unsere "Dialing Location" am Telefon keine Kundenspezifischen Profile.
      • als Vorlage ist im Cloudkom-Metadir Server ein Template eingerichtet "dc=template". Die config-Einstellungen sind (für andere Hoster) auch aus dem screenshot ersichtlich.
  • kurze Anleitung zum exportieren von Kontakten in Outlook 2010:
    • man kann nur eigene Kontakte exportieren. Hat man nur eine globale Kontaktliste, muss man diese Kontakte erstmals in die eigene Kontakte kopieren. (IP Kontakte -> Rechtsklick -> kopieren -> eigene Kontakte auswählen)
    • in Outlook Datei -> Öffnen -> Importieren -> In Datei exportieren -> Kommagetrennte Werte(Windows) -> Kontakte/IP Kontakte auswählen -> "Benutzerdefinierte Felder zuordnen" -> Nachname, Vorname, Firma, Telefon geschäftlich, Mobiltelefon auswählen -> Fertigstellen
  • LDAPS
    • Selfsigned Zertifikat auf den Metadir Server installiert. Da der LDAP-Client auf dem Telefon das Zertifikat nicht überprüft, sollte es hier keine Probleme geben.
    • Metadir Server verwendet port 714 für LDAPS, SBC1 hat dafür ein NAT-Map für den Port (bei Cloudkom 9007)
  • die Directories Einstellungen sollten per config - template verteilt werden, auf der VM10 gibt es dazu als Beispiel das config-template "default"

myPBX

  • hier gibt es das Problem dass normalerweise die PBX die LDAP - Anfrage des myPBX - Clients macht, dazu verwendet man normalerweise die am User gespeicherte phone-config. Da die PBX im internen Globe Netz ist, kann es mit der darin enthaltenen public-IP(externe IP des NAT Routers) nicht anfangen. durch ein Hack von Matthias kann man im PBX0 modul fest konfigurieren welcher LDAP Server genutzt werden soll.

config add PBX0 /ldap-default-addr 10.30.0.2 /ldap-default-port 714

Voicemail

Konfiguration Kunden PBX

  • Gateway-config
    • Media GW1, Register as Gateway, 212.124.38.123, Name= innovaphone-media
    • HTTP-INT GW3, Register as Gateway, 127.0.0.1, Name= HTTP-INT
    • HTTP-EXT GW4, Register as Gateway, 212.124.38.123 (Media1), Name= HTTP-EXT
    • vmrelay GW5, Register as Gateway, 127.0.0.1, Name= vmrelay
  • Routes
    • GW3 HTTP-INT --> ###12 GW4 HTTP-EXT
    • GW5 vmrelay --> ###12 GW4 HTTP-EXT
  • https Zertifikate trusten auf Media1.

Operator

Datensicherung

Thomas Leone 16:50, 8. Jan. 2013 (CET) Datensicherungskonzept überlegen.

Ausser uns auf globe zu verlassen, dass IPVAs wieder hergestellt werden können, sollten configs extra gesichert werden.

1. Wie am 17.12. besprochen, Datensicherung der PBXn lokal. PBX Admins können dann configs selbst einspielen. --> IPVA kaputt (warum auch immer), ist die Sicherung weg.

2. Configs der Kunden-PBXn auf Michael Khayats Windows Server (zusätzlich) sichern. Server ist im auch im privaten Netz. Configs könnten auch von Michael K. wieder upgeloadet werden.

3. Eine IPVA als Reserve. Kann von uns schnell gestartet und konfiguriert werden. Globe wird dann noch nicht benötigt.

Thomas Leone 11:38, 23. Jan. 2013 (CET) Desaster Recovery von Globe

1. Jede VM wird 2 Wochen Montag -Freitag + 1 x Monatlich gesichert. Es gibt also von jeder VM 11 separate Generationen die auf Wunsch wiederhergestellt werden können.

2. Die Aussage, dass unsere IPVA nicht VSphere konform sind ist obsolet (kam vorschnell aus der Technik da unsere VM nicht bei VSphere aufgelistet sind).

3. Recovery wurde mit VM8 (IPVA) und VM12 (LAP) erfolgreich getestet.

Retrieved from "https://wiki.innovaphone.com/index.php?title=Howto:Hosting_with_V10&oldid=28861"