Seite 2 von 2 ErsteErste 12
Zeige Ergebnis 16 bis 25 von 25

Thema: Lizenzprobleme nach Verlagerung der Starface VM auf anderen Host

  1. #16
    STARFACE Expert
    Benutzerbild von fwolf
    Registriert seit
    28.12.2011
    Ort
    72622 Nürtingen
    Beiträge
    2.167

    Standard

    Zitat Zitat von ReinerW Beitrag anzeigen
    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.
    Grüße,
    Fabian

    STARFACE Excellence Partnerwww.fluxpunkt.deinfo@fluxpunkt.de

    Informationen über Fluxpunkt Module für STARFACE
    Produktupdates, Neuigkeiten & sonstiges gezwitscher: Fluxpunkt bei Twitter

  2. #17
    STARFACE User
    Benutzerbild von ReinerW
    Registriert seit
    19.02.2008
    Beiträge
    12

    Standard

    Zitat Zitat von fwolf Beitrag anzeigen
    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.

  3. #18
    STARFACE Expert
    Benutzerbild von thomas.hertli
    Registriert seit
    30.05.2007
    Ort
    Arisdorf (CH)
    Beiträge
    960

    Standard

    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.
    STARFACE Certified Partner

    Gruss
    Thomas

    hertli ¦ IT
    hertli Informatik+Treuhand

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


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

  4. #19
    STARFACE Crew
    Benutzerbild von TomAnson
    Registriert seit
    11.11.2014
    Ort
    Karlsruhe
    Beiträge
    1.331

    Standard

    Zitat Zitat von ReinerW Beitrag anzeigen
    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.
    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.
    STARFACE Quality Assurance

    Bug gefunden? Hier melden!
    Featurewunsch oder Verbesserungsvorschlag? Trage es in unserem Feature Request Portal ein!
    Unsere Knowledge-Base für STARFACE findet ihr hier!

  5. #20
    STARFACE User

    Registriert seit
    22.06.2018
    Beiträge
    17

    Standard

    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.
    Geändert von Tschoasch (01.02.2019 um 15:37 Uhr)

  6. #21
    STARFACE Expert
    Benutzerbild von fwolf
    Registriert seit
    28.12.2011
    Ort
    72622 Nürtingen
    Beiträge
    2.167

    Standard

    Zitat Zitat von ReinerW Beitrag anzeigen
    Hallo Fabian,
    über die Reaktion bin ich nun überrascht, da plötzlich eine faktische Wahrnehmung als falsche Schlussfolgerung dargestellt wird.
    Nunja,... was kommt denn sonst in Frage?

    Wenn sich die genannten Hardwareeigenschaften sowie der SSH-Public-Key nicht verändern, kann sich die Hardware-ID nicht verändern.

    Es ist also viel wahrscheinlicher, dass sich eine Hardwareeigenschaft geändert hat, Du aber nichts davon gemerkt hast.
    Ich nehme an, Du hast die genannten CPU-Eigenschaften, die das Linux-System "wahrnimmt", vorher und nachher nicht verglichen.
    Das bedeutet, Du weißt nicht, ob es eine Änderung gegeben hat, vermutest es nur, dass es nicht so war (da sich an der physikalischen Maschine vielleicht nichts verändert hat). Das läßt jedoch keine Schlussfolgerung in Bezug auf die virtuelle Maschine zu. Hier liegt der logische Fehler.

    Zitat Zitat von ReinerW Beitrag anzeigen
    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.
    Die Berechnung der Hardware-ID funktioniert so, wie von mir beschrieben.
    Und wenn andere das selbe beobachten, liegt vermutlich die selbe Ursache zugrunde.

    Niemand bestreitet, dass eine Lizenz "verloren gehen kann", wenn man eine VM irgendwohin migriert.
    Ich sage nur, dass deine Behauptung (in Form einer "Negativbestätigung") auf meine Erläuterungen zur Berechnung der Hardware-ID und Lizenzbindung einen logischen Fehler enthält. Nämlich den, dass deine Schlussfolgerung aus einer Beobachtung auf einer nicht bestätigten Vermutung beruht.

    Zitat Zitat von ReinerW Beitrag anzeigen
    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.
    Du kannst mir glauben, was die Berechnung der Hardware-ID (auf einer Linux-Plattform der STARFACE) angeht. Ich vermute da nicht, sondern ich weiß, wie die Implementierung aussieht.
    Geändert von fwolf (01.02.2019 um 15:50 Uhr)
    Grüße,
    Fabian

    STARFACE Excellence Partnerwww.fluxpunkt.deinfo@fluxpunkt.de

    Informationen über Fluxpunkt Module für STARFACE
    Produktupdates, Neuigkeiten & sonstiges gezwitscher: Fluxpunkt bei Twitter

  7. #22
    STARFACE Expert
    Benutzerbild von fwolf
    Registriert seit
    28.12.2011
    Ort
    72622 Nürtingen
    Beiträge
    2.167

    Standard

    Zitat Zitat von Tschoasch Beitrag anzeigen
    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.
    [x] Du weißt nicht, was ein Denial-of-Service-Angriff ist.

    Zitat Zitat von Tschoasch Beitrag anzeigen
    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.
    Selbst eine Doppelnutzung von Lizenzen ist eine gewisse Zeit lang möglich. Die Lizenzen werden in in diesem Fall für etwas mehr als eine Woche freigeschaltet, die Anlage informiert über den Umstand und zeigt neben den Lizenzen ein Ablaufdatum. Alles was man tun muß, ist die Serverlizenz neu einzutragen -- ein einziger Lizenzschlüssel -- alle anderen Lizenzen werden automatisch mit eingetragen.
    Sorry, was willst Du mehr?

    Die Umstände, die zur Annahme einer Lizenzverletzung führen, sind seit Jahren hier im Forum verfügbar. Man kann sich in einem solchen Fall also ohne Weiteres informieren und hat hierfür auch über eine Woche Zeit. In der Zeit muß ein STARFACE-Partner oder STARFACE selbst, die Änderung der Hardware-ID bestätigen. Das ist in der Regel völlig problemlos.
    Grüße,
    Fabian

    STARFACE Excellence Partnerwww.fluxpunkt.deinfo@fluxpunkt.de

    Informationen über Fluxpunkt Module für STARFACE
    Produktupdates, Neuigkeiten & sonstiges gezwitscher: Fluxpunkt bei Twitter

  8. #23
    STARFACE User
    Benutzerbild von ReinerW
    Registriert seit
    19.02.2008
    Beiträge
    12

    Standard

    Zitat Zitat von fwolf Beitrag anzeigen
    Nunja,... was kommt denn sonst in Frage?

    Wenn sich die genannten Hardwareeigenschaften sowie der SSH-Public-Key nicht verändern, kann sich die Hardware-ID nicht verändern.

    Es ist also viel wahrscheinlicher, dass sich eine Hardwareeigenschaft geändert hat, Du aber nichts davon gemerkt hast.
    Ich nehme an, Du hast die genannten CPU-Eigenschaften, die das Linux-System "wahrnimmt", vorher und nachher nicht verglichen.
    Das bedeutet, Du weißt nicht, ob es eine Änderung gegeben hat, vermutest es nur, dass es nicht so war (da sich an der physikalischen Maschine vielleicht nichts verändert hat). Das läßt jedoch keine Schlussfolgerung in Bezug auf die virtuelle Maschine zu. Hier liegt der logische Fehler.

    Die Berechnung der Hardware-ID funktioniert so, wie von mir beschrieben.
    Und wenn andere das selbe beobachten, liegt vermutlich die selbe Ursache zugrunde.

    Niemand bestreitet, dass eine Lizenz "verloren gehen kann", wenn man eine VM irgendwohin migriert.
    Ich sage nur, dass deine Behauptung (in Form einer "Negativbestätigung") auf meine Erläuterungen zur Berechnung der Hardware-ID und Lizenzbindung einen logischen Fehler enthält. Nämlich den, dass deine Schlussfolgerung aus einer Beobachtung auf einer nicht bestätigten Vermutung beruht.

    Du kannst mir glauben, was die Berechnung der Hardware-ID (auf einer Linux-Plattform der STARFACE) angeht. Ich vermute da nicht, sondern ich weiß, wie die Implementierung aussieht.
    Jaja alles klar, ich steige nun aus. Leider driftet dieser Thread (wieder mal, wie bei vielen anderen Themen im Internet) spitzfindig mit unnötigen Emotionen, vom Objektiven kleinkariert ins Subjektive und mit jeder Menge aus der Luft gegriffenen Unterstellungen, ab. Dafür ist mir meine Zeit zu schade. Irgendwann wird das Problem schon irgendwie gelöst werden. Kannst gerne so weiter machen aber ohne mich das ist nicht mein Niveau. Viel Spass und eine gute Zeit noch.

  9. #24
    STARFACE Expert
    Benutzerbild von fwolf
    Registriert seit
    28.12.2011
    Ort
    72622 Nürtingen
    Beiträge
    2.167

    Standard

    Das ist interessant,... vielleicht liest Du das von mir Geschriebene nochmal, ohne mir dabei irgendeine Emotionalität zu unterstellen. Mir scheint, als wärst Du hier sehr emotional und schließt von dir auf andere.

    Ich habe dich lediglich auf einen Fehler in deiner Schlussfolgerung hingewiesen und war in dieser Diskussion derjenige, der sich von subjektiven und unvollständigen Beobachtungen distanziert und dir stattdessen erklärt hat, was da unter der Haube in der STARFACE passiert.
    Aber wenn das nicht dein Niveau ist...

    Die Sache ist die:
    Mir ist egal, ob Du mir glaubst, ob Du irrst oder was Du denkst.
    Wenn Du aber in einem öffentlichen Forum -- in dem Dritte Hilfe und fundierte Informationen suchen -- durch deine Posts suggerierst, etwas entspräche nicht der Realität, bei dem es sich jedoch um nachweisbare Fakten handelt, dann korrigiere ich das und weise gerne und ausführlich darauf hin, wo und weshalb Du irrst.
    Denn wie sollen Dritte sich ansonsten auf irgendeine Information in einem öffentlichen Forum verlassen können? Das geht nur, indem jeder selbst und für sich die Glaubwürdigkeit einer Behauptung bewertet. Und um bewerten zu können, muß ich die Gedankengänge, mögliches Wissen und Nichtwissen sowie die Richtigkeit von Schlussfolgerungen nachvollziehen können.
    Grüße,
    Fabian

    STARFACE Excellence Partnerwww.fluxpunkt.deinfo@fluxpunkt.de

    Informationen über Fluxpunkt Module für STARFACE
    Produktupdates, Neuigkeiten & sonstiges gezwitscher: Fluxpunkt bei Twitter

  10. #25
    STARFACE Expert
    Benutzerbild von thomas.hertli
    Registriert seit
    30.05.2007
    Ort
    Arisdorf (CH)
    Beiträge
    960

    Standard

    Zitat Zitat von Tschoasch Beitrag anzeigen
    @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.
    Dann ebenfalls mit Verlaub scheint es an einer Fehlkonfiguration des VMware-Clusters zu liegen.
    STARFACE Certified Partner

    Gruss
    Thomas

    hertli ¦ IT
    hertli Informatik+Treuhand

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


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

Ähnliche Themen

  1. Starface Anlagenverbund - Gruppe ab- / anmelden am anderen Standort
    Von heikokast im Forum STARFACE Einrichtung & Administration
    Antworten: 0
    Letzter Beitrag: 15.11.2017, 11:02
  2. SF 6.0.1.13 unter Virtual Box; Probleme nach Neustart des Host-Systems
    Von BIGAIRFOX im Forum STARFACE Einrichtung & Administration
    Antworten: 2
    Letzter Beitrag: 21.08.2015, 08:36
  3. Sporadisches Problem: No Such Host bei SIP Provider
    Von mattla93 im Forum Leitungen SIP, NGN, ALL-IP
    Antworten: 8
    Letzter Beitrag: 15.07.2013, 09:22
  4. Starface im Vergleich zu anderen Tk-Anlagen
    Von Chilavert im Forum Off-Topic & Smalltalk
    Antworten: 3
    Letzter Beitrag: 30.06.2011, 05:37
  5. [Gelöst] Lizenzprobleme nach Update auf Pro
    Von helmut im Forum STARFACE Installation
    Antworten: 1
    Letzter Beitrag: 27.07.2009, 14:16

Stichworte

Lesezeichen

Forumregeln

  • Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
  • Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
  • Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
  • Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
  •