Beiträge von kk

Steht beim AppInstaller bei diesen Anwendungen aktuell "Status: Deinstallation..."?

Zitat von Aybee

Wir haben nun unter mein Webhosting alle Subdomains mit Einträge hinterlegt (A,MX,TXT etc)

Wie sieht das nun aus,wenn ich für einen neuen Kunden eine Domain anlegen? Muss ich dann dort immer für jede Domain beim Kunden die Einträge von hand anlegen? Da LC ja nur www.domain.de und domain.de anlegt z.b legt er nicht *.domain.de an

Das kommt drauf an... wenn die Domain auf einem DNS von LiveConfig verwaltet wird, dann legt LiveConfig natürlich auch automatisch die notwendigen A/AAAA-Records an. Sobald Sie E-Mail für eine Subdomain aktivieren, legt LiveConfig automatisch den MX-Record an.
Ein Wildcard-Record ist eine sehr einfache aber recht unsaubere Lösung.

Zitat

Wie kann man es den ändern das in den E-Mails Templatet bei Postausgang und Co nicht der Hostname steht sondern z.b mail.meinedomain.de als Posteingang und Ausgang?

Es macht in der Regel keinen Sinn, als Mailserver so etwas wie mail.<kundendomain> einzurichten. Heutzutage sollte die Kommunikation mit dem Mailserver ausschließlich über SSL/TLS laufen. Da Sie wohl kaum ein Multi-Domain-Zertifikat mit allen mail-Domains aller Kunden anlegen werden, müssen Sie zwangsweise den Hostnamen für den Mailserver verwenden, auf den auch das SSL-Zertifikat ausgestellt ist (z.B. "mail.provider.de").
LiveConfig trägt im Standard-Template für die Zugangsdaten-Mail den Hostnamen ein, auf dem der Mailserver läuft (so wie es streng genommen auch konfiguriert sein sollte), mit einem der nächsten Updates wird man für die einzelnen Dienste aber auch Alias-Namen definieren können.

Viele Grüße

-Klaus Keppler

Das heißt normalerweise, dass die zu prüfende Subdomain nicht bei den zuständigen DNS-Servern gefunden werden konnte (kann z.B. bei neu angelegten Domains der Fall sein).
Die Resolver von Let's Encrypt cachen die Ergebnisse leider relativ lange - es lohnt sich daher meist erst nach 6-12 Stunden einen erneuten Versuch zu starten.

Wurde bereits mit v2.0.1-r3991 behoben, ist somit im kommenden Update erledigt.
Das betrifft nur die Filterung von ACME-Account, in der Regel reicht dort ja ohnehin ein einziger Account.

Zitat von ManDal

Hab mir vor 10min auf einem Windows 10 die letzte Version installiert und da wird das Zerti als unsicher gekennzeichnet aber die Seite wird geöffnet...

Prüfen Sie die Domain mal mit unserem SSL-Check (http://sslcheck.liveconfig.com). Was wird da bei Port 443 berichtet?
Wenn Sie das SSL-Zertifikat im LiveConfig bearbeiten (Hosting -> SSL-Zertifikate), wird dort ein CA-Zwischenzertifikat angezeigt?

Zitat von starkiller

Folgen sind das die EMails erst nach Wochen ankommen, und die Auto Konfiguration garnicht funktioniert.

Die Meldung von Dovecot ist nur eine Warnung, die in diesem Fall überhaupt keine Rolle spielt.
Außerdem werden eintreffende E-Mails von Postfix verarbeitet, mit Dovecot hat es also überhaupt nichts zu tun, wenn Mails "spät" ankommen.

Ohne einen konkreten Fall werden wir da leider auch nicht weiterhelfen können.
Wenn sich das Problem mit den verzögerten Mails reproduzieren lässt, dann senden Sie bitte mal eine Mail an Ihren Server und schauen anschließend, was in /var/log/mail.log genau auftaucht. Dort (und nur dort) finden Sie alle Details und somit auch die Ursache.

Viele Grüße

-Klaus Keppler

Zitat von WebService4U

ich muss leider das bereits gelöste Thema hier im Forum - denn auf E-Mails antwortet der Support mal wieder nicht

Ich kann hier aktuell kein offenes Ticket von Ihnen finden - könnten Sie mir bitte die Ticket-Nummer kurz durchgeben?

Zitat

mein Kunde hat mir mir mitgeteilt, dasss die Traffikanzeige aktuell schon wieder weg ist.

Sind auch Verträge betroffen, bei denen keine Catchall-Subdomain eingerichtet ist?

Fehler ist gefunden: das Mailpasswort wird zwar korrekt im LiveConfig aktualisiert, diese Änderung wird in manchen Fällen aber nicht gleich an den Mailserver weitergegeben (dann erfolgt das erst nach beim nächsten Update-Intervall oder LiveConfig-Neustart).

Wir haben das nun geändert, mit dem nächsten LC-Update (ab r3994) wird die Änderung dann immer gleich an den Mailserver durchgereicht.

Thank you for the feedback. We've found it: the uploadscan.sh script is run from NGINX without valid PATH environment variable.

Edit /usr/lib/liveconfig/uploadscan.sh and insert the following line before FILE="$1":

PATH="/usr/bin:/bin"

That's all. Restart of NGINX or FastCGI/PHP is not required.

We're including this line in all future releases.

What do you get when you run

/usr/lib/liveconfig/uploadscan.sh session.php

and what does "pidof clamd" return?

Are Apache and NGINX running on the same machine, or are these different servers?
If different: please check if "clamav-daemon" is running on the NGINX host.

Basically it should work independently of the web server software, because upload scanning is handled by PHP itself (suhosin extension).

Nutzen Sie den Standard-Passwortmanager von Chrome oder irgendeine Extension?
Ist das Passwort-Feld direkt vorausgefüllt wenn Sie ein Postfach bearbeiten?

Ich kann das derzeit nicht reproduzieren (wir wenden einige Tricks an, um jeglichen Passwortmanager an dieser Stelle zu umgehen).

LiveConfig macht das definitiv nicht von sich aus.

Welchen Browser verwenden Sie? Haben Sie zudem irgendeinen Passwort-Manager aktiviert?

Das geht derzeit leider gar nicht. Eine Umbenennung eines Vertrags würde bedeuten, dass auch der Betriebssystem-User umbenannt werden muss, ebenso alle anderen Accounts die diesen Namen evtl. als Präfix enthalten (z.B. Datenbanken, virtuelle FTP-User, und so weiter). Das in allen Details durchzuziehen ist eine recht komplexe Sache und gerade bei den Datenbanken praktisch nicht mehr automatisierbar (da ändern sich ja dann auch Zugangsdaten...).

Ich habe das eben geprüft - die Funktion arbeitet einwandfrei.
Die Parameter "password", "spamreject" etc. sind aber alle optional - wenn die also falsch übergeben werden (so dass LiveConfig die nicht erkennt) dann führt das dementsprechend auch nicht zu einer Fehlermeldung.

Daher wäre interessant, wie die SOAP-Nachricht ausschaut, die Sie zum Server schicken. Setzen Sie dazu bei "$client = new SoapClient()" die Option "'trace' => 1" - unmittelbar nach der SOAP-Abfrage haben Sie über $client->__getLastRequest() Zugriff auf die SOAP-Anfrage.

$client = new SoapClient($wsdl_url,
    array(
        'style'    => SOAP_DOCUMENT,
        'use'      => SOAP_LITERAL,
        [COLOR=#ff0000][B]'trace'    => 1[/B][/COLOR]
    )
);


[...]


$res = $client->HostingMailboxEdit($params);


[...]


print_r [B][COLOR=#ff0000]$client->__getLastRequest();[/COLOR][/B]

Soweit ich das mitbekommen habe hatten wir uns für allow_url_fopen vor CURL entschieden, da ersteres in PHP standardmäßig vorhanden (und meist aktiviert) ist, während CURL eine Erweiterung ist die eben manchmal nicht vorhanden ist.

Wir testen aber in der nächsten Stunde beide Varianten noch mal durch und schauen wo es da zu Problemen kommen kann.

Was für eine Änderung genau führen Sie durch?

Zitat von mDirk

Ich sehe es als wichtig an, gerade sicherheitsreleavante Features auch in der Basiclizenz mit freizugeben.

Das Let's Encrypt-Feature in LiveConfig ist nicht sicherheitsrelevant, sondern ein reines Komfort-Feature. Eine Basic-Lizenz ist kein bisschen "unsicherer" als eine Standard-Lizenz - es stehen da aber (natürlich) weniger Funktionen zur Verfügung (dafür kostet die ja auch deutlich weniger).
So lange unsere Entwickler sich nicht von Luft und Liebe ernähren können/wollen und neue Funktionen nicht vom Himmel fallen, sind wir gezwungen, für eine langfristige Weiterentwicklung auch auf die Wirtschaftlichkeit und die Refinanzierung zu achten.

Mit der nächsten Version (2.0.2) fängt LiveConfig diese Fehlermeldung übrigens ab und zeigt das in der GUI an (so dass man das nicht erst im Logfile findet).

Zum o.g. Problem: einfach in 3-4 Tagen noch mal probieren (das Limit gilt ja "nur" pro 7 Tage).

Welche Meldungen gibt es in /var/log/liveconfig/liveconfig.log? Suchen Sie dort einfach mal nach "ACME".