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 - byl_jsem_donucen_se_registrovat

Stran: [1] 2
1
Software / Re:Část bash historie občas záhadně zmizí
« kdy: 03. 04. 2024, 08:08:14 »
Klasickou bash historii používám pouze na šipku nahoru (nedávno provedené příkazy). Na dlouhodobější historii jsem si nainstaloval Atuin, který mám nabindovaný na Ctrl+R. Dá se v tom hezky vyhledávat a nic se neztrácí. V ~/.config/atuin/config.toml mám nastaveno
Kód: [Vybrat]
enter_accept = false, abych ještě příkaz mohl po potvrzení entrem upravit. V ~/.bashrc jsem upravil
Kód: [Vybrat]
atuin init bash na
Kód: [Vybrat]
atuin init bash --disable-up-arrow, tím se zachová normální funkce šipky nahoru.

Atuin vypadá dobře, možná vyzkouším, neznal jsem, díky.

2
Software / Re:Část bash historie občas záhadně zmizí
« kdy: 02. 04. 2024, 22:38:20 »
Je to tak. Bash má historii v paměti a po ukončení ji zapíše do .bash_history. Tím pádem tam bude historie z toho posledního.

Ono to jde nastavit, aby se to tam zapisovalo hned, tím tam budou sice všechny příkazy, ale míchá se to mezi více shelly, takže když děláte v jednom něco a v druhém něco jiného, tak se to bude motat. Takže jsem to měl jen chvilku, nezvyk jsem si a zrušil jsem to.

To si právě myslím že mám nastaveno tím history -a, což by měl měl být append history dané bash session, po spuštění příkazu se příkaz ihned objeví v .history souboru:
Kód: [Vybrat]
export PROMPT_COMMAND="history -a; $PROMPT_COMMAND"

Ano, tak nějak to bylo. Ale jestli si pamatuju dobře, tak to stejně úplně nefungovalo - nebralo to všechno. Navíc nejde pak intuitivně používat šipka nahoru v jednotlivých terminálech, jak se to míchá vše dohromady. Tak jsem to vypnul.

Takhle "hloupě" se to chová při nastavení
Kód: [Vybrat]
export PROMPT_COMMAND="histrory -a;history -c; history -r;$PROMPT_COMMAND"
  • history -c clears the in-memory history
  • history -r appends the contents history file to the in-memory history

Jelikož používám ext4 tak jsem zkusil nastavit soubor s historií tak aby se do něj dal dělat pouze append, třeba mi to pomůže:
Kód: [Vybrat]
chattr +a .history

3
Software / Re:Část bash historie občas záhadně zmizí
« kdy: 02. 04. 2024, 20:30:49 »
Je to tak. Bash má historii v paměti a po ukončení ji zapíše do .bash_history. Tím pádem tam bude historie z toho posledního.

Ono to jde nastavit, aby se to tam zapisovalo hned, tím tam budou sice všechny příkazy, ale míchá se to mezi více shelly, takže když děláte v jednom něco a v druhém něco jiného, tak se to bude motat. Takže jsem to měl jen chvilku, nezvyk jsem si a zrušil jsem to.

To si právě myslím že mám nastaveno tím history -a, což by měl měl být append history dané bash session, po spuštění příkazu se příkaz ihned objeví v .history souboru:
Kód: [Vybrat]
export PROMPT_COMMAND="history -a; $PROMPT_COMMAND"

4
Software / Část bash historie občas záhadně zmizí
« kdy: 02. 04. 2024, 17:29:11 »
Ahoj všem. Nastavil jsem si nekonečnou bash history podle návodu na webu https://www.soberkoder.com/unlimited-bash-history/ a na první pohled to vypadalo že se historie spuštěných příkazů ukládá tak jak má. Bohužel jsem po čase zjistil že mi ze souboru .history/.bash_history občas zmizí několik stovek příkazů. Níže je moje nastavení historie v .bashrc (zkráceno):

Kód: [Vybrat]
shopt -s histappend

export HISTFILESIZE=-1
export HISTSIZE=-1
export HISTFILE=~/.history

export HISTTIMEFORMAT="[%F %T] "
export PROMPT_COMMAND="history -a; $PROMPT_COMMAND"
export HISTCONTROL=ignoredups

Po každém spuštěném příkazu by se měla historie uložit (histappend) díky nastavení v proměnné PROMPT_COMMAND. Jako emulátor terminálu používám Tilix ve kterém běží bash 5.1.16 (Ubuntu 22.04 LTS). V Tilix profilu je nastaveno "Run command as login shell".

