Beiträge von kk

    Hallo,


    wir haben das Problem nun lokalisiert.
    Damit der Ajax-Request auf eine "fremde" Domain funktioniert, erzeugt LiveConfig einen "Access-Control-Allow-Origin:"-Header (CORS). Dabei tritt in den Fällen ein Fehler auf, in denen die hinterlegte phpMyAdmin-URL keinen Schrägstrich nach dem Hostnamen enthält.


    Klappt: https://phpmyadmin.example.org/
    Klappt nicht: https://phpmyadmin.example.org


    Der Fehler ist behoben, Update wird in Kürze bereitgestellt. Als Workaround bis dahin einfach einen Schrägstrich an die URL anfügen (Serververwaltung -> Datenbanken -> dort die hinterlegte phpMyAdmin-URL bearbeiten).


    Vielen Dank auch für die Unterstützung bei der Fehlersuche!


    Viele Grüße


    -Klaus Keppler

    Magento bringt Status: Fehler: Error while installing package
    Aber die URL kann ich aufrufen und sehe dann Welcome to Magento's Installation Wizard!
    Wenn ich das dann abarbeite bekomme ich There has been an error processing your request
    Exception printing is disabled by default for security reasons.


    Error log record number: 1500288450646


    Kann ich nicht nachvollziehen. Installation klappt fehlerfrei, Anmeldung danach im Backend ebenfalls fehlerfrei.
    Welche Distribution genau verwenden Sie, welche PHP-Versionen sind installiert, und enthält der Vertrag in dem Sie das testen genügend Webspace?


    Zitat

    Bei Drupal bekomme ich Fehler.
    Error
    The website encountered an unexpected error. Please try again later.
    Error messagePDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'd1.semaphore' doesn't exist: SELECT expire, value FROM {semaphore} WHERE name = :name; Array ( [:name] => variable_init ) in lock_may_be_available() (line 167 of /var/www/web0/apps/drupal/includes/lock.inc).
    Uncaught exception thrown in shutdown function.
    PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'd1.semaphore' doesn't exist: DELETE FROM {semaphore} WHERE (value = :db_condition_placeholder_0) ; Array ( [:db_condition_placeholder_0] => 131690414359f6c7346c38d6.05802030 ) in lock_release_all() (line 269 of /var/www/web0/apps/drupal/includes/lock.inc).


    Diese Meldung erhalten Sie dann, wenn Sie Drupal aufrufen ohne die Installation abgeschlossen zu haben.
    Klicken Sie nach der Installation im AppInstaller auf den Link hinter "Installation:" und folgen den Anweisungen.
    Auch diese Installation klappte eben fehlerfrei und problemlos.


    Zitat

    Bei modified Shop bekomme ich auf einem Server Status: Fehler: failure while executing tar
    Erst Haken und dann wieder Kreuze. Also genauso wie es gestern nach dem Update war.


    Kann ich auch nicht nachvollziehen, klappt auch fehlerfrei.
    Es gelten die selben Fragen wie oben (Version, PHP, Webspace-Quota, ...)


    Zitat

    Bei Contao dasselbe wie gestern.
    Wenn ich die URL aufrufe kommt Unvollständige Installation
    Der Rest wurde noch nicht getestet.


    Klappt ebenfalls. Ich tippe auf ein lokales Problem.

    Das Update war wohl noch nicht ganz vollständig - wird das Datenbankpasswort von LiveConfig "zu früh" gelöscht, dann steht es dem AppInstaller nicht mehr zur Verfügung.
    Mit r4741 klappt die Installation wieder komplett. Wir werden den AppInstaller künftig vor Releases ausführlicher testen - für die entstandenen Unannehmlichkeiten möchte ich mich entschuldigen.
    Bei Fragen: morgen (Montag) ist unser Büro bis ca. 16:00 besetzt (trotz "Brückentag").

    Danke für die Info!
    Der Fehler entstand leider durch die Arbeiten am phpMyAdmin Single-SignOn. LiveConfig löscht ja nach dem erfolgreichen Anlegen einer Datenbank das nicht mehr benötigte Passwort - hier hatte sich eine Änderung ergeben, in unseren Tests hatten wir unter anderen Bedingungen geprüft und das daher nicht bemerkt.
    Fehler ist behoben, das Update (v2.5.0-r4740) steht ab sofort in den Repositories bereit.


    Viele Grüße


    -Klaus Keppler

    phpMyAdmin Single Sign On ist klasse. Aber lässt sich der neu angelegte Server aus der PMA-Loginseite entfernen? Ich habe dazu keine Konfigurationsmöglichkeit gefunden.


    Kommt auf die phpMyAdmin-Version drauf an. Ab Version 4.7 funktioniert das, wenn Sie in der config.inc.php den "host" auf einen leeren String setzen:

    Code
    $cfg['Servers'][$i]['host'] = '';


    Dann taucht der Server nicht mehr in der Liste auf. Was wir allerdings auch nicht lösen konnten ist die Frage, wie man die Dropdown-Liste der Server (falls es mehrere gibt) aus der PMA-Übersichtsseite ausblenden kann.
    Wir empfehlen übrigens folgende (allgemeine) Einstellungen zu setzen:

    Code
    $cfg['NavigationDisplayServers'] = false;
    $cfg['ShowPhpInfo'] = false;
    $cfg['ShowServerInfo'] = false;
    $cfg['ShowChgPassword'] = false;
    $cfg['ShowCreateDb'] = false;

    Die Checkbox für Single Sign-On kann nun auch bei bestehenden Datenbanken korrekt gesetzt werden (v2.5.0-r4739).


    Das mit dem Ajax-Fehler versuchen wir mal zu reproduzieren.

    Danke für den Hinweis! Das war noch ein kleiner GUI-Fehler (da wurde nicht geprüft, ob beim Setzen vom Häkchen evtl ein Passwort mitgeschickt wird). Klappt also nur wenn man erst ein (neues) Passwort setzt, speichert, und gleich danach das Häkchen setzt.
    Ein Update (v2.5.0-r4737) steht in wenigen Minuten bereit.

    Ja, der ist auch behoben - wurde nur versehentlich nicht ins Changelog auf die Website übernommen. Ich kümmere mich gleich darum.

    Zitat

    Cron-Jobs wurden nicht wieder aktiviert nachdem ein gesperrter Vertrag wieder aktiviert wurde

    Haben Sie die neueste Version von "lc-sso.php" installiert? (6067b89 vom 18.10.)
    Die o.g. Fehlermeldung tritt auf, wenn ein Ajax-Request vom Browser an LiveConfig nicht ausgeführt werden kann - in der aktuellsten Version sollte die Fehlermeldung eigentlich etwas aussagekräftiger sein.
    Zudem: welchen Browser nutzen Sie? Läuft der Browser im "privaten Modus"?


    Ansonsten schicken Sie uns bitte mal Test-Zugangsdaten (LiveConfig) an support@liveconfig.com, dann schauen wir uns das mal an.


    Unter https://demo.liveconfig.com (admin/admin) haben wir eine Demo eingerichtet.


    Viele Grüße


    -Klaus Keppler

    Hello,


    LiveConfig version 2.5.0 is now available!
    The most important new features are:

    • supporting HTTP/2 with Apache and NGINX
    • ECDSA are supported - also with Let's Encrypt
    • Single Sign-On to phpMyAdmin (siehe GitHub)
    • supporting CAA records in DNS


    ... as well as many minor improvements. For a full list of all changes see the changelog.


    Currently we're mainly working on "lcpolicyd" (configuration via GUI) and on backup/restore of subscriptions. As soon as there are any news, we'll publish them in the forum.


    Best regards


    -Klaus Keppler

    Hallo,


    ab sofort steht LiveConfig in der Version 2.5.0 bereit.
    Die wichtigsten neuen Funktionen sind:

    • Unterstützung von HTTP/2 mit Apache und NGINX
    • ECDSA-Zertifikate werden unterstützt - auch mit Let's Encrypt
    • Single Sign-On an phpMyAdmin (siehe GitHub)
    • Unterstützung von CAA-Records im DNS


    ... sowie viele weitere Verbesserungen. Die vollständige Liste aller Änderungen steht wie immer im Changelog.


    Derzeit arbeiten wir hauptsächlich am Thema "lcpolicyd" (Konfiguration über die GUI) sowie am Backup/Restore von Verträgen. Sobald es hier Neuigkeiten gibt, werden wir das im Forum melden.


    Viele Grüße


    -Klaus Keppler

    Die Beschreibung ist leider recht vage - schicken Sie uns bitte ggf. mal einen Screenshot an support@liveconfig.com


    Let's-Encrypt-Zertifikate können ja nur dann angelegt werden, wenn man die Berechtigung für die SSL-Verwaltung hat. Ich tippe daher darauf, dass Sie die LE-Zertifikate als "admin" angelegt und dem Kunden zugewiesen haben?
    In dem Fall braucht der Kunde gar keine Berechtigung für die SSL-Verwaltung - er kann unter "Hosting" -> "Domains" direkt beim Webspace HTTPS aktivieren und die ihm zugeordneten Zertifikate auswählen.


    (Voraussetzungen: SSL (HTTPS) muss im Vertrag aktiviert sein und in der IP-Gruppe (Serververwaltung -> Web) muss HTTPS/SSL aktiviert sein)


    PS: die gesamte SSL-Verwaltung wird Anfang 2018 (mit ACME v2) deutlich vereinfacht werden.

    Bekomm dann immer folgendes: PHP Fatal error: Cannot use object of type stdClass as array in /root/testo.php on line 53


    [...]


    Code
    object(stdClass)#2 (1) {
      ['customers'] => object(stdClass)#3 (1) {
        ['CustomerDetails'] => object(stdClass)#4 (7) {
                ['id'] => string(12) "cAsaMQdGmVAy"
    [...]


    Das "Problem" ist, dass PHP das Objekt "customers" in diesem Fall nicht als Array, sondern als einfaches Objekt interpretiert. Daher schlägt der Zugriff via "customers[0]" dann fehl.
    Eine mögliche Lösung wäre, einen expliziten Typecast zu machen:

    Code
    $response->customers = array($response->customers);


    Wenn die Suche (via CustomerGet) so ausgeführt wird dass es nur einen Ergebnisdatensatz geben kann, dann kann man theoretisch auch direkt auf das customers-Objekt zugreifen (also ohne "[0]") - finde ich persönlich aber nicht sehr sauber.

    Frage aus Neugier: Was genau wurde denn geändert, dass nun 50x weniger I/O entsteht?


    Bislang war es so, dass lclogsplit nur eine kleine, fest definierte Anzahl an (Ziel-)Log-Dateien gleichzeitig geöffnet gehalten hat. Dieser Dateideskriptor-Puffer wurde nach dem FIFO-Prinzip genutzt.
    Nun liest lclogsplit aus dem Betriebssystem die maximal erlaubte Anzahl gleichzeitig geöffneter Dateien aus (quasi "ulimit -n"), deckelt diesen Wert auf maximal 256, und erlaubt entsprechend viele offene Ziel-Dateien. Der Overhead durch das öffnen/flushen/schließen wird somit drastisch reduziert.
    Aufgefallen war der Flaschenhals bei Tests, als die Verarbeitung einer 10 GB großen Logdatei etwa eine Minute gedauert hatte. Nach der Änderung waren das nur noch wenige Sekunden. :)

    Merkwürdig, hier klappt alles einwandfrei. Welche Distribution und welches Datenbank-Backend (SQLite/MySQL) nutzen Sie?


    Hat sich erledigt - ist vermutlich mit MySQL als DB-Backend, da gibt es noch einen (bekannten) Fehler.
    (der CAA-Record hat den Typ 257, im entsprechenden Feld können aber nur "unsigned char"-Werte gespeichert werden). Wird kurzfristig noch geändert.