Beiträge von KB19

  • Das längste Thema

    Danke für die Tipps. Ich bin übrigens lieber den Weg über --init-file gegangen. Ich weiß noch immer nicht, wie ich mich ausgesperrt habe. Ich habe mich mit der frischen phpMyAdmin Installation blöd bei den Benutzerrechten rumgespielt und plötzlich konnte ich mich über phpMyAdmin und über CLI nicht mehr einloggen. Shit happens! :)

  • Suche deutsche Anleitung für Munin um einen entfernten Server zu überwachen.

    (Getestet unter Debian, bei anderen Distributionen müssen die Pfade eventuell angepasst werden!)

    Benötigte Pakete installieren:

    Bash
    # am Munin Node
apt install munin-node

# am Munin Master
apt install munin munin-node

    Am Munin Master den zu überwachenden externen Server über seinen Hostnamen (FQDN) hinzufügen:

    Code: /etc/munin/munin.conf
    [servername.example.net]
address servername.example.net

    Am Munin-Node die IP-Adressen vom Master Server freischalten:

    Code: /etc/munin/munin-node.conf
    allow ^2001:db8::dead:affe$
allow ^10\.1\.2\.3$

    Und einmal schnell service munin-node restart am Node eintippen. Fertig! Normalerweise sollte es jetzt laufen. Bei Bedarf kurz die Logdateien beobachten:

    Bash
    # am Munin Node
tail -F /var/log/munin/munin-node.log

# am Munin Master
tail -F /var/log/munin/munin-update.log

    Wenn das quer übers Internet ohne vLAN/VPN/usw. laufen soll, würde ich allerdings dringendst TLS empfehlen: http://guide.munin-monitoring.org/en/latest/advanced/tls-setup.html

    Falls Du eine Firewall verwendest, muss Port 4949 am Munin Node natürlich für den anderen Server freigegeben werden.

  • Das längste Thema

    Jetzt kann ich das auch endlich von der Liste streichen:

    • Sich zum ersten Mal im Leben als »root« in MySQL/MariaDB aussperren ✔

    Ich glaube, ich gehe lieber ins Bett. Das endet heute nicht mehr gut, wenn ich so weiter mache… ^^

  • Email authentifizieren

    Ah, das ergibt langsam Sinn! :)

    Dann könnte es nämlich sein, dass die Google Server teilweise noch die alten DNS-Informationen gespeichert haben. In diesem Fall kann es 24-48 Stunden dauern, bis alles wieder einwandfrei erkannt wird. Da Google Tausende verschiedene Server in vielen verteilten Rechenzentren hat, kann es durchaus passieren, dass Du den Fehler noch siehst, ich mittlerweile aber nicht mehr.

    Insofern bleibt mein Tipp: Abwarten und notfalls noch einmal im Forum melden. Wichtig ist nur, dass Du es in den nächsten Tagen mit neuen Testmails ausprobierst! Die alten Nachrichten werden den "nicht authentifiziert" Status nämlich unverändert beibehalten.

  • Email authentifizieren

    Eventuell war es nur ein temporäres Problem bei Google. Die Domain ist wahrscheinlich noch relativ jung und wurde erst vor wenigen Tagen registriert? Da können DNS-Einträge schon mal bis zu 48 Stunden brauchen, bis sie weltweit bekannt sind. Wenn dann falsche bzw. fehlende Daten im Zwischenspeicher eines DNS-Servers landen, vergehen gerne nochmals 24-48 Stunden, bis alles einwandfrei klappt.

    Da ich es bei meinem Googlemail Account aktuell nicht nachvollziehen kann, würde ich Dir empfehlen nochmals 24-48 Stunden zu warten. Sollte die Meldung bei neu versendeten Mails danach noch immer auftauchen, melde Dich bitte nochmals! :)

  • Email authentifizieren

    Laut den Supportseiten von Google gilt als "nicht authentifiziert" jede E-Mail, die kein SPF und DKIM verwendet. Letzteres ist beim Webhosting derzeit aber noch nicht möglich. Einen SPF-Eintrag sollte allerdings jede Domain bei netcup haben.

    Kannst Du im CCP einmal nachschauen, was bei Deiner Domain unter DNS alles eingetragen ist? Relevant sind vor allem die TXT-Einträge. Du findest im Wiki weitere Informationen, wie Du dort hin kommst: https://www.netcup-wiki.de/wiki/Domains_CCP#DNS

    Alternativ kannst Du mir auch gerne den Domainnamen einmal per PN senden oder gleich eine Testmail an meine Googlemail Adresse. Bei Bedarf einfach mittels Konversation melden: https://forum.netcup.de/system/conversation-add/?userID=597

  • Das längste Thema

    Zitat von joergmschulz

    phpmyadmin - Erleuchtete, erleuchtet mich: wo hat Debian ein Problem? Welche Alternativen schlagt Ihr vor?

    z.B. dass es seit Ewigkeiten keinen Upload mehr gab. Es braucht einen neuen aktiven Maintainer des Pakets. Alternative: Selber installieren.

    Das war bei Roundcube vor einigen Jahren bei Debian Jessie auch schon mal so. Mittlerweile gibt es wieder Roundcube Pakete in Debian.

    Zitat von Kraeutergarten

    Wusstet ihr das man bei nginx im server_name einen regex (mit Variable) verwenden kann?

    Jep, das ist extrem nützlich! :) Nutze ich z.B. für einen Weiterleitungs-vHost:

    Code
    server_name ~^(?<sub>.+\.)?example\.net$;
