Beiträge von kk

Zitat

Lässt sich die <module>.NOUPDATE Vorgehensweise auch auf Dovecot übertragen?

Prinzipiell ja, spricht eigentlich nichts dagegen. Nehme ich gleich mal mit auf...

Zitat

"Konfiguration wegen NOUPDATE nicht überschrieben"

Klingt sinnvoll, ich muss mal schauen inwiefern es evtl. schon eine Möglichkeit gibt, das als Hinweismeldung (und nicht als Fehlermeldung) in der GUI anzeigen zu lassen.

--

Und noch was ganz anderes: es gab eben noch mal ein Update (r2047) - die r2045 hatte einen Fehler in einer SQL-Anfrage, die mit dem SQLite-Backend Probleme gemacht hatte. Ist nun beseitigt.

Viele Grüße

-Klaus Keppler

Hallo,

prinzipiell ein guter Vorschlag, aber wir verzichten derzeit noch ganz bewusst auf eine "pauschale" Aktivierung von IPv6 für diese Dienste (vor allem eigentlich bei Postfix).
Hintergrund: viele Server haben heutzutage bereits IPv6-Adressen von denen der Betreiber gar nichts weiß (Stichwort: Router-Advertisement). Wird nun zB. IPv6 für Postfix aktiviert, so versucht dieser auch (völlig standardkonform) ausgehende Verbindungen über IPv6 aufzubauen wenn der Zielserver einen AAAA-Record hat. Blöderweise ist aber häufig noch kein korrekter Reverse-DNS-Eintrag für die per Router-Advertisement zugewiesene IPv6-Adresse eingerichtet, was dann zu einem permanenten Zustellungsfehler bei SMTP führen kann (so dass also gar keine Alternativzustellung über IPv4 versucht wird).

Wir möchten das lieber so lösen, dass man - wie auch beim Webserver schon - explizit auswählen kann, auf welchen IP-Adressen ein Dienst verfügbar sein soll. Das ist dann auch ohnehin sauberer als auf allen verfügbaren Interfaces zu lauschen.

Einen Feature-Request hierzu werde ich gleich aufmachen.

Viele Grüße

-Klaus Keppler

So, die Preview für Version 1.6.0 wurde voraussichtlich ein letztes Mal aktualisiert (v1.6.0-r2045).
Wir werden das heute und am Montag noch ausführlich testen - wenn nichts dagegen spricht, wird diese Version dann am Dienstag (27.11.2012) als "stabil" freigegeben.
Die letzten Änderungen sind im Changelog im Lab-Bereich aufgeführt und begrenzen sich in erster Linie auf Fehlerbeseitigungen und kleinere Verbesserungen. Die "großen" neuen Funktionen (insbes. php.ini-Verwaltung und DNS-Management) werden in den nächsten Tagen dann in der 1.6.1-Preview aktiviert. Hier haben wir noch einige größere Baustellen offen, insbes. an der Echtzeit-Aktualisierung der DNS-Zonen über dynamische Updates ("Live" eben :)).

Im ebenfalls aktualisierten Handbuch (PDF) gibt es nun auch einen neuen Abschnitt "Fortgeschrittene Konfiguration", in dem zunehmend die speziellen Anpassungsmöglichkeiten beschrieben werden (wird künftig weiter ausgebaut, es gibt nur schon eine Menge Speziallösungen, die wir nicht undokumentiert lassen möchten).

Außerdem erfährt unsere Website am Dienstag eine Aktualisierung, bei der dann u.a. die bisherige statische und zugegebenermaßen etwas veraltete Roadmap durch eine Einbindung von Redmine ersetzt wird. Außerdem sollen die verfügbaren Anwendungen im AppInstaller besser dokumentiert werden. Nebenher gab es außerdem noch kleinere Verbesserungen und Bugfixes am Confixx-Migrationswerkzeug.

Viele Grüße & ein schönes Wochenende

-Klaus Keppler

Hallo,

ich gehe davon aus, dass der neue Server "frisch" ist (d.h. dass dort noch keine Accounts mit LiveConfig angelegt wurden etc.), und dass es sich um die selbe Distribution und Version wie beim alten Server handelt?
Dann gehen Sie bitte wie folgt vor:

• kopieren Sie zuerst /etc/passwd, /etc/shadow und /etc/group vom alten Server auf den neuen Server
• installieren Sie anschließend LiveConfig und alle benötigten Pakete auf dem neuen Server (z.B. "aptitude install liveconfig-meta liveconfig")
• beenden Sie anschließend LiveConfig auf dem neuen Server
• kopieren Sie die LiveConfig-Datenbank (SQLite: /var/lib/liveconfig/liveconfig.db) vom alten auf den neuen Server
• kopieren Sie alle Daten vom alten auf den neuen Server (/var/mail, /var/www, /var/lib/mysql, /var/spool/cron)
• kopieren Sie alle Konfigurationsverzeichnisse auf den neuen Server (/etc/apache2, /etc/postfix, /etc/dovecot, /etc/ssl, /etc/proftpd bzw. /etc/vsftpd, ggf. /etc/nginx)
• kopieren Sie den Lizenzschlüssel auf den neuen Server (/etc/liveconfig/liveconfig.key), beenden LiveConfig auf dem alten und starten es auf dem neuen Server
• melden Sie sich im neuen LiveConfig als "admin" an. Öffnen Sie die Serververwaltung, gehen auf "Web" und wählen in "IP-Adressen" die IPs des neuen Servers aus. In den IP-Gruppen deaktivieren Sie entsprechend die IPs des alten Servers.
• Klicken Sie auf die Mailserver-Verwaltung und dort jeweils bei Postfix und Dovecot auf den "bearbeiten..."-Button. In dem Popup klicken Sie auf "speichern" (auch wenn das ausgegraut ist) - somit wird die Konfiguration jeweils aktualisiert.
• prüfen Sie unter "Datenbanken", ob die Verbindung zur MySQL-Datenbank klappt (ggf. neue MySQL-root-Zugangsdaten angeben)
• starten Sie zum Schluss alle betroffenen Dienste auf dem neuen Server neu (apache2, postfix, dovecot, proftpd bzw. vsftpd). Sollte ein Dienst nicht starten, prüfen Sie die entsprechende Log-Datei.

Längerfristig soll LiveConfig eine Möglichkeit erhalten, sämtliche Konfigurationseinstellungen eines oder mehrerer Benutzer in eine XML-Datei zu exportieren, die dann auf dem neuen Server importiert werden kann (und dort automatisch ggf. die Accounts wieder anlegt usw.) - das sollte einen Umzug erheblich vereinfachen.

Viele Grüße & viel Erfolg

-Klaus Keppler

Manchmal sind Software-Termine ähnlich wie Geburtstermine: man kann das ungefähr voraus sagen, aber wann es dann letztendlich genau soweit ist, entscheidet immer noch die Natur.

Eigentlich steht 1.6 schon in den Startlöchern, es wurde eine ganze Menge Änderungen, Erweiterungen und Verbesserungen vorgenommen. Die Überarbeitung des Application-Installers ist nahezu abgeschlossen, für die DNS-Verwaltung sind die Masken für die SOA-Verwaltung & Secondary-DNS fertig, für die php.ini-Verwaltung fehlt jedoch noch einiges im Frontend+Backend (die Datenstruktur ist fertig und die ersten Lua-Scripte angepasst, fehlt noch die Verwaltung der Einstellungen in Verträgen etc.)

Ich denke, dass wir morgen noch mal ein Update der Preview bereit stellen und die noch nicht komplett abgeschlossenen Funktionen in der 1.6.0-Release noch deaktivieren (die werden dann einfach einige Tage später in 1.6.1 nachgereicht).
So gibt es dann wieder einen stabilen Stand zum Upgraden, der viele der neuen Features enthält.

Viele Grüße

-Klaus Keppler

Der falsche CSS-Link ist mit v1.6.0-r2034 dann auch beseitigt.

