Beiträge von Marco

Ich weiss nicht, ob es nur mir so geht. Oder ob andere sich auch schon daran gestossen haben.

Bei der Anzeige des DKIM-Schlüssel würde ich mir eine sinnvollere Darstellung wünschen. Vor allem die mit Leerzeichen und " eingerückten Zeilenumbrüche sind doch etwas nervig. Sinnvoller würde ich es erachten, wenn der Key in einer Zeile stehen würde. Dazu evtl. dann Zeilenumbrüche nach Funktion, z.B. Hostname, Type, TTL getrennt mit Zeilenumbruch.

Zusätzlich noch ein Problem bei der API.

Unter HostingSubscriptionAdd lässt sich unter SSL der Wert 0, 1 oder 2 auswählen. Je nachdem, ob SSL zugelassen ist oder nicht bzw. ob auch die Verwaltung zugelassen ist. Dummerweise ist dies bei HostingPlanAdd nicht möglich. Dort sind als Werte nur 0 oder 1 erlaubt. Ich kann im Plan jedoch nicht einstellen, ob der Kunde auch Zertifikate verwalten kann. Macht meiner Meinung nach an dieser Stelle aber Sinn, wenn man es schon in der Vorlage festlegen könnte.

Das zu Grunde liegende Problem ist wohl, dass die Änderungen laut ChangeLog auf dem System vorgenommen werden, aber eine Aktualisierung der "liveconfig.conf" unterbleibt.

Die aktuell verwendete Version von LiveConfig ist 2.7.0-r5079.

Die vorherige Version ist von 2.3 bis 2.5 unterschiedlich. Teilweise wurden auch Systeme von Wheezy über ein Dist-Upgrade auf Jessie aktualisiert. Aktualisierung meint apt-get update und apt-get upgrade bzw. dist-upgrade.

Aktuell stellen wir bei Servern vermehrt fest, dass der Webdienst Apache ausfällt. Allen Systemen ist gemein, dass sie vor kurzem aktualisiert wurden. Bis zu dieser Aktualisierung gab es bei den Servern keine erkennbaren Probleme. Komplett neu eingerichtete Systeme zeigen keine dieser Ausfälle und laufen stabil durch.

Fehlerbild ist, dass der apache2 Prozess auf dem betroffenen System noch aktiv ist, jedoch Anfragen an das System in ein Timeout rennen. Nach einem Neustart des Prozesses liefert das System wieder Antworten aus. Nach der Dauer von ein bis zwei Stunden (wohl abhängig nach Zugriffszahl) stellt sich wieder der vorherige Zustand ein.

Bei der Durchsicht der Systeme fallen im apache2 error Log folgende Einträge auf:
AH00106: piped log program '/usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats' failed unexpectedly
lclogsplit: no input source specified (use -i or -f/-F)

Eine Datei "/etc/apache2/accesslog.map" existiert auf den betroffenen Systemen nicht.

Weiterhin ist bei dem Vergleich eines betroffenen Systems mit einer Neukonfiguration aufgefallen, dass die Datei "liveconfig.conf" einen anderen Inhalt besitzt.

In den aktualisierten Systemen steht die Zeile:
CustomLog "||/usr/lib/liveconfig/lclogsplit -m /etc/apache2/accesslog.map -s /var/lib/liveconfig/apachelog.stats" LiveConfig

Bei der Neukonfiguration steht jedoch:
CustomLog "||/usr/lib/liveconfig/lclogsplit -i -w" LiveConfig

Wird der Eintrag der Neukonfiguration auf dem aktualisierten System gesetzt, dann scheint dieses wieder stabil zu arbeiten.

Zusatz:
Neuerdings scheint die Datei "liveconfig.conf" falsch gesetzt zu werden. Bei einer Neuinstallation liegt diese direkt in dem Ordner "/etc/apache2/conf-enabled". Bei früheren Installationen lag sie richtigerweise in dem Ordner "/etc/apache2/conf-available" und wurde durch einen Symlink aktiviert.

Wir schweifen nun etwas ab.

antondollmaier