Netuší někdo čím by tohle chování mohlo být způsobeno? Případně jaká další nastavení bych mohl zkontrolovat?

Předem všem děkuji za reakce.

5
Software / Re:Co sa stalo s PDF suborom, ked nejde otvorit
« kdy: 08. 01. 2022, 23:22:10 »
Omlouvám se za duplicitu, vlákno jsem samozřejmě četl celé, ale na mobilu, takže jsem to trochu odfláknul.

6
Software / Re:Co sa stalo s PDF suborom, ked nejde otvorit
« kdy: 08. 01. 2022, 22:17:30 »
Dokonce se dají najít instrukce k instalaci - co ten plugin vzít ze starého počítače, pokud je to ještě možné?

Kód: [Vybrat]
Instrukce k instalaci.
1. Nainstalujte Acrobat Reader, pokud ještě není nainstalován.
2. Zkopírujte soubor Nxsec2__en.API ​​​​do složky Reader's: \ Program Files \ Adobe \ Acrobat 4.0 \ Reader \ plug_ins \
nebo soubor Nxsec.api z \ SETUP CD do \ Program Files \ Adobe \ Acrobat 4.0 \ složka plug_ins \

8
Hardware / Re:Lepidlo na gumové nožičky - router
« kdy: 06. 01. 2022, 00:36:31 »
Téma je sice staré ale stále aktuální řeším naprosto stejnou věc.

Docházím k závěru že se na podobné účely používá transferová lepící páska, jsou varianty s nosičem nebo bez nosiče a také záleží na použitém lepidle, např. při lepidle 300LSE to umí slepit i plasty s nízkou povrchovou energií https://www.advasro.cz/3m-8132le-transferova-paskalepidlo-300lse-v-archu-609-x-914-mm-tl-005-mm a dělají se různé tloušťky (např. i 0,05 mm apod..) i archy nebo pásky.

Přemýšlím že na přilepení gumových nožiček použiju tohle. Nemáte někdo zkušenost? Je to dost drahé tak nevím jestli jsem to všechno správně pochopil, kdyžtak mne opravte.

9
Server / Re:Nedaří se vytvořit bitovou kopii disku
« kdy: 23. 11. 2021, 17:12:50 »
Chybí jakékoliv ověření, že se nahrála všechna data, bez zapnutého pipefail se ani nedozvím, jestli ssh přenos dopadl v pořádku a vše se na druhé straně uložilo.

Zapnutí pipefail myslíte např. takto?

Kód: [Vybrat]
set -e -o pipefail; dd if=/dev/vdb bs=4M | ssh root@192.168.1.1 'dd of=/dev/sdd bs=4M'

10
Server / Re:Nedaří se vytvořit bitovou kopii disku
« kdy: 23. 11. 2021, 13:27:13 »
Kopírování clonezillou dopadlo špatně, XFS šlo připojit ale po chvíli kdy se do něj zapsalo tak IO error a poškozený FS, který nešlo v rozumném čase opravit. Clonezilla co vím tak interně používá partclone, sfdisk, grub, dd dle jejího uvážení. Zajímavé bylo že změnila svévolně velikost některých LV (zjištěno při obnově) i když to po ní nikdo nechtěl. Spíše jsem uvažoval samostatném použití partclone.

11
Server / Re:Nedaří se vytvořit bitovou kopii disku
« kdy: 23. 11. 2021, 13:19:27 »
V dmesg nic zajímavého vidět není, selinux vypnutý.

Zkusil jsem udělat pomocí dd img soubor, spočítat jeho md5sum. Pak jsem ho pomocí SSH zkopíroval na nový stroj, ověřil jsem kontrolní součet a pomocí dd if=/opt/root.img of=/dev/sde bs=4M jsem zapsal bloky na nový disk. Chování stejné.

