Öffne ich allerdings die http über die 301 ist der Post öffentlich. Setze ich http auch auf Spiegelung wie die https. Hab ich das gleiche Problem wieder mit dem Login das ich wieder auf der Anmeldemaske lande.
- HTTP: 301-Redirect, Ziel: "https://liveconfig.example.com/*"
- HTTPS: Proxy, Ziel: "https://liveconfig.example.com:8443" (Domain entspricht dem CN des SSL-Zertifikates, das in der LiveConfig-SSL-Konfiguration verwendet wurde!)
kk: eventuell könnte man das in die FAQ aufnehmen?
Meine Vermutung: HTTP-Aufruf, obwohl das HTTPS-Only-Cookie gesetzt ist.
=> Alles über HTTPS (und Port 8443) laufen lassen. HTTP als 301-Redirect auf HTTPS laufen lassen.
ich wollte kurz das von mir getestete Setup in Sachen DNS-Replikation vorstellen. Das Problem ist ja, dass LiveConfig andere DNS-Server nicht über neue DNS-Zonen benachrichtigen kann. Daher müssen die Zonen immer erst vorher angelegt werden, was durchaus mühselig sein kann.
nö.
LiveConfig-Client dem Nameserver installieren und in den LC-Cluster einbinden. Läuft problemlos, so dass LiveCOnfig die Zonen dann auch auf den Slaves anlegt.
ZitatPowerDNS unterstützt den Superslave-Modus und ist damit in der Lage vom LiveConfig-BIND alle Zonen zu pullen und diese selbstständig anzulegen, zu löschen und zu updaten. Man kann die Replikations-Slaves also völlig unangetastet lassen nach der ersten Konfiguration.
Das Löschen halte ich - auch aus eigener Erfahrung - für ein Gerücht.
Ich darf aus der Doku zitieren:
Zitat von https://doc.powerdns.com/md/authoritative/modes-of-operation/Note: Removal of zones provisioned using the supermaster must be done on the slaves themselves. As there is no way to signal this removal from the master to the slave.
Inwieweit das praktikabel ist, muss jeder selbst entscheiden. Ich empfinde es als suboptimal, wenn ein Slave auch weiterhin auf eine Zone reagiert, die schon gelöscht ist.
[2016/09/28 11:01:05.075407] [1016|1016] UNCAUGHT DATABASE EXCEPTION: 'unable to open database file'
Welche SQLite-Datei wurde angegeben? Stimmen die Berechtigungen?
Warum wurde nicht auf MySQL migriert? 
Wenn man nun eine LiveConfig Standard Lizenz/Server benutzt mit Aktiven Kunden, ist es dann möglich nachträglich noch ein MultiServer Instanz zu erstellen?
ja.
Lizenz tauschen (Key löschen, neu registrieren), dann wird aus dem Standard-Server ein Business-Server.
ZitatWas passiert dann mit den Kunden die auf den Standard Server sich befinden?
nichts.
Es ist aktuell nicht möglich, aus einem LiveConfig Server (ob nun Basic, Standard oder Business) einen LiveConfig Client zu bauen.
Somit kann ein bestehender Server dann halt weitere Web/Mailserver verwalten. Die bestehenden Kunden können aber nicht verschoben werden (auch nicht "alles lokal" zu "hier Web/DB, dort Mail").
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.
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.
ZitatDanach bekomme ich leider immer wieder den Fehler 503.
Der Apache-Errorlog sagt dazu:
CodePermission 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.
ZitatVielleicht 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.
Ü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.
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/
ZitatVerstehe 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
ZitatWarum 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:
Kurioserweise funktioniert jetzt auch phpmyadmin nach der 4 Neuinstallation :confused:
Herzlich Willkommen in der Welt von DNS und Time To Live (TTL).
Wir machst Du das bisher?
Puppet (oder Ansible, je nach persönlicher Präferenz)
is possible to activate LDAP extension on php 7.0.11 version???
-sure:-
my bad. LDAP is core, not a PECL extension.
alterserver:~$ dpkg --get-selections > liste.txt;
alterserver:~$ scp liste.txt root@neuerserver:~;
neuerserver:~$ dpkg --set-selections < liste.txt;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.
Soweit mir bekannt ist verlangt Google aber einen korrekten SPF Eintrag?
wäre mir neu.
ZitatZu 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.
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.