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 Cloudkom:Projekt Cloudkom.

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 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.

Kerberos User

Abgesehen von den normalen Admin Accounts des Hosters muss hier auch ein Dienstaccount paccess für den programmatischen Zugriff auf die Boxen konfiguriert werden. Dieser wird beispielsweise vom Metadir Server zum Zugriff auf den SBC verwendet (wird aber auch von einer eventuellen Administrationssoftware verwendet werden). Zusätzlich wird der Account für die URL https:// und http:// unter Services/HTTP/Client auf dem SBC, Media und Kunden-PBX eingetragen, was bewirkt, dass alle http/https Zugriffe von diesen Geräten aus damit authentifiziert werden (was überall funktionieren wird, da alle Geräte die in Frage kommen Teil der Keberos Domäne sind).

Diese Account Credentials sind auch sicher zu verwahren, da sie Administrationszugriff auf alle Geräte ermöglichen!

Um das automatische Einbuchen der Geräte in die Kerberos Domain beim Staging zu ermöglichen, gibt es noch einen speziellen Account der nur Join Realm Rechte hat: joiner, joiner. Dieser Account ist nicht sonderlich Sicherheitsrelevant, da man mit ihm an sich nichts böses anstellen kann.

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. Derzeit ist die Begrenzung an NAT Maps bei ca. 290 pro SBC, gegeben durch die max. Länge einer config Zeile. Pro Kunden-IPVA werden 2 MAPs benötigt(1xHTTPS + 1xLDAPS).

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

Services

Der Medienserver muss für Ansagen und voice-mails auf die WebDav Server der Kunden-PBXen zugreifen können. Daher HTTP Client credentials für die URLs http:// und https:// über paccess@hoster.tld.

