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 - Peter Fodrek

Stran: 1 [2] 3 4 ... 13
16
Ale oni tam tie súbory sú
...
pre /usr/bin/bash mám overené, že na blok sedí veľkosť, podľa screenshotu z času, keď to fungovalo..
Má suse něco jako debsums, že to zkontroluje checksumy nainstalovaných souborů? Velikost nic neznamená, jenom že to správně obnovilo metadata - ale v těch blocích můžou být libovolné nesmysly.


jasne, file a ldd overí len magic bytes/magic block. readelf mi  možno dá niečo podrobnejšie a ani to nemusí bzť dostatočné.

17

Dále chroot do kompletně rozbitého systému provedeš tak, že tam hodíš staticky linkovaný busybox a uděláš "chroot ./suse /bin/busybox sh". Staticky linkovaný busybox pro všechny možné architektury stáhneš tady: https://packages.debian.org/buster/busybox-static


Vďaka uvažoval som nad staticky linknutým  bash-om, ale bussybox je lepší..

18
A proc se vlastne snazis neco poustet ze sveho disku nebo tam delat chroot, kdyz vis ze tam neni /usr ?
Prvni pravidlo zachrany je - nesahat do poskozeneho. A druhy je zalohovat.. nejspis to mas hodne roz*****e takze bootni live distro / live cd (gentoo admincd ?), a odzalohuj si /etc, /root a /home, pripadne /opt a jine.. a udelej reinstall.

Protoze i kdyby jsi s e2fsck /dev/susedisk pochodil, to neni nastroj ktery by ti navratil /usr, ale vytvori zmet anonymnich souboru v lost+found.


Ale oni tam tie súbory sú

ja mám zvlášť partície pre

2x swap
/
/home
/usr
/var/log
/boot
/boot/efi


na /home a /boot nikdy nebol problém.

/boot/efi bol 1x plný
/var/log bol pomerne často plný

pre /usr/bin/bash mám overené, že na blok sedí veľkosť, podľa screenshotu z času, keď to fungovalo..

Reinštalácia je prejavom  rezignácie alebo osobnej neschopnosti. Prosba o radu na  odstránia osobného zacyklenia je prostriedok osobného odborného rastu(učiť sa môžete len od lepších od Vás) lebo sa človek dozvie, čo sa oplatí zvažovať.

19
pri  dumpe2fs ma zarazili 7 vecí:
A 399 groups
B. mount count: 1 (pri  nepripojenom fs)
C. filesytem  revision 1(dynamic)
D filesystem state: clean
E. filesytem flag:  signed_directory_hash
F. filesystem featues: ........extra_isize
G. First inode: 11

nevidí tam niekto, čo mňa len mätie?

Ten Nonzero mount count  pre mountom partície ma desí a netuším ako sa ho zbaviť= google zatiaľ nepomáha

Ešte raz  vďaka


20
SystemRescueCD 4.9.0 kernel  4.4.28-amd64

no to máte dost starý systemrescuecd, tam sice bývaly jádra 32 a 64 bit, ale userspace byl jen 32bit, to asi vadí, že nenajde knihovny atd.

novější systemrescuecd má 64bit userspace, tím by to mělo jít


vďaka skúsim

21
Pokud me pamet neklame, tak *file not found* byva i problem kdyz chces pustit 64bit exac z 32bit kernelu.

To asi nie

SystemRescueCD 4.9.0 kernel  4.4.28-amd64

openSUSE

štandardný kernel 5.13.0rc3 (rc1 aj rc2 to neurobili aj rc3 viac ako 24 hodín)
fallback kernel 5.12.4-1

a robia to všetky 3 kernely... Teda ešte som neskúšal  boot dista s  SystemRescueCD kernelom, ktorý ale robí  to isté...


22
A neni to nahodou primountovany s 'noexec' ?


Ale to  by  musel byť ten parameter  v partition table alebo   v metadátach  EXT4 a tie som nepozeral, ale nezdá a mi, že by tam bol taký  parameter.

Mountuje to  ako  initrd s openSuse  aj zo SystemRescueCD bez  dodatočných parametrov pri mounte. 

Jediné, čo ma napadá je nastavený Execute In Place  parameter pre partíciu  na rotačnom disku..


Ale vďaka toto je nápad.  Ale už som tak dlho nerobil  s parametrami  EXT4fs, že si to musím znovu  naštudovať, ak mi  niekto priamo neporadí tu. Asi je ideálne skúšať obe veci naraz, poprosiť o radu a hľadať paralelne inde

23
Vážené kolegyne, vážení  kolegovia!

Stala sa mi  podivná vec s ext4 a poprosil by som o radu


 na openSUSE Tumbleweed  zmizli  všetky súbory z oddielu mapovaného na adresár  /usr
Tým pádom sa stal systém nepoužiteľným...

Po  reštarte nevedel  nájsť ani /bin/sh ani init.