return 301 "https://${sub}example.net$request_uri";

    (Könnte man noch auf die erlaubten Zeichen im Hostnamen einschränken, aber so erfüllt es bisher auch den Zweck.)

  • Das längste Thema

    Es läuft! :love:

    OpenSSL 1.1.1 setzt unter Debian bekanntlich MinProtocol = TLSv1.2 in der /etc/ssl/openssl.cnf. Da die älteren Clients aber ausschließlich TLSv1.1 (oder gar nur TLSv1) unterstützen, schlägt der Verbindungsaufbau somit fehl. Durch eine Verkettung von anderen (selbst verursachten) Fehlern zeigte das Erlauben von TLSv1.1 in der Vergangenheit keine Wirkung. Das war nämlich meine allererste Vermutung.

  • Server verrät nginx vhosts

    Diese Dienste betreiben normalerweise eine eigene Datenbank mit Zuordnungen von Domains und IP-Adresse. Diese Informationen sind über eine einfache DNS-Anfrage (A/AAAA Records) zu ermitteln, wenn man genügend Domains zum Testen und ausreichend Ressourcen sowie Zeit hat. Das kannst Du bei öffentlichen Webseiten nicht verhindern, außer Du spendierst jedem vHost eine eigene IP-Adresse, was bei IPv4 im Jahr 2019 unrealistisch ist.

    Du kannst solchen Diensten aber die Arbeit erschweren, indem bei SSL-Zertifikaten als SAN nicht unnötig viele Subdomains genannt werden. Damit vermeidest Du wenigstens, dass keine Hostnamen auftauchen, die zwar öffentlich erreichbar, aber nirgends verlinkt bzw. indexiert sind.

  • Das längste Thema

    Mittlerweile bin ich weiter gekommen: PHP mittels PDO klappt durch diverse Änderungen, der MariaDB 10.1 Client (und damit die Replikation) weigert sich aber noch immer eine Verbindung aufzubauen…

    Code
    ERROR 2026 (HY000): SSL connection error: unknown error number

    Allerdings habe ich zum Test nochmals den aktuellen MariaDB 10.3 Client in einer VM angeworfen, und siehe da: Die Verbindung kann endlich aufgebaut werden! :love:

    Bleibt die Frage, warum keine älteren Versionen mehr verbinden können? Das ist ja irgendwie nicht Sinn der Sache und kann in produktiven Umgebungen fatale Konsequenzen haben. Ich werde nochmals weiter testen und gegebenenfalls einen Bugreport bei Debian einreichen. Oder wenigstens einmal auf der Mailingliste nachfragen, ob jemand eine Idee dazu hat.

    Zitat von eripek

    Hast Du das Letsencrypt-Cert cert.pem oder fullchain.pem genommen?

    Ich verwende eine eigene CA für interne Dienste. (Let's Encrypt unterstützt afaik gar keine Clientzertifikate.)

  • Das längste Thema

    Zitat von killerbees19

    Gestern bin ich erstmals nach zig Jahren an der SSL-Konfiguration von MariaDB verzweifelt. Ich betreibe diverse MySQL/MariaDB Systeme mit SSL und eigener CA. Aber bei dieser Installation habe ich es nicht zum Laufen gebracht… :cursing:

    Frage in die Runde: Verwendet hier irgendjemand MariaDB 10.3 inkl. SSL? Das Ding will nicht. Egal ob ich mit MySQL 5.7, MariaDB 10.1 oder MariaDB 10.3 Clients verbinden möchte, es klappt nicht.

    Eigentlich schätze ich mich schon so ein, dass ich SSL bei MySQL/MariaDB richtig konfigurieren kann. Das habe ich schon sehr oft gemacht, aber noch nie bei MariaDB Version 10.3. Entweder übersehe ich hier eine kürzliche Änderung oder das Ding hat einen Bug… X/

  • langsamer Start - A start job is running for dev-sda1.device

    Weil es gerade dazu passt: Ich lief gestern in ein ähnliches Problem. Der Systemstart dauerte immer 30-60 Sekunden, weil er auf die nicht mehr existente Swap-Partition für ein "Resume" wartete. Die hatte ich zuvor aber gelöscht, da ich sie doch nicht brauche.

    Die Lösung unter Debian (10): Einfach mal einen Blick in die Datei /etc/initramfs-tools/conf.d/resume werfen. Siehe: https://lists.debian.org/debian-user/2017/09/msg00866.html

  • Das längste Thema

    Gestern bin ich erstmals nach zig Jahren an der SSL-Konfiguration von MariaDB verzweifelt. Ich betreibe diverse MySQL/MariaDB Systeme mit SSL und eigener CA. Aber bei dieser Installation habe ich es nicht zum Laufen gebracht… :cursing:

    Die Kurzversion: MariaDB 10.3 unter Debian 10 Buster, SSL erfolgreich wie immer eingerichtet, angeblich alles aktiv. Trotzdem können zwei verschiedene Clients (MariaDB 10.1 aus Debian Stable & Testing) nicht verbinden. Das Beste daran, eine nichtssagende Fehlermeldung: ERROR 2026 (HY000): SSL connection error: unknown error number

    Keine Fehlermeldungen im Log. Der OpenSSL-Testclient meldet keine Fehler beim Verbindungsversuch. Ich habe so ziemlich alles ausprobiert, was man testen kann. Ich weiß echt nicht mehr, wie ich das weiter eingrenzen soll. Auffällig ist nur, dass sich beim MySQL Paket irgendwas mit YaSSL/OpenSSL geändert hat. Und natürlich, dass bereits OpenSSL 1.1.1a aktiv ist.

    Irgendwelche kreativen Ideen? ?(