Bislang hatte ich vor dem Namen Respekt. Vor allem, weil hier immer wieder fachliche Kompetenz an den Tag gelegt wurde. Aber damit scheint es nun vorbei zu sein.

"Bullshit" ist alleine der abgegeben Kommentar. Ein DEB zu ziehen und notfalls die Meldung zu übergehen, ist eine Sache. Ich weiss nicht, wie das bei ADITSYSTEMS läuft, aber ich installiere ein Serversystem nicht Step-by-step von Hand. Viele Prozesse laufen skriptgesteuert ab, da dies die alltägliche Arbeit erleichtert.

Wenn dann ein entscheidendes Element fehlt, dann kommt am Ende ein nicht "sauber" konfiguriertes System heraus. Okay, in dem Sinne mein eigener Fehler, auch so ein Umstand hätte man im Skript abfangen können. Aber wer denkt im Vorfeld an so etwas.

Und ich könnte mir auch den Vorwurf machen, hätte ich doch gestern Abend schon die Grundinstallation vorgenommen, bevor die ganzen Kundendaten kopiert werden. Dann wäre das Problem auch nicht aufgetreten.

Ich mache hier keinen "Aufriss". Meine Anmerkungen waren hier ironisch gemeint. Eine Beschwerde hätte ich auch nie im Forum gepostet, sondern dann hätte ich direkt zum Telefon gegriffen.

LiveConfig hat so seine Höhen und Tiefen. Aber ein abgelaufenes Zertifikat muss nicht sein. Und betrachte ich mir das neue Zertifikat, dann schwant mir Übles. Ablauf kurz nach Ende der Sommerferien in Bayern? Wenn das nicht mal in der Erholung untergeht

Nur, um das klar zu stellen.

Das Problem war kein Update, welches vorgenommen werden sollte. Sondern es handelte sich um eine grundlegende Neuinstallation auf einem nackten System.

Ärgerlich war in diesem Fall nur, dass ein Umstellungstermin mit Kunden abgesprochen war, der nicht eingehalten werden konnte. Und das die weitere Einrichtung des Systems etwas "vermurkst" wurde, da grundlegende Funktionen eben nicht mehr zu Verfügung standen.

Aber nun werden halt 900 GB Daten ein zweites Mal durch RZ geschoben.

Zitat von kk

... Zudem wurde der neue Key bereits mit LiveConfig v2.5.0 verteilt ...

Nicht hilfreich, wenn man 2.5.0 nicht installiert bekommt, da der für die Installation benötigte Key erst nach der Installation vorhanden ist

Aber für manch einen kommt Weihnachten halt auch immer überraschend.

Aber nun geht die grundsätzliche Installation wieder.

Alle Jahre Weihnachten...

Nicht ganz, aber es ist mal wieder so weit. Der GPG-Key ist abgelaufen.

W: GPG-Fehler: http://repo.liveconfig.com main InRelease: Die folgenden Signaturen waren ungültig: KEYEXPIRED 1509911458 KEYEXPIRED 1509911458 KEYEXPIRED 1509911458

Somit ist aktuell keine Installation von LiveConfig möglich, da apt sich weigert, unsignierte Pakete zu installieren.

Okay,

alles zurück genommen.

Ist kein Bug in der neuen Version. Fehlerursache lag an anderer Stelle.

Beim Einrichten von LiveConfig wurde die Verwaltung von Apache2 durch LiveConfig aktiviert. IP-Adressen wurden dann normal zugewiesen, aber die zugehörige IP-Gruppe "default" wurde dabei seltsamerweise nicht erstellt.

Zwischen gestern früh und heute morgen wurde wohl die Version von r4630 auf r4635 angehoben.

Seit dieser Umstellung schlägt der Import von Confixx fehl. Mit der Version r4630 konnten gestern noch erfolgreich Systeme umgestellt werden.

Fehlerstring

PHP Fatal error:  Uncaught SoapFault exception: [SOAP-ENV:Server] Webserver not found or not permitted in /root/import.php:858
Stack trace:
#0 /root/import.php(858): SoapClient->__call('HostingSubscrip...', Array)
#1 /root/import.php(858): SoapClient->HostingSubscriptionAdd(Array)
#2 {main}
  thrown in /root/import.php on line 858

