Beiträge von bash

Hey,

gibt es bekannte Probleme oder etwas worauf man achten sollte wenn man von Debian 9.9 auf Debian 10 Upgraden möchte?

Wird ja dann doch langsam mal Zeit da manche Standart Pakete ja dann doch etwas veraltet sind. (Standart PHP7.0 und MariaDB 10.1 usw)

Wäre ja mal cool wenn langsam mal ein Backup oder Transfersystem kommt das man auch Kunden einzeln oder das komplette System auf einen neuen Server schieben könnte mit allem drum und dran.

Ja ok, das dachte ich mir bereits.

Hilft mir aber nicht immer weiter da ich zwei-drei Kunden habe dir mir quasi von ihren eigenen Servern Mails Senden und ich da halt gerne mal drauf warten darf.. xD
(Diese sind nicht in solchen Listen enthalten)

Wird mal Zeit für eigene White/Blacklisten..

Hey...

Mal eine Frage bzgl. der DNS-Whitelists funktion in LC.
Muss man hier einen Server angeben oder legt LC hier dann selber eine Liste der genannten an? Oder muss man hier einen Server für Eintragen? Werd aus der Sache nicht ganz so schlau aus dem Handbuch... :confused:

Hab das Problem eigentlich eher bei den bekannten immer das es dann erstmal paar min dauert durch Greylisting und das würd ich gerne bisschen umgehen.

Zitat von aziegler

Vielleicht ist das das "Problem" bei dir...

Weniger, weil selbst wenn ich diese IP einem Unbenutzen Reseller oder generell einem Reseller zuweise dann setzt der diese Einträge nicht.
Erst wenn ich eine IP-Gruppe als gemeinsam setze dann trägt er das mit dieser IP ein für default SSL. (Aber auch NUR mit dieser IP und nicht mit den anderen IP-Gruppen)

Normal müsste er aber doch generell für alle IPs auf dem Server diesen VirtualHost setzen für SSL damit quasi alle ein default vom Server nutzen falls kein SSL für eine bestimmte Domain angelegt wäre.

Denke aber das können nur die Entwickler uns beantworten..

Habs jedenfalls jetzt erstmal so das ich die Einträge manuell in die 000-default Conf geschrieben habe mit allen IPs die auf dem Server geschaltet und genutzt werden für die Reseller.

<IfModule mod_ssl.c>
<VirtualHost 192.XX.XX.1:443 192.XX.XX.2:443 192.XX.XX.3:443 [ipv6....1]:443 [ipv6....2]:443>


    ServerName default
    DocumentRoot "/usr/share/liveconfig/html/"


    SSLEngine On
    SSLCertificateFile /etc/ssl/certs/httpd-default.crt
    SSLCertificateKeyFile /etc/ssl/private/httpd-default.key
    SSLCertificateChainFile /etc/ssl/certs/httpd-default-ca.crt
    <Directory "/usr/share/liveconfig/html/">
        <IfModule mod_include.c>
            ErrorDocument 404 /not-available-ssl.shtml
            <IfModule !mod_rewrite.c>
                DirectoryIndex not-available-ssl.shtml
            </IfModule>
        </IfModule>
        <IfModule !mod_include.c>
            ErrorDocument 404 /not-available-ssl.html
            <IfModule !mod_rewrite.c>
                DirectoryIndex not-available-ssl.html
            </IfModule>
        </IfModule>
    </Directory>
</VirtualHost>
</IfModule>

damit geht dann auch alles wie gewohnt bei allen Reseller-Kunden die keine SSL Domain haben..

Ok, das Zertifikat konnte man nun wieder anlegen wenn man die default IP einmal auf Typ; exklusiv und dann wieder auf gemeinsam stellt. Allerdings lößt das mein Problem selber nicht da alle IP Gruppen bei mir auf exklusiv stehen damit jeder Reseller nur seine eigene IP nutzt.

