Beiträge von Steinweber

    Hallo


    welche API verwendest du? Die "alte" API ist die einzige, die noch aktiv verwendet wird und ein SSL-Zertifikat benötigt. Ich würde an deiner Stelle mal nach der neue API fragen. Aber was die Frage mit LiveConfig zu tun hat, entzieht sich mir gänzlich... Das Zertifikat wird ja nicht von LC angeboten, sondern von PSC mit der API.

    Warum implementierst du den letzten Teil deines Verwaltungs-Systems, nämlich die tatsächliche Konfiguration auf den Servern, nicht auch noch?


    Dovecot mit MySQL-Backend ist ziemlich easy. Einzig beim Apache hätte ich persönlich Bauchschmerzen bei der Implementierung (da einige Abhängigkeiten, vgl. System-Accounts, php.ini, FastCGI, ...).


    Ergebnis: komplette Unabhängigkeit von LiveConfig oder sonstigen Panels.


    Wenn es doch nur so einfach wäre ;)
    Aber mein Ziel ist es, dass die Kunden sich nicht mehr in LC anmelden müssen. KK hat dadurch ja keinen Nachteil. Die Lizenzen werden genau so weiter gekauft...

    Sehe ich teilweise auch so. Kunden neu anlegen und löschen sollte vollständig via API realisierbar sein.


    Ansonsten gibt es ja die Möglichkeit, die Rechnungen etc direkt im LiveConfig zu integrieren. Da mehrere Hosting-Accounts ja eh dem gleichen Kunden zugeordnet werden, hat jeder _Kunde_ auch eigentlich nur einen Login.


    Das sehe ich nicht so. Es gibt so viele Gründe, warum ich keine Funktionen in LC integrieren würde, sondern immer LC über die API in ein anderes System.
    Der erste Punkt wäre schon mal, dass viele Hoster nicht nur ein Panel anbieten. Also müsste man jede Funktion in jedes Panel integrieren. Deutlich einfacher, wenn man die Funktionen des Panels über die API in sein eigenes System einbaut.
    Die Steuerung von einzelnen Verträgen eines Kunden ist auch viel einfacher, wenn man eine Oberfläche hat. Was macht man, wenn ein Kunde über Jahre immer wieder neue Verträge macht? Die kann man nicht alle auf einen Server packen. Dann ist der Login auch immer unterschiedliche...
    Dann kommt noch die Domainverwaltung dazu usw.
    Wenn man davon ausgeht, dass ein Unternehmen solche Entwickungen/Integrationen zahlen muss, sei es an Externe oder die Zeit von Mitarbeitern, kostet es unterm Strich deutlich mehr und die Verwaltung ist erheblich umständlicher, wenn man kein eigenes "Backend/Panel" hat und LC/Plesk/etc über eine API anbindet.


    Ich möchte hier auch mal den Punkt ansprechen, was passiert, wenn man mal von LC weggeht. Hat man einen eigenen Datenstand, kann man jede API anbinden. Verwendet man aber LC und fügt dort die Funktionen ein, hat man keinen "eigenen" Datenbestand und man könnte nicht einfach wechseln. Zudem müssten sich die Kunden dann wieder an eine neue Oberfläche gewöhnen... Ich sehe bei jeder Betrachtungsweise nur Nachteile...


    Leider werden hier Fragen über Pläne bezüglich der API nicht beantwortet. Weder im Forum noch per E-Mail.

    Danke für die Antwort Herr Keppler.


    Ich würde gerne wissen ob es möglich wäre
    a) einen detaillierten Changelog für die API zu erstellen
    b) in der Doku/Handbuch Versionsangaben hinzuzufügen


    Meiner Meinung nach ist es sehr sinnvoll, wenn man angibt, in welcher Version (bei welchem Update) welcher Parameter oder welche Funktion hinzugekommen ist. Denn weder ich noch andere Entwickler werden die Zeit haben und ihre Scripte nach jedem Update mit dem Handbuch - Funktion für Funktion und Parameter für Parameter - zu vergleichen und Änderungen zu suchen.


    Ich wäre bereit meine neue SDK (php) wieder auf Github zu teilen. Dort könnten dann auch andere Entwickler Updates eintragen. Dazu muss man aber auch wissen, was sich geändert hat.


    Zitat

    Backend oder Frontend? Wenn Sie alle Objekte vollständig über die API verwalten möchten klingt das eher nach einem alternativen Frontend.


    Ja, das ist aus Ihrer Sicht richtig. Aus meiner Sicht möchte ich das LC-Frontend in mein Backend einbinden.

    Hallo


    Ich habe hier schon mehrmals Fragen zur API gestellt. Leider werden diese nicht oder erst sehr spät beantwortet. So hoffe ich, dass meine Fragen hier beantwortet werden.


    Meine aktuellste Frage betrifft HostingMailboxEdit. Dort kann man keinen Parameter "forward" angeben. Fehlt dieser oder ist er nur nicht in der Doku enthalten?


    Je mehr ich mit der API arbeite, desto mehr habe ich den Eindruck, dass die API nicht dazu gedacht ist, die Verwaltung über ein anderes System zu gestalten, sondern lediglich die einmalige Erstellung von Kunden/Reseller ermöglichen soll.
    Auch wenn es Funktionen wie Mailbox Edit gibt, so kann man hier z.B. keine neuen alias anlegen oder forwards einrichten, die doch nicht unwichtig sind.
    Zudem fehlt die Funktion HostingMailboxGet ganz.


    Die Integration der wichtigsten Funktionen (Datenbank, Mail, Passwortschutz, ...) in ein bereits bestehendes Backend oder gar die Entwicklung eines neuen Backends ist mit dieser API absolut unmöglich.


    Mir persönlich gefällt LiveConfig. Es ist für Einsteiger sehr einfach zu verstehen und die Kunden benötigen nicht viel Hilfe. Wenn ich das aber nicht in meinen Projekten verwenden kann, weil ich z.B. keine Datenbank oder E-Mail bearbeiten kann, muss ich mich nach einer anderen Lösung umsehen.

    Hallo


    Kann keinem Kunden/Vertrag eine Domain zuordnen.
    Dachte erst, es liegt daran, dass er auch einen Reseller-Vertrag hatte. Habe dann alle Kunden und alle Resellerverträge gelöscht und den Kunden neu angelegt. Geht aber noch immer nicht.
    Dropdown für Verträge ist leer.



    LiveConfig-Version: 1.9.0 (r3657) (aktuell)
    Plattform: x86_64-unknown-linux-gnu
    Konfigurationsdatei: /etc/liveconfig/liveconfig.conf
    Datenbank: SQLite 3.8.10.1 (stmt_open=0, stmt_cached=220)
    Edition: Business-Edition
    Lizenz: Testlizenz

    Hallo


    Ich möchte mich dafür bedanken, dass die API erweitert wurde. Ich schätze das wirklich. Würde aber auch gerne wissen, wann die restlichen Funktionen für die API kommen. Ich vermisse noch Funktionen wie:
    - HostingDomainDelete
    - HostingDomainEdit
    - HostingDatabaseDelete
    - HostingDatabaseEdit
    - HostingSubdomainDelete
    - HostingSubdomainEdit
    - HostingMailboxDelete
    - HostingCronEdit
    - HostingCronDelete
    - HostingFtpDelete
    - HostingFtpEdit
    - UserDelete
    - UserHasPermittion/UserGetPermittion
    - HostingPasswordUserDelete
    - HostingPasswordPathDelete


    Bei vielen Funktionen kann man das Edit umgehen, in dem man erst löscht und dann mit neuen Werten wieder anlegt. Aber ohne Delete, wird sogar das unmöglich.


    Würde mich sehr freuen, wenn eine Umsetzung zeitnah möglich ist.

    Danke für die Antwort.
    Ich habe noch eine Frage zum Anlegen von Kunden.


    Wenn ich einen Kunden mit der Kundennummer 1 anlege, wird dieser erzeugt. Wenn ich den gleichen Request nochmals schicke, wird der Kunde nicht angelegt. Die Rückgabe ist dann die ID des Kunden.
    Lege ich aber einen ähnlichen/anderen Kunden mir der Kdnr. 1 an, wird dieser erzeugt. Hier wundert mich, dass die Kundennummer nicht unique ist.


    In keinem Fall kann ich einen Fehler erzeugen. Ist das alles so beabsichtigt?

    Leider finde ich keine Informationen, was an der API genau geändert wird. Aber ich möchte hier zur Sicherheit nochmal auf den Fehler mit dem Parameter "type" in Contact* hinweisen.
    Der Parameter ist in ContactGet Response nicht enthalten und wird bei ContactEdit/Add nicht beachtet.

    Hallo


    Ich hatte am Wochenende ein paar Minuten Zeit und habe eine Art SDK geschrieben die den Einstieg und die Verwendung der API vereinfachen soll.
    Die wichtigsten Fakten:
    Das System ist so geschrieben, dass auch unerfahrene Entwickler sehr einfach damit arbeiten können. Selbst Einstellungen für die SOAP-Verbindung können mit nur eine Zeile Code sehr einfach angepasst werden. Durch die flexible Programmierung kann man aus einer Instanz direkt auf einen anderen Server zugreifen, oder man erstellt mehrere Instanzen um Daten zwischen Servern zu kopieren/verschieben/abzugleichen...
    Der enthaltene Log beinhaltet alle Fehler, die beim Ausführen verursacht wurden. Zudem ist es möglich für unterschiedliche SOAP-Verbindungen auch unterschiedliche Log-Dateien zu erstellen.
    Zudem unterstützt das System unbegrenzt viele vordefinierte Konfigurationen. Dabei ist das System so flexibel, dass die Daten aus einer Datenbank / externem System kommen können oder als eigene Config-File angelegt werden können.


    Die Erweiterung mit einer eigenen Klasse, kann mit nur 3 Zeilen eingebunden werden. Genau so einfach ist auch ein Aufruf einer Funktion


    require_once('system/system.php');
    $system = new System;
    $result = $system->api->request('LiveConfigVersion');


    Weitere Beispiele, Informationen und das System ist kostenlos auf github zu finden.
    https://github.com/Steinweber/LiveConfig-SOAP-SDK