Wirklich?
Jetzt wo endlich die ersten Lebkuchen in den Einkaufsregalen stehen, können wir ja mal mit den Weihnachtsgeschenken anfangen.
Wirklich?
Jetzt wo endlich die ersten Lebkuchen in den Einkaufsregalen stehen, können wir ja mal mit den Weihnachtsgeschenken anfangen.
Ab sofort steht die Version 1.9.1-r3736 als Preview bereit, gegen 16 Uhr wird diese dann produktiv freigegeben.
Die wichtigsten Änderungen sind:
Viele Grüße
-Klaus Keppler
Der Parameter "type" hatte im WSDL gefehlt (wurde also per SOAP zurückgegeben, per WSDL generierte Interfaceklassen hatten den Parameter dann aber nicht ausgewertet).
Ist in v1.9.1-r3725 behoben (Release erfolgt im Laufe dieser Woche).
Das sind die Betriebssysteme die ich bei meinem Hoster zur verfügung habe:
debian-7.6-x86_64
debian-7.6-amd64-minimal
debian-8.0-x86_64
Die sind leider etwas veraltet - nach der Installation müssen eine ganze Menge Pakete aktualisiert werden.
Zitatroot@server01:~# service dovecot start
[....] Starting IMAP/POP3 mail server: dovecotError: socket() failed: Address family not supported by protocol
Nicht nur dass die Images veraltet sind - IPv6 scheint in dem Kernel komplett deaktiviert zu sein (was wenig bis gar keinen Sinn macht).
Erstellen Sie bitte eine Datei mit den Namen /etc/dovecot/dovecot.local.conf und tragen dort folgende Zeile ein:
Danach gehen Sie im LiveConfig auf "Serververwaltung" -> "Mail", öffnen die Dovecot-Einstellungen und speichern diese neu ab. Damit wird die dovecot.locel.conf per Include in die Konfiguration aufgenommen.
Naja, das Apache-Modul "cgi" ist nicht aktiviert.
Lösung also: "a2enmod cgi; service apache2 restart".
Was liefert denn "liveconfig --diag"? (Apache-Abschnitt genügt)
Das stimmt so (siehe http://www.liveconfig.com/de/versionen)
DNSSEC ist in einigen Fällen recht supportlastig, und das rechnet sich bei 2,80 EUR pro Monat (brutto) leider nicht.
Wer aber DNSSEC im größeren Stil einführen möchte, betreibt LiveConfig i.d.R. ohnehin in einem Multiserver-Setup (für das automatische Anlegen der Zonen auf den Slaves), daher sollte das keine allzu dramatische Einschränkung sein.
Session-Daten usw sollten in /var/www/<Vertrag>/tmp/ landen - dieses Verzeichnis sollte <Vertrag>:www-data gehören und mode=0770 haben.
Was zeigt denn eine phpinfo() bei "session.save_path" an?
- PHP 5.6.9 (code='php5', bin='/usr/bin/php')
default php.ini: '/etc/php5/cli/php.ini'
Da haben wir's ja schon - Ihnen fehlt das Paket "php5-cgi".
Wenn Sie "liveconfig-meta" installiert haben, hätte das eigentlich mit installiert werden sollen... :confused:
Lösung also: "aptitude install php5-cgi", anschließend LiveConfig neu starten und dann den Vertrag noch mal neu speichern (z.B. indem Sie irgendeine Einstellung bearbeiten)
Was gibt denn der Befehl "liveconfig --diag" aus? (der Abschnitt rund um Apache/PHP reicht)
Meiner Meinung ist es weitaus sinnvoller solche Sachen zu integrieren wie openDKIM oder DNSSEC das zu 90% niemand verwendet...
http://www.heise.de/netze/meld…ren-DANE-ein-2782473.html
Dafür braucht man DNSSEC.
Aber keine Angst, wir arbeiten natürlich auch an anderen Sachen.
E: Internal Error, No file name for libapache2-mod-fcgid:amd64
Oh je... da stimmt wohl einiges nicht. Mit LiveConfig hat das aber nichts zu tun - der Paketmanager selbst macht da schon Probleme (liveconfig-meta hat lediglich eine Installationsabhängigkeit zu libapache2-mod-fcgid).
Mal ein paar Hinweise/Denkanstöße:
- welche Debian-Version genau setzen Sie ein?
- gibt's Fehler bei "aptitude update && aptitude upgrade"?
- was steht in /etc/apt/sources.list und in /etc/apt/sources.list.d/*
Auf den ersten Blick sieht das für mich so aus, als ob da per Copy&Paste irgendwelche Repos oder APT-Einstellungen eingerichtet wurden...
Wenn "service apache2 reload" einen Fehler bringt, dürfte es ungemein weiterhelfen, einen Blick in die Log-Dateien zu werfen.
Mit v1.9.1-r3707 werden eigene DH-Parameter ab Apache 2.2.22-13+deb7u5 (Debian Wheezy) unterstützt. Alle weiteren Details zu diesem Update sind in diesem Beitrag.
Die Preview wurde eben auf Version 1.9.1-r3707 aktualisiert - die Arbeiten für's Release nähern sich dem Ende.
Die wichtigsten Änderungen sind:
Wir haben zudem den SSL-Check so erweitert, dass dieser nun explizit die DH-Parameter prüft. Aktuell wird es pauschal als "Problem" gemeldet, wenn irgendein Dienst mit 1024-Bit DH-Parametern arbeitet. Das werden wir aber noch ändern: gerade bei SMTP/IMAP/POP3 gibt es viele Inkompatibilitäten, wenn man "blind" auf 2048-Bit-Parameter umstellt. Wir forschen hier noch etwas weiter - über Neuigkeiten werden wir dann noch mal separat informieren. Die 1024-Bit-Warnung wird also voraussichtlich in Kürze für die E-Mail-Dienste ausgesetzt.
Viele Grüße & ein schönes Wochenende!
-Klaus Keppler
when you already working on translation, you could translate and this:
These phrases are generated from JavaScript. We have built a translation file for this (js.po) and have integrated it into our Pootle system.
Thanks to all translators for their support!
Als "root" im Verzeichnis /var/www/<Vertrag>/ eine Datei namens ".httpd.conf" anlegen, und dort die gewünschten Apache-Anweisungen eintragen (konkret z.B. "ErrorLog /var/www/<Vertrag>/logs/error.log").
Danach den vHost des Kunden neu erzeugen lassen (z.B. irgendeine Einstellung einer Domain oder den Vertrag neu speichern) - damit wird die .httpd.conf per Include aufgenommen.
Wichtig ist, dass diese Datei root:root gehört und vom Kunden nicht beschrieben werden darf ("chmod 644 .httpd.conf").
Der Grund für die automatische Abschaltung der error.logs ist, dass Apache nur eine begrenzte Zahl an Filehandles zur Verfügung hat; bei Massen-Hosting mit z.B. 1000 Webspaces wären somit 1000 Filehandles in Verwendung - was blöd ist wenn man (ohne manuelle Eingriffe) erst mal nur 1024 Handles nutzen kann.
Denkbar wäre aber, dass wir eine Möglichkeit schaffen um als Admin das error.log eines Kunden dauerhaft zu aktivieren.
Ach noch was: die Anleitung bei DigitalOcean enthält mindestens einen häufig gemachten Fehler. Ich verrate den hier aber nicht, denn an dem Fehler kann man schön erkennen wer sich selbst mit OCSP beschäftigt hat und wer nur aus anderen Anleitungen abschreibt. :p
Bitte immer schön sachlich bleiben.
Der Apache bei Debian 8 unterstützt OCSP-Stapling (sonst hätte er diese Fehlermeldung ja gar nicht bringen können).
Das eigentliche Problem besteht vielmehr darin, dass selbsignierte Zertifikate üblicherweise keine OCSP-URL enthalten, LiveConfig aber trotzdem auch hier OCSP aktiviert. Ein Kollege arbeitet da schon dran, ich denke dass das in den nächsten 1-2 Werktagen erledigt ist*.
Apache funktioniert soweit zwar trotzdem, aber ordentlich ist das nicht.
*) die Funktion in LiveConfig, welche die Zertifkate an Apache schickt, muss analysieren, ob das Zertifikat selbst oder ein Aussteller-Zertifikat eine OCSP-URL enthält; nur wenn das der Fall ist soll dann OCSP aktiviert werden.