Dies betrifft die Zeile

$response = $client->HostingSubscriptionAdd($hostingpaket);

Zuvor wurde definiert, da kein Resale-Contract:

$hostingpaket['webserver']  = 'localhost';	# fix, da Standard-Lizenz

Heute bei einem Kunden aufgefallen.

Kunde hat einen Reseller-Vertrag. Dieser steht auf "individuell", da aus Confixx migriert. Zusätzlich sind im System nun Angebote für Reseller angelegt.

Wähle ich nun bei dem Kunden unter "Vertrag bearbeiten" anstelle des individuellen Angebots ein voreingestelltes Angebot aus, dann werden in der Maske die Daten dieses Angebots dargestellt. So weit, so gut.

Aber wähle ich dann ein anderes Angebot aus, dann verbleiben in einzelnen Feldern die Daten hängen. Aufgefallen ist dies bei Webspace, betrifft aber wohl auch Kunden und Benutzer.

Und nun das Highlight. Ein anderer Reseller wurde neu angelegt mit einem vorgegebenen Angebot. Stelle ich dort das Angebot um, dann ändern sich die Daten nicht. Hier wird eine Änderung erst angezeigt, wenn ich "individuell" und danach das neue Angebot auswähle. Natürlich unter der Prämisse des vorgenannten, nicht zwei oder mehr Angebote nacheinander aufzurufen.

Neue Installation eines Systems:

Status
LiveConfig-Version: 2.4.0 (r4602) (aktuell)
Neueste Version: 2.3.1-r4556
letzte Prüfung: 27.06.2017 09:23:47 CEST

Ich habe nun das Feature, dass der Server von selbst eine Schreibtest auf die Plattenkapazität vornimmt. Das Syslog füllt sich mit abertausenden Meldungen

Jun 27 06:41:58 XXX dovecot: auth: Error: passwd-file(brendan,104.193.9.76,<P9uetu5SsQBowQlM>): stat(/etc/dovecot/deny.imap) failed: No such file or directory
Jun 27 06:41:58 XXX dovecot: auth: Error: passwd-file(brent,104.193.9.76,<gwqgtu5SuQBowQlM>): stat(/etc/dovecot/deny.imap) failed: No such file or directory
Jun 27 06:41:59 XXX dovecot: auth: Error: passwd-file(brett,104.193.9.76,<hUy2tu5SLwBowQlM>): stat(/etc/dovecot/deny.imap) failed: No such file or directory

