Mein neuer Liebling:
Das Grundproblem bei so Alias-Mailinglisten-Gefrickel: sobald irgend jemand an die Mailadresse schreibt (Spam...), geht der Kram an alle Recipients raus.
Mein neuer Liebling:
Das Grundproblem bei so Alias-Mailinglisten-Gefrickel: sobald irgend jemand an die Mailadresse schreibt (Spam...), geht der Kram an alle Recipients raus.
Wenn ich fragen darf: Welche Optimierung ist gemeint? Einfach nur von SQLite auf MySQL oder wurde mit 1.8.3 noch mehr geändert?
> postalias /etc/aliases
Was zum Henker ist "sm-mta"? Sendmail? Der hat doch auf dem Server gar nichts verloren und wird von LiveConfig nicht mal unterstützt.
ab version 1.9 können eigene app-repositories definiert werden (https://www.liveconfig.com/dev/issues/185). Beispielcode wird gerade vorbereitet und steht in kürze bei github bereit (https://github.com/liveconfig).
yes!
Sollte somit auch in der 1.8.3 auftauchen.
Entweder hab ich mich zu doof angestellt - oder der Permission-Bug ist immer noch vorhanden.
Neu angelegter Webspace-Vertrag war für den zweiten LC-Benutzer nicht sichtbar, trotz aktiver "Angebotsverwaltung".
Da läuft vermutlich ClamAV-Freshclam nicht.
Oder einfach den ClamAV-Milter neu starten. Wenn der nicht aktiv ist, gibt es besagte 45x-Fehler.
Da steht definitiv was.
Welche Distribution? Debian? SuSE? CentOS? Ubuntu?
> grep "451 " $LOGFILE
$LOGFILE z.B. /var/log/mail.log
Zudem habe ich das Protokoll täglich im blick!
Bei wie vielen Servern, die du betreust, hast du das Protokoll tatsächlich täglich im Blick? Wird nämlich ab einer gewissen Anzahl an Systemen schwierig bis unmöglich
(Dafür gibt es centralized Logging mit Alerting - Push von Events statt Pull ...)
Grundsätzlich kann ich mir einen "Expire" durchaus vorstellen - aber dann so, dass das ganze einen Audit übersteht. Dazu gehört zu 99,99% auch, dass das Protokoll Read-Only ist, gerade für Admins.
/var/www/$vertrag/.httpd.conf mit gewünschtem Inhalt anlegen, eine der Seiten in LC neu speichern.
Ansonsten muss vermutlich eine der LUA-Dateien gepatched werden. Ob das persistent bleibt, ist aber fraglich
- Joomla/Wordpress sind nun wirklich DAU-installierbar
- Magento - wo es verm. EUR 10.000 aufwärts beginnt,
glaubt da wirklich jemand, eine Agentur installiert das
über LC?
- Wer nennt mir eine Anwendung, die nach einer 1Click-Installation
ohne Folge-KnowHow praxisreif ist?
Zustimmung - ja.
Mit einer Ergänzung/Anmerkung: der Benutzer spart sich den Download des Paketes, das Auspacken sowie das Hochladen der Dateien an die richtige Stelle.
Gerade für Wordpress, Joomla oder die "einfacheren" Online-Shops (Prestashop, Veyton, Shopware), an denen sich gerade die Einsteiger versuchen, ist das eine gravierende Vereinfachung.
Zitat<vorurteilsmode>
...und nicht vergessen: wer über eine 1Click-Installation eine Anwendung
laufen hat und diese nicht per 1Click updaten kann, wird es auch nicht per Hand
updaten (weil: nicht können oder wollen) - Ausnahme: z.T. WordPress
</vorurteilsmode>
Auch Joomla hat inzwischen den Updater integriert. Aber grundsätzlich stimmt es natürlich.
Und Prestashop.
DKIM? Cool. Sehr cool, dass es auch mit externen Nameservern klappt.
Wie siehts mit Bugfixes aus? Stichwort LC Basic, Hosting-Permissions
Wenn Let's Encrypt _komplett_ unterstützt wird, wäre das schon mega genial.
Sprich: "ich hätte bitte gerne SSL für example.com und shop.example.com" - alles andere macht dann LC.
Kann ja intern über die SSL Verwaltung laufen - aber so hätten auch Kunden die Option (wenn erlaubt), automatisiert die Zertifikate zu nutzen.
Wie sieht der DomainADd-Aufruf aus? Grundsätzlich sollte das nämlich so klappen.
Nach allen Files, die der *Gruppe* des Benutzers gehören - LC arbeitet mit Gruppenquota, nicht mit User-Quota.
Womit wir wieder beim Thema wären: wie schaut's mit dem eigenen App-Repository aus?
Persönlich würde ich bei xt:Modified eh zu "rauswerfen" tendieren. Der Shop ist ja nicht mehr gerade der neueste ...
Das ist doch sicher ein Hetzner-Server, oder?
Bitte die Basis-Einstellungen bzgl. Hostname vornehmen - insbesondere Postfix dürfte fehlerhaft konfiguriert sein (Hostname, /etc/mailname):
http://www.liveconfig.com/de/h…/server.requirements.html
Zu den Login-Versuchen: das ist "Grundrauschen". Fail2ban drauf und fertig.
aaaah, bitte Bugfixing :mad:
So schön PHP5-FPM für Nginx wäre (wundert mich, dass da nicht von Anfang an drauf gesetzt wurde, anstatt einen eigenen FastCGI-Wrapper zu bauen) - muss ich mich doch Andreas mit der Bitte um "Bugfixing!" (Stichwort LC Basic Secondary Admin-Permissions!) anschließen.