Ja, das ist recht einfach.
Legen Sie eine Datei namens /var/www/<Vertrag>/conf/nginx.conf an und tragen Sie da die gewünschten NGINX-Anweisungen ein.
Anschließend speichern Sie im LiveConfig irgendeine Vertrags- oder Domaineinstellung neu ab (dadurch schreibt LiveConfig die /etc/nginx/sites-enabled/<Vertrag>.conf-Datei neu und holt per include die o.g. nginx.conf mit hinein).
Viele Grüße
-Klaus Keppler
Ich vermute, dass es (aus welchem Grund auch immer) Verbindungprobleme zum CA-Server von Let's Encrypt gibt.
Wenn Sie "openssl" auf dem Server installiert haben, führen Sie bitte mal testweise folgenden Befehl aus:
openssl s_client -connect acme-v01.api.letsencrypt.org:443Kann damit eine TLS-Verbindung aufgebaut werden, oder gibt es eine Fehlermeldung?
Es geht hier ja letztendlich nur um das Session-Cleanup-Script /usr/lib/liveconfig/cron.php.sh
Wir gehen dabei davon aus, dass auf dem Server das Paket "php-cli" installiert ist, welches die Datei /usr/bin/php bereitstellt.
Ab Ubuntu 16 und Debian 9 ist "php-cli" ein virtuelles Paket, das auf "php7.0-cli" verweist.
Das cron.php.sh ist eigentlich darauf ausgelegt, mit dem jeweiligen "System"-PHP-CLI ausgeführt zu werden. Wenn das System-Paket (php7.0-cli) nicht installiert ist, dann erzeugt LiveConfig auch keinen "/conf/php7"-Pfad, was dann zu Fehlern mangels richtiger php.ini führt.
Wer also manuell die /usr/bin/php umbiegt, wird zwangsläufig auch das cron.php.sh-Script anpassen oder ersetzen müssen.
"Unsere" PHP-Pakete werden übrigens demnächst überarbeitet, so dass diese sich "alleine" bei LiveConfig registrieren (ohne addPHP()-Aufruf in der custom.lua). Da werden dann auch die CLI-Binaries registriert, und die können dann auch vom cron.php.sh-Script verwendet werden.
Habe ich da irgendwo einen Denkfehler?
Vielleicht. Ich glaube es ist wenig hilfreich, den Link zum Zurücksetzen des E-Mail-Passworts an die betroffene Mailadresse zu schicken...
Oder kurz gesagt: Passwörter von Mailadressen lassen sich nicht über die "Passwort vergessen"-Funktion zurücksetzen.
Präfixe werden derzeit nicht vererbt (es besteht die Gefahr dass diese zu lang werden - gerade bei Datenbanken wird das eng).
Einfach eine Session als Reseller öffnen, und dort das Präfix in dessen Wiederverkäufer-Einstellungen eintragen.
Viele Grüße
-Klaus Keppler
Hello,
our PHP packages for Debian and Ubuntu have just been updated to version 7.1.14 and 7.2.2.
Best regards
-Klaus Keppler
Hallo,
unsere PHP-Pakete für Debian und Ubuntu wurden eben auf die Versionen 7.1.14 und 7.2.2 aktualisiert.
Viele Grüße
-Klaus Keppler
Dazu müsste ich dann per URL den Benutzernamen und Passwort mit angeben können was aber eben leider noch nicht funktioniert..
Beim Dynamic-DNS Update-Aufruf an LiveConfig?
Da wird Benutzername und Passwort (wie bei DynDNS "üblich") per HTTP Basic Auth übermittelt.
Optional können wir gerne alternativ einen URL-Parameter dafür einrichten.
für mich ist eher der Dienst mit Dyndns noch nicht gescheit gelöst.
Was genau?
IPv4 und IPv6 Updates funktionieren über die dokumentierte Update-Methode (soweit wir das beurteilen können) einwandfrei. Vielen Kunden nutzen das, und auch wir selber - und zwar ohne Probleme.
DynDNS mit IPv6 ist insgesamt etwas "tricky", das liegt aber weniger am DynDNS als viel mehr an den Eigenschaften von IPv6 (dass sich also alle Geräteadressen im LAN ändern wenn sich der IPv6-Präfix z.B. nach DSL-Zwangstrennung ändert).
So lange eine IP-Gruppe "exklusiv" in Verwendung ist, kann diese nicht auf "gemeinsam" zurück geändert werden.
Unter "Serververwaltung" -> "Web" gibt es in der Box mit den IP-Gruppen eine Spalte "Domains". Dort sieht man, wie viele Domains diese IP-Gruppe derzeit noch nutzen.
In Einzelfällen kann man das über einen Eingriff in die LiveConfig-Datenbank erzwingen.
(Sie bekommen gleich noch eine separate Antwort auf Ihr Ticket bei uns)
PS: eine Mail an den Support mit der richtigen Mailadresse ist bereits raus.
Eine Antwort an Ihr Ticket ist auch bereits raus...
Ich tippe auf ein per copy&paste mit eingefügtes, unsichtbares Steuerzeichen.
Sorry, ich hatte den letzten Absatz von Ihnen nicht gelesen...
Ich kann mir nicht erklären, warum die liveconfig[.conf] plötzlich fehlen könnte - LiveConfig löscht diese schließlich nicht. Wurde Apache vielleicht mal "gepurged"?
Ansonsten legen Sie die conf-available/liveconfig.conf manuell an:
# _ _ ___ __ _ (R)
# | | (_)_ _____ / __|___ _ _ / _(_)__ _
# | |__| \ V / -_) (__/ _ \ ' \| _| / _` |
# |____|_|\_/\___|\___\___/_||_|_| |_\__, |
# |___/
# Copyright (c) 2009-2011 Keppler IT GmbH.
# ----------------------------------------------------------------------------
# Access logging
# We define a special log format here, which gets piped into the 'lclogsplit'
# utility (see lclogsplit(1) for more details).
# This way Apache httpd needs only one file handle for all access_log files,
# and we get nice real-time statistics on HTTP traffic.
# IMPORTANT: the module 'mod_logio' needs to be enabled!
LogFormat "%v:#:%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-agent}i\" %I %O" LiveConfig
CustomLog "||/usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats" LiveConfig
ErrorLog /var/log/apache2/error.log
# <EOF>-----------------------------------------------------------------------... und aktivieren diese dann mit "a2enconf liveconfig".
Suchen Sie in /etc/apache2/ mal nach der Datei "liveconfig.conf". Es kann sein, dass diese noch in conf.d/ steht.
Die Datei muss aber nach /etc/apache2/conf-available/, und mittels "a2enconf liveconfig" aktiviert werden.
In den Ubuntu-Paketen scheint die php.ini-Einstellung "sendmail_path" zu fehlen. Wir nehmen das ins nächste Update mit auf.
Bis dahin erstellen Sie einfach eine Datei namens /opt/php-7.1/etc/conf.d/sendmail.ini mit folgendem Inhalt:
sendmail_path=/usr/sbin/sendmail -t -iDanach noch ein "service apache2 reload" ausführen - fertig.
Viele Grüße
-Klaus Keppler
Unter anderem:
- es wird kein "admin/admin"-Standardlogin mehr bei blanken Neuinstallationen geben (Sicherheit)
- die automatische Installation (z.B. über Server-Templates) wird vereinfacht
- Domain-individuelle Einstellungen für NGINX sind möglich (allerding nur durch den root-User)
- viele GUI-Verbesserungen (u.a. mehrere Domains gleichzeitig hinzufügen)
Bitte jetzt aber keine Diskussion ob/wann/warum Feature XY kommt oder nicht kommt. Alles zu seiner Zeit.
Die Preview wurde eben noch mal aktualisiert und wird (wenn nichts dazwischen kommt) in den nächsten Tagen in dieser Form freigegeben.
Mit der nächsten Version (v2.6.0) gibt es einige größere Änderungen und neue Features (wird als Preview freigegeben sobald 2.5.3 "stable" ist).
Viele Grüße
-Klaus Keppler
Läuft OpenDKIM? (ps aux | grep -i dkim)
Sollte etwa so aussehen:
opendkim 21304 0.0 0.4 83736 3240 ? Ss 14:45 0:00 /usr/sbin/opendkim -P /var/spool/postfix/opendkim/opendkim.pid -p local:/var/spool/postfix/opendkim/opendkim.sock
opendkim 21305 0.0 0.8 190384 6404 ? Sl 14:45 0:00 /usr/sbin/opendkim -P /var/spool/postfix/opendkim/opendkim.pid -p local:/var/spool/postfix/opendkim/opendkim.sockWas liefert "grep smtpd_milters /etc/postfix/main.cf"?
Kann man ohne Glaskugel schwer sagen. 
Ist denn ein "DKIM-Signature:"-Header in versendeten E-Mails enthalten?
Wenn nein, was taucht alles in /var/log/mail.log auf, wenn eine E-Mail versendet wird?
Allerdings gibt es im Lizenzportal nun einen "Error 502 - "Bad Gateway".
Das war vermutlich eine kurze Nebenwirkung eines PHP-Neustarts (aktuell funktioniert alles). Im Log finde ich aktuell auch keine 502er - ansonsten geben Sie bitte Bescheid bei welcher URL genau es hakt.
Viele Grüße
-Klaus Keppler
Hallo,
offenbar gab es da ein Problem auf unserer Seite - wir haben das Repo neu synchronisiert, nun müsste wieder alles da sein.
Viele Grüße
-Klaus Keppler
PS: es gab letzte Woche schon mal ein Problem mit den RPM-Repositories, daher werden wir die Repo-Bereitstellung noch mal gründlich prüfen...
