Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Linux
  3. Archiv
  4. Kopia
  5. Kopia - Administrative Aufgaben

Kopia - Administrative Aufgaben

Kopia
  • FrankMF

    Es gibt ja für Kopia ganz viele Konsolen Befehle, wenn man nun von entfernt auf den Kopia-Server zugreift, kann man viele davon nicht ausführen! Nehmen wir dieses Beispiel.

     kopia maintenance info

    Um diesen Befehl abzusetzen, muss mal als der User eingeloggt sein, dem das Repository gehört. Beispiel, das Repo gehört dem KOPIA-USER. Dann kann auch NUR dieser den Befehl absetzen.

    Eingeloggt als KOPIA_USER

     $ kopia maintenance info
 Owner: USER@DOMAIN
 Quick Cycle:
   scheduled: true
   interval: 1h0m0s
   next run: 2020-08-22 15:23:55 CEST (in 53m31s)
 Full Cycle:
   scheduled: true
   interval: 4h0m0s
   next run: 2020-08-22 17:56:10 CEST (in 3h25m46s)
 Recent Maintenance Runs:
   full-delete-blobs:
     2020-08-22 13:56:12 CEST (0s) SUCCESS
   full-rewrite-contents:
     2020-08-22 13:56:12 CEST (0s) SUCCESS
   index-compaction:
     2020-08-22 14:23:55 CEST (0s) SUCCESS
     2020-08-22 13:16:28 CEST (0s) SUCCESS
     2020-08-22 12:16:28 CEST (0s) SUCCESS
     2020-08-22 11:15:10 CEST (0s) SUCCESS
     2020-08-22 10:10:33 CEST (0s) SUCCESS
   quick-delete-blobs:
     2020-08-22 14:23:55 CEST (0s) SUCCESS
     2020-08-22 13:16:28 CEST (0s) SUCCESS
     2020-08-22 12:16:28 CEST (0s) SUCCESS
     2020-08-22 11:15:10 CEST (0s) SUCCESS
     2020-08-22 10:10:33 CEST (0s) SUCCESS
   quick-rewrite-contents:
     2020-08-22 14:23:55 CEST (0s) SUCCESS
     2020-08-22 13:16:28 CEST (0s) SUCCESS
     2020-08-22 12:16:28 CEST (0s) SUCCESS
     2020-08-22 11:15:10 CEST (0s) SUCCESS
     2020-08-22 10:10:33 CEST (0s) SUCCESS
   snapshot-gc:
     2020-08-22 13:56:10 CEST (1s) SUCCESS

    Eingeloggt als Root und in /home/KOPIA-USER

    # kopia maintenance info
