Lizenzprobleme nach Verlagerung der Starface VM auf anderen Host

  • Wir haben nun bereits zweimal das Problem gehabt, das nach Wiedereinschalten alle Lizenzen weg sind. Das ist ärgerlich. Nach Eintragen der Baselizenz sieht man alle Lizenzen wieder und Starface muss das wieder freischalten. Im folgenden sind dann aber alle UCC Premium Rechte bei den Benutzern weg. Zur automatisierten Wiedererteilung habe ich ein PSQL Script gemacht. Darüber hinaus ergeben sich dann aber weitere Probleme, die UCC Clients verbinden sich nicht mehr richtig mit der Telefonie, der Status bleibt Offline. Witzigerweise verbindet aber der Chat. Das Problem ist dadurch zu lösen, dass man einfach irgendeine Rufnummer dem Benutzer zuordnet, speichert und dann ggf. gleich wieder entfernt.


    Hier der SQL Befehl und einige Beispiele, die ich zur Herleitung zuvor verwendet habe:


    Zunächst per SSH an Starface Console anmelden,
    dann "psql asterisk" eingeben und folgenden Befehl ausführen:


    /* Allen Benutzer mit einem WinClient als primäres Telefon das Premium UCC Recht erteilen, sofern nicht vorhanden */
    insert into account2permission (accountid, permissionid)
    (
    select id,34 from account where
    id not in (select accountid from account2permission where permissionid = 34) and
    primarytelephoneid in ( select b.telephoneid from telephone a,telephonenumber2telephone b where b.telephoneid = a.id and a.telephone like '%WinClient')
    );



    /* Beispiele, wie man zu diesen Tabellen und Feldern kommt, im Folgenden nicht mehr relevant nach Ausführung obiges SQL Befehls, nur BEISPIELE! */


    /* Alle Starface SQL Tabellen ausgeben */
    SELECT table_name FROM information_schema.tables WHERE table_schema = 'public' and table_type='BASE TABLE' ;


    /* Alle UCC Windows Telefone auslesen */
    select * from telephone where telephone like '%WinClient';


    /* Alle Benutzer ohne das UCC Premium Rechte auslesen */
    select comment,primarytelephonenumberid from account where id not in (select accountid from account2permission where permissionid = 34);


    /* Ein bestimmten Benutzer suchen */
    select comment,primarytelephoneid from account where comment like '%Luithle%';
    comment | primarytelephoneid
    -----------------------+--------------------
    Trainee, Nachname | 3372
    Nachname, Vorname | 3348



    /* Suche Benutzer, welche keine keine UCC Premium Berechtigung hat und dessen Haupt Telefon, wenn es ein WinClient ist */
    select id,comment,primarytelephoneid from account where
    id not in (select accountid from account2permission where permissionid = 34) and
    primarytelephoneid in ( select b.telephoneid from telephone a,telephonenumber2telephone b where b.telephoneid = a.id and a.telephone like '%WinClient');


    id | comment | primarytelephoneid
    ------+---------------------+--------------------
    1004 | Nachname, Vorname | 3356



    /* Test mit der Einschränkung auf eine bestimmte Benutzer ID */
    select id from account where id = 1893 and
    id not in (select accountid from account2permission where permissionid = 34) and
    primarytelephoneid in ( select b.telephoneid from telephone a,telephonenumber2telephone b where b.telephoneid = a.id and a.telephone like '%WinClient');


    insert into account2permission (accountid, permissionid) values (
    (
    select id from account where id = 1893 and
    id not in (select accountid from account2permission where permissionid = 34) and
    primarytelephoneid in ( select b.telephoneid from telephone a,telephonenumber2telephone b where b.telephoneid = a.id and a.telephone like '%WinClient')
    ), 34) ;

  • Wie betreibt Ihr Eure STARFACE ?


    Nicht per Zufall auf einem Hyper-V Cluster ?


    Falls ja, haben die Hyper-V Hosts verschiedene Prozessoren oder sonst verschiedene Hardware die Berechnung der Maschinen-ID der STARFACE einfliesst ?


    Wenn durch abweichende Hardware auf den Hosts eine andere Maschinen-ID errechnet wird, führt das zu dem Verhalten wenn die STARFACE-VM nach verschieben auf einen anderen Host neu gestartet wird.


    Wenn die VM auf einem Cluster betrieben wird, müssen die Cluster-Host identische Hardware-Ausstattung haben, resp. die VM darf nur unter Hosts mit derselben Hardware verschoben werden.


    Wir betreiben unsere STARFACE auf einem Hyper-V-Cluster mit identischen Hosts und haben keine Probleme

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

    2 Mal editiert, zuletzt von thomas.hertli ()

  • Wir haben das selbe Problem. Wir haben am Freitag Nacht unseren neuen VmWare Cluster in Betrieb genommen und haben alle virtuellen PBX unserer Kunden dahin verschoben. Wir waren vorbereitet, dass wir die Server Keys neu einspielen müssen, aber das die Zuordnung der UCC Premium Lizenz weg ist hat uns getroffen :)


    ->> Ich habe ein Ticket eröffnet


    Gruss Mirko

  • Es sollte möglich sein, unmittelbar nach dem Umzug ein Backup einzuspielen. Darin sind die Rechtezuordnungen enthalten.


    Hi Fabian


    Das ist eine gute Idee, das probiere ich mal.


    Gruss Mirko

  • Hallo zusammen,
    das gleiche Problem habe wir mit unserem VMWare Cluster (V6.7) leider auch. Es fallen immer wieder die Lizenzen raus, je nach Situation wie z.B. Verschieben der VM wg. Lastenausgleich, Re-Boot der VM, etc. Mit CPU-IDs etc. hat das jedoch - warum auch immer - nicht wirklich geklappt.


    Die einzige Möglichkeit innerhalb eines vollwertigen Cluster wäre im Moment, das Neueinspielen der Lizenz und anschließend über den Support freischalten lassen - und zwar jedesmal. Das unschöne dabei ist, dass man es nicht sofort merkt wenn die Lizenzen weg sind sonder erst dann, wenn die Telefonie nicht mehr wie gewohnt funktioniert - und dann hat man wieder Stress, vor allem am Freitag nach 17 Uhr.


    Aktuell habe ich 3 Interessenten, welch die Starface in ihrem HA-Cluster einsetzen wollen, aber vor diesem Hintergrund kann die Starface als einwandfreie VM im Cluster nicht empfohlen werden. Weiterhin ist es kaum realistisch, von 100% identischer Hardware aller Hosts im Cluster auszugehen. Dies kann nicht sichergestellt werden (außer anfangs bei kompletten Neukauf eines Clusters), zumal der Cluster sich im Laufe der Zeit mit neuer Hardware erweitern oder ändern kann. Z.B. werden immer wieder mal einzelne Hosts, z.B. wg. defekte, mit neuer Hardware bestückt/ergänzt/erweitert oder ganz ausgetauscht, usw. Falls so etwas nach längerer Zeit Eintritt, weis später keiner mehr, weshalb plötzlich die Starface nicht mehr einwandfrei funktionert. Insofern ist dies auch keine vernünftige Lösung. Andere Alternativen für den Eigenbetrieb wären, dies Starface-VM im Cluster an nur einem Host zu binden, wodurch der Vorteil des Clusters für die Starface obsolete wäre, oder (in der fortschreitenden IT-Virtualisierung) weiterhin eine klassische Starface Hardware-Appliance zum Einsatz zu bringen.


    Schönen Gruß,
    Reiner


  • Hallo Reiner,


    die Problematik mit dem Betrieb einer STARFACE auf einem VM-Cluster ist uns bekannt, und wir arbeiten an einer Lösung die den reibungslosen Betrieb auf einem Cluster ermöglicht und unser Schutz gegen doppelten Betrieb eines Lizenzen in Einklang bringt. Ich kann aber derzeit keine Auskunft geben wann diese Lösung verfügbar sein wird.


    Viele Grüße

    Quality Assurance


    STARFACE GmbH | Adlerstraße 61 | 76137 Karlsruhe | www.starface.com

  • Hallo Reiner,


    die Problematik mit dem Betrieb einer STARFACE auf einem VM-Cluster ist uns bekannt, und wir arbeiten an einer Lösung die den reibungslosen Betrieb auf einem Cluster ermöglicht und unser Schutz gegen doppelten Betrieb eines Lizenzen in Einklang bringt. Ich kann aber derzeit keine Auskunft geben wann diese Lösung verfügbar sein wird.


    Viele Grüße


    Okay und besten Dank für's Feedback.

  • Ich fände es klasse, wenn man dieses "Feature" auch auf den Werbeseiten anbringt.
    Man kauft sich als Kunde teure gedoppelte Hardware ein, die höchst Komplex einzurichten und zu betreiben ist, um für den Fall einer Geschäftsunterbrechung durch Hardwaredefekt gewappnet zu sein. Und dann wird man von der Software flankiert, die genau diese Errungenschaften zunichte macht. Ganz ehrlich: doppel-fail!


    Ich habe zwar Verständnis dafür, dass man gerne sein Produkt rechtmäßig betrieben sehen möchte. Dafür aber alle ehrlichen und zahlenden Kunden in Sippenhaft nehmen? Das hinterläßt sicherlich nicht nur bei mir einen ganz üblen Nachgeschmack und mein Vertrauen in Fa. Starface ist erheblich beschädigt.

  • wir betreiben die Starface auch in einem vsphere cluster. is also auch für uns interessant

    1 x Starface VM | 231 User mit Snom | Telekom SIP-Trunk | Peoplefone SIP-Trunk | 25 ASCOM DECT Sender | 64 DECT ASCOM Mobilteile | 45 x PAP2T für Fax/Tor/Tür Sprechstellen|
    1 x Starface Pro | 20 User mit Snom | Peoplefone SIP-Trunk | 2 x PAP2T für Fax/Tor/Tür Sprechstellen
    1 x Starface Advanced | 11 User mit Snom | Telekom SIP-Trunk | Peoplefone SIP-Trunk | 2 x PAP2T für Fax/Tor/Tür Sprechstellen

  • [UPDATE zum Post vom 21.01.2019]
    Vor dem letzen Einspielen der Lizenz und dem anschließenden Freischalten über den Support, hatte ich vorsichtshalber die Starface-VM im Cluster an nur einen Host gebunden. Aber heute - nach dem Neustart (immer noch der gleiche Host) - war die Lizenz schon wieder verschwunden. Insofern kann es nun nicht mehr alleine mit der Hardware zu tun haben, weil sich diese nicht geändert hat. Es scheint so, als ob die "Starface Lizenz-Prüfprozedure" grundsätzlich in einer (geclusterten) VMWARE-Umgebung sich manchmal nicht wirklich zurecht findet. Ich überlege mir im Moment, ein Nagios Prüfmodul zu bauen, damit das Verlieren der Lizenz auch zeitnah automatisch bemerkt wird, bevor die Anwender sich beschweren, was mich nicht gut dastehen lässt (und meine Laune verdirbt). Oder vielleicht wäre es stressloser und einfacher wieder zurück zur reinen Hardwarelösung zu gehen (ich glaube wir haben im Keller noch eine Advanced liegen), bis das Thema mal endgültig gelöst ist. Jedenfalls hat es aktuell den Anschein, als wäre es nicht nur ein Schutz gegen doppelten Betrieb, sondern auch gegen den Betrieb im Cluster. Hmmm ...?

  • Bei uns läuft die STARFACE auf einem HyperV-Cluster und wir hatten bis anhin keine Probleme damit.

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • Um es nochmal kurz und knapp zusammenzufassen:


    Die Hardware-ID, an die die Lizenzen gebunden werden, berechnet sich aus CPU-Eigenschaften und SSH-Key.


    Ändert man einen dieser beiden Bestandteile, ändert sich die Hardware-ID und die Lizenzprüfung geht von einer Nutzung auf einem anderen Host aus.
    Man muß in der Regel also nur Acht geben, dass sich die CPU-Eigenschaften (Anzahl, Art und Features) nicht ändern. Wenn man das im Cluster berücksichtigt, ist der Betrieb in einem solchen auch kein Problem.

  • Um es nochmal kurz und knapp zusammenzufassen:


    Die Hardware-ID, an die die Lizenzen gebunden werden, berechnet sich aus CPU-Eigenschaften und SSH-Key.


    Ändert man einen dieser beiden Bestandteile, ändert sich die Hardware-ID und die Lizenzprüfung geht von einer Nutzung auf einem anderen Host aus.
    Man muß in der Regel also nur Acht geben, dass sich die CPU-Eigenschaften (Anzahl, Art und Features) nicht ändern. Wenn man das im Cluster berücksichtigt, ist der Betrieb in einem solchen auch kein Problem.


    Dies kann ich leider nicht Bestätigen. Faktum ist, beim letzten Re-Boot der PBX-VM, welche nur ein einem einzigen Host gebunden ist, hat sich an den o.g. Parametern rein gar nichts geändert und trotzdem musst die Lizenz neu eingetragen werden.

  • Dies kann ich leider nicht Bestätigen. Faktum ist, beim letzten Re-Boot der PBX-VM, welche nur ein einem einzigen Host gebunden ist, hat sich an den o.g. Parametern rein gar nichts geändert und trotzdem musst die Lizenz neu eingetragen werden.


    Das hast Du vielleicht beobachtet -- deine Schlussfolgerung ist jedoch falsch, denn meine Aussage zur Berechnung der Hardware-ID ist korrekt.
    Ich kann diese sogar weiter präzisieren: Es werden CPU-Modell (Nummer und Name der CPU inkl. Taktrate), Vendor-ID und Cache-Size bewertet. Das sieht dann (für einen CPU-Kern) z.B. so aus:


    vendor_id : GenuineIntel
    model : 45
    model name : Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
    cache size : 20480 KB


    Vielleicht hast Du die Anzahl der Kerne geändert oder eine Aktualisierung des Hypervisors hat eine Veränderung der CPU-Eigenschaften bewirkt, die mit einem Neustart aktiv wurde... who knows. Fakt ist jedoch, dass die Hardware ID aus den genannten CPU-Eigenschaften und dem SSH-Public-Key errechnet wird.


  • Hallo Fabian,
    über die Reaktion bin ich nun überrascht, da plötzlich eine faktische Wahrnehmung als falsche Schlussfolgerung dargestellt wird.


    Es mag durchaus möglich sein, dass die Berechnung der Hardware-ID genauso funktioniert wie von dir beschrieben, dies hatte ich nie bestritten. Das Resultat jedoch ist, dass die Lizenz - wann und warum auch immer - plötzlich verschwindet, was mittlerweile von vielen anderen bestätigt wird.


    Und nochmals, beim letzten mal hat sich an der VMware Umgebung rein gar nichts geändert - gleicher Host, alles identisch. Und trotzdem war die Lizenz weg. So ist die Situation. Insofern kann resultierend aus der gegebenen Situation eine reiner Bezug zur Hardware nicht bestätigt werden, weil sich diese und dessen Konfiguration eben nicht geändert hat. Vielleicht wird bei der Berechnung der Hardware-ID etwas mit einbezogen, was sich nach einem Reboot in einer VMWare-Umgebung gelegentlich ändert und die Berechnungsprozedur dies als Hardwareänderung interpretiert.


    Wie auch immer, letztendlich stellt sich die Hardware-ID-Berechnungsprozedur als quasi uneinsichtige „BlackBox“ aus einer Prä-Virtualisierungsepoche dar.

  • Und trotzdem gibt es diese Probleme anscheinend nur in VMware-Umgebungen.


    Wir kennen dies in HyperV-Umgebungen nicht.


    Scheint also doch so zu sein, dass die Ursache bei VMware liegt.

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security


  • Die Berechnung der Hardware-ID zieht physikalische CPU-Eigenschaften und SSH-Schlüssel der Anlage zur Berechnung heran. Da ich davon ausgehe dass ihr die SSH-Schlüssel der Anlage nicht gelöscht habt, muss sich also die CPU aus Sicht der VM geändert haben (das heißt nicht dass sich die Hardware selbst geändert hat, sondern wie der Hypervisor sie der VM exponiert). Ich würde dort für die Suche nach der Ursache ansetzen, so ein Szenario scheint mir am schlüssigsten.


    Ist die VM seit dem Umziehen auf einen einzelnen Host vor dem verlieren der Lizenz neugestartet wurden? Eventuell wurde es dadurch ausgelöst. Auf unserem VMWare ESXi Host habe ich das Phänomen noch nicht beobachtet.


    Wir gesagt, arbeiten wir an einer Lösung wie man den Betrieb im Virtualisierungscluster realisieren kann.

    Quality Assurance


    STARFACE GmbH | Adlerstraße 61 | 76137 Karlsruhe | www.starface.com

  • Da fühlt man sich als Kunde sicher gleich richtig gut. Höchste Zeit, Starface weiter zu empfehlen.


    Vor allem dann, wenn man seine Arbeits- und Lebenszeit mit Dingen verbringen darf, die absolut nicht im SINNE DES KUNDEN sind, sondern nur im Sinne des Herstellers (die Gier). Denn eine Routine die dafür sorgt, dass das Produkt unter bestimmten (völlig intranparenten) Vorraussetzungen den Dienst einstellt - an anderer Stelle spricht man dann von DENIAL OF SERVICE (Angriff) - ist gerade mal das, was ganz sicher niemand gerne in seinem Betrieb hat.
    Dem Kunden dann noch zu unterstellen, dass er selbst für die Betriebsunterbrechung verantwortlich ist, ist schon recht "interessant". Und das, obwohl man heute durchaus schon weiß, dass Software (ggf. auch Denial-of-Service Module) inherent fehlerbehaftet ist. In meiner Welt ist das ein absoluter Nogo - nicht auf Augenhöhe - am Kunden vorbei.


    Das ist übrigens gerade Gratis-Feedback! Es gibt nicht wenige Firmen und Konzerne, die ganz ordentliche Summen für Umfragen ausgeben, um herauszufinden, was der Kunde so denkt. Ich habe überlegt, ob ich euch das schreibe oder es nur extern Verblogge. Aber ich bleibe fair und lasse euch das auch hier wissen. Denn: Nicht nur ReinerW und ich lesen diese Zeilen und öffnen ihren Geldbeutel in Zukunft möglicherweise Unternehmen, die sie ernst nehmen.


    thomas.hertli
    Mit Verlaub: Nein, die Ursache liegt nicht bei Anderen. Die Ursache liegt in einer Routine, die das Produkt lahm legt, wenn es vom Kunden von einem Host zum anderen verschoben wird, um Ausfällen vorzubeugen. Das Außerkraftsetzungsmodul ist Ursache. Sie macht alle Arbeit - Planung, Integration von HA-Geschichten - zunichte, die man teuer eingekauft hat, um Betriebsausfällen vorzubeugen.

    Einmal editiert, zuletzt von Tschoasch ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!