1
Distribuce / Re:Automatický fsck před připojením oddílu
« kdy: 07. 12. 2022, 23:36:23 »
Děkuji, vyzkouším.
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.
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
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ě?
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.targetTo 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
Software / [vyřešeno] Re:Btrfs - nemožnost smazání starého snapshotu
« kdy: 06. 05. 2021, 13:04:24 »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 filesKó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
test7
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:
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 {} \;
exitTohle 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)
A teď bych ten unixtime potřeboval změnit na formát jako je například 19980118T073000Z (jako používá DTSTART v icalu)
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.
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í.
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.
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.
