Beiträge von Wachert

Es wäre auch schön wenn man optional LiveConfig unter einem definierten ServerName (Domain) erreichbar machen könnten anstatt das dies auf allen Hosts/IPs per entsprechendem Port erreichbar ist, optional versteht sich, also einstellbar

Ein sehr gern genutztes Feature aus Confixx ist im Massenbereich von Hostings die Kommentarfunktion für Datenbanken. Dort kann man, ohne den Benutzernamen oder Datenbankname zu "missbrauchen" eine Info hinterlegen wofür die Datenbank z.B. zum Einsatz kommt oder interne Bezeichnungen hinterlegen.

Als Feature wäre das noch sehr praktisch.

Dem kann man nur zustimmen, die bisherigen Ansätze stimmen, wenn auch die Entwicklung ein bischen "schläfrig" ist wie es normalerweilse nur bei freien OpenSource Paneln ohne Firma dahinter der Fall ist. Ok, Confixx ist auch nicht das schnellste aber die haben ja eh abgedankt. Plesk ist keinen Vergleich wert und so viele nennenswerte Alternativen ausser evtl. noch pdadmin oder CPanel gibts ja dann nicht mehr unter den kommerziellen.

Aber in Anbetracht der Tatsache wie ressourcen-schonend und einfach zu bedienen liveconfig bisher ist, ist es das warten noch wert und die Preise sind ja auch sehr annehmbar und in Ordnung für das was man bekommt. Ich hätte ehrlich gesagt sogar damit gerechnet das es teurer werden würde.

Ja, phpmyadmin war ein blödes Beispiel Roundcube wieder ein anderes *g* Wie gesagt, mit der extension lassen sich da hybsche eigene Sachen kreieren und basteln, ich bin an manchen Sachen bereits eifrig dran, "Fertiglösungen" wie andere Panel / Interfaces sind da leider etwas schwieriger wenn man es sauber lösen will ohne besagtes JS direkt in das Ziel einzubinden.

Ich quäl mich daran auch gerade ab da ich Seiten einbinden "muss" an denen nichts geändert werden darf geschweige denn ein JS geadded wird. Hab dann viel mit "Zwischenseiten" per PHP probiert aber das ist auch nur halbwegs brauchbar. Schlussends ist das ganze nur brauchbarer wenn man eigenen Content einbinden möchte, Einbindungen wie externes PHPMA, ZNC-Webinterface und ähnliches kann man leider vergessen.

Die Idee mit der "Iframe API" ist nett aber nur ein Tropfen auf dem heissen Stein, da gibts durchaus bessere Lösungen bei anderen Paneln, vielleicht kommt da ja nochmal was Die Api Extension wiederum ist natürlich echt nicht schlecht.

Dann wurde die falsche php.ini bearbeitet, ganz sicher das die richtige genutzt wurde?

Wenn es auskommentiert ist, ist es nicht gesetzt und damit nicht aktiv, die Auskommentierung muss entsprechend entfernt werden, damit es aktiv ist. Anschließend muss der Webserver natürlich neu gestartet werden bzw. ein Reload angestoßen werden. Man muss jedoch beachten das die manuellen Änderungen in liveconfig durch gewisse Events im Panel ggf. wieder überschrieben werden.

Wieso Geheimniskrämerei? Einfach mal ein bischen googlen Spamhaus ist alles ausser empfehlenswert. Rein technisch: ok, die Art und Weise der Anfragen- und Austragungsbearbeitung ist schlichtweg unter aller Sau. Zu den Methoden und sonstigen "Vorgehensweisen" sage ich allerdings mal lieber nix

Es geht hier auch mehr um das Prinzip das halt keine Liste vorgegeben sein sollte sondern das man entweder selbst eine definieren kann oder die vorhandenen nur als Option zur Verfügung stehen. Derzeit ist es ja so das liveconfig einem "vorgreift" was genutzt wird. Bearbeitet man die Config wird sie ggf. wieder überschrieben etc. Das sollte halt anders gelöst werden, ganz egal welche Liste zum Einsatz kommt.

Wenn die Option zur Nutzung kommt und es nicht mehr von Haus aus fest vor eingetragen ist, ist alles super ansonsten würde ich liveconfig nicht massentauglich verbreiten wollen.

/usr/lib/liveconfig/php/installer.inc.php

/* Callback für array_walk to trim the array entries */

Eine totale Kleinigkeit aber ist mir grad aufgefallen

Es wäre nicht schlecht wenn LiveConfig die Dienste so konfigurieren würde das diese auch gleich das SSL Zertifikat für SSL nutzen würden welches bei LiveConfig hinterlegt ist, z.B. FTPES, pop-ssl, imap-ssl etc