v SystemRescueCD (viem dnes už  bez  CD, ale toto je stará  osvedčená verzia), fsck -pvcf na všetky oddiely sa súbory sa "objavili" na všetkých pripojených oddielocjh (tam, kde majú byť pre chroot ./suse /bin/bash, ktoré  mi  v minulosti  fugovalo) Práva sú  OK(755)  ls -la /usr/bin/bash je ok. cp so súborom ide, file zo SystemRescueCD hlási  ELF 64 bit x86 dynamicky linkovaný ldd  zo  SystemRescueCD hlási, že nie je dynamicky linkovaný a teda nedá  zoznam  potrebných  knižníc a sputenie  ./suse/usr/sbin/bash dá  file not found. Ale chroot  padne na file not found a som teda  mimo  možnosti použiť yast, zypper.. . Bash z System  rescue CD  potrebuje ncurses5 ale   na disku  je ncurses 6.2, takže sa nespustí ale nedá  file not found  ldconfig nejede, keďž chroot spadne na bash-i. pridanie položky .  do LD_LIBRARY_PATH  pre  chroot nefunguje, lebo  nevie, čím to interpretovať.

zdrojáky rozpúaracovaného projektu v C a Qt5 ostali  nedotknuté ale nemám ich  čím skompilovať inde.


Vie mi  niekto poradiť, čo sa mohlo stať a ako to  opraviť, prosím... Ja už  strácam nápady.

S vďakou  za radu

Peter Fodrek.

24
Hardware / Re:Jak dlouho přežije vypnutý počítač
« kdy: 27. 05. 2021, 07:35:45 »
Práve  oživujem a aktualizujem priemyselný PC, ktorý  bol pustený 15.5.2013 a teraz až v 21.5.2021 Pričom bol nezabalený vo výrobnej hale s vodivým prachom. Nie je to spoľahlivé ale ide to. čim dlhšie je pustený tým je spoľahlivejší pri štarte. Update OpenSuse z Lean 12.2 na Tumbleweed mal problém s tým, že rpm a  teda prenesene aj zypper nevedli  inštalovať nové rpm balíčky  a momentálne  to už potrebuje len upgrade na glibc 2.33, aby zypper dup išiel.. 

25


A nemuze si to zarizeni nahazovat a shazovat svuj ETH? Byl by defaultne shozeny, pred prenosem dat by si ho zarizeni nahodilo a po prenosu zase shodilo. Nebo je prenos dat inicializovany zvenci?

Bohužiaľ nie lebo je to sieťový riadiaci systém a teda  tá mašina  prijíma  dáta z inej podčasti stále
 cez  ETH a má len jeden  port.-.

26
Sítě / Re:Existuje etherenetový kábel s vypínačom?
« kdy: 13. 05. 2021, 20:39:06 »
ďakujem všetkým.

28
Jestli tomu správně rozumím, tak jde o snížení rizika napadení nějakého zařízení tím, že se razantně omezí čas, který bude mít útočník k dispozici pro útok. Jedna možnost je použít několik relé (nejlépe signálových) a těmi odpínat jednotlivé vodiče. Druhá možnost je vřadit nějaký levný switch a vypínat mu napájení.

Ide o dáta z  výrobnej linky  v master  databáze/databázach  pričom na druhej strane je firemená sieť so slave databázou, ktorá je master databázou pre backup a niektoré tabuľky  budú posielané z backupu, druhej databázy cez  synchronizáciu VPN k odberateľom. A výrobná llnka by síce mala byť podľa Industry 4.0 k dispozícii  partnrrom na  cez VTS, alebo aspoň dáta z nej. A ja sa bojím výrobnej linky trvalo fyzicky spojenej s VTS. Raz za nejaký čas    zapnem switch  a slave databáza si natiahne dáta z liniek a odpojíme sa. a partneri a vedenie majú dáta k nejakému času, ak chcú novšie, zapen vypínač v trezore a o pár sekúnd je hotovo a môžem linku odpojiť.



29
Existuje, ale je to dost drahá sranda.
https://www.amazon.com/Anarchy-Machines-Ethernet-Killswitch-2-0/dp/B07KW467DH

vďaka = Keby to stálo 200 EUR bolo by to veľa. ale 25 EUR je OK

30
Sítě / Existuje ethernetový kábel s vypínačom?
« kdy: 13. 05. 2021, 17:24:36 »
Vážené kolegyne, vážení kolegovia!
V súvislosti  s Industry 4.0 by sa mi hodilo, aba sa občas nejaké priemyselné  zariadenie  občas pripájalo k sieti  a prenieslo  nejaké údaje a väčšinu času  bolo fyzicky od firemnej siete odpojené.  Riešenie  s vyťahovaním  Ethernet  kábla sa mi  nepáči a riešenie cez SW vypínanie portu na  sieťovom prepínači   nepovažujem  za dosť bezpečné.

Chcem sa opýtať, či  niekto niečo podobné neriešil a neexistuje  riešenie napr. podľa nadpisu?

S vďakou

Peter

Stran: 1 [2] 3 4 ... 13