Ok hab zumindest eine vorzeitige Lösung gefunden. Nachdem ich mal ein Testsystem Installiert hab und mal alle configs verglichen habe. Mir viel dann auf das dort etwas fehlt.
In der neuen Test Installation hat er mir dann auch ein Default Zertifikat angelegt welches man auch nicht löschen kann. Das gab es aber ganz früher wohl nicht und deswegen hatte er auch keines angelegt wohl?

In der 000-default.conf Datei fehlen somit folgende Einträge

<IfModule mod_ssl.c>
<VirtualHost 192.XX.XX.XX:443 [XXXX:XXX:XXXX:XXXX:XXX:XXXX:XXXX:XXXX]:443>


    ServerName default
    DocumentRoot "/usr/share/liveconfig/html/"


    SSLEngine On
    SSLCertificateFile /etc/ssl/certs/httpd-default.crt
    SSLCertificateKeyFile /etc/ssl/private/httpd-default.key
    SSLCertificateChainFile /etc/ssl/certs/httpd-default-ca.crt
    <Directory "/usr/share/liveconfig/html/">
        <IfModule mod_include.c>
            ErrorDocument 404 /not-available-ssl.shtml
            <IfModule !mod_rewrite.c>
                DirectoryIndex not-available-ssl.shtml
            </IfModule>
        </IfModule>
        <IfModule !mod_include.c>
            ErrorDocument 404 /not-available-ssl.html
            <IfModule !mod_rewrite.c>
                DirectoryIndex not-available-ssl.html
            </IfModule>
        </IfModule>
    </Directory>
</VirtualHost>
</IfModule>

Kann ich zwar jetzt manuell hinzufügen, aber bei der kleinsten änderung in Liveconfig an den IPs oder sowas dann ändert er mir das und haut diese wieder raus...

Gibt es dafür irgendwie ne Lösung seitens LC? :confused:

Update: Hab den Grund dafür gefunden warum er keines Angelegt hat oder er diese Codezeilen oben nicht benutzt.
Habe meine Reseller die IP-Gruppen so zugewiesen das diese auf Typ; exklusiv stehen so das jeder Reseller seine eigene IP mit seinen Kunden benutzt. (Selbst die default IP habe ich auf exklusiv aber ohne Kunden/Reseller Zuweisung, damit keiner diese IP nutzen kann) Die einzelnen Kunden der jeweiligen Reseller nutzen die IP gemeinsam die ich dem jeweiligen Reseller zugewiesen habe, es hat also kein Endkunde eine IP nur für sich!

Nun die Frage, kann man das irgendwie dann lösen? Oder ist das absicht das er das dann nicht anlegt? Er müsste normal ja den Code oben für alle Reseller/exklusiv IPs auch anlegen so wie als wenn es als gemeinsamme IP wäre?

Ja also das mit "apache2ctl -S" klappte... es scheint kein default Eintrag für :443 zu geben
einzig alleine sind paar Kunden Domains die so eingetragen sind...

Zum Default Certificate das gabs bei meiner Liveconfig Version ursprünglich garnicht. Hatte das bei dem Server mal manuell hinzugefügt nachdem ich gesehen hatte das es bei dem Test-Server mit ner frischen Installation drin war.
Kann man das irgendwie neu anlegen lassen?

Ja gut... keine Pflicht wenn eine Seite ohne Logins/Downloads (selbst Bilder) Newsletter Anmeldung.. Gästebücher usw.
Sobald man eines auch davon nur nutzt muss das mit SSL laufen. (Und die wenigsten haben das im Überblick. Im Privaten Bereich!) Wäre doch dann sinnvoller das direkt mit SSL als Standart zu machen und per Ausnahme nur HTTP nur noch zu erlauben oder?

Hier nochmal auch zum aktuellen Thema mein Problem.

https://www.liveconfig.com/de/…tto-wegen-SSL-Zertifikate

wäre schön wenn es dafür ne Lösung gibt.

Müsste laut DSGVO es sowieso nicht so sein das es KEINE normalen HTTP Seiten mehr geben darf? Weil ab 25. Mai herrscht doch SSL Pflicht...?

4 IPv4 - 4 IPv6

Jeweils jeder Reseller Account hat seine eigenen IPs jeweils eine von jedem IPv4/6