Nachtrag: im Optimalfall kann man dafür bei der Serviceverwaltung in LiveConfig einen Haken setzen, oder dort direkt eigene Zertifikate angeben.

Ich könnte hier jetzt locker 5-6 DIN A4 Seiten an Beispielen runterrattern und es sehr detailliert erläutern, aber ich verweise einfach mal auf Google und Spamhaus mehr braucht man eigentlich nicht. Ich verkneife mir aus privaten und beruflichen Gründen weitere Kommentare zu Spamhaus

Zitat von cr

Der Updateprozess für Apps wird sich aus unserer Sicht nur auf die Kernanwendung selbst beziehen (z.B. Joomla! oder Wordpress) und nicht die eventuell installierten Plugins. Herauszufinden welche Plugins installiert sind und für jedes verfügbare(!) Plugin eine Download URL und Installations/Update Anweisungen bereitzustellen ist einfach (unserer Meinung nach) nicht realisierbar.

Es geht weniger darum das die Plugins aktualisiert werden sondern viel mehr um Plugins die mit der neueren Version der Basissoftware nicht kompatibel sind und dafür sorgen das die App nicht mehr funktioniert, oftmals mit für den Endbenutzer unerklärlichen Fehlern (gerne 500er). Wordpress und Joomla sind die besten der negativen Beispiele wo dies ständig vorkommt. Hint: Sitze im Support eines Anbieters und weiss wovon ich rede wenn es danach geht

Zitat von cr

Anders als hier Befürchtet werden wir auch keinen Update Prozess automatisiert anstoßen (da kann unserer Meinung nach zu viel kaputt gehen wenn der Anwender nicht Bescheid weiss das seine App aktualisiert wurde und dann plötzlich einige Plugins nicht mehr funktionieren). LiveConfig wird im Webinterface darauf hinweisen dass ein Update für eine App bereitsteht. Der Anwender muss dann selbst tätig werden und auf "Update" klicken um das Update zu starten.

Klingt besser wenn ausreichende Warnhinweis der möglichen Folgen enthalten sind

Zitat von cr

Anwendungen die einen internen Update Mechanismus haben (wie z.B. Wordpress) werden von uns nicht aktualisiert da hier der Hersteller ja schon eine entsprechende Lösung bereitstellt. Auch hier wird LiveConfig den Anwender darauf hinweisen dass seine App nicht mehr aktuell ist und ihm ggf. eine kleine Schritt für Schritt Anleitung bereitstellen wie er sie über das Hersteller Interface updaten kann.

*thumbsup*

Bezüglich Spamhaus ist klar das die diverse Listen haben, aber Spamhaus bleibt Spamhaus und kommt einem guten Admin nicht ins Haus Daher ist es schön das die Option kommen wird

Wegen helo, müsste man ggf. filtern das erspart einem die Warnings die Postfix halt ggf. einige male ausgibt wenn der Dienst durchstartet. Auch wenn es nur ein Warning ist.

Die Anwendung von Spamhaus Listen in den Mailservices sollte umgehend als Option eingebaut werden und nicht einfach als Vorgabe bei der Konfiguration.

Spamhaus ist das letzte auf Gottes Erden was Admins einsetzen sollten. Mich wunder es etwas warum dies eingesetzt wird. Warum setzt man auf so einen Schrott?

Nachtrag:

smtpd_require_helo=yes <- gibt es übrigens nicht mehr

Das Problem wird viel mehr durch Plugins kommen und vor allem durch geänderte Dateien von Usern, daher sollte in jedem Falle der User entscheiden können ob ein Update ausgeführt wird oder nicht. So ein Feature nur für "manche" Apps anzubieten wäre wieder nicht verkäuflich als Anbieter. "Jetzt mit Auto-Update für manche Anwendungen" ist ein ziemlicher Fail

Das Problem sind hier jedoch massivst Softwareupdates die mehr benötigen oder wenn in der Software Plugins verwendet werden und und und... sowas ist nicht wirklich Massen- geschweige denn Endkundentauglich.

Eigentlich reicht es doch die IPs im Server anzulegen und liveconfig ggf. einmal durchzustarten damit man diese in der Dienstverwaltung für die Dienste wie Webserver aktivieren kann.

Im lc-api.css Zeile 151

table.tabBox > tbody > tr > td { padding:2px 8px; xbackground-color:#FFFFFF; color:#888888; }

Richtig:

table.tabBox > tbody > tr > td { padding:2px 8px; background-color:#FFFFFF; color:#888888; }

Richtig, es wird immer ein Benutzer angelegt, der User selbst sozusagen. Einfach in den Leistungen des Hostings den Haken bei FTP entfernen, dann wird der User angelegt aber kann sich eben nicht per FTP verbinden. Der User selber muss aber immer bestehen da dieser nicht für FTP da ist.