Ist doch klar. bei der Distro ist in der Regel der phpmyadmin dabei, der schon alles kann, was der "veraltete" mysqld auch kann. Von meinen Kunden ist in 9 Jahren Webhosting-Betrieb keiner gekommen: "Wähhh der phpmyadmin ist zu alt". In meinen Augen ist das Geschwätz.
volle Zustimmung.
Den LiveConfig-Dienst schon einmal neugestartet?
Was sieht man im liveconfig.log ?
Hi,
und die komplette GUI für den Web-Kunden nicht vergessen! :o
Welche? Also dass die Leute ihre Stammdaten selber bearbeiten können, finde ich nicht sinnvoll...
Aktuell in Arbeit sind (neben etlichen kleineren Bugfixes) ein überarbeitetes Backup, Lösch-Funktionen in der SOAP-API sowie das komfortablere Bearbeiten (und Löschen!) von Kontakten.
Punkt.
Danach bitte Releasen und erst in 1.9.2 weitere Features 
Herr Keppler, gab es hier schon eine Entscheidung oder gar Umsetzung?
wurden die Pakete dort manuell heruntergeladen und installiert oder per Repository?
grep php /etc/apt/sources.list.d/liveconfig.list
verrät das.
Wenn es den Eintrag gibt, sollte "apt-get update && apt-get upgrade" auch die PHP-Pakete aktualisieren.
Interessante Vorgehensweise, geht das Vollautomatisch per IDS oder schaltet ihr das per Hand bei eventuellen Auffälligkeiten?
per Hand, da das nichtmal einmal pro Tag nötig ist, in manchen Wochen gar nicht.
Der Kunde bekommt dann eine E-Mail und kann weiterhin per FTP zugreifen um die Bereinigung und meist auch Update dann durchführen zu können. Der Angreifer kommt aber nicht mehr dran, wenn es nicht mehr in htdocs liegt.
Ob das FTP-Passwort zusätzlich geändert werden muss, sagt mir ein grep VERTRAG auf den ftp-Log.
Wie realisiere ich denn nun ein Versions Upgrade ohne mir Liveconfig zu schiessen! Habe mir aktuell mal die PHP-Version: 5.6.10-1~dotdeb+7.3 installiert aber ich meine mal gelesen zu haben das die dotdeb versionen für den hintern sind?
Da LiveConfig nicht in PHP geschrieben ist, kannst du mit einem PHP-Update das LC nicht "schiessen".
Wozu wurde denn eine dotdeb-Version installiert?
Einfach die normale Version behalten und parallel die von Keppler bereitgestellten installieren:
http://www.liveconfig.com/wiki/de/multiphp
für den produktiven Einsatz im Bereich Webhosting kann ich zumindest nicht auf eine API verzichten.
das "ich" muss hier betont werden.
Wir zumindest kommen gut ohne API klar, im Gegenteil: eine API-Anbindung programmieren (zu was eigentlich? Kundenverwaltung? Bestellsystem?) kostet deutlich mehr Zeit als wir manuell in LC verbringen für die Webhosting-Kunden...
Vermutlich benötigt man das nur bei billig&massenhosting, damit man die Skaleneffekte nutzen kann...
zum Thema:
klar, einen Vertrag sperren zu können wäre gut.
Aber auch nur den Webspace-Teil eines Vertrags sperren wäre super, z.B. für einen Hacker-Fall - aktuell verschieben wir da den htdocs-Ordner per bash-Skript und legen einen neuen, leeren an.
Mini-Bug:
Wenn man in den Mailservereinstellungen (Postfix) auf das "i" neben DANE klickt, erscheint als Meldung "undefined"
Mogwais
OT, aber mit dem richtigen Firefox-Addon wirkt der Rechtsklick-"Schutz" nicht
ja, so machen wir es auch - wobei die Lösung ja von dir stammt
Betrifft Debian in keiner Version
falsch :p
in keiner stabilen Version. testing&unstable sind betroffen.
aus Admin-Sicht ist die "viele Funktionen in einem Screen" Lösung von LC super, aber aus User-Sicht war die Confixx-Lösung deutlich übersichtlicher.
Uns betrifft das nur halb, weil wir kein Massen-Hosting machen und für viele Kunden die Änderungen selbst vornehmen (nach Auftrag per Mail/Telefon), aber andere Geschäftsmodelle sicher stärker...
Nicht unbedingt - der AppInstaller vergleicht eine SHA-Prüfsumme mit dem Download, daher ist der Transport relativ egal.
achso, sehr gut
oh, danke für den Tipp, glatt übersehen bisher diese Info!
Wird als Quelle eigentlich - wo möglich - HTTPS genutzt?
Uns kam noch die Idee, optional Weiterleitungen komplett für einen Vertrag zu verbieten (wenn z.B. Policies im Unternehmen das nicht erlauben).
Bitte dann aber nur für externe Weiterleitungen, oder?
Trotzdem denke ich, dass es in diesem Fall sinnvoller ist, irgendein Relay auf irgendeinem billigen vServer einzurichten und über Policy Routing betroffene Mails über diesen (quasi als Smarthost) zu senden.
ja, transport eben auf Zieldomain-Basis.
Nützt aber auch nur bei AOL u.ä., bei GMail/Office365 hat man das Problem, dass ja beliebige Zieldomains deren Mailserver nutzen 
Was für Probleme denn genau?
Wir haben hier ja auch eine Menge Mails an AOL und Google, die aber alle reibungslos durchkommen. Bei AOL muss man halt die Feedback-Loop (FBL) einrichten, bei Google sollte man nicht per IPv6 einliefern (außer die Absenderdomain hat SPF/DKIM). Aber auch prominentere Kunden mit fünfstelligen Mailaussendungen pro Tag machen hier keine Probleme.
Prinzipiell halte ich es für sinnvoller, die Ursache zu beseitigen statt aufgrund der Symptome einfach die Weiterleitung zu verbieten. Wie schon früher in diesem Thread erwähnt schränkt man die Kunden dadurch ein, was vielleicht nicht überall auf Zustimmung stößt.
Ja, die übliche Antwort, die man sich anhören darf... (bei anderen Adressaten wohl auch gerechtfertigt)
Ich habe hier aktuell 2 Situationen (unterschiedliche Organisationen):
1) Subnetze/IPs, die AOL seit 2012(!) einfach nicht freischaltet - ohne Begründung und ohne erkennbares auf der FBL!
Workaround: Umleitung aller AOL-Mails via anderes Subnetz - das funktioniert seitdem, ein weiteres Zeichen, dass die Blockade unbegründet ist, es sind ja genau die selben Mails.
2) Freischaltungsantrag läuft, für Umleitung steht aber kein Host bereit - da wäre es besser dass der Kunde gleich informiert ist, dass seine Weiterleitung nicht klappen wird. Ich weiß ja nicht, wie lang AOL sich noch Zeit lässt.
Gmail wird nur über IPv4 geschickt, ja - SPF und korrekter rDNS alleine helfen leider anscheinend nicht ohne DKIM (und sämtlichen Kundendomains DKIM einstellen ist Arbeit, die keiner bezahlt)
Du meinst die da direkt mit der Mailfunktion aufgeschalten sind? Die sind ja egal, laufen ja nicht durch deinen Mailqueue
ich meine nicht meine Kunden (oder nicht nur), sondern Empfänger-Domains (=Kunden von MS/Google), die dort aufgeschalten sind
Natürlich durchlaufen Mails, die von meinen Kunden als solche Domains geschickt werden, meine Queues...
Dennoch könnten sich Kunden benachteiligt fühlen und zu einem anderen Provider wechseln, wo solche Weiterleitungen gestattet sind.
Ach, es ist also besser, wenn der Kunde erst nach 5 Tagen erfährt, dass die Zustellung scheitert? Interessante Ansicht...
Öhm. "live.fr", "live.co.uk", "hotmail.de", "hotmail.com", "outlook.com" - landet alles bei Microsoft. Wäre also ein Provider. Wie soll da genau reglementiert werden?
Wenn es nur die wären!
Vergesst nicht die Kundendomains(!) die über Office365 oder GoogleMail laufen!