Das Default Certifikat gab es anfangs nichtmal. Das war erst nach dem späteren Neu installieren auf einem neuen Server dort.
Hab aber irgendwie das Gefühl das er das total ignoriert. (Die Resellerdaten usw sind per Backup zurück gespielt worden nach der Anleitung hier im Forum)

Hey hab mal eine Frage.

Ist das normal das wenn man Domain xy.de ohne Webspace oder gar SSL Zertifikat angelegt hat das wenn man dann die Domain als https://xy.de aufruft das er dann eine X beliebige andere Domain aa.de nutzt wo ein SSL Zertifikat genutzt wird dann diese anzeigt?

Hab das Problem bei allen Domains die bspw keinen Webinhalt haben oder für sowas halt nicht genutzt werden. (Bspw. weils reine Email Domains sind!)

Zu dem Verständnis, habe 3 Domains bspw bei einem Account:
domain1.de ohne Webspace/SSL
domain2.de mit Webspace & SSL Zertifikat
domain3.de ohne Webspace/SSL

gehe ich jetzt her und ein "fremder" gibt die Domain: domain1.de mit https:// davor an dann landet der bei domain2.de wo ein SSL Zertifikat ja genutzt wird.

Sollte ja so nicht gewollt sein oder? Frage ob das nur bei mir so ist und wo da der Fehler ist oder ob das ein generelles Liveconfig Problem/Bug ist?

mfg
bash

Zitat von cr

Mit welchem Client machen Sie denn diese URL Aktualisierung? Viele Clients können mit URLs nach dem folgenden Format umgehen (inkl wget & curl).

Code

http(s)://<username>:<password>@<hostname>/pfad/zum/dynDNS...

sogar ein simples php file_get_contents() erkennt das und macht einen "Authorization: Basic"-Header draus

Die Geräte selber haben keinen Dyndns nur ich könnte dann via crontab diese URL immer wieder mal aufrufen lassen und dann müsste er ja die IPv6 damit abändern..
Das muss ich die Tage dann echt mal probieren ob das geht bei den Geräten...

Zitat von antondollmaier

Subdomain anlegen, die keinen IPv4-Record, sondern nur einen AAAA-Record aufweist. Dann kann nur IPv6 verwendet werden.

Auszug aus dem LiveConfig-Handbuch:

Hilft das?

(nicht selbst getestet, sorry)

Alles anzeigen

Ja soweit würde dieses gehen ja.. aber dann hab ich immer noch das Problem weil ich hier Geräte im Einsatz habe wo ich das nicht auswählen lassen kann ob IPv4 oder IPv6 (das Gerät nimmt automatisch die IPv4) und dann widerrum auch zwei Geräte die keinen Dyndns Client besitzen (sind normalerweise dafür nicht vorgesehen) diese kann ich dann nur via URL quasi ins Netz nach außen bringen. Dazu müsste ich dann per URL den Benutzernamen und Passwort mit angeben können was aber eben leider noch nicht funktioniert..

Klingt doof, aber bin wohl einer der wenigen der solch Geräte oder konstellationen betreibt..

Aber wie gesagt, Problem is mittleerweile erstmal gelößt. Hab mein altes DNS Interface auf den Code für php7 gebracht und das läuft nun wieder.

Zitat von kk

Was genau?
IPv4 und IPv6 Updates funktionieren über die dokumentierte Update-Methode (soweit wir das beurteilen können) einwandfrei. Vielen Kunden nutzen das, und auch wir selber - und zwar ohne Probleme.
DynDNS mit IPv6 ist insgesamt etwas "tricky", das liegt aber weniger am DynDNS als viel mehr an den Eigenschaften von IPv6 (dass sich also alle Geräteadressen im LAN ändern wenn sich der IPv6-Präfix z.B. nach DSL-Zwangstrennung ändert).

Ja und da genau is mein Problem mit IPv6.. da mein naja sagen wir mal so Internet Provider ja schönes DS-Lite verwendet kann ich bei vielen Geräten nur per URL die IP-Updaten und da hab ich bisher noch keine schöne Lösung hinbekommen. Weil er da nämlich dann zu 99% die IPv4 verwendet die ja bei mir nach "innen" nicht funktioniert... :-/