Auslöser scheint ein neu vorhandener Eintrag in der Datei "/etc/dovecot/dovecot.conf" zu sein, wobei die angesprochene Datei nicht existiert.
[...]
passdb {
args = /etc/dovecot/deny.%s
[...]

In älteren Installationen nicht vorhanden, aber in dieser Neuinstallation schon.

Wurde hier etwas vergessen in der Umsetzung? Oder hängt dies mit der neuen Funktion lcpolicyd zusammen und muss noch irgendwie konfiguriert werden?

Zitat von Marco

Sinn würde so ein Verhalten nur machen, wenn damit ein "Downgrade" vermieden werden soll.

Wie ich schon sagte, der Weg zurück (also geringerer Wert) kann gerne gesperrt sein.

Wie man es letztlich löst, ist eigentlich nebensächlich. Ein Schalter, über eine interne Regel oder wie auch immer. Unhaltbar ist jedoch der Umstand, das es eben keinen Weg zurück gibt. Einmal einen Wert gesetzt, blockiere ich alle Zugriffe.

Mir geht es auch nicht um eine Möglichkeit, über SOAP eine Verwaltungsoberfläche für ein Verwaltungspanel zu erschaffen. Aber jeder, der ernsthaft Hosting betreibt, hat irgendeine Art von Kundenverwaltung in Betrieb, die über ein Excel-Sheet hinausgeht. Und dafür fehlen etliche Funktionen in der SOAP-API, um dies sinnvoll einzubinden. Für mich sieht diese API so aus, als ob sie mit der heißen Nadel gestrickt wurde, um eine Migration von Confixx zu ermöglichen. Nicht mehr und nicht weniger unterstützt diese API.

Und über CURL ein System zu stricken, das die Weboberfläche malträtiert, macht keinen Sinn, wenn man eine API ausbauen kann/würde.

Meine Frage mal hier in den Raum geworfen, evtl. übersehe ich nur einen Parameter.

Auf einem Server wurden verschiedene Angebote (HostingPlanAdd) angelegt, die entsprechende Einstellungen definieren. Nun wurde ein Vertrag über SOAP mit "HostingSubscriptionAdd" angelegt und ein entsprechender "plan" übergeben.

Im Laufe der Zeit benötigt der Kunde z.B. etwas mehr Speicherplatz. Dieses kann ich mittels "HostingSubscriptionEdit" und "webspace" zuweisen. So weit so gut. Der Kunde wächst weiter und wünscht generell mehr Leistungsumfang. Ergo weise ich ihm mit "HostingSubscriptionEdit" einen neuen "Plan" zu, der diese Leistungen enthält. Mein Gedanke, somit stelle ich das gesamte Paket auf den neuen Leistungsumfang ein.

Leider falsch gedacht. LiveConfig übernimmt zwar die neuen Einstellungen des geänderten Plans, der zuvor einzeln abgeänderte Punkt "webspace" behält jedoch weiterhin die vom vorherigen Plan abweichende Einstellung.

Ist dieses Verhalten ein Fehler? Oder habe ich hier etwas übersehen? Meine Erwartung wäre gewesen, dass LiveConfig bei Angabe eines neuen Plans ohne weitere Einzel-Übergaben auch die vorgegeben Werte des Plans verwendet. Das aktuelle Verhalten ist in meinen Augen unsinnig bzw. kontraproduktiv.
Sinn würde so ein Verhalten nur machen, wenn damit ein "Downgrade" vermieden werden soll.

Okay, schlechter Zeitpunkt für Wünsche. Die ersten fallen so langsam in den Winterschlaf und der Rest erwähnt wohl nur, für Wünsche ist demnächst der Mann mit dem dicken Mantel zuständig.

Aber ich probiere es trotzdem, in der Hoffnung, etwas zu bewirken.

Eben ein bestehendes System von Confixx auf Liveconfig migriert und zusätzlich einen Neukunden unter LiveConfig eingerichtet. Dabei sind folgende Probleme aufgetreten, die mit etwas Überarbeitung keine Probleme sein müssten:

- IP-Adressen aktivieren:

Aktuell muss man für jede einzelne IP-Adresse einen Haken setzen, um diese unter LiveConfig zu aktivieren. Hier fehlt eine Funktion, alle auf einmal zu aktivieren. Es ist einfacher, bei 100 IPs zwei unerwünschte IPs abzuhaken, als 98 anzuhaken.

- IP-Gruppen:

Das vorstehende nicht so dringend notwendig, aber wäre doch schön, es zu haben.

- Domainzuweisung:

Aktuell lässt sich einem Kunden nur eine Einzeldomain zuweisen. Jede weitere Domain benötigt einen wiederholten Aufruf des Formulars. Hier wäre es sinnvoll, mehrere Domains als Liste zuzuweisen.

Ich habe nun die gesamte Dokumentation durchforstet, aber nichts entsprechendes gefunden.

Gibt es eine Liste mit den erlaubten oder alternativ unerlaubten Schriftzeichen, die im Kennwort für admin (nicht) verwendet werden dürfen?

LiveConfig hat nämlich die selten dämliche Angewohnheit, als Kennwort alles anzunehmen, dann aber den Login über die Schnittstelle zu verweigern, weil angeblich das Kennwort nicht stimmt. Offenbar wird hier im Hintergrund das übergebene Kennwort gefiltert und dann als bereinigter String übergeben, der mit dem Original nichts mehr gemein hat.

Und btw., wäre es möglich, die (eigentlich sinnvolle) IP-Sperre bei fehlerhaften Logins gleich mit zurückzusetzen, wenn ein neues Kennwort für admin vergeben wird? Es macht keinen Spass, 15 Minuten zu warten, weil LC sein Kennwort nicht mag.