Beiträge von antondollmaier

Zitat von codexer

Welche Alternativen habe ich?
Wäre es besser, für Kunden die phpMyAdmin benötigen, die ofizielle phpMyAdmin Version auf den jeweiligen Webspace zu installieren?

Oder auf phpmyadmin.example.com, die als reguläre (Sub-)Domain auf einem Vertrag liegt, den PHPmyAdmin als Anwendung installieren und diese URL dann bei der MySQL-Serververwaltung zu hinterlegen.

Somit kann jeder Kunde beim Klick auf die Datenbank den zentralen PHPMyAdmin nutzen.

Und ja, es ist egal, auf welchem Vertrag der PHPMyAdmin dann liegt: MySQL kann nicht unterscheiden, aus welchem Webspace-Vertrag eine MySQL-Verbindung aufgebaut wird.

Zitat von kt01

Zuerst mit "a2dismod php5" das php5-Modul entfernt und mit "a2enmod fcgid" FastCGI geladen.

das war suboptimal.

Solange der Apache noch Konfigurationen mit mod_php hat, sollte das Modul nicht deaktiviert werden.

Zitat

Danach bekomme ich leider immer wieder den Fehler 503.

Der Apache-Errorlog sagt dazu:

Code

Permission denied: mod_fcgid: couldn't bind unix domain socket /var/run/mod_fcgid/(wechselnde Zahlen)

/var/run ist bei Debian ein Symlink auf die Ramdisk /run, die Einstellung wäre also nach einem Reboot korrigiert.

Allerdings gibt es auf unseren Debian 8 den /var/run/mod_fcgid nicht.

Zitat

Vielleicht noch ein kleiner Exkurs, warum ich das überhaupt anstrebe:
Ich habe in einem anderen Thread über Zugriffsprobleme gesprochen. Nunja, diese existieren, seitdem ich den Apache2 mal gepurged habe. Warum weiß ich mittlerweile selbst nicht mehr. Da ging die Eskapade erst los. Danach hab ich die Konfig vom Apache wieder von LC übernehmen lassen. Leider funktionen seit dem Tag keine PHP-Settings mehr über LC und auch die von LC gesetzten Schreibrechte sorgen für Probleme auf meinem Webspace (Wordpress kann keine Pakete updaten oder installieren). Das konnte ich bisher nur mit einem "chown -R www-data:www-data ." im entsprechenden Verzeichnis lösen. Ich erhoffe mir nun, dass diese Probleme durch die Abwicklung über FastCGI ablaufen. (Die Schreibrechte setze ich wie hier beschrieben auch vorher wieder zurück: https://www.liveconfig.com/de/…ar-www-%C3%BCberschrieben). Ich bin auch für andere Lösungsvorschläge sehr dankbar.

Da sollte sich jemand den Server wirklich mal genauer anschauen. Das dürfte schneller und einfacher gehen, als hier endlos über das Forum Unterstützung zu geben.

Zitat von Subdata

Über eine Subdomain in Liveconfig habe ich es schon versucht. Allerdings wird diese Aufgedeckt.

Typ: "Spiegelung (Proxy)"

Damit wird nichts aufgedeckt, das haben wir hier auch so im Einsatz.

Zitat von andreas

Hallo,
für alle mit einer Basic-Lizenz die eingeschränkt sind hier eine Browsermöglichkeit die es ermöglicht schnell LE-Zertifikate anzulegen: https://zerossl.com/free-ssl/#crt
Funktioniert ohne Probleme, habe es soeben getestet.

und das wiederholst du nun alle 61 Tage selber?

Alternative: https://gethttpsforfree.com/

Zitat

Verstehe nicht wirklich, warum dies bei einer Basic Lizenz nicht integriert ist!

Damit mehr Standard/Business-Lizenzen verkauft werden.

OpenSuse 12.3 ist End of Life:

https://en.opensuse.org/Lifetime

Zitat

Warum werden die Installer-Scripte nicht mit der eingestellten LiveConfig PHP-Version ausgeführt/installiert?

wäre in diesem Fall ein Feature Request und kein Bugfix. Der Installer an sich hat ja nur gewisse Mindest-Anforderungen, ist aber kein Hexenwerk:

https://github.com/LiveConfig/apps-example

Zitat von Subdata

Kurioserweise funktioniert jetzt auch phpmyadmin nach der 4 Neuinstallation :confused:

Herzlich Willkommen in der Welt von DNS und Time To Live (TTL).

Zitat von suppenuser

Wir machst Du das bisher?

Puppet (oder Ansible, je nach persönlicher Präferenz)

Zitat von leo

is possible to activate LDAP extension on php 7.0.11 version???

-sure:-

my bad. LDAP is core, not a PECL extension.

Zitat von Aybee

Nein eben nicht. Hostname sowie ReverseDNS ist korrekt und auf einer Blacklist steht die IP auch nicht, trotzdem kommen die Mails ausschließlich an Google nicht an.

Siehe kk.

Da Google selbst auch DKIM nutzt, wäre das eher zu empfehlen als SPF.

Zitat von Aybee

Soweit mir bekannt ist verlangt Google aber einen korrekten SPF Eintrag?

wäre mir neu.

Zitat

Zu 98% landen unsere E-Mails bei Google im Spam oder kommen gar nicht erst an.

das liegt dann tendentiell an was anderem. ReverseDNS, Hostname, evntl. Spamversand von der eigenen IP/dem benachbarten Subnetzen, ungültige E-Mails, ...

Wird es den da seitens LC eine Lösung geben SPF mit SRS ?[/QUOTE]

LiveConfig kann kein FPM, nur FastCGI.

Empfehlung: Debian Jessie. PHP5 als Default, PHP7 über das LiveCOnfig-Repository.

Zitat von Aybee

Kurze frage legt LiveConfig keinen SPF Rekord an selbständig für die Domains?

Nein.

Persönliche Meinung: SPF ohne SRS taugt nichts und macht mehr kaputt als es nützt.

Siehe das web.de/GMX-Fiasko.

Zitat von mgoeben

Das Rate Limit kommt nur deswegen zum tragen, weil ich das defekte Zertifikat gelöscht habe und dann ein Neues zu bestellen.

Also doch ein Ratelimit gebrochen.

Wenn sowas passiert: ACME-Tab aufrufen, nichts ändern (bzw Checkbox an und wieder aus bzw andersrum), danach speichern - und abwarten.

Zitat von WebOscar

Mittlerweile hat sich das ursprüngliche Problem, nämlich das der WebDav-Client in Windows nicht auf SNI-SSL-Verbindungen eingeht, erledigt. Zumindest unter Win10 läuft das nun.

Danke für die Info - das war mir noch nicht bekannt

Zitat von Beichti

Irgendwie finde ich den Punkt nicht um Endkunden zu verschieben. Naja vielleicht wird man im alter einfach Blind.

von "Kunde verschieben" war nie die Rede: Verträge können nun an andere Kunden/Reseller verschoben werden.

Quota falsch?

was sagt "liveconfig --diag"?

Zitat von bash

Hey... wäre langsam mal toll wenn man das Server Zertifikat auch automatisch erneuern könnte damit...

LiveConfig normal auf :8443 laufen lassen, zusätzlich aber eine Domain (z.B. config.example.com) im Webspace via LiveConfig erstellen. Weiterleitungs-Typ Proxy, Ziel: "https://localhost:8443".

Für "config.example.com" bekommt man ganz normal Zertifikate.

Zitat von kk

Die wichtigsten Änderungen sind:

• Verträgen aus beliebiger Tiefe können nun einem Administrator oder Reseller neu zugeordnet werden
• Status-Anzeige auf Kunden-Detail-Seite wenn Kunde gesperrt/deaktiviert ist
• Passwort von zusätzlichen (virtuellen) FTP-Accounts wurde zurückgesetzt wenn nur das Startverzeichnis geändert wurde
• Lua: Fehler in LC.timeout()-Funktion behoben, wodurch z.B. Dienste manchmal zu früh aktualisiert (reloaded) wurden
• SOAP API: Berechtigungen wurden nicht aktualisiert wenn das Angebot eines Vertrags via HostingSubscriptionEdit() geändert wurde

wuhu! Danke!

Zitat von ensky

Nun zur Frage:
Gibt es eine Möglichkeit die mkdir und chown Befehle beim Erstellen des Vertrags zu automatisieren

Die von Herrn Keppler erstellte Funktion kann auch genutzt werden, um direkt in LUA neue Verzeichnisse etc zu erzeugen:

> http://www.liveconfig.com/de/h…pi.lua.reference.fs.xhtml