Skip to content

Storage Box für den REST-Server

Restic
  • Ich nutze schon lange einen REST-Server zur Datensicherung. Dazu benutze ich auch schon länger eine Storage Box von Hetzner für die Speicherung der Datensicherungen. Bedingt durch eine Neuinstallation hatte ich ein paar Probleme, die etwas Zeit gekostet haben. Beim Mounten des DAV Laufwerkes kam immer eine kryptische Fehlermeldung, zu der ich auch nicht wirklich was gefunden habe.

    Installation

    apt install davfs2
    

    Danach legt man die Zugangsdaten unter

    nano /etc/davfs2/secrets
    

    ab. Beispiel

    https://<Benutzername>.your-storagebox.de <Benutzername> <Passwort>
    

    Jetzt muss man das noch unter /etc/fstab mounten. Aus der Hetzner Anleitung.

    https://<Benutzername>.your-storagebox.de /MOUNTPOINT davfs rw,uid=<Systemkonto>,gid=<Systemgruppe>,file_mode=0660,dir_mode=0770,_netdev 0 0
    

    Ich habe einen angelegten Benutzer, für den REST-Server, der soll auch das DAV Verzeichnis mounten.
    Das soll nötig sein, wenn man als User ein DAV Verzeichnis mounten möchte.

    chmod u+s /usr/sbin/mount.davfs
    usermod -a -G davfs2 <USER>
    

    Nun brauche ich noch die UID des Users, die bekommt man mit

    id -u <USER NAME>
    

    Bei mir war das Problem gewesen, das ich in meinem Eintrag die falsche UID gesetzt hatte, nach Korrektur klappte alles einwandfrei. Noch ein Problem gibt es. Wenn man den Server mit gemountetem DAV Laufwerk über die Konsole rebootet, mag er das nicht. Ich musste immer, virtuell, den Stecker ziehen. Wenn man vorher, das DAV Verzeichnis entfernt, dann geht es einwandfrei.

    umount /mnt/<MOUNT VERZEICHNIS>
    

    Quelle: https://docs.hetzner.com/de/robot/storage-box/access/access-webdav

  • Semaphore - Die API

    Verschoben Ansible
    2
    0 Stimmen
    2 Beiträge
    199 Aufrufe
    FrankMF
    Ich hasse schlecht lesbaren Code, scheint man sich bei Python so anzugewöhnen. Habe da nochmal was mit der langen Zeile getestet. stages: - deploy deploy: stage: deploy script: # $SEMAPHORE_API_TOKEN is stored in gitlab Settings/ CI/CD / Variables - >- curl -v XPOST -H 'Content-Type: application/json' -H 'Accept: application/json' -H "Authorization: Bearer $SEMAPHORE_API_TOKEN " -d '{"template_id": 2}' https://<DOMAIN>/api/project/2/tasks only: - master # Specify the branch to trigger the pipeline (adjust as needed) Hier noch was Dr. ChatGPT dazu schreibt [image: 1692643209159-631de9d4-b04d-4043-bfff-c5f2d1b6eea7-grafik.png] Erledigt - läuft Und verstanden habe ich es auch.
  • Semaphore - Installation & Anwendung

    Verschoben Ansible
    4
    +8
    0 Stimmen
    4 Beiträge
    1k Aufrufe
    FrankMF
    Ich parke das mal hier, damit ich das nicht noch mal vergesse. Hat mich eben mal wieder eine Stunde gekostet /etc/ansible/ansible.cfg [defaults] host_key_checking = False Edit -> https://linux-nerds.org/topic/1493/ansible-host_key_checking
  • Flatpak Paket zurückrollen

    Linux
    1
    0 Stimmen
    1 Beiträge
    67 Aufrufe
    Niemand hat geantwortet
  • RISC-V

    VisionFive 2
    1
    0 Stimmen
    1 Beiträge
    86 Aufrufe
    Niemand hat geantwortet
  • Debian Bullseye - ZFS installieren und Pool erstellen

    Linux
    1
    +0
    0 Stimmen
    1 Beiträge
    1k Aufrufe
    Niemand hat geantwortet
  • Kopia 0.7.0-rc1 Kurztest

    Kopia
    2
    +1
    0 Stimmen
    2 Beiträge
    331 Aufrufe
    FrankMF
    Nachdem ich doch ziemlich lange Snapshot Zeiten hatte, habe ich Jarek mal gefragt woran das liegt. I guess you could run it in the cloud but latency will be progressively worse because it's a chatty protocol sensitive to latency Technisch verstehe ich das nicht, aber ich habe dann mal als kurzen Test auf meine lokale SSD einen Snapshot gemacht. Der war nach 2 Minuten (ca. 11GB) fertig. Der zweite Snapshot brauchte ca. 12 Sekunden. Das hört sich schon mal viel besser an, als die Stunden. Aktuell ist der Plan den Kopia-Server im Internet zu nutzen damit beerdigt. Das scheint so nicht zu funktionieren. Ich mache da noch einen kurzen Test, diesmal Lokal auf meinem NAS.
  • ClusterSSH

    Angeheftet Linux
    4
    +0
    0 Stimmen
    4 Beiträge
    896 Aufrufe
    FrankMF
    Mal wieder lange dran rumgefummelt, bis es passte. I have figured out how to use any font in xterm. So for the case of the mentioned Inconsolata font size 14, the following works: Add these 2 lines into ~/.Xresources (create it if it does not exist) XTermfaceName: Inconsolata XTermfaceSize: 14 Then, tell xterm to use this file: export XENVIRONMENT="${HOME}/.Xresources" Preferably add this export into .bashrc, so that it is persistent. comment out the font settings in ~/.clusterssh/config, if it exists: # terminal_font=6x13 Quelle: https://unix.stackexchange.com/questions/230106/cluster-ssh-specify-terminal-font
  • Upgrade auf NodeBB 1.11.0

    NodeBB
    1
    +0
    0 Stimmen
    1 Beiträge
    387 Aufrufe
    Niemand hat geantwortet