autsch, ja.. nicht schön
Beiträge von webby
-
-
wenn ich mich nicht irre wird durch die deaktivierung derzeit nur der login per ftp deaktiviert aber nicht der fürs webinterface (oder anders herum). Soweit ich weiss ist das aber schon in der pipeline ... (ich hoffe ich bringe das hier gerade nicht mit einem anderen control panel durcheinander)
-
ich könnte mir vorstellen das das für das LC-Team über die lclogsplit-geschichte realisieren lassen könnte...
siehe: https://www.liveconfig.com/de/…-Hosting?highlight=access -
Zitat
Eine tolle Erweiterung wäre das einbinden von fail2ban da ich schon mehrere login versuche auf dem mail server sowie ftp server hatte die offensichtlich von einem Bot kommen.
Hat meines erachtens nichts in LiveConfig zu suchen. Das ist eigentliche sache des Administrators schliesslich gibt es diverse möglichkeiten eben solche automatisierten sperren zu realisieren - auch wenn ich derzeit fail2ban favorisiere ... auf dieser ebene wäre meines erachtens nach nur der bereits in diesem forum irgendwo angesprochene punkt zur verwaltung der iptables um die kommunikation der liveconfig server untereinander zu regeln interessant...ZitatEine feste Einbindung von phpmyadmin wäre auch eine tolle Sache da man gerade bei der Konfiguration viele Fehler machen kann. ( Gerade bezüglich suhosin. )
Wurde schon ein paar mal im Forum angesprochen und es ist derzeit möglich dies über die APPs zu installieren.
Hierzu gehört auch z.B. roundcubemail - diese dinge sind jedoch etwas das zentral vom administrator gesteuert werden sollte und nicht für jeden user über die APPs zu installieren sein sollte.. - auch das wird in einem entsprechenden thread schon besprochen.ZitatEinfach um anderen Benutzern den Umstieg zu erleichtern.
Das erste verwalten des Servers und dessen Einstellungen.
Das erste Anlegen eines Vertrages sowie Kunden.
Das erste einrichten eines weiteren Benutzers.
Wäre durchaus für die einführen in LiveConfig hilfreichZitatIn einem anderen Thread wurde es bereits angesprochen, und zwar wäre es schön wenn man in der CP sehen würde das sämtliche Dienste laufen oder nicht.
Einfach im entsprechenden Thread deine stimme bzw. deinen senf dazu geben wird sicher in irgendeiner weise berücksichtigt.ZitatUnd als letzter Punkt, weiß ich nicht wie andere es sehen, aber die freie Bearbeitung der php.ini für die Nutzer finde ich nicht so klasse. Evtl, kann man es so umstricken das die Benutzer keinen direkten zugriff auf die php.ini haben, sondern man als admin freigeben kann welche werte in der CP verändert werden dürfen und jeweils einen Maximal wert angeben kann.
Ich habe die aktuelle version in der die individuelle verwaltung der php.ini möglich sein soll leider noch nicht antesten können. Aber so wie ich bereits einige Thread hier gelesen habe wird das ganze vom LC-Team schon gut gedacht so das der unbedarfte oder habgierige user nicht das ganze system für sich beanspruchen bzw. lahmlegen kann. -
Falls es dabei bleiben sollte, dass die eigentliche anzahl an datenbanken mit der anzahl der datenbanken für APPs nicht "verrechnet" wird, wäre es meines erachtens besser das für jede app ein eigener datenbankbenutzer angelegt wird z.B. app_web1 und diesem auch eine datenbank ausserhalb des benutzerkon... hmm... wenn ich so drüber nachdenke... der kunde kann ja per ftp immernoch die konfigdaten etc. einsehen wodurch er schon wieder zugriff auf die extra db hat... argh
hmm.... ich finde es hat tatsächlich - wie m_k schon schrieb - etwas kundenfreundliches wenn es so bleibt wie bisher.. jedoch dürfte die db für den kunden dann nicht für andere zwecke nutzbar sein.. ansonsten teile ich die meinung von WebOscar...
-
das müsster eigentlich funktionieren... welcher dienst genutzt wird ist hier ja dann nurnoch von dem port abhängig...
-
Falls Du weitere Server verwalten möchtest, müsstest Du z.B. Deinen Server mit der basislizenz auf business upgraden. Dann kannst du weitere Server sehr einfache mit dieser busineslizenz verwalten. Du Benötigst für die weiteren server jedoch auch eine eigene lizenz... ob diese dann eine basis oder standart lizenz bekommen - wenn ich richtig informiert bin - ist egal.
Der Login bleibt also nur gleich, wenn du deine jetzige basislizenz auf business upgradest da ja alle deine kunden bisher den login vom server mit der basislizenz kennen.
soweit klar?
lg
Webby -
Gern geschehen
Hab mal meinen obigen Post ein wenig angepasst, jetzt sind ein paar mehr infos drin.Gutes gelingen WebOscar
-
Ich arbeite mich gerade auch durch die APIs durch und gestern habe ich mir dieselbe frage gestellt.
Die ContactGet-ID habe ich bisher auch noch nicht im klartext gefunden.
In verschlüsselter form bekommt man aber eine ID wenn mann CustomerGet-CustomerDetails aufruft:Code
Alles anzeigenstdClass Object ( [customers] => stdClass Object ( [CustomerDetails] => Array ( [0] => stdClass Object ( [id] => cH4lr.FWBgyS [cid] => 11592 [owner_c] => cH4lr.FWBgyS [admin_c] => cH4lr.FWBgyS [billing_c] => cH4lr.FWBgyS [locked] => 0 [subscription] => web1 ) [1] => stdClass Object ( [id] => cB5D4Fy2w5tk [cid] => 11593 [owner_c] => cH4lr.FWBgyS [admin_c] => cH4lr.FWBgyS [billing_c] => cH4lr.FWBgyS [locked] => 0 [subscription] => web18 ) [2] => stdClass Object ( [id] => cBVD2ytrKv6Z [cid] => 11594 [owner_c] => cH4lr.FWBgyS [admin_c] => cH4lr.FWBgyS [billing_c] => cH4lr.FWBgyS [locked] => 0 ) [3] => stdClass Object ( [id] => cLGjVw-RXQdL [cid] => 11595 [owner_c] => cB5D4Fy2w5tk [admin_c] => cB5D4Fy2w5tk [billing_c] => cB5D4Fy2w5tk [locked] => 0 [subscription] => web23 ) [4] => stdClass Object ( [id] => cJe8tgGscK4S [cid] => 11732 [owner_c] => cLGjVw-RXQdL [admin_c] => cLGjVw-RXQdL [billing_c] => cFNsgU1GkpW7 [locked] => 0 [subscription] => web30 ) ) ) )
Das ist die Ausgabe die man bekommt wenn man sich das ganze array ausgibt:
Ob man mit dieser verschlüsselten information weiterarbeiten kann, weiss ich noch nicht. Soweit bin ich leider noch nicht gekommen...Ein beispiel um z.B. an die obiger owner_c zu kommen, wäre
PHPforeach ($response->customers->CustomerDetails as $key => $value) { echo "Key: ".$key." cid: ".$value->owner_c."<br />"; }
Mit dem obigen Code bekommst Du die "owner_c" zu allen Kunden. Gibtst hier also keine "cid" für "CustomerGet" an.
Um z.B. den owner_c zu zu genau einer cid zu erhalten die du ihm angibst, müsstest du verwenden:PHPecho "Der Owner_C zur angegebenen Kundennummer: ".$response->customers->CustomerDetails->owner_c;
Hoffe das hilft dir schon weiter. Ansonsten mache ich es etwas auführlicher. Btw. bin aber selbst recht neu was die programmierung betrifft... habe bisher nicht viel selbst mit php und array programmiert. Meistens waren es nur kleine anpassungen.
-
Argh, jetzt sehe ich es ...
Es betrifft hier lediglich die Kontakte bzw. Handles.
hmm.. Kontakte=Contacts?Versuch mich dann mal weiter. Der Thread braucht erstmal nicht weiter beachtet werden
-
Ich versuch mich gerade an der SOAP API und haben schon erfolgreich
- TestSayHello
und
- LiveConfigVersionaufgerufen - juchuu
Jetzt bin ich bei "ContactAdd". Hierzu habe ich ein Formular erstellt das beim abschicken die Werte per "POST" an die Funktion "ContactAdd" übergibt.
Ich erhalte auch als "ContactID" einen Wert zurück "ContactID: cJe8tgGscK4S".
Würde also sagen das der Kunde erfolgreich angelegt wurde (dieser existierte noch nicht). Leider finde ich diesen nicht bei den "Kunden" im LiveConfig-Interface... muss ich hier vielleicht noch zusätzliches machen damit ich den Kunden auch tatsächlich im System habe? -
Das mit der nicht änderbaren Kundennummer ist mir vor 8 Minuten auch aufgestoßen zwar hatte es einen anderen hintergrund aber aber "ja" wäre eine möglichkeit der änderung der Kundennummer denkbar?
-
Ich habs zumindest vor einigen Minuten gelesen fand die tatsache das dieser umstand zu dem fehler führt auch nicht gerade "optimal"
Da ich jedoch LiveConfig noch nicht produktiv einsetzen kann weil eben mir noch einige dinge fehlen bzw. anscheinend ja noch nicht völlig sicher arbeiten (SSL ist auch für mich auf einem produktiven Server unabdingbar) habe ich mir erst einmal einen kommentar verkniffen -
Es ist zumindest normal das er derzeit so ist... habe das ebenfalls als kleinen Layout-Fehler bereits im Forum erwähnt:
-
Ich denke ja nach wie vor das die dinge wie z.B. phpMyAdmin und RoundCube zentrale dinge sind die dem anwender zur Verfügung gestellt werden und somit eigentlich nicht in die app-verwaltung reingehören... zumindest nicht in die die auch die kunden nutzen können... warum sollte sich dieser den z.B. noch RoundCube installieren sollen wenn der Administrator doch ein eMail-WebInterface zur Verfügung stellt den der Kunde per Klick in seinem WebInterface aufrufen kann?
Dann können auch solche lösungen wie mit "git" oder einem anderen vom adminitrator preferierten weg realisiert werden.
just my 5cents. -
Ich vergass leider zu erwähnen das ich die dinge wie z.B. roundcube und phpMyAdmin als zentrale dinge sehe die nicht unbedingt vom kunden selbst zu installieren sein müssten sondern eben vom administrator des system.
Somit würde für diese dinge dann die von mir genannte subdomain-lösung greifen.
Andere Themen wie z.B. das "blog" sind natürlich sehr gern in der form zu sehen wie Sie es beschreiben.
Ich fänds nicht zwingend erforderlich das hierfür nur "blog.domain.tld" oder "domain.tld/blog" verwendung findet. Der Kunde kann das über sein LiveConfig-Interface selbst recht bequem einrichten wenn ich mich nicht irre. (Habe gerade meine testkisten offline, kann also nicht mal eben nachsehen ) -
Ich sehe in dieser Form jedoch einen nachteil für den Kunden.
Hiermit wird dem Kunden ja die möglichkeit genommen dieselben ordnernamen in seinem Hostingpaket zu verwenden.Die Subdomain-Lösung ist eine ebenfalls von mir präferierte Lösung die ich bei meinem aktuellen Verwaltungstool nutze.
Der Kunde hat dann in seinem Kundeninterface die entsprechenden Links in seinem Menü "WebMail" und "phpMyAdmin".Und falls er ohne das Kundeninterface auf z.B. sein WebMail-Interface zugreifen möchte, muss er eben die Subdomain verwenden z.B. http://mail.kundendomain.tld. Derzeit wird bei mir der Aufruf per redirect nach https://server.name.tld/roundcube weitergeleitet. So benötige ich auch nur ein SSL für die Subdomain.
Unschön hierbei ist natürlich das im Browser nicht mehr "mail.kundendomain.tld" steht sondern "server.name.tld/roundcube".
Ist aber eben so, falls der Kunde einen für seine Domain gültigen SSL-Aufruf haben möchte, müsste er ein entsprechendes Zertifikat samt dedizierter IP beauftragen. -
Dank Dir für den Hinweis!
-
Ich muss leider gestehen das ich den Punkt bezüglich der "vHost"-funktionalität doch nicht entdecken konnte - bei dem von mir derzeit eingesetzten Interface konnte ich das über die Konfigurationsdatei machen. Bei LC hätte ich das bei der Aktivierung des WebServer vermutet... hmm... Hat einer den Punkt schon gefunden und kann mir verraten wo der ist?
Zudem würde ich noch einmal gerne meine zweite Frage von meinem letzten Post hier "puschen" wollen...
ZitatWie sieht es inzwischen mit der unterstützung durch die GUI von verschiedenen PHP-Versionen aus?
Seinerzeit wurde freundlicherweise sogar eine Ausführliche Anleitung hierzu in aussicht gestellt -
Mir ist eben bei einem weiteren zum Test angelegten Web aufgefallen das die Zeitzone wieder einmal von PHP angemeckert wird.
Ist ja in Ordnung. Dabei wollte ich das wieder über den oben von Herrn KK angesprochen Trick machen... da fiel mir ein das ja für 1.5.2 die Verwaltung über das GUI in aussicht gestellt wurde... derzeit verwende ich 1.5.2 (r1851). Leider konnte ich keinen entsprechenden Punkt zur Verwaltung der php.ini über das GUI finden
Hat den einer schon entdeckt und kann mir sagen wo es versteckt ist oder wird dies vorraussichtlich doch nicht in die 1.5.2 schaffen?