Beiträge von Berichtigung

    Ebenso schlicht: Die, die du nicht brauchst.

    Und wenn du das nicht weißt, können das nicht einmal die Götter wissen.


    Programme erstellen sich bei der Installation und/oder beim ersten Aufruf im Home des jeweiligen Users ihre Konfig- Dateien, oder eben nicht. Und bearbeiten sie bei allen Folgeaufrufen, oder eben nicht.

    Das hängt alleine von dem Programm selbst ab.


    Zwar mögen NSA und BKA wissen, welche Programme du tatsächlich verwendest, aber die Götter sicher nicht.

    Wie sollte ich dir da helfen können?

    Ganz nach Gusto.

    Manche Programme halten ihre Konfigdateien im Home in Unterverzeichnissen, manche verwenden nur eine Datei

    Der Editor vi zum Beispiel verwendet unter anderen eine .vimrc Konfigdatei im Home des Users, aber dort auch ein Unterverzeichnis .vim (Dort finden sich Plugins und diverse (third-party) Funktionen.

    Man kopiert nach /etc/skel also die .vimrc selbst und das Pluginverzeichnis .vim


    Es ist wirklich so schlicht:

    ALLES, was in /etc/skel liegt (egal wie tief die Verzeichnisse dort geschachtelt sind), wird beim Erstellen eines neuen Users einfach in das neue Home kopiert (und natürlich Owner auf den neuen User gesetzt).

    Wie derwunner schon schrieb, werden Certs von Letsencrypt nur für Domains vergeben, die auch via DNS erreichbar sind/existieren.


    Deine Domain ist rein lokal. Dafür gibt es keine direkten SSL/TLS Zertifikate.


    Du hast zwei Möglichkeiten:

    1. Du arbeitest mit selbsterstellten Zertifikaten.
      Was den Nachteil hat, dass der Aufruf einer damit HTTPS- verschlüsselten Website bei jedem Browser zu einer Sicherheitswarnung führt, wo man erst dieses Zertifikat einmal für rechtens erklären muss.
    2. Du besorgst dir ein sogenanntes DynDNS Domainlabel, und erstellst via deren Domain ein Letsencrypt Zertifikat.
      Der deutsche Verein DeSEC.io bietet kostenlos solche Domainlabels, für die auch Letsencrypt Zerts möglich sind.
      Guckst du https://desec.io
      Damit kriegst du ein gültiges Zertifikat für <deinLabel>.dedyn.io , das von jedem Browser aktzeptiert wird.

    Ein selbstsigniertes Zert (, das dann jeder Browser anmault), kannst du dir mit diesem kleine Script erzeugen:

    (Kopiere dir das Script nach /usr/local/bin und mache es ausführbar)

    Bash
    #!/bin/bash
    years=${1:-3}
    valid_days=$((365 * years))
    name=${name:-$1}
    mkcert(){
    openssl req -x509 -nodes -newkey rsa:4096 -keyout ${name}_key.pem -out ${name}_cert.pem -days $valid_days
    }
    mkcert $*

    Der Aufruf ist dann einfach:

    scriptname localdomainlabel.local.site 2

    für ein zwei Jahre gültiges Zertifikat.

    (Lässt du die Anzahl der Jahre weg, ist der Default 3

    Lässt du auch noch das Domainlabel weg, so wird der Name des Scripts selbst im Cert verwendet (was meist nicht viel Sinn machen dürfte)


    Es genügt auch einfach nur die openssl Zeile auszuführen.


    Und klar: Das Plugin muss installiert sein, und der Webserver laufen, wenn du richtige Zerts mit einem DynDNS Provider erzeugen möchtest.

    Der Sender wird von der PTB betrieben.
    Und selbstverständlich sind Laufzeiten von der tatsächlichen Zeitquelle bis zum Sender eingerechnet.
    Er IST die Primärquelle.


    Du kannst selbstverständlich die Stratumsquelle ändern.
    Nur halt nicht mit YaST.


    Wurstel dich einfach in der Konsole durch systemd-time[b]sync[/b]d.service und Konsorten. chrony nicht vergessen.

    Für Deutschland ist die PhysikalischTechnischeBundesanstalt in Braunschweig zuständig. Das ist richtig.


    Sie ist die Referenz. Und sie senden ein DCF-77 (Langwellen-) Signal, anhand dessen viele NTP- Server ihre Uhren an genau dieser Referenzzeit ausrichten.


    Eine solche Hardware- DCF Uhr kannst du für lau kaufen und an deine Kiste hängen.
    Dann hättest du auch einen Stratum 1 NTP-Server.
    (Wobei du in diesen erlauchten Kreis nur aufgenommen wirst, wenn du bestimmte Kriterien an Ausfallsicherheit, bla, bla, bla ebenfalls erfüllst)

    @Alero Probiere doch mal einfach selbst aus, das Packman Repo auf die GLEICHE Prio, wie die offiziellen Update - Repos zu stellen.


    Dann machst du ein zypper dup --from <packman>.
    Beobachte dann, wenn du gemütlich deine zypper ups machst, ob sich etwas ändert.
    Wirst sehen, deine Theorie ist nicht haltbar.


    Wir reden hier von Leap* - nicht von Tumbleweed.


    Es wäre schön, wenn alle Moderatoren hier einen guten Plan von zypper hätten, wenn sie dabei helfen möchten.
    Dass man Anfängern das Vorgehen mit der Priorisierung an's Herz legt, hat schlicht den Grund, bei ihnen Fehler möglichst auszuschliessen.
    Es ist kein Gesetz. man zypper rules!
    Es gibt tatsächlich Leute, die damit souverän umgehen können.
    Es sind eben niemals alle gleich.

    @Sauerland hat recht. Ein systemd Servicefile hilft da. Oder ein Timerfile.
    Mit sysctl kannst du das nur sehr umständlich lösen.


    Schreibe dir ein Script, das deinen Restart- Befehl ausführt.
    Du MUSST Ein- und Ausgabe abfangen (oder nach /dev/null schicken).


    Dann erstelle dir ein Servicefile für dein Script.
    Ungefähr sowas:


    Bash
    [Unit]Description=My Restart Job
    After=Default.target
    [Service]
    Exec=/absoluter/Pfad/zu/My_Restart_Job.scriptfile
    [Install]
    WantedBy multiuser.target

    Das ist das absolute Minimum. Kannst es auch korrekt schreiben. Lies dazu man 5 systemd.service


    Das Servicefile legst du nach /etc/systemd/system und kannst dann danach mit systemctl enable My_Restart_Job.service einschalten.


    Und rein aus Interesse: Warum willst du das überhaupt? Was bezweckst du damit?