Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - beer

Stran: [1] 2 3 ... 49
1
Distribuce / Re:Automatický fsck před připojením oddílu
« kdy: 07. 12. 2022, 23:36:23 »
Děkuji, vyzkouším.

2
Distribuce / Automatický fsck před připojením oddílu
« kdy: 07. 12. 2022, 17:43:55 »
ahoj, mám dotaz, jak automaticky zkontrolovat a opravit chyby na disku po rebootu?


v /etc/default/grub mám
GRUB_CMDLINE_LINUX="fsck.mode=force fsck.repair=yes"


to způsobí check pouze na systémech ubuntu based, ale na centosech/redhatech je ignorováno.


Dále - check proběhne jen na /, ale ne na ostatních filesystémech (třeba /var/log má separátní ext4 oddíl a neproběhne).


Zkoušel jsem na to jít cestou vytvoření systemd-servicy


Kód: [Vybrat]
[Unit]
Description=File System Check on non Root Device
DefaultDependencies=no
Conflicts=shutdown.target
Before=local-fs.target
Wants=systemd-fsckd.socket systemd-fsck-root.service
After=systemd-fsckd.socket systemd-fsck-root.service


[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/usr/local/scripts/check_non_root_fs
TimeoutSec=0


[Install]
WantedBy=local-fs.target


To ale nepomohlo, disky se nestihnou opravit a některé oddíly se nestihnou připojit.


Změna WantedBy na RequredBy způsobí, že systém nebude dostupný přes ssh.


Nějaké nápady? Ideálně funkční v rhel i ubuntu světě?

3
neni ro primo /.backup ?
To mne nenapadlo, ano je. Díky.

4
Software / Re:Btrfs - nemožnost smazání starého snapshotu
« kdy: 06. 05. 2021, 09:41:52 »
nikdo nic?

5
Software / Re:btrfs - nemožnost smazání starého snapshotu
« kdy: 05. 05. 2021, 20:27:43 »
Podařilo se mi smazat ze snapshotů vše, ale samotné subvolume ne.
Kód: [Vybrat]
[20:24] root@medved-kladno:~ # tree /.backup/
/.backup/
├── 2104212220
├── 2104221200
├── 2104231200
├── 2104261200
├── 2104271200
├── 2104281200
├── 2104291200
├── 2104301200
├── 2105011200
├── 2105031200
└── 2105041200

11 directories, 0 files
Kód: [Vybrat]
btrfs subvolume get-default /.backup/2104212220/
ID 5 (FS_TREE)
[20:26] root@medved-kladno:~ # btrfs subvolume show /
@
    Name:             @
    UUID:             be804fc7-902d-6249-8f59-def7adbc82b7
    Parent UUID:         -
    Received UUID:         -
    Creation time:         2021-01-06 01:59:10 +0100
    Subvolume ID:         256
    Generation:         173849
    Gen at creation:     6
    Parent ID:         5
    Top level ID:         5
    Flags:             -
    Snapshot(s):
                @/.backup/2104212220
                @/.backup/2104221200
                @/.backup/2104231200
                @/.backup/2104261200
                @/.backup/2104271200
                @/.backup/2104281200
                @/.backup/2104291200
                @/.backup/2104301200
                @/.backup/2105011200
                @/.backup/2105031200
                @/.backup/2105041200


6
Software / Re:btrfs - nemožnost smazání starého snapshotu
« kdy: 05. 05. 2021, 19:25:30 »
Ty snapshoty nejsou jen read only, proč si btrfs stále myslí, že jsou?
Kód: [Vybrat]
[19:13] root@medved-kladno:~ # ls /.backup/2104221200/test
ls: nelze přistoupit k '/.backup/2104221200/test': Adresář nebo soubor neexistuje

[19:24] root@medved-kladno:~ # echo test > /.backup/2104221200/test

[19:24] root@medved-kladno:~ # cat /.backup/2104221200/test
test


7
Software / Btrfs - nemožnost smazání starého snapshotu
« kdy: 05. 05. 2021, 19:21:12 »
Ahoj, nemohu přijít na to, proč nemůžu smazat starý btrfs snapshot, poradí někdo?
Můj zálohovací skript, který by měl i staré snapshoty mazat:
Kód: [Vybrat]
#!/bin/bash
DATE="$(date +%y%m%d%H%M)"
btrfs subvolume snapshot / \
  /.backup/${DATE}
touch /.backup/${DATE}
btrfs property set -ts /.backup/${DATE} ro true
find /.backup/ -mindepth 1 -maxdepth 1 -type d -mtime +30 -exec btrfs property set -ts {} ro false \; \
  -exec btrfs subvolume delete {} \;
exit
Tohle mi to dělá:
Kód: [Vybrat]
[19:12] root@medved-kladno:~ # find /.backup/ -mindepth 1 -maxdepth 1 -type d -mtime +10 -exec btrfs property set -ts {} ro false \; -exec btrfs subvolume delete {} \;
Delete subvolume (no-commit): '/.backup/2104221200'
ERROR: Could not destroy subvolume/snapshot: Read-only file system
Delete subvolume (no-commit): '/.backup/2104231200'
ERROR: Could not destroy subvolume/snapshot: Read-only file system

[19:12] root@medved-kladno:~ # touch /.backup/2104221200

[19:12] root@medved-kladno:~ # rm -rf /.backup/2104221200
rm: nelze odstranit '/.backup/2104221200': Systém souborů je pouze pro čtení

[19:12] root@medved-kladno:~ # stat /.backup/2104221200
  Soubor: /.backup/2104221200
Velikost: 0             Bloků: 0          I/O blok: 4096   adresář
Zařízení: 5ch/92d    I-uzel: 256         Odkazů: 1
Práva: (0755/drwxr-xr-x)  UID: (    0/    root)   GID: (    0/    root)
Přístup: 2021-05-05 19:12:31.757627999 +0200
Změna obsahu: 2021-05-05 19:12:46.881173966 +0200
Změna i-uzlu: 2021-05-05 19:12:46.881173966 +0200
       Vznik: 2021-01-06 01:59:10.554144173 +0100

8
Vývoj / Re:Python - převedení na unixtime
« kdy: 01. 11. 2019, 15:11:46 »
Funguje. Moc díky.
A teď bych ten unixtime potřeboval změnit na formát jako je například 19980118T073000Z (jako používá DTSTART v icalu)

9
Vývoj / Re:Python - převedení na unixtime
« kdy: 01. 11. 2019, 11:27:58 »
díky, vyzkouším

10
Vývoj / Python - převedení na unixtime
« kdy: 01. 11. 2019, 10:13:15 »
Ahoj, mám skript, který tahá údaje s jiry, čas dostává ve formátu 2019-11-30T20:00:00.000+0100. Pomůže mi někdo s převedením na unixtime stamp v pythonu?

11
Server / Re:Nextcloud: přihlášení Google účtem
« kdy: 07. 06. 2018, 08:40:08 »
Podporuje:https://github.com/zorn-v/nextcloud-social-login
Už jsem přišel na to, jak spárovat existující účet s účtem na sociální síti: po přihlášení heslemúplně dole na stránce v  nextcloudu na webu v url .../index.php/settings/user/additional zaškrtnout tu danou sociální síť a pokud jsem do ní přihlášen, tak se účet propojí.
Zatím jsem nevyřešil ten problém s klíčem. Vše mi funguje, šifrování v server side nextcloudu nevedu, takže se k souborům dostanu, ale rád bych to taky vyřešil.

12
Server / Nextcloud: přihlášení Google účtem
« kdy: 06. 06. 2018, 09:00:03 »
Zdravím, povolil jsem si přihlášení do nextcloudu google účtem. Místo, aby podle e-mailu rozpoznal nextcloud již existujícího uživatele, vytvoří nového se jménem google-nějaké číslo a zobrazuje hlášku:
Chybný soukromý klíč pro šifrovací aplikaci. Aktualizujte prosím heslo svého soukromého klíče v osobním nastavení, abyste znovu získali přístup ke svým zašifrovaným souborům.
Dají se tyto 2 nedostatky nějak vyřešit? I když uživateli vytvořím přímo heslo, a v nastavení Zapezpečení - základní šifrovací modul nastavím stejné heslo, tak to tu hlášku pořád píše.
Co bych tedy rád, aby se nevytvářeli noví uživatelé, když existuje stávající, a aby se vyřešila ta hláška šifrovacího modulu. U uživatelů, které vytvořím ručně to není, ale u těch není možné google přihlášení.

13
Vývoj / Re:Paralelní zpracování souboru
« kdy: 24. 02. 2018, 16:47:39 »
To je interní funkcionalita jpeg-recommpress, bohužel optipng to nemá.

Kód: [Vybrat]
optimages2.sh Obrázky/
File already processed by jpeg-recompress!
Metadata size is 15kb
smallfry at q=67 (40 - 95): 97.331100
smallfry at q=81 (68 - 95): 99.249321
smallfry at q=88 (82 - 95): 100.479576
smallfry at q=92 (89 - 95): 101.507240
smallfry at q=94 (93 - 95): 102.012131
smallfry at q=95 (95 - 95): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
smallfry at q=95 (95 - 94): 102.358299
Final optimized smallfry at q=95: 102.355392
New size is 58% of original (saved 1891 kb)
Metadata size is 15kb

14
Vývoj / Re:Paralelní zpracování souboru
« kdy: 24. 02. 2018, 13:41:46 »
Když zakomentuji png, tak to projde jen od největších jpg a vyčte si to z poznámky, že ten daný soubor to již zpracovávalo a dál ho nezpracovává.

Tak funguje to i na desktopu s Ubuntu, ale protože tam mám hodně velké soubory - obrázky, které mají poměrně dost megabajt, tak se zdá, jako kdyby to pořád pracovalo a nic se neděje. Ale pak už je to lepší. Nejhorší je to u skenů, u klasické fotky cca 5 MB trvá optimalizace pár minut.

Horší je, že narozdíl od severu na desktopu někdy stroj zamrzne, když se na něm dělá něco jiného. Přece jen je desktop starší a má jen dvě jádra. Kdybych odstranil -l 128 tak by to bylo mnohem mnohem rychlejší, ale ne s tak dobrými výsledky.

15
Vývoj / Re:Paralelní zpracování souboru
« kdy: 22. 02. 2018, 09:02:33 »
Tak funguje to napůl. Na debianu 9 bez problémů, na destkopu s ubuntu to taky dokáže vytížit na 100 % všechna jádra, ale bez jakéhokoliv výpisu a výsledek nikde. I když odstraním ty zpětná lomítka. V htopu vidím, že to něco dělá, ale žádný výstup a pořád nad stejnými soubory.

Stran: [1] 2 3 ... 49