doch ich meine Sie bei den Angeboten/Verträge gesehen zu haben. Beim SMTP Server muss man es allerdings vorher aktivieren.
Da ist nichts zu finden, nur die Checkbox in der Serververwaltung.
kk: ist das überhaupt schon (fertig) implementiert?
doch ich meine Sie bei den Angeboten/Verträge gesehen zu haben. Beim SMTP Server muss man es allerdings vorher aktivieren.
Da ist nichts zu finden, nur die Checkbox in der Serververwaltung.
kk: ist das überhaupt schon (fertig) implementiert?
nur die Protokolle aktiviert, und in confs übernommen.
a2enmod http2
# cat /etc/apache2/conf-enabled/http2.conf
Protocols h2 http/1.1
H2Push on
H2PushPriority * after
H2PushPriority text/css before
H2PushPriority image/jpeg after 32
H2PushPriority image/png after 32
H2PushPriority application/javascript interleaved
Alles anzeigen
Ergibt dann weiterhin HTTP/1.1, da eben blacklisted Cipher mit drinnen sind.
Was sagt der Qualys SSL-Test bei euch genau?
Bei uns:
Android 7.0 Server negotiated HTTP/2 with blacklisted suite
RSA 4096 (SHA256) | TLS 1.2 > h2 | TLS_RSA_WITH_AES_256_GCM_SHA384
Chrome 51 / Win 7 R Server negotiated HTTP/2 with blacklisted suite
RSA 4096 (SHA256) | TLS 1.2 > h2 | TLS_RSA_WITH_AES_256_GCM_SHA384
Firefox 47 / Win 7 R Server negotiated HTTP/2 with blacklisted suite
RSA 4096 (SHA256) | TLS 1.2 > h2 | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | ECDH secp256r1
Firefox 49 / XP SP3 RSA 4096 (SHA256) TLS 1.2 > h2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
Firefox 49 / Win 7 R RSA 4096 (SHA256) TLS 1.2 > h2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
Das sieht für mich nicht nach "geht" aus.
Was habt ihr da genau geändert?
- über Protocols aktiviert, klar
- dann müssen aber die Cipher angepasst werden: PCI-kompatible Cipher sind teilweise für HTTP/2 blacklisted.
- mit den empfohlenen Ciphern werden aber einige ältere Clients auch von HTTPS abgehalten.
Oder hab ich da was falsch getestet?
"php-cgi" nicht installiert, sondern noch php5-cgi?
WUHU! Danke! ![]()
gibt es hierzu etwas neues? - der Debian 9 Release naht bereits
![]()
Im Repo finde ich nach wie vor nur Jessie und Squeeze.
LiveConfig wird über Codename "main" installiert. Funktioniert mit Stretch wunderbar.
(ja, die PHP-Pakete fehlen. IMHO ist das allerdings seitens Keppler IT ein "zusätzlicher Service", kein Teil des Produktes LiveConfig.)
Oder einen Daemon-Prozess gesondert anlegen und mit mod_rewrite die Anfragen auf die wsgi.py umleiten.
Ja, bei denen klappt es auch, aber halt nicht bei "spezial"-Hostings, die nur über HTTPS genutzt werden sollen.
HTTP-Redirect rein und fertig.
ZitatIst TLS-SNI-02 schon verfügbar, oder kommt das noch? Genauso die DNS-Validierung, die wäre mir eigentlich am liebsten.
Ist in LiveConfig aktuell nicht drinnen.
Ich habe alle Webhostings so eingerichtet, dass HTTP auf HTTPS umgeleitet wird.
Da klappt die HTTP-Validierung problemlos. Haben wir nirgends anders.
Achtung: HTTP-Zugriff muss aktiv sein, und wenn es nur ein 301-Redirect ist.
Oder ist es immer noch sinnvoller, das Ganze manuell zu erledigen?
Aktuell: ja.
das geht vermutlich nicht, ich fand gerade folgendes dazu:
"HTTP-01 is defined by the ACME standard to require HTTP on port 80"
anscheinend sieht der Standard dies nur so vor, dass Port 80 genutzt werden muss
Genau, für HTTPS gibt es ja auch TLS-SNI-02.
"apache2ctl -S", außerdem alle Error-Logs prüfen.
Apache ist normal sehr gesprächig.
Kann ich bestätigen. Entweder fehlt die Installer-Datei, oder es wurde die falsche Version ins Repository aufgenommen.
Da wir bisher nur einen Server mit MySQL-Backend nutzen, wäre das für uns also schon fertig.
Manueller Eintrag in der my.cnf: sql_mode=NO_ENGINE_SUBSTITUTION.
Oder die /usr/my.cnf (zumindest bei den Oracle-Paketen von MySQL) löschen.
ZitatFehlend? Spricht was gegen die Parallelinstallation weiterer Versionen, wie bisher auch?
Nö. Hatte nur bisher keine Zeit, die Pakete zu bauen / zu suchen ![]()
Kann ich bestätigen: grundsätzlich funktioniert LiveConfig mit Stretch (LCClient).
Das fehlende PHP5 wird hingegen erstmal noch für andere Späße sorgen.
Die Milter sind sauber eingebunden, im Log fehlt aber noch der Eintrag zu LCSam - mein Fehler.
Bitte suche die entsprechende Zeile noch raus.
Zusätzlich: "systemctl stop lcsam.service", danach manuell mit "/usr/lib/liveconfig/lcsam -g spamd -U postfix -d" starten sowie Output davon prüfen/posten.
Außerdem sicher stellen, dass deine "me@hchristo.de" auch wirklich in /etc/postfix/spamassassin steht.
Bitte die main.cf von Postfix posten, sowie einen Auszug aus dem Mail-Log, das die entsprechende Mail beinhaltet ("grep $QUEUEID /var/log/mail.log").
LCSam arbeitet genau so, wie man es erwartet: Spamd wird angesprochen und die Antwort zurückgegeben.
Deine beiden sa-learn-Befehle sind außerdem fehlerhaft: Amavis kommt nicht zum Einsatz, der --dbpath ist falsch.
Der Content-Filter ist für LC-Spam unnötig.
Bitte Logs prüfen, ob die Mails überhaupt an LCSam übergeben wurden. Ein allgemeines Problem in der Software gibt es nicht.
Hi,
* Our idea is to have 10.000 max. customers per LC-Server (with its many attached LC-Clients) with SQLite.
Don't use SQLite.
Use a dedicated machine with mySQL and LiveConfig for the central LC business server (8GB RAM should be enough).
Zitat1) Is Debian preferred over other distros? I see Debian as a favorite by the LC developers in the forum. We have chosen CentOS for our deployment due to CloudLinux but we could consider dropping it if Debian is a *much* more safe and good choice for LC.
I won't see why there should be a difference: in the end, LiveConfig is just writing config files for the web/db servers.
Use trial licenses to verify your setup - and report bugs to support@liveconfig.com ![]()
Zitat3) Is it possible and recommended to create our own AppInstaller installers?
it is possible, yes:
> https://github.com/LiveConfig/apps-example
Zitat4) In the manual you say "We always recommend to install LiveConfig on an empty (fresh installed) system." However we usually modify the fresh installation a bit by: changing the SSH default port to another privileged port, securing SSH (allowing access only via keys, etc), creating an administrative user with sudo privileges, and setting up the firewall. Does any of those modifications interfere with the installation of LiveConfig?
LiveConfig does not interfere with the SSH server.
Zitat5) Do these restrictions to Lets Encrypt still apply?
Those are applied by Let's Encrypt directly, so please check there:
https://letsencrypt.org/docs/rate-limits/
Zitat6) What is the recommended way of installing a correct (not self-signed) SSL certificate for the LiveConfig control panel itself? Should I create it manually via Let's Encrypt certbot CLI and then save it as /etc/liveconfig/sslcert.pem and it is going to work? Would not that interfere with the certificate generation for the customers?
Configure a regular domain in your account (e.g., config.example.com), get a certificate and configure the domain as a proxy to "https://localhost:8443".
This way, customers don't need to access port 8443 at all.
(yes, this is just a workaround)
Zitat7) CentOS (installed in OVH) by default sets the /etc/hostname file as server.example.com instead of only the shortname server. This differs from the recommendation in the LC manual. Should I follow the LC manual and set the hostname to the shortname? (maybe it is different for Debian)
not relevant.
We configure the full hostname there as well and everything's fine.
Zitat
About SELinux. In the forum I have read (and everybody in the world agrees) that SELinux is complex, and I had decided to disable it. However, in the post-install message console prompt, LC informed me that "if you have SELinux enabled (or plan to do so), you need to adjust some permissions" meaning that is it indeed sensible and easy to enable it currently in LC?
I personally have no experience with selinux and don't work with this.
Zitat9) Otherwise, do you recommend another Mandatory Access Control like Tomoyo or AppArmor (if it is Debian)?
why?
LiveCOnfig already configures file owners and permissions appropriately.
Zitat10) Does LC manages clamav-milter in CentOS? Should I install it? (We are going to use the email server only for notifying the customers)
if you don't intend to provide mail hosting, LiveConfig does not configure the mailserver at all. ClamAV-milter is thus neither required nor configured.
In case of questions, please contact also support@liveconfig.com directly.
Best,
Anton