Byla vydána (𝕏) nová verze 24.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 24.7 je Thriving Tiger. Přehled novinek v příspěvku na fóru.
Binarly REsearch upozorňuje na bezpečnostní problém PKFail (YouTube) v ekosystému UEFI. Stovky modelů zařízení používají pro Secure Boot testovací Platform Key vygenerovaný American Megatrends International (AMI) a jeho privátní část byla při úniku dat prozrazena. Do milionů zařízení (seznam v pdf) po celém světě tak útočníci mohou do Secure Bootu vložit podepsaný malware. Otestovat firmware si lze na stránce pk.fail. Ukázka PoC na Linuxu na Windows na YouTube.
Mobilní operační systém /e/OS (Wikipedie) založený na Androidu / LineageOS, ale bez aplikací a služeb od Googlu, byl vydán ve verzi 2.2 (Mastodon, 𝕏). Přehled novinek na GitLabu. Vypíchnuta je rodičovská kontrola.
Společnost OpenAI představila vyhledávač SearchGPT propojující OpenAI modely umělé inteligence a informace z webů v reálném čase. Zatím jako prototyp pro vybrané uživatele. Zapsat se lze do pořadníku čekatelů.
Distribuce Linux Mint 22 „Wilma“ byla vydána. Je založená na Ubuntu 24.04 LTS, ale s desktopovým prostředím Cinnamon (aktuálně verze 6.2), příp. MATE nebo Xfce, balíkem aplikací XApp, integrací balíčků Flatpak a dalšími změnami. Více v přehledu novinek a poznámkách k vydání.
Příspěvek na blogu Truffle Security: Kdokoli může přistupovat ke smazaným a privátním repozitářům na GitHubu.
Byla vydána nová verze 14 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v cgitu. Vypíchnout lze podporu rozšíření v Lua.
Byla vydána verze 1.80.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Apple oznámil, že v beta verzi spustil své Apple Maps na webu. Podporován je také webový prohlížeč Chrome. Ne však na Linuxu.
Portál Stack Overflow po roce opět vyzpovídal své uživatele, jedná se především o vývojáře softwaru, a zveřejnil detailní výsledky průzkumu. Průzkumu se letos zúčastnilo více než 65 tisíc vývojářů. Z Česka jich bylo 710. Ze Slovenska 246.
Řešení dotazu:
+-------+---------------------+---------------------+---------+-----------+----------+---------------+ | JobId | Name | StartTime | JobType | JobStatus | JobFiles | JobBytes | +-------+---------------------+---------------------+---------+-----------+----------+---------------+ | 6240 | /var/log/emerge.log | 2011-07-22 18:00:02 | B | T | 575 | 103161408 | | 6231 | /var/log/emerge.log | 2011-07-21 18:03:44 | B | T | 77151 | 1400689036 | | 6218 | /var/log/emerge.log | 2011-07-20 18:00:03 | B | T | 488 | 83690330 | ... | 6019 | /var/log/emerge.log | 2011-06-28 18:00:03 | B | T | 76274 | 1328834334 | | 5939 | /var/log/emerge.log | 2011-06-19 20:38:45 | B | T | 82992 | 1397323096 | | 5871 | /var/log/emerge.log | 2011-06-12 14:40:13 | B | T | 83793 | 1575742423 | +-------+---------------------+---------------------+---------+-----------+----------+---------------+System si uklada informacie o kazdom backupe v databazovom katalogu. V GUI sa da pozriet aj timestamp samotneho suboru a checksum. Podla roznych kriterii sa da nastavit co ma obnovit. Samotna zaloha moze byt ako by sa ocakavalo "full backup", "incremental", alebo "difrerential".
Git má bohužel problémy s velkými souboryMáš pro to nějaký (současný) odkaz?
Například prosinec 2010 - http://lwn.net/Articles/419241/.Tam žádný konkrétní popis problémů nevidím.
IFS=$(echo -en "\n\b") export SVN_EDITOR=cat # echo "provadim zmeny repozitare v pripade potreby" ADDR_OUT="domain.tld" # vnejsi adresa ADDR_HOME="192.168.0.1" # adresa ve vnitrni siti # cesta k repozitari PATH_REPO="/cesta/na/serveru/REPO" PATH_SRC="/cesta/na/lokalnim/stroji/REPO" cd $PATH_SRC # Pingne na vnitrni adresu. Pokud dostane odpoved, predpoklada, ze je # dostupna. Pokud vyprsi timeout, nastavi adresu SVN serveru na vnejsi # adresu. if [ `ping -q -c 1 $ADDR_HOME | grep "1 received" -c` -eq 0 ];then echo "nejsem doma, nastavim vnejsi repo" svn switch --relocate svn+ssh://user@$ADDR_HOME$PATH_REPO svn+ssh://user@$ADDR_OUT$PATH_REPO else echo "jsem doma, nastavim domaci repo" svn switch --relocate svn+ssh://user@$ADDR_OUT$PATH_REPO svn+ssh://user@$ADDR_HOME$PATH_REPO fi echo "processing files to add..." find . | grep -v "\.svn" | sed -e s/^/\"/g -e s/$/\"/g | xargs -r svn add 2>&1 | grep -v "under version control" echo "done" echo "processing files to delete..." svn status | grep "^!" | sed -r 's/^\![ ]+//' | xargs -r svn delete echo "done" echo "processing commit..." svn commit --non-interactive -q -m "auto" || echo "Nelze commitnout" svn up || echo "nelze aktualizovat" echo "done"
Z toho důvodu ani nemůžu použít snapshotový FS, jelikož se chci obvykle vrátit u jednoho souboru a ne u všech.
To jsem moc nepochopil.
Osobně používám kombinaci rsync (pro úsporné přenášení dat ze síťových strojů) a následný btrfs snapshots. Výsledkem je, že mám k dispocici kompletní data ze všech serverů a to ve velmi úsporné formě na disku. Kdykoliv mohu vytáhnout jakýkoliv soubor z jakéhokoliv snapshotu.
Celá tato operace je tak rychlá, že ji mám v cronu každou hodinu (což je možná overkill, ale chtěl jsem trochu vyzkoušet i co btrfs zvádne).
Snapshoty se tváří jako adresáře (resp mountpointy), takže můžeš pro "vytažení" zálohy použít jakýkoliv protokol na soubory (scp, ftp, samba, nfs).
S prvím odstavcem nezbývá než souhlasit.
To druhé, upřímně, to jsem ještě neřešil. Určitě to půjde zálohovat stejně jako každý jiný FS - umount a dd
. Podle featur na wiki by to mělo mít incremental backup celého fs, ale nenašel jsem na to příkaz. Asi ještě není implementovaný.
Otázkou je, proč řešit zálohování zálohovacího media (pokud by to mělo vystupovat v této roli). Zálohovací pásky také přece nezálohujete.
dd
neuvažuji, partimage
to ještě neumí. Snad už jen RAID 1.
Tiskni
Sdílej: