Da steht definitiv was.
Welche Distribution? Debian? SuSE? CentOS? Ubuntu?
> grep "451 " $LOGFILE
$LOGFILE z.B. /var/log/mail.log
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.
Haben Sie vielleicht nen Tipp wie ich das beheben kann ?
Nutzen Debian Wheezy (aktuelles Update)
*hüstel* da fehlt "libc-client.a" ... Google anwerfen und das fehlende Paket identifizieren sollte noch machbar sein
FAT-Dateisystem?
Hat jetzt aber nichts mehr mit LiveCOnfig zu tun
ich mache wöchentlich ein Backup auf einen externen Server. Ich habe auf dem LiveConfig Server einen neuen Benutzer angelegt, für die Backups. Dieser Benutzer hat jedoch keine Berechtigung auf beispielsweise /var/www/web.../. Ich möchte diesem Benutzer ungerne Root geben, da er eigentlich nur Zugriff auf bestimmte Ordner haben soll wie beispielsweise: /var/www.
Innerhalb /var/www sind Dateien anderer Benutzer, die im schlechtesten Fall nur Berechtigungen für den User selbst haben (Konfigurationsdateien für PHP, da reicht 0400).
Zitatunter /etc/passwd gibt es den Liveconfig benutzer. Ich denke mal er hat die Berechtigung zum Lesen und schreiben von dem /var/www Ordner.
Nein, der LiveCOnfig Client läuft mit Root-Rechten.
ZitatWenn ich meinem Backup User diese Gruppen gebe hat er dann Rechte für /var/www? Oder gibt es eine andere möglichkeit, wie der Backup User Zugriff zum /var/www Ordner hat? Der jeweilige web... soll ja nach wie vor Besitzer sein.
Keine Möglichkeit.
Einzig UID 33 / GID 33 hat zumindest Leserechte dort - aber eben auch nicht in allen Fällen. Mit Pech ist das Backup also unvollständig.
Root nehmen, Backup-Verzeichnis mit root:root und 0700 zusperren - wenn Zugriff von Remote, dann nur mit SSH-Key und Restricted Commands. Sollte reichen.
Update: Sicherheitsprobleme in Webanwendungen kombiniert mit Kernel-Sicherheitslücken würden mir deutlich mehr zu schaffen machen als ein Backup-Prozess mit zu weit greifenden Möglichkeiten.
Warum wird trotzdem das Passwort nicht dargestellt bzw. mit **** gekennzeichnet? Das Passwortfeld ist/bleibt leer.
Ist dies absichtlich so?
Passwörter stehen verschlüsselt / gehashed in der Datenbank und können ab dem Create-Vorgang nicht mehr im Klartext dargestellt werden.
- Fehler bei Verwendung von syslog für LiveConfig-Meldungen behoben
(syslog wurde zwar "geöffnet", Log-Meldungen wurden vorher aber alle herausgefiltert...)- Parameter "webserver", "mailserver" und "dbserver" zu SOAP-Funktion HostingSubscriptionEdit() hinzugefügt (wird benötigt wenn Ressourcen erstmals einem Vertrag zugeordnet werden)
YES! Danke!
*10z*
Bei mir in LiveConfig Basic werden alle Zertifikate, die im Jahr 2016 und später ablaufen, bereits mit einem Warndreieck als abgelaufen markiert.
Macht Chrome auch so, wenn es kein SHA1/SHA256-Zertifikat ist.
Oder es ist wirklich ein Bug
Man könnte das weiter treiben und in der UI integrieren.
Halte ich für sinnvoll(er).
ISPConfig erlaubt z.B. URL-Crons und setzt den Wget/Lynx-Aufruf dann intern in die Crontab.
Bis KK&Team das in die GUI integriert haben, ist das sicher ein gangbarer Weg. Ob nun gerade Anfänger damit klar kommen, wage ich aber zu bezweifeln.