14:31:32.776 [kopia/repo] failed to open repository: cannot open storage: cannot access storage path: stat kopia: no such file or directory
kopia: error: open repository: cannot open storage: cannot access storage path: stat kopia: no such file or directory, try --help

    Oder hier von extern

     $ kopia maintenance info
     kopia: error: operation supported only on direct repository, try --help

    Wichtig!
    Man muss an der Stelle im Dateisystem sein, von dem aus man das Repo sieht. Beispiel:

    cd /home/KOPIA-USER/

    Dann muss ich das Repo hier befinden!

    /home/KOPIA-USER/Repository

    Ich hoffe das war verständlich.

    Im Fediverse -> @FrankM@nrw.social

    1. NanoPi R5S
    2. Quartz64 Model B, 4GB RAM
    3. Quartz64 Model A, 4GB RAM
    4. RockPro64 v2.1
    0

  • FrankMF

    Crowdsec - Ein fail2ban Ersatz?

    Linux
    2
    +0
    0 Stimmen
    2 Beiträge
    820 Aufrufe
    FrankMF
    Ich kann jetzt hier von meiner ersten Erfahrung berichten und wie CrowdSec mich gebannt hat Was war passiert? Ich war gestern sehr intensiv mit der Konfiguration von Nextcloud <-> Collabora Online beschäftigt. Nachdem ich irgendwie nicht weiterkam habe ich mich der Erstellung eines Dokumentes gewidmet. Nach einiger Zeit war die Nextcloud nicht mehr erreichbar. Ok, hatte ich bei der Konfiguration auch schon mal, den Server einmal neugestartet und fertig. Doch jetzt kam es, Server neugestartet - hilft nicht. Gut, schauen wir mal nach, Der SSH Login ging auch nicht Jetzt war guter Rat gefragt. Zu diesem Zeitpunkt ging ich noch davon aus, das auf diesem Server kein CrowdSec installiert war, sondern fail2ban. Und fail2ban hatte eine sehr kurze Bantime vom 10M. Also blieb wohl nur noch das Rescue System von Hetzner. [image: 1694411392066-488866bc-3dcf-4abc-9e98-6107d65aa4c7-grafik.png] Da hatte ich ja so gut wie gar keine Erfahrung mit. Also mal kurz den Nico angetriggert und es kam folgender Link. https://docs.hetzner.com/de/robot/dedicated-server/troubleshooting/hetzner-rescue-system/ Das Laufwerk war schnell bestimmt und schnell nach /tmp gemountet. Danach musste man sich noch mit chroot in diese Umgebung anmelden. chroot-prepare /mnt chroot /mnt Nachdem das klappte, habe ich eben fail2ban disabled. sysmctl disable fail2ban Danach das Rescue beendet. Der Server startete wieder und ich kam wieder per SSH drauf. Puuh. Bei meiner ersten Kontrolle fiel mir was auf root@:~# pstree systemd─┬─2*[agetty] ├─atd ├─cron ├─crowdsec─┬─journalctl │ └─8*[{crowdsec}] ├─crowdsec-firewa───9*[{crowdsec-firewa}] Wie? Da läuft CrowdSec? Da ich dabei bin die Server auf CrowdSec umzustellen, war das wohl hier schon gemacht, aber leider nicht vernünftig. fail2ban hätte mindestens disabled werden müssen und in meiner Dokumentation war das auch nicht enthalten. 6 setzen! CrowdSec besteht ja aus zwei Diensten, CrowdSec und dem Firewall-Bouncer. Der CrowdSec Dienst lief aber nicht, der war irgendwie failed. Ok, starten wir ihn und schauen was passiert. Nachdem er gestarte war mal die Banliste angeschaut. cscli decisions list ergab diesen Eintrag. 2551501 │ crowdsec │ Ip:5.146.xxx.xxx │ crowdsecurity/http-crawl-non_statics │ ban │ │ │ 53 │ 1h5m55.391864693s │ 1671 Meine IP war gebannt. Dann wissen wir ja , woher die Probleme kamen. cscli decisions delete --id 2551501 Nach Eingabe war der Ban entfernt. Na gut, aber da ich aktuell immer noch an der richtigen Konfiguration von NC <-> CODE bastel, könnte das ja wieder passieren. Was machen? Kurz gegoogelt. Es gibt eine Whitelist. Aha! /etc/crowdsec/parsers/s02-enrich/whitelists.yaml name: crowdsecurity/whitelists description: "Whitelist events from private ipv4 addresses" whitelist: reason: "private ipv4/ipv6 ip/ranges" ip: - "127.0.0.1" - "::1" - "5.146.XXX.XXX" cidr: - "192.168.0.0/16" - "10.0.0.0/8" - "172.16.0.0/12" # expression: # - "'foo.com' in evt.Meta.source_ip.reverse" Danach den Dienst neustarten. Jetzt hoffen wir mal, das es hilft. Zum Schluss noch was, was mir aufgefallen war und was mich auch sehr verwirrt hatte. CrowdSec hatte wegen einem crowdsecurity/http-crawl-non_statics gebannt. Dadurch konnte ich meine subdomain.<DOMAIN> nicht erreichen. Ok, logisch, wenn der Ban von da ausgeht. Ich konnte aber gleichzeitig eine andere subdomain mit derselben <DOMAIN> auch nicht erreichen. Komplett verwirrte es mich dann, als ich eine andere <DOMAIN> auf dem selben Server erreichen konnte. Und zum Schluss ging auch der SSH nicht. Also, wieder viel gelernt..
  • FrankMF

    Star64 - UART

    Hardware
    1
    0 Stimmen
    1 Beiträge
    56 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Star64 lieferbar

    Star64
    1
    0 Stimmen
    1 Beiträge
    74 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Vaultwarden - SystemD

    Linux
    1
    0 Stimmen
    1 Beiträge
    198 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    NanoPi R5S - Samba

    NanoPi R5S
    5
    +0
    0 Stimmen
    5 Beiträge
    359 Aufrufe
    FrankMF
    Test zu dem NFS Mount (240GB USB SSD an USB-Port) [frank-ms7c37 nfs]# dd if=/dev/zero of=sd.img bs=1M count=2048 oflag=direct,nonblock 2048+0 Datensätze ein 2048+0 Datensätze aus 2147483648 Bytes (2,1 GB, 2,0 GiB) kopiert, 20,0851 s, 107 MB/s Test zum NAS Mount (Samba) (2TB 2,5Zoll HDD am USB-Port) [frank-ms7c37 NAS]# dd if=/dev/zero of=sd.img bs=1M count=2048 oflag=direct,nonblock 2048+0 Datensätze ein 2048+0 Datensätze aus 2147483648 Bytes (2,1 GB, 2,0 GiB) kopiert, 21,4538 s, 100 MB/s Das für den NAS Mount (Samba) sollte die maximal Schreibgrenze der Festplatte sein. Mehr dürfte da nicht gehen. Das andere könnte an den Adaptern liegen, die ich dafür benutze. Bei mir ist NFS hier aktuell nicht viel schneller, oder ich bin zu doof dafür.
  • FrankMF

    IPTables Logging

    Linux
    1
    0 Stimmen
    1 Beiträge
    290 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Passwort Manager - KeePassXC

    Allgemeine Diskussionen
    1
    +1
    0 Stimmen
    1 Beiträge
    402 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Wenn dir der Redis-Server flöten geht....

    Verschoben Redis
    3
    0 Stimmen
    3 Beiträge
    574 Aufrufe
    FrankMF
    So, nach einer kleinen Pause und ein wenig nachdenken ist mir doch noch was eingefallen Backports! Man so einfach! nano /etc/apt/sources.list Das folgende eintragen. # backports deb http://deb.debian.org/debian stretch-backports main Danach ein apt update Und dann schauen wir uns mal die Version an.... apt -t stretch-backports search redis-server Sorting... Done Full Text Search... Done golang-github-stvp-tempredis-dev/stretch-backports 0.0~git20160122.0.83f7aae-1~bpo9+1 all Go package to start and stop temporary redis-server processes libtest-redisserver-perl/oldstable,oldstable 0.20-1 all redis-server runner for tests python-hiredis/oldstable,oldstable 0.2.0-1+b2 amd64 redis protocol reader for Python 2.X using hiredis python3-hiredis/oldstable,oldstable 0.2.0-1+b2 amd64 redis protocol reader for Python using hiredis redis/stretch-backports 5:5.0.3-3~bpo9+2 all Persistent key-value database with network interface (metapackage) redis-server/stretch-backports 5:5.0.3-3~bpo9+2 amd64 [residual-config] Persistent key-value database with network interface Und die habe ich gestern Abend gebaut. 127.0.0.1:6379> INFO # Server redis_version:5.0.5 Ok, das schmerzt jetzt