Das Problem bestand darin, dass IE9 die Seite im IE8-Kompatibilitätsmodus angezeigt hat. Das passierte wiederum, weil LiveConfig speziell für den IE8 einen eigenen Header mitgesendet hat, damit dieser wiederum keinen Kompatibilitätsmodus anbietet. Wie ich diesen Browser inzwischen hasse... :mad:

Ab v1.6.0-r2032 ist das also beseitigt, Update heute Abend verfügbar.

Viele Grüße

-Klaus keppler

Wir testen das hier gleich mal mit CentOS durch.
Zur Uhrzeit: ich schätze mal, dass da die lokale Zeit einfach falsch ist (NTP nicht installiert? ;))

An diesem Problem (hängende/fehlerhafte Installationen) wird aktuell gearbeitet, voraussichtlich bis morgen Abend sollte das dann endlich vom Tisch sein

webby: wissen Sie evtl. noch, wann bzw. welche Version Sie MediaWiki installieren wollten? Ich schätze, dass das auch auf Ihrem CentOS-Webserver ausgeführt wurde?

Viele Grüße

-Klaus Keppler

Danke für den Hinweis, der Fehler wurde eben beseitigt.
Das Problem bestand darin, dass nach der Aktivierung von SSL für die neue (exklusive) IP-Gruppe die "default.conf" nicht neu erzeugt wurde. Wenn Sie nach der Aktivierung von SSL im Kunden-Webspace noch mal die IP-Gruppe öffnen und dort einfach wieder auf "speichern" klicken, dann wird auch der notwendige Listen-Eintrag erzeugt.
Ist also ab v1.6.0-r2027 beseitigt (voraussichtlich ab morgen Mittag downloadbar)

Hallo Herr Knick,

ein LiveConfig-Partner versorgt uns derzeit dankenswerterweise mit der niederländischen Übersetzung, voraussichtlich wird Spanisch auch in Kürze folgen.
Französisch steht aktuell nocht nicht auf dem Plan, wir können aber bei Interesse gerne die Übersetzungsdateien (handelsübliche .po-Files) bereitstellen, deren Übersetzung wir einpflegen könnten. Bei Änderungen/Erweiterungen an LiveConfig müssten dann auch nur die jeweils geänderten/neuen Phrasen übersetzt werden (wir bauern hierfür gerade eine entsprechende Phrasendatenbank auf).
Bei Interesse geben Sie mir bitte am besten per Mail Bescheid.

Viele Grüße

-Klaus Keppler

Nur so als Hinweis: auch "Kunden verwalten" wird angezeigt, obwohl das mit der Basic-Lizenz nicht möglich ist.

Die Berechtigungen werden in der Datenbank verwaltet und nicht nach Lizenztyp gefiltert. Ist aber eine gute Idee, das aufzuräumen - ich schaue mal, wo wir das am besten unterbringen.

Viele Grüße

-Klaus Keppler

Und wurde auch schon von anderer Seite ein entsprechender Änderungswunsch herangetragen. Ab Mitte nächster Woche werden wir daher einige Änderungen am AppInstaller vornehmen:

• sofern die Anwendung das unterstützt, wird es eine Auswahlmöglichkeit für die gewünschte Datenbank geben (MediaWiki und ownCloud unterstützen beispielsweise auch SQLite, phpMyAdmin kann optional ganz ohne Datenbank laufen, mittelfristig soll außerdem auch PostgreSQL unterstützt werden)
• anschließend kann der Kunde auswählen, welche Datenbank er mit der Anwendung nutzen möchte, oder ob er - falls verfügbar - eine neue Datenbank einrichten möchte.
  Es wird also nicht mehr automatisch eine weitere Datenbank pro Anwendung angelegt werden. Bestehende Installationen werden aber natürlich berücksichtigt (so dass nach einem LiveConfig-Update also weiterhin noch alles funktioniert)
• last but not least soll es dann auch für die ersten Anwendungen bereits eine Möglichkeit zum Update durch LiveConfig geben (wir werden dabei mal mit ownCloud anfangen)

Ich hoffe, das ist im Sinne aller LiveConfig-Nutzer?

Viele Grüße

Klaus Keppler

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 quota

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

Zitat

Ueber 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

Zitat von loswebos.de

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/null

Danach 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