PBX

  • PBX Objekt für jeden Kunden (Long Name, Name: Kuenkel00001, Nummer #+Nummer-aus-Kuenkel00001)
  • Gateway Objekt HTTP-EXT ohne Nummer. 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 ein 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 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 beim Hoster. 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 eh nix mehr mit dieser Kunden-PBX
  • Unknown Registrations an mit With PBX Pwd only. Dadurch kann sich der Endkunde mit seinem Endgerät anonym anmelden und damit die Zuordnung zum Teilnehmer wie üblich per Zero Administration ausführen

Globale Objekte in der Kunden-PBX

default template
  • heißt default
  • Hide from LDAP und Critical
  • Store Phone Config
  • alle Häkchen unter License
  • unter Access einen Eintrag für @customer.tld (das ist der System Name aus der PBX Config) mit allen Häkchen
  • unter Config wird nur die LDAP Config (Directories) gesetzt:

<phone> 

 <loc cc='ountry-code' ac='area-code' ntp='0' itp='00' pbx='subscriber-number'/>
 <ldap id='2' 
   tls='1' port='ldap-port-map-to-pbx-on-sbc, e.g. 9004'/>
 <ldap id='3' 
   enable='1' tls='1' mode='basic' 
   addr='sbc-ip-address' port='ldap-port-map-to-metadir-on-sbc, e.g. 9007' 
   dn='PBX Name' pw='??' base='dc=PBX Name' 
   attr='sn,givenName,company' phone='telephoneNumber:D,mobile:M,:@'/>

</phone> 

pw für ldap2 ist heikel: das ist sensitiv (Kundendaten öffentlich zugänglich per LDAP)

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 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. Initial wird in den Kundenobjekten kein Device eingetragen. Damit wird die Einbuchung von Endgeräten durch den Kunden auf das gewünschte Endgerät durch Zero Administration möglich.

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 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, der anhand der Seriennummer des Gerätes den Hoster und den (End)Kunden aus 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
      update.txt            - dauerhaftes update script nach dem staging
      global.txt            - overrides für globale settings im laufenden update (nach dem staging)
      local.txt             - overrides für SBC-lokale settings im laufenden update (nach dem staging)
      set-customerid.txt    - overrides für Kundenspezifische settings im laufenden update (nach dem staging)
      staging/              - speziell Skripte für das Staging
        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
      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 direkt angemeldet (wobei man davon ausgeht
  • cfg-gateway.txt
    1. Anmeldung der Schnittstellen an der richtigen PBX
  • update.txt
    1. Datensicherung (auf die Kunden-PBX)

Die Staging Scripte verwenden einige weitere Scripte, die nur Daten zur Installation enthalten:

  • global.txt: Daten, die für den Hoster insgesamt gelten (z.b. sein Domain Name). Ist auf jedem SBC identisch
  • local.txt: Daten, die für einen speziellen SBC gilt (z.b. die IP Adressen der Media-PBX)
  • set-Kundenname.txt: Daten, die für einen einzelnen Kunden gelten (z.b. die IP Adresse seiner PBX und die verschlüsselten Anmelde-Passwörter des Kunden). Diese Datei kann vom Hoster Kundenspezifisch über eine hosting site generiert werden
  • dev-Gerätetyp.txt: legen für jeden verwendeten Gerätetyp fest, welches Geräteklassenspezifisches staging-config Script (z.b. cfg-phone.txt) verwendet wird
Update Script Sicherheit

Das update Script kann die Registrierungskennwörter enthalten (siehe set-Kundenname.txt oben). Im Prinzip sind die staging Scripte für jederman lesbar. Das kann man auch nicht ändern, da die einzige Alternative wäre, den Kunden (bzw. ihren Geräten) ein Admin Kennwort für den Update Script Server zu geben (zumindest wenn es sich dabei um ein Gerät von uns handelt). Wenn das als Sicherheitsproblem aufgefasst wird, dann muss man die Kennwörter nicht generieren (device= leer lassen) und der Kunde muß das Kennwort selber mit dem Web Interface eintragen oder über das Telefon-UI eintragen.

Inbetriebnahme

Initial

Zentrale Geräte anlegen

  • Kerberos und Kerberos Backup anlegen
  • Neuen Kunden-Account für den Hoster in my.innovaphone anlegen
Neue Infrastruktur

Von einer Gruppe von Kunden genutzte Geräte anlegen

  • SBC anlegen
  • MediaPBX anlegen
  • Metadir anlegen
  • Reporting und Fax Linux-AP anlegen
  • global.txt, cfg-*.txt, dev-*.txt auf dem SBC ablegen (die sind immer identisch auf allen SBCs)
  • das passende local.txt erzeugen und auf dem SBC ablegen
Neuer Kunde
  • VM mit PBX anlegen
  • das passende set-Kundenname.txt erzeugen und auf dem SBC ablegen
  • Einrichten der passenden User Objekte auf der Kunden-PBX und der dazu gehörenden SBC Objekte auf dem SBC
  • Projekt für den Kunden in my.innovaphone anlegen, als URL das staging.txt des Hosters (z.b. https://212.124.38.120/DRIVE/CF0/update/staging.txt) und als Trust das Root-Zertifikat des Hosters eintragen (wie aus der config), sofern der Hoster mit HTTPS arbeitet
Endgerät
  • Device in das Kunden-Projekt eintragen
  • Gerät lang resetten
  • unter Services/Upate als Command File URL immer das Redirect Script http://145.253.157.4/redirect.php eintragen
  • ggf. poll forcieren
  • Endgerät bucht sich auf der richtigen Kunden-PBX als _UNKNOWN_ ein und kann per ZAD einem Userobjekt zugewiesen werden

Support / debugging von Kundenproblemen

  • Alarms, Events und syslog sind auf der jeweiligen Kunden-PBX zentralisiert
  • Config Sicherung erfolgt auf die CF der Kunden-PBX
  • Alle Geräte (auch die beim Kunden) sind in der Kerberos Domäne, wodurch Hoster Admins sich dort anmelden können
  • Kunde muss Zugriff durch Teamviewer erlauben falls nötig
  • Inbetriebnahme semi-automatisch

Reporting (Multiple PBX)

VM muß von Anfang an eine größere VM betrieben werden:

  • Plattengröße von 50GB haben um die erwarteten CDR Daten für 200 Kunden ein Jahr lang auzubewahren
sehr grobe Schätzung. Da muss man Erfahrungen sammeln
  • RAM 1GB

V10 Linux Image und Reporting Files werden benötigt, nur die enthalten die Mandantenfähigkeit. Gebraucht wird die Linux-AP und das Reporting. Eine solche Linux-AP kann mehrere (200) Kunden bezüglich der Ruflisten und des Reportings bedienen (Erfahrungen fehlen allerdings noch).

TODO: Namenskonventionen / Login / Filter / ...

  • Mails??
  • Reporting Zugang?

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

Konfiguration Kunden-PBX

Gateway / CDR0
  • Type Remote-AP-S
  • Address Reporting Linux-AP
  • Port 443
PBX / myPBX / Call List Service
  • Type Remote-AP-S
  • Host SBC-IP-addr:Reporting-User-HTTP-Map-Port-auf-SBC
  • User innovaphone-reporting ?????

pass: reporting

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

Telefonbuch - PBX

  • pro Kunde wird im SBC ein NAT-Port-Map für LDAPS(TCP Port 636) zur entsprechenden Kunden-IPVA konfiguriert. Das Telefon hat die Möglichkeit den Port in der Phone/User/Directories/PBX anzugeben und benutzt dadurch den LDAP-Server der Kunden-IPVA-PBX(und nicht den des SBC).
  • Es wird LDAPS verwendet, 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 das erhaltene Zertifikat nur zur Verschlüsselung.

Telefonbuch - External LDAP Server

Estos Metadir
  • pro SBC gibt es einen Metadir Server der alle im SBC verwaltete Kunden bedient. Für alle Kunden an einem SBC gibt es ein gemeinsam-genutztes NAT-Map(beim SBC1 ist es Port 9007) zum Metadir Server
  • pro Kunde gibt es einen LDAP-Knoten (dc=Kunden-ID) und 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 contacts.csv verwenden, damit der Replikator immer einheitlich konfiguriert werden kann.
      • die CSV Datei wird via https auf der CF-Karte des SBCs hochgeladen. Jeder Kunde hat auf der CF-Karte ein eigenes Verzeichnis (Kunden-ID) darin enthalten ist die contacts.csv Datei. Der Kunde verwendet curl um die csv-Datei auf den SBC zu laden.
        Die Syntax dafür ist: curl --verbose -k https://212.124.38.120/DRIVE/CF0/directory/Kunden-ID/ -T contacts.csv

Struktur auf dem SBC 

/DRIVE/CF0/
    directory/                  - directory Verzeichnis und Unterverzeichnisse sind write-only ohne Authentifizierung
      Kunden-ID/           
        contacts.csv
  • der Estos Metadir Server hat die gleiche Ordnerstruktur wie die CF-Karte des SBC
    C:\directory\
      script.bat                - script wird vom Replikator vor dem Einlesen der csv-Datei ausgeführt. Script überschreibt die csv-Datei mit dem Inhalt der csv-Datei auf dem SBC
      contacts.csv              - Vorlage für eine contacts.csv, wird verwendet beim Erstellen des Replikators
      Kunden-ID\           
        contacts.csv
  • Der Replikator verwendet die entsprechende lokale contacts.csv, vor dem Lesen der csv-Datei ruft der Replikator noch die script.bat mit dem Parameter Kunden-ID auf(z.b. script.bat Kuenkel0001). Das der Replikator vor/nach dem Replizieren eine Datei ausführt, kann man beim Erstellen/Bearbeiten des Replikators über die Metadir-Admin-Oberfläche(genannt Datenbank-Wizard) im Menu "Zusätzliche Anwendungen" konfigurieren.

Die script.bat lädt via curl die csv-Datei aus dem per Parameter übergebenen Verzeichnis und stellt somit sicher dass man immer die aktuelle csv-Datei(vom SBC) verwendet. Die curl - syntax ist:
curl --verbose -k -u user:password https://10.30.255.0/DRIVE/CF0/directory/%1/contacts.csv -o c:\directory\%1\contacts.csv

user:password in der script.bat Datei sind Administrator - Credentials auf dem Kerberos-Server(Berechtigung muss Administrator sein, Viewer geht nicht)

Der Replikator wird alle 3 Stunden(möglicher Zeitintervall x Minuten - Monate) gestartet.
Alternativ kann der Replikator per cmd-line gestartet werden, dafür gibt es im EstosMetadir Installationsordner für jeden Replikator eine entsprechende exe-Datei(z.B. für den TXT/CSV Replikator - TextReplicator.exe). Die weiteren Parameter zum Aufruf der exe-Datei sieht man in der ebenfalls im InstallOrdner vorhandenen Datei "lastreplicator.bat". Falls diese noch nicht existiert, muss man den Replikator über die MetadirAdmin - Oberfläche einmalig starten, die "lastreplicator.bat" enthält dann die cmd-line Ausgabe des Replikator-Start-Befehls.
Im Replikator-Wizard werden die Spalten der csv Datei ("Nachname","Vorname","Firma","Telefon geschäftlich","Mobiltelefon") den gleichnamigen LDAP-Attributen/DB-Felder zugeordnet. Als Primärschlüssel verwendet man eine Kombination von "Nachname","Vorname","Telefon geschäftlich","Mobiltelefon".
Graphische Uebersicht des Replikator-Mechanismus

  • LDAP-Knoten:
    • Authentifizierung für den Zugriff auf LDAP-Knoten erfolgt per Username(=Kunden-ID)/Passwort(=Kunden-Registrier-Kennwort), es gibt keine Einschränkung auf IP-Netze.
    • als Profil wird immer das "Default" Profil(bei der Installation des Metadir Servers erstelltes Profil, ohne Rufnummerinfo) 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 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)
LDAP-Client
  • die Directories Einstellungen sollten per config - template verteilt werden, auf der VM10 gibt es dazu als Beispiel das config-template "default"
  • Phone/User/Directories/External LDAP Server Einstellungen
  • die Dialing Location am Telefon wird entsprechend der Amtsleitung des Kunden konfiguriert
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) nichts anfangen. Durch ein Parameter kann man im PBX0 Modul fest konfigurieren welcher LDAP Server genutzt werden soll.

config add PBX0 /ldap-default-addr 10.30.0.7 /ldap-default-port 714 (wobei 10.30.0.7 die IP des Metadir-Servers ist und 714 der LDAPS port)

Voicemail

Läuft auf der Kunden-PBX. Als Medienendpunkt muss das Webmedia auf der Media-PBX verwendet werden. Das Script und die Voice-Mails liegen auf der Kunden-PBX. Um ein externes Webmedia-IF verwenden zu können, muss es eine Registrierung auf dem VM-Objekt geben. Über diese wird der Ruf zum fernen Webmedia abgewickelt. Die Registrierung wird von einem GWxx lokal durchgeführt deren Rufe alle zum lokalen HTTP-EXT geroutet werden (Rufe zum VM-Objekt gibt es nicht, nur von dem Objekt).

Aktivierung der VM je nach Kundenwunsch.

PBX

Gateway

    • vmrelay GWxx, Register as Gateway, 127.0.0.1, Name= vmrelay
    • Route GWxx (vmrelay) --> ###12 GWyy (HTTP-EXT)

MWI

Geht einfach so.

Mail MWI

Versand erfolgt über den Mail Server des Hosters. In der Regel erfordert das eine SMTP Authentifizierung. Für jede Kunden-VM kann und muss das email.xml angepasst werden:

  • message sender
  • Betreff der MWI Mail
  • mail server
  • authentifizierung

Die Änderungen sind (zumindest für gleichsprachige Kunden, cf. Betreff) gleich. Das kann also einmal gemacht und dann immer kopiert werden.

Für jeden mail Empfänger muss die Email Adresse vollständig in den URL Parameter des User eingetragen werden (praktischer als als Textfile in den User Directories),

Operator

Datensicherung

Die Datensicherung gegen "Disaster Recovery" (also das Wiederherstellen verloren gegangener Daten) sollte durch den Hoster erfolgen. Konkret bedeutet dies, dass der in der LÖage sein sollte, eine oder mehrere VMs aus seinen Sicherungen wieder herzustellen.

Die Sicherung der Benutzerdaten (individuelle Telefonkonfigurationen, Ruflisten und Verzeichniseinträge) erfolgt per Update Script auf die Kunden-VM. Die Konfiguration der Kunden-PBX erfolgt auf den SBC. Diese Daten dienen eher der Wiederherstellung versehtnlich gelöschter oder unerwünscht (ver-)konfigurierter Daten. Die Sicherung dieser Daten wiederum erfolgt dann (s.o.) durch den Hoster.

Logistik

Im Moment sehen wir keine spezielle Logistik vor. Das bedeutet, dass alle Produkte(vor allem also Telefone) "Standard-Produkte" sind. Es gibt daher auch keine spezielle Provisionierung dafür. Der in Update Server oben beschriebene Staging Mechanismus basiert auf den normalen Features und erfordert daher einen manuellen Eingriff des Hosters/Resellers/Endkunden (Festlegen der Update URL am Gerät oder im DHCP Server des Kunden).

UI

Im Moment ist keinerlei spezielles UI für den Hoster, den Reseller oder den Endkunden vorgesehen. Dies kann (und muss recht wahrscheinlich) durch den Hoster und/oder Reseller selbst realisiert werden, wenn er das für sein Geschäftsmodell für erforderlich hält.

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