A už asi tuším kde jsem udělal školáckou chybu  >:(, vypadá to že na cílovém systému jsem zapomněl před xfs_repair či mount udělat aktivaci VG a LV pomocí lvchange -ay vg_root/lv_root. Po aktivaci je již vidět zdravé XFS.

Co je na přenosech po síti špatné? Měl jsem za to že TCP případné síťové chyby vyřeší, nebo na ně alespoň upozorní.

12
Server / Re:Nedaří se vytvořit bitovou kopii disku
« kdy: 23. 11. 2021, 11:31:55 »
Disk pochází z aktuálního RHEL7. Live distribuce ze které dělám dd je aktuální clonezilla. Při blokovém kopírování disku by přece mělo být jedno co je tam za FS, ne? V době kopírování není FS připojen.

Na zdrojové clonezille v pohodě XFS připojím (mount). Na cíli již ne. Na obou stranách je stejná verze clonezilla tedy i XFS knihoven a kernelu.

13
Server / Nedaří se vytvořit bitovou kopii disku
« kdy: 23. 11. 2021, 09:59:12 »
Ahoj, nedaří se mi vytvořit bitovou kopii disku. Snažím se zmigrovat disk používaný u KVM vmka z qcow2 do vmdk formátu a tento disk použít ve vmware u jiného vmka. Disk nemá partition, je na něm pouze LVMko, přes celý disk. Na LVM lv je XFS filesystém.

Kód: [Vybrat]
root@debian:~# lsblk
vdb                     254:16   0   1.1G  0 disk
└─vg_root-lv_root       253:7    0   1.1G  0 lvm

root@debian:~# pvs
  PV         VG         Fmt  Attr PSize   PFree
  /dev/vdb   vg_root    lvm2 a--   <1.10g    0

root@debian:~# lvs
  LV         VG         Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_root    vg_root    -wi-a-----  <1.10g

Jako první jsem se pokusil disk přemigrovat pomocí konverze qcow2 -> vmdk pomocí:

Kód: [Vybrat]
qemu-img convert -f qcow2 -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized,compat6 disk.qcow2 disk.vmdk

Tento disk jsem následně importoval do vmware a připojil k novému vmku. Bohužel na zkonvertovaném disku vidím správně LVM (vg,lv), ale XFS filesystém je poškozený tak že nejde připojit ani opravit. Zkoušel jsem ještě různé kombinace parametrů pro konverzi pomocí qemu-img convert, ale došel jsem k závěru že tudy prostě cesta nevede.

Rozhodl jsem se tedy udělat bitovou kopii disku pomocí dd. To mi ale také nefunguje a vůbec netuším proč.

Kopii dělám tak že na starém i novém vmku mám nabootované nějaké live cd a na starém stroji spustím dd a obraz přenesu přes SSH (adresa nového stroje 192.168.1.1):

Kód: [Vybrat]
dd if=/dev/vdb bs=4M | ssh root@192.168.1.1 'dd of=/dev/sdd bs=4M'
Následně na novém stroji opět vidím správně LVM (vg,lv), ale XFS filesystém je poškozený:

Kód: [Vybrat]
root@debian:~# vgchange -ay
  1 logical volume(s) in volume group "vg_root" now active
root@debian:~# pvs
  PV         VG      Fmt  Attr PSize  PFree
  /dev/sdd   vg_root lvm2 a--  <1.10g    0
root@debian:~# lvs
  LV      VG      Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv_root vg_root -wi-a----- <1.10g
root@debian:~# xfs_repair /dev/mapper/vg_root-lv_root
Phase 1 - find and verify superblock...
superblock read failed, offset 0, size 524288, ag 0, rval -1

fatal error -- Input/output error
root@debian:~#

Netušíte někdo, prosím, co dělám špatně, popřípadě co by se dalo ještě vyzkoušet? Napadá mě dump xfs filesystému, popřípadě kopie samotných dat pomocí rsync.

Ještě bych dodal že zdrojový stroj běží virtualizován v KVM kde se používá VirtIO driver (předpokládám). Předem díky za nápady.

14
Sítě / Re:Mikrotik, IPv6 a ISP Metronet
« kdy: 13. 05. 2019, 06:27:22 »
Podle toho co píšeš tam máš parametry asi stejné - VDSL po drátech které patří Cetinu. Pevná IPv4 a IPv6 pro LAN /56 pro WAN /64. Delegovali prefix přes DHCPv6 - viz screenshot https://imgur.com/a/VsiAmOc, úplně dole je IPv6-PD a to je prefix který jsem nikde nekonfiguroval.

15
Sítě / Re:Mikrotik, IPv6 a ISP Metronet
« kdy: 12. 05. 2019, 23:01:52 »
Ahoj, já jsem k Metronetu přešel před cca dvěma týdny. Mám OpenWRT (snapshot) a IPv6 se nakonfigurovala na první dobrou sama - takže u tebe bude asi problém někde na straně konfigurace. V nastavení vidím že jsem dostal od Metronetu pomocí SLAAC + DHCPv6 stateless delegovaný IPv6 prefix /56. OpenWRT je na IPv6 asi dobře připraveno - i klienti v interní síti dostávají IPv6 adresy z delegovaného prefixu.

Stran: [1] 2