würde es nicht auch ausreichen, im htdocs jeweils einen Unterordner zu erstellen ?
Der selbe Gedanke kam mir auch beim Lesen dieses Threads.
Beiträge von aziegler
-
-
Du kannst phpmyadmin auch einfach selbst updaten. Es gibt außerdem hier irgendwo im Forum ein Auto Update Script
Ja, genau, ich installiere es um es dann gleich wieder zu updaten, sehr effizient -
Vielen Dank für diese Information Herr Keppler.
Kann man auch den Reseller einschränken in seinen diesbezüglichen Konfigurationsmöglichkeiten?
Der Hintergedanke ist, dass man, um auf Nummer sicher zu gehen, IP-Adressen möglichst nicht oder nur sehr kurz loggt. Man könnte seine Reseller also davor bewahren, rechtlich unsicheres Terrain zu betreten. -
@Keppler-IT-Team
Wann kann man denn damit rechnen, dass PHPMyAdmin 4.0.x im App-Installer verfügbar wird? -
gibt es hierzu schon neues? Bei einigen Kunden wachsen die Logs mit der aktuellen Einstellung in ziemliche Höhen
Wäre denn auch geplant, dass man den Kunden eine Veränderung der Werte verbieten kann? Dies würde ich bevorzugen...
P.S.:
siehe auch https://www.liveconfig.com/de/…nstellungen-von-Webspaces von Dezember 2012 -
das geschieht vermutlich direkt in LiveConfig - falls meine Vermutung stimmt kannst du das nicht ändern, da der Quellcode nicht öffentlich ist.
Die User werden außerdem von FTP-, Mail- und Webserver bzw. PHP verwendet - je nachdem welche User du meinst musst du also sehr viel anpassen...
-
wenn man im Kunden Vertrag zb mod_php aktiviert sehe ich keine Änderung, wenn ich im Kundenaccount eine info.php hochlade....:(
Man verwendet auf Servern mit mehreren Kunden aus Sicherheitsgründen kein mod_php
Woran der Fehler bei der Umstellung konkret liegt kann ich aber nicht sagen. -
soll man Roundcube und phpmyadmin mit dem admin login von LC einrichten oder soll das jeder Benutzer über die Apps installieren? Was ist der beste Weg?
Am Besten jeweils eine zentrale Installation durch den Admin. Den Link zum zentralen PHPMyAdmin kannst du dann auch in der LC-Serverkonfiguration im Reiter Datenbank hinterlegen. -
da Herr Keppler schreibt: "So oder so ist geplant, dass Logrotate-Einstellungen auch individuell pro Vertrag angepasst werden können." bin ich als bisher einziger für die erste Variante
-
Grundsätzlich schließt man dabei aber auch den Versand in den Fällen aus, in denen ein Kunde z.B. seine GMX-Adresse als Absenderadresse verwendet (außer man ließe in LiveConfig auch noch "sonstige erlaubte Absenderadressen" mit pflegen).
Ja, natürlich schließt man diese Fälle aus, aber wenn jemand via $fremdserver mit seiner GMX-Adresse versendet hat er sowieso Probleme, mindestens bei @gmx.de Empfängern kommen seine E-Mails dann nicht an, da dort meines Wissens von extern nichts mit @gmx.de angenommen wird.Dass man jeden Mail-Server für jede Absenderdomain benutzen kann ist zwar komfortabel, aber aus Spamschutz-Gründen seit Jahren schon eine schlechte Praxis - ich sehe kein Problem darin, für jede Domain den zugehörigen SMTP-Server einzutragen im Mail-Client...
Danke für die Aufnahme als Feature-Ticket, natürlich gibt es zig wichtigere Themen als dieses.
-
Wäre es möglich - womöglich optional - den Postfix-Parameter "reject_sender_login_mismatch", evtl. in der Ausprägung "reject_authenticated_sender_login_mismatch" mit aufzunehmen?
Hierzu braucht man auch "smtpd_sender_login_maps".Man kann dadurch vermeiden, dass Kunden E-Mails mit "gefälschten" Absendern verschicken (z.b. wenn ein Spammer an das Passwort des Accounts kommt).
-
Willst du wirklich einen eigenen DNS aufsetzen?
Das tu ich mir nicht an, ich hab einen Provider, bei dem ich eigene Nameserver anlegen kann. Und das sogar recht günstig.
Dem schließe ich mich an, bei den meisten Anbietern sind die Nameserver gratis dabei - wozu hier die Mühe und eigene betreiben... -
-
so dass es ggf über ein bösartiges Script ausgelesen werden kann
Wenn ich ein bösartiges Script auf dem Rechner habe, ist sowieso schon alles zu spät. Das kann das auch mein Passwort abgreifen, das ich aus dem Gedächtnis eintippe. Nicht mehr also, als bei Einsatz von KeePass oder/und FF mit Master-Passwort.
-
Erklär mir, in wie weit aus Deiner Sicht ein "Masterpasswort" das Abgreifen unterdrückt/verhindert (und nicht nur unwesentlich erschwert...).
in der von Herrn Keppler verlinkten BSI-Empfehlung zu Firefox steht auch nur, dass man Master-Passwörter verwenden soll, nicht dass man das Speichern der Passwörter komplett unterbinden soll.
Welchen Unterschied macht es, ob das Passwort in der Firefox-DB oder in der (z.B.) KeePass-DB liegt - außer dass der Komfort (und damit die User-Akzeptanz) deutlich sinkt? -
Ich empfehle an dieser Stelle die Lektüre der PCI-DSS Richtlinie, die Empfehlung des BSI und zusätzlich einfach mal testweise ein Systemtest (Hackerguard, Nessus, CPI) mit aktiviertem AutoComplete. Es hat seinen Grund, warum man z.b. bei Kreditkartenabrechnungssystemen das Zertifikat nicht erhält, wenn man so etwas aktiviert. (Ach ja, gerade bei Firefox ist es auch herrlich einfach, die Daten direkt per Scipt auszulesen (beim BSI gibt's zu dieser Unsitte einen herrlichen Artikel)
Sind deine Ausführungen auch gültig, wenn man in Firefox ein Master-Passwort hat? Ich wüsste nicht, was mit Master-Passwort dagegen spricht... -
Wir werden aber noch eine Lösung einbauen, um auch ohne PHP-CGI (z.B. wenn man nur mod_php nutzen möchte) die korrekte Version herauszufinden.
Das wäre sehr gut, denn wir installieren auch nicht auf jedem Server php5-cgi, wenn es kein Multi-Website-Server ist... -
Ist dies denn mittlerweile möglich?
Das wäre z.B. auch sehr hilfreich, wenn man von einer Basic- auf die Standard-Lizenz wechselt, um dann die webs einem Kunden (die es mit Basic ja nicht gibt) zuzuordnen... -
auch mir geht es wie Mogwais, viele andere Dinge sind (zumindest in unseren Anwendungsfällen) deutlich wichtiger als z.B. der App-Installer. Auch zum Confixx-Ersatz fehlt noch so einiges - und dazu gehört der App-Installer nicht.
Ja wir deaktivieren diesen sogar meistens, denn er führt mittelfristig zu noch viel mehr ungepflegten Webspaces (= keine Sicherheitsupdates) als es ohne App-Installer schon der Fall ist.
Aber der App-Installer ist ja nun schon länger vorhanden, also kann man sich die Diskussion darüber ersparen.
Was uns sehr freuen würde, wenn vor der Integration der größeren Dinge (DNS o.ä.), mehr auf die Kleinigkeiten und Bugs eingegangen würde. -
auch die lange Speicherdauer ist mir ein Rätsel, da es der deutschen Gesetzgebung/Rechtssprechung zum Datenschutz widerspricht, Logs in denen Nutzer-IPs enthalten sind derart lange zu speichern.
Es wäre sehr gut, Herr Keppler, wenn man in LC konfigurieren könnte, wie lange die Logs (nicht nur web, auch mail,ftp...) aufgehoben werden - mit einer Default-Einstellung, die dem dt. Datenschutz genügt.
