aber dami meinte ich ob es möglich ist Liveconfig auf einem bereits konfiguriertem server zu nutzen ohne die config zu verlieren
Nein.
Wie soll das gehen? Wie soll LiveConfig sich selbst konfigurieren, ohne die bisherige Config zu zerstören?
Neues System holen, LiveConfig auf den leeren Server installieren und die Daten vom alten System gezielt migrieren.
Für was?
Pakete installieren, danach LiveConfig.
Die tatsächliche Dienst-Konfiguration macht dann LiveConfig.
Vielen dank aber das ist mir bekannt. Die Fragestellung zielte darauf ab ob dokumentiert ist was sich hinter den Werten 0-8 jeweils für Einstellungen verbergen
https://www.liveconfig.com/de/…=9445&viewfull=1#post9445
kk: stimmt das noch so?
Hier ebenso.
Gut, hat sich ja Ende der Woche erledigt, da dann ja Zeitumstellung ist.
Schade, keine Antwort vom Entwickler dies bezüglich :eek:
Erinnere ich richtig, dass können auch in basic (extern bezogene) Zertifikate eingetragen werden können?
ja.
*10z*
Nimm Plesk. Da ist Let's Encrypt kostenfrei enthalten.
Oder nimm ISPConfig. Da kannst du die Unterstützung reinfriemeln.
Oder bau deine Konfigurationen manuell. Dann kannst du über dehydrated.sh die Zertifikate kostenlos bekommen.
Wenn es nur vier Domains sind: Comodo verkauft Zertifikate für 10€/Jahr. Das ist also günstiger als die 10€ für LE Standard.
Liegt in:
~/apps/$APPNAME/config/config.inc.php
Die Kunden haben keine Möglichkeit, die PHP-Einstellungen selbst zu bearbeiten.
Per GUI? Korrekt.
Per CLI? Falsch. Da greift grundsätzlich die globale, bis etwas angegeben wird.
Es gibt noch die Umgebungsvariable PHPRC. Aber sowas kann man ja auch wieder durchaus überschreiben.
Naja, liveconfig generiert ja "eigene" PHP inis (in den Webs) und bearbeitet ja nicht die globale.
/usr/bin/php -c /var/www/VERTRAG/conf/php5 /var/www/VERTRAG/htdocs/cron.phpTendenziell wollten die Kollegen LC so erweitern, dass Kunden mit individueller IP-Adresse auch am Mailserver mit genau dieser IP erreichbar sind. In diesem Stadium dürfte auch das Zertifikat genau/eindeutig diesem Mail-Host zuordenbar sein.
das setzt voraus, dass Webserver und Mailserver auf dem gleichen Host liegen. Ist das nicht der Fall, müsste logischerweise auf dem Mailserver erneut eine eigene IP aktiviert und verwaltet werden.
ZitatFür alle Webspace-Kunden, die die Zentrale Server-IP nutzen und auch mit ihren "Post-Subdomains" auf dieser IP auflaufen, würde ich eine Frage in den Raum stellen. Können die PEMs oder TLS-Dateien im Postfix eine Sammlung von Schlüsseln und Zertifikaten bedienen und verkraften?
Nö:
Zitat von http://www.postfix.org/TLS_README.htmlThere are no plans to implement SNI in the Postfix SMTP server.
ZitatPraktisch habe ich das noch nicht getestet. Auf die Schnelle spricht die Doku http://wiki.dovecot.org/SSL/DovecotConfiguration auch von diesen Varianten. Nur die Mail-Programme http://wiki.dovecot.org/SSL/SNIClientSupport werden nicht alle damit umgehen können.
Postfix != Dovecot, IMAP != SMTP.
Letztendlich: genau für diese Fälle wurde Autodiscovery/Autoconfig geschaffen.
Ein Client schickt eine Anfrage an eine zentrale Stelle und erhält dadurch die tatsächliche Server-Konfiguration zurück.
Ob da dann "server123.example.com" drinnen steht, oder "mail.example.com", kann dem Endkunden egal sein.
Microsoft macht es mit Office365 ja auch nicht anders.
So was die "mail.kundendomain.de" geht (vereinfacht gesagt) nicht.
*hust* SNI *hust*
aber ja, im Normalfall ist das natürlich nicht praktikabel.
ZitatEinzige Ausnahme wäre ein Multi-Domain-Zertifikat, das macht mit mehr als 3-4 Kunden dann aber auch keinen Spaß mehr. Zudem sähe da jeder Kunde die Domains der anderen Kunden mit im Zertifikat.
ZitatSauberste und gängige Lösung ("best practive"): das Ding "mail.anbietername.de" nennen und den Kunden eben diesen Namen mitteilen. Oder "server123.anbietername.de".
Gibt noch was sinnvolleres - aber das sprengt den Rahmen des Forums und ist mit einem Server auch nicht machbar.
Nochmal: solange dein Mailserver (IMAP/POP3/SMTP) nicht genau das Zertifikat verwendet, dessen Hostname du im Client konfigurierst, kannst du so viele Zertifkate holen, wie du willst: es bringt nichts.
ZitatIn die Serververwaltung komme ich nicht rein, ich hab nur nen VServer beim Hoster. Ich denke da sollte aber alles vom Hoster eingetragen sein.
Dann sag deinem Hoster, er soll das gewünschte Zertifikat beim Mailserver hinterlegen.
Falls da nicht eh schon ein Zertifikat hinterlegt ist: verwende doch einfach diesen Namen im Mailclient?
Nun dachte ich, dass man damit auch die Mailkonten absichern kann, doch hier funktioniert das nicht. Sind die LE-Zertifikate nicht für die eMailkonten nutzbar?
vs
ZitatDas Zertifikat wurde bereits erstellt:
- Domain: zertifikat.domain.de
- eMail: zertifikat@domain.de
Der Mailserver im DNS lautet: mail.kundendomain.de
Es muss das korrekte Zertifikat hinterlegt werden:
http://www.liveconfig.com/de/h…tml#tutorial.servers.mail
Zertifikats-Name (CN) sowie verwendeter Hostname für POP3/IMAP/SMTP im Mailclient müssen identisch sein.
Klappt 1a.
Domain -> E-Mail -> Auto-Konfiguration aktiv?
Ich hoffe nur das nicht alle so denken ...
Ich schon.
Nicht gepflegte Server werden schnell als Quelle für Spamversand, Angriffe gegen Dritte oder gar als Teil von DDoS-Attacken missbraucht.
Geübt wird lokal im LAN. Dafür gibt es Virtualbox, VMWare Player und Konsorten. Wer eigene Hardware dafür nutzt, kann auch VMWare Server ESXi oder Proxmox PVE verwenden, um sich ein virtuelles Netzwerk aufzubauen.
Ö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.
