Ich habe das eben getestet und den Fehler gefunden.
Unter CentOS 6 kommt auch Dovecot 2 zum Einsatz; in dessen Konfiguration fehlte eine Zeile zur Aktivierung der Quota:
mail_plugins = $mail_plugins quotaIrgendwie haben wir's heute mit vergessenen Zeilen... :-|
Ist korrigiert und dann im Update mit drin. Das Quota wird dann natürlich auch für alle bestehenden Postfächer nachberechnet.
Viele Grüße
-Klaus Keppler
Danke für den Hinweis - das ist definitiv nicht beabsichtigt. Wie es aussieht ist uns im Lua-Script (postfix.lua) eine Zeile "verloren" gegangen:
virtual_mailbox_maps = hash:/etc/postfix/virtual_alias
Die virtual_alias-Datei enthält auch für "echte" Postfächer jeweils einen Eintrag und soll daher auch als Lookup-Tabelle für die Prüfung auf korrekte Postfächer her genommen werden. Wenn Sie also o.g. Zeile in die main.cf hinzufügen, werden ungültige Empfänger mit einem REJECT abgelehnt.
Ich habe den Fehler eben in der postfix.lua behoben - mit dem Update heute Nachmittag wird das also beseitigt. Bei der Gelegenheit wurde gleich noch ein "show_user_unknown_table_name=no" hinzugefügt, was die Fehlermeldung weniger verwirrend gestaltet.
ZitatUeber die TLS-Warnung grummel ich auch gerade. Dieses Problem scheint in letzter Zeit haeufig aufzutreten, wenn ein Squeeze-Postfix mit einem Lenny-Postfix spricht.
Das verschwindet mit Postfix 2.8: http://archives.neohapsis.com/…postfix/2011-01/0865.html
Viele Grüße
-Klaus Keppler
Nginx wird jetzt erkannt ist aber unter CentOS scheinbar nicht nutzbar.
Status: >Distribution family 'RedHat' not supported (yet)3
Morgen (Freitag) gibt es noch mal ein Preview-Update, da ist das dann auch mit drin (seit heute haben wir auch die ersten automatisierten Tests für NGINX am Laufen)
Viele Grüße
-Klaus Keppler
Exakt. Am besten aber noch in der sshd_config die Option "ChallengeResponseAuthentication no" und "PasswordAuthentication no" setzen (damit SSH-Logins nur mit Key möglich sein).
Im Abschnitt unter "Match Group sftponly" muss dann entsprechend noch "ChallengeResponseAuthentication yes" bzw. "PasswordAuthentication yes" gesetzt werden.
(ungetestet, gerade aus dem Gedächtnis)
Viele Grüße
-Klaus Keppler
In der Tat nur ein "kleiner" GUI/Usability Bug; erledigt in v1.6.0-r2021.
Viele Grüße
-Klaus Keppler
Nachtrag: nehmen Sie bitte in /etc/httpd/conf.d/awstats noch folgende Zeilen mit auf, damit die Icons korrekt angezeigt werden:
<Directory /var/www/awstats/icon/>
Allow from all
</Directory>... kommt auch gleich mit in die Doku.
Viele Grüße
-Klaus Keppler
Hallo,
hier liegt leider ein Bug vor - das AWStats-Tool "buildstaticpages" findet unter CentOS das Programm "awstats.pl" nicht (meiner Meinung nach ziemlich bescheuert, aber was soll's...)
Wir haben das nun durch eine Anpassung im Aufruf von buildstaticpages gelöst (ist im nächsten Update enthalten).
Öffnen Sie bitte die Datei /usr/lib/liveconfig/cron.awstats.sh und fügen in Zeile 43 vor dem Parameter "-config=$1" noch den Parameter "-awstatsprog=$AWSTATS" ein:
nice -n $AWSTATS_NICE $STATICPAGES [COLOR=#b22222][B]-awstatsprog=$AWSTATS[/B][/COLOR] -config=$1 -configdir=/etc/awstats/liveconfig -staticlinks -year=$2 -month=$3 -dir=$LC_WEBROOT/$1/stats/$2-$3/ >/dev/nullDanach führen Sie einfach /usr/lib/liveconfig/cron.awstats.sh einmal manuell aus, und die Statistiken sollten ordnungsgemäß erzeugt werden.
Viele Grüße
-Klaus Keppler
SFTP und FTPS sind (leider) zwei komplett verschiedene Sachen - SFTP wird via SSH (bzw. scponly) realisiert, FTPS über ProFTPd.
Entsprechend sind eventuelle Fehlermeldungen ggf. in /var/log/auth.log oder in /var/log/proftpd/proftpd.log zu finden.
Nicht zuletzt ist SFTP nur mit "echten" Systemaccounts und nicht mit zusätzlichen (virtuellen) FTP-Usern möglich.
Da SFTP erfahrungsgemäß häufig Probleme verursacht und auch recht tricky zu konfigurieren ist (Stichwort: chroot-Umgebung), empfehlen wir eigentlich FTPS für die sichere Übertragung.
Für SFTP wird noch eine spezielle Anleitung vorbereitet, wie man das halbwegs sicher bereitstellen kann (ab OpenSSH 5.x gibt es einen integrierten SFTP-Dienst, der auch chroot unterstützt)
Viele Grüße
-Klaus Keppler
Ab sofort ist eine aktualisierte Preview verfügbar (v1.6.0-r2019).
Dort sind größtenteils alle kleineren Verbesserungen und Bugfixes der letzten Wochen enthalten:
Für Freitag ist noch ein weiteres Update geplant, in welchem dann u.a. DNS-Verwaltung und die ersten Teile der php.ini-Verwaltung enthalten sind. Hier sind bei uns noch ein paar Baustellen offen, dennoch wollten wir zwischenzeitlich mal einen aktuellen Stand freigeben.
Ich bitte also darum, Diskussionen á la "gibt es das Feature xyz nun doch noch nicht" vorerst noch zu verschieben. 
Viele Grüße
-Klaus Keppler
Mit welcher Version vom IE haben Sie das Problem?
Ein Test mit IE8 hier hat eben reibungslos funktioniert.
Die Rechte für den clamav-Milter-Socket sind leider zu restriktiv gesetzt.
Öffnen Sie bitte /etc/clamav-milter.conf und setzen dort folgende Einstellung (ca. Zeile 30):
MilterSocketMode 666Danach starten Sie clamav-milter einfach neu - dann sollte es laufen.
Wir werden das in die Installationsanleitungen (KB#6 und Handbuch) mit aufnehmen.
Viele Grüße
-Klaus Keppler
Heute wurden noch einige Tests eingebaut und viele Bugfixes/Verbesserungen übernommen; morgen Mittag wird die Preview dann aktualisiert. Wenn nichts mehr dazwischen kommt, sollte die Freigabe dann am Montag (19.11.) erfolgen.
Alle weiteren Details dazu dann morgen in einem neuen Thread.
Viele Grüße
-Klaus Keppler
Sehr merkwürdig...
Läuft dieser Server auch unter CentOS 6.x?
Wissen Sie noch, welche Version von LiveConfig (bzw. lcclient) Sie dort ursprünglich installiert haben? (findet sich evtl. noch in den ersten Einträgen in /var/log/liveconfig/lcclient.log)
Hoppla... 
Ja, das Datenbankfeld ist nur für 32bit unsigned ausgelegt, was für max. 4GB Datenbankgröße reicht.
Wir speichern nun einfach den Wert statt in Bytes in Kilobytes ab, was für bis zu 4 TB reichen wird.
Beim nächsten Update dieser Tabelle wird das Feld dann in eine 64bit-Zahl umgewandelt.
Bugfix ist in v1.6.0-r2013 enthalten und somit im nächsten Update verfügbar.
Wie groß ist die Datenbank denn tatsächlich?
Ich kann mir vorstellen, dass es hier irgendwo zu einem 32bit-Overflow kommt.
SELECT SUM(DATA_LENGTH + INDEX_LENGTH) AS DBSIZE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA <> 'information_schema' AND TABLE_SCHEMA = 'web2db1'
GROUP BY TABLE_SCHEMA;Ja, da das "offizielle" CentOS-Repo kein NGINX enthält, wurde dieser bislang noch nicht berücksichtigt.
Ist aber keine große Sache, weil ja praktisch nur nach dem RPM gesucht werden muss; wir erweitern die Erkennungsfunktion gleich mal entsprechend.
Update wird kurzfristig bereitgestellt, ich gebe dann an dieser Stelle noch mal Bescheid.
Viele Grüße
-Klaus Keppler
Da vorhin diese Frage bei Twitter kam: die verfügbare Webserver-Software wird praktisch durch die verfügbaren IP-Gruppen definiert. Derzeit kann ein Kunde/Wiederverkäufer alle "gemeinsamen" IP-Gruppen sowie natürlich alle ihm exklusiv zugewiesenen IP-Gruppen nutzen. Die Rechteverwaltung (intern) ist bereits so vorbereitet, dass Verträge auch so eingestellt werden könnten, dass neben den exklusiv zugewiesenen Gruppen auch nur eine bestimmte "shared"-Gruppe oder gar keine gemeinsamen Gruppen ausgewählt werden dürfen.
Ich denke mal, dass das in rund zwei Wochen auch in der Oberfläche einstellbar sein dürfte (an diesem Bereich wird derzeit eh gearbeitet um die php.ini-Einstellungen verwaltbar zu machen).
Viele Grüße
-Klaus Keppler
Das "Kundenverzeichnis" muss definitiv dem root-User gehören, somit kann ein Kunde da auch keine eigene .httpd.conf anlegen.
Diese Möglichkeit der "Spezialeinstellungen" ist inzwischen auch schon teilweise im neuen Handbuch dokumentiert (ich weiß gerade nicht ab welcher Revision, aber das neue Kapitel nennt sich "Fortgeschrittene Konfiguration"); wir werden das Anfang nächster Woche auch im Lab-Bereich aktualisieren.
Zu den httpd_special-Einstellungen: alles was mit PHP zu tun hat gehört dort eigentlich nicht rein - hierfür gibt es nun eine eigene php.ini-Verwaltung innerhalb LiveConfigs (Details dazu dann auch nächste Woche). Dort können alle Einstellungen bequemer und sicherer verwaltet werden (z.B. ob ein User einzelne Einstellungen überschreiben darf, wenn ja welche min/max-Werte gelten, für welche PHP-Version welche Einstellungen gelten, und vieles vieles mehr).
Alle restlichen Spezial-Einstellungen (z.B. besondere Apache-Module etc.) sind dann am besten in der .httpd.conf aufgehoben.
Viele Grüße
Klaus Keppler
Hallo,
für FTPS gibt es bereits ein Ticket, das wird auch in Kürze in Angriff genommen (sollte in max. 2 Wochen vom Tisch sein).
Zu scponly: leider gibt es nur bis CentOS5 ein entsprechendes Paket bei rpmforge. Die Alternative hierzu ist offenbar das Paket "rssh" (ebenfalls via rpmforge). Wir werden die Lua-Scripte entsprechend anpassen, so dass - falls vorhanden - rssh statt scponly verwendet wird.
Manuell können Sie die Shell für einen User vorerst mit "usermod -s /usr/bin/rssh username" ändern. Ich denke, die notwendigen Anpassungen sollten auch bis Anfang kommender Woche drin sein.
Viele Grüße
-Klaus Keppler
Öh - das ist ein Bug. Allgemein fehlt derzeit die Möglichkeit, beim Bearbeiten eines Vertrags die Shell festzulegen (bzw. zu ändern). Wird kurzfristig in Angriff genommen...
(PS: derweil können Sie die Shell z.B. mit "usermod -s /bin/bash username" ändern - LiveConfig wird das nicht überschreiben)