Demnach wäre ein direkter URL-Update aufruf von nöten, was aber dann daran scheitert derzeit wegen der Benutzerdaten... so müsste das nämlich dann irgendwie klappen.. http://server.tld/dyn/dyn.php?…HIMMER&password=IRGENDWAS und als Absender müsste er automatisch dort "nur" die IPv6 nehmen statt die IPv4..

Zitat von antondollmaier

Öhm.

- für das DynDNS-Feature benötigt LiveConfig Zugriff auf die Nameserver.
- davon benötigt man immer mindestens zwei.

Das Argument "DynDNS kostet 20€/Monat mehr!" ist somit hinfällig: nicht DynDNS kostet mehr, sondern die Verwaltung von zwei Nameservern durch LiveConfig.

Kannst natürlich auch nur einen Nameserver durch LC verwalten lassen und einen externen Secondary hinterlegen, wenn sich da ein Secondary-Dienst findet.

Alles anzeigen

Ja das der Dienst Dyndns nicht nur die 20 Euro kostet ist logisch. Meinte aber alles in allem wären dann ca 20 Euro Mehrkosten durch die Business Version. (Und das dann in meinem Fall nur wegen der DNS sache)...

Problem mit dem Secondary wäre das kleinere Übel abgesehen von der manuellen Eintragung der Domains einmalig... für mich ist eher der Dienst mit Dyndns noch nicht gescheit gelöst. Bin da aber immer wieder mal am testen mit ner TestInstall....

Naja es gibt beim Dyndns bei mir schon Probleme mit dem ipv6 weil das Script nicht wahlweise arbeitet ob ich ipv4 oder ipv6 erkennen will/kann. Er Updatet quasi immer ipv4 dann Dyndns meines QNAP will nur mit bastel Scripts usw... gibt da leider noch so einige Punkte...

Und was mich dazu dann noch am meisten Stört is eben das ich für eine "kleine" funktionserweiterung direkt mal 20 Euro mehr bezahlen muss und das jeden Monat.. (nutz nur einen Server)... alles im allen also derzeit etwas bescheiden... wäre cool gewesen wenn das ganze etwas einfacher gegangen wäre...

Installierte Version: 2.5.3 (r4805)
Verfügbare Version: 2.6.0-r4805

Ist das so gewollt? xD

Ja merci habs dann mal getestet, aber irgendwie funktioniert das ganze noch sehr suboptimal.. xD

Musste mich dann mal hinsetzen und hab mit dem Kollegen mein altes Interface auf php7 gepatcht, dort geht auch in allem meine dyndns funktion..

Kleinen Fehler in der Versionabfrage?

LiveConfig-Version: 2.5.3 (r4805) (aktuell)
Neueste Version: 2.5.2-r4777
letzte Prüfung: 28.01.2018 02:13:27 CET

sollte so ja denke mal nicht sein oder?

Im Admin unter LiveConfig Status...

Ja wäre Interessant zu wissen.. Man kann zwar das Zertifikat manuell wieder hinzufügen wenn man sich die Daten vorher mal gesichert hat allerdings wird das nicht für Kunden zur auswahl gegeben so wie es normalerweise ist...

Dazu muss man auch noch sagen jene welche schon länger Liveconfig nutzen hatten diese funktion erst garnicht? Hab das nur durch zufall auch gesehen als ich einen Testserver neu Installiert hatte...

Hab nämlich öfters das Problem das wenn User irgendwelche Seiten öffnen mit https://sub.irgendwas obwohl es diese gar nicht gibt bspw dann nimmt der gerne mal ein Zertifikat von irgendeiner Domain die zufällig nen Zertifikat besitzt.. (is etwas unschön!)

Gemeint is dieses (Dies ist das Standard SSL-Zertifikat für den Webserver (Apache/NGINX). Dieses Zertifikat wird standardmäßig an allen HTTPS-Schnittstellen mit gemeinsamen IPs verwendet (SNI - Server Name Indication).)