Beiträge von kk

Zitat von lebenszeit

Nach Aktivierung von http/2 in Nginx explodiert die Last auf dem Server. Requests werden gefühlt endlos erneut abgesetzt:

Wir haben inzwischen u.a. www.liveconfig.com auf HTTP/2 (NGINX/Debian9) umgestellt, die Last ist gleichbleibend niedrig.

Zitat von lebenszeit

Nach Aktivierung von http/2 in Nginx explodiert die Last auf dem Server. Requests werden gefühlt endlos erneut abgesetzt:

Haben Sie HTTP/2 auf einer exklusiven IP-Gruppe mit NGINX aktiviert und gleichzeitig keine "gemeinsame" IP-Gruppe mit SSL im NGINX aktiv?
Wenn ja, dann ist das Problem bereits gelöst (LiveConfig v2.5.1-r4752), die Pakete stehen in Kürze bereit.

Falls das Problem in einer anderen Konstellation aufgetreten ist, schicken Sie uns bitte mal die /etc/nginx/sites-available/default an support@liveconfig.com

Viele Grüße

-Klaus Keppler

Das haben wir kürzlich schon behoben, im nächsten Update (v2.5.1) klappt FIDO-U2F auch mit Firefox Nighty.
(Es gibt eine aktualisierte Version der U2F-API, die zwar aufwärtskompatibel, nicht aber abwärtskompatibel ist - wir haben LiveConfig auf die neue API umgestellt, damit klappt es dann überall)

Zitat von Marco

Und betrachte ich mir das neue Zertifikat, dann schwant mir Übles. Ablauf kurz nach Ende der Sommerferien in Bayern? Wenn das nicht mal in der Erholung untergeht

Ich kann zur Beruhigung versichern, dass keiner der Mitarbeiter schulpflichtig ist und sich zu diesem Zeitpunkt in Schulferien befinden wird. Vom Azubi vielleicht abgesehen, aber der hat ohnehin keine Berechtigung um die Zertifikate zu verwalten.
Spaß beiseite: das sogenannte "Personenrisiko" ist intern genau dokumentiert - Schlüsselrollen sind entsprechend verteilt.
Wie schon angekündigt werden wir beim nächsten Key-Rollover den neuen Schlüssel früher ausrollen. Konkret ist geplant, den Schlüssel mit einer Gültigkeit von 3,5 Jahren zu erstellen und 6 Monate vor dem Ablaufdatum auszurollen. Einen sauberen Weg dafür haben wir ja inzwischen gefunden.

Die restliche Diskussion beenden wir bitte an dieser Stelle.

Zitat von Marco

Nicht hilfreich, wenn man 2.5.0 nicht installiert bekommt, da der für die Installation benötigte Key erst nach der Installation vorhanden ist

Hilfreich aber für alle, die v2.5.0 (seit dem 26.10. verfügbar) bereits installiert haben.
Vor allem: nachdem dieser Weg soweit technisch funktioniert hat, werden wir das künftig wieder so machen - dann aber mit mehr Vorlauf.

The GPG keys for signing the LiveConfig packages and repositories are replaced every three years for security reasons.
From today, a new GPG key is used:

Key name: LiveConfig Package Signer <pkgadmin@liveconfig.com>
Key ID old: 08708961 (2048 bit, valid until 2017/11/05)
Key ID new: 3A2B2840 (4096 bit, valid until 2020/09/19)

The new key was already installed automatically with LiveConfig v2.5.0. For older installations, the key must be updated manually:

Debian/Ubuntu:

wget -O - https://www.liveconfig.com/liveconfig.key | apt-key add -

CentOS/OpenSUSE:

rpm --import https://www.liveconfig.com/liveconfig.key

When not updating the key, you'll get an error message when trying to update LiveConfig packages - on Debian for example like this:

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.liveconfig.com main InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E73A23BF3A2B2840


W: Failed to fetch http://repo.liveconfig.com/debian/dists/main/InRelease:
W: Some index files failed to download. They have been ignored, or old ones used instead.

Ab heute gilt ein neuer GPG-Schlüssel für die LiveConfig-Pakete und -Repositores.
Wer Liveconfig <2.5.0 installiert hat, muss hierfür den Signaturschlüssel aktualisieren.

Die GPG-Schlüssel zur Signatur der LiveConfig-Pakete und -Repositories werden aus Sicherheitsgründen alle drei Jahre ausgetauscht.
Ab heute gilt wieder ein neuer GPG-Schlüssel für LiveConfig:

Key-Name: LiveConfig Package Signer <pkgadmin@liveconfig.com>
Key-ID alt: 08708961 (2048 Bit, gültig bis 05.11.2017)
Key-ID neu: 3A2B2840 (4096 Bit, gültig bis 19.09.2020)

Mit LiveConfig v2.5.0 wurde der neue Key bereits automatisch mit installiert. Bei älteren Installationen muss der Key manuell aktualisiert werden:

Debian/Ubuntu:

wget -O - https://www.liveconfig.com/liveconfig.key | apt-key add -

CentOS/OpenSUSE:

rpm --import https://www.liveconfig.com/liveconfig.key

Ohne eine Aktualisierung des Signaturschlüssels kommt es ansonsten zu einer Fehlermeldung, unter Debian z.B.:

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.liveconfig.com main InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E73A23BF3A2B2840


W: Failed to fetch http://repo.liveconfig.com/debian/dists/main/InRelease:
W: Some index files failed to download. They have been ignored, or old ones used instead.

Der Key wurde auf dem Webserver eben ausgetauscht und die Repositories neu signiert. Zudem wurde der neue Key bereits mit LiveConfig v2.5.0 verteilt - nur ältere Installationen müssen den Key manuell aktualisieren.

wget -O - https://www.liveconfig.com/liveconfig.key | apt-key add -

Viele Grüße

-Klaus Keppler

Das ist merkwürdig. Prüfen Sie bitte, ob in /var/log/liveconfig/liveconfig.log was protokolliert wird während Sie den phpMyAdmin-Link anklicken, und schicken Sie uns (falls vorhanden) die Ausgabe mal an support@liveconfig.com.
Nur zur Sicherheit: der phpMyAdmin-Link selbst (also unter "Hosting" -> "Datenbanken") enthält wirklich irgendwo einen Slash?
(der Fehler trat eigentlich nur auf, weil ein Slash gesucht wurde um einen CORS-Header zu bauen)

Zitat von Aybee

Uns schmeißt er nur auf die phpMyAdmin Anmelde-Maske

Für die Unterlagen: in der lc-sso.php war der "PMA_SIGNON_INDEX" falsch gesetzt (stand auf "0" statt auf dem Index des Signon-Servers).

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

Zitat von dicker

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] =&gt; 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

Bei wem der Fehler auftritt: bitte mal auf https://demo.liveconfig.com gehen. Dort als admin/admin anmelden, dann auf "Hosting" -> "Datenbanken" und dort auf den phpMyAdmin-Link klicken.
Klappt die Anmeldung an phpMyAdmin, oder tritt da auch ein Fehler auf?

Bitte (formlos) an support@liveconfig.com

Zitat von Ringelnatz

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:

$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:

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