Örülök hogy sikerült - és gratula!
Én is a GParted-el költöztettem át egy EFI-s Mint-et egy 500GB-os HDD-ről
250GB-os SSD-re.
Nálam indul a Rescuezilla is meg a Foxclone is - de még nem használtam
őket - mert nem volt rá szükség.

Hat nem irigylem oket. Nekem a mai napig elmeny leulni a kis (most /pill) DeskMini asztali gep ele amit a telefon kvara nem fog soha a budos eletbe kivaltani. nalam biztosan pedig telo fronton is megy a sajat debloat script, root meg minden ami kell de ez nagyon neeeem pc.
Mondjuk jelen generacionak mar mindegy is...csak a face, insta menjen... ezek nem tudjak milyen ISA buszos kartyat jumperelni es kulonben is, a turbot gombot sem ismerik

Passionate about minimalistic software, the Linux philosophy, and having fun. SFF enthusiast.

Srácok kis segítség kellene!
Azt szeretném elérni Fedora 38 alatt, hogy ha beállítom a LAN alatt hogy WOL működjön, akkor első bekapcsolás után ne álljon vissza tiltásra.
Ez az alapbeállítása.

Ez meg a beállított WOL.

De ha kikapcsolom, majd be, akkoor visszaálll alaapértelmezett d-re (gondolom denied lesz) és újra be kell állítani ha használni szeretném.
Valami ötlet hogy tudnám egyszer beállítani és úgy maradjon

"Ha egyedülállóval találkozunk, mindegy, mit mond, de biztos, hogy nem azért van egyedül, mert élvezi a magányt, hanem mert már megpróbált beilleszkedni a világba, de az emberek újra meg újra kiábrándítják."

Ebben van a válasz. Nekem a 2.2.6-os pont segített.
[link]
Végre tudom telefonról kapcsolni a nuc-ot.

[ Szerkesztve ]

"Ha egyedülállóval találkozunk, mindegy, mit mond, de biztos, hogy nem azért van egyedül, mert élvezi a magányt, hanem mert már megpróbált beilleszkedni a világba, de az emberek újra meg újra kiábrándítják."

Sziasztok!
Lassan kezdem feladni, hogy megvalósíthatatlan...
Azt szeretném megoldani, hogy a pegeant egy jelszóval védett titkosított kulcs jelszavát csak egyetlen egyszer kérje be. Mivel olyan személyeknek adnám ki a privát kulcsot, akiknek nem szeretném elárulni az titkosított privát kulcs jelszavát ezért amikor én beállítom a gépükön, akkor egyszer én adjam meg és többször ne kelljen.
Parancsikont csináltam nekik, be is tölti az encryptált kulcsot, de a jelszót a parancsikon elindítása után ismét kéri..

Magadnak csinálsz problémát. Privát kulcsot nem osztunk meg senkivel. Mindenkinek sáját kulcsa van, így könnyen kezelhető ha közös accountot haszálnak is.

Ez egy SFTP csatlakozáshoz kell, és egy közös usert használnak.

Ezzel nem cáfoltad meg, amit írt. Generálj(anak) kulcsot és add hozzá a public kulcsot az ftp-hez.

Köszi, de ez nem kivitelezhető. Több okból is.
Az eredeti felvetésemre, akkor nincs vagy nem lehet megoldás?

leveszed a kulcsrol a passphraset. ha a user gépen tárolnád, akkor nem mindegy?
egyébként miert nem lehet minden usernek saját kulcsa?

Sziasztok!

Nem tudom, hogy mennyire haladó téma, de hátha.

Van egy samba megosztásom, és be is állítottam az host allow opciót, de a /var/log/samba mappában megjelentek olyan logfájlok, amik más IP-kről jöttek, persze hibával.
A kérdés, hogy be tudok-e állítani valami alertet, ha nem az engedélyezett ip-kről próbálj valami progi kapcsolódni.
meg tudom írni a shell scriptet, ami figyeli a logokat, de hátha van valami beépített erre való opció.

Kössz!

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

fail2ban-nal automatice tiltani is tudsz.

https://www.coreinfinity.tech

Talán így meg tudod oldani, bár nem írtad milyen distro de példaként vegyük az apt csomagkezelőt, arch-nál pacman.
sudo apt-get install putty
Létre kell hoznod egy id_rsa fájlt a .ssh saját könyvtárad mappájában ssh-keygena *.ppk (puttygen generált fájl) segítségével,vagy konvertálnod kell onnan. A név id_rsa legyen ez fontos!
puttygen private.ppk -O private-openssh -o $HOME/.ssh/id_rsa
A id_rsafájl nem lehet mások által olvasható vagy írható:
chmod 600 $HOME/.ssh/id_rsa
Létrehozol egy agent.shfájlt a saját könyvtáradban,de bárhová elhelyezheted:
. $HOME/.ssh/ssh-agent.env 2>/dev/null
if [ "`ssh-add -l | grep id_rsa`" = "" ]; then
mkdir -p $HOME/.ssh/
ssh-agent >$HOME/.ssh/ssh-agent.env
. $HOME/.ssh/ssh-agent.env
ssh-add
fi
A gitt a következőként hajtható végre:
. ./agent.sh; putty
vagy:
. ./agent.sh
putty
A "." (pont és idézőjel) is fontos, a végrehajtott szkript környezeti változóit exportálja. Először a kulcsfájl jelszavát fogja kérni, a következő alkalommal pedig jelszókérés nélkül hajtja végre a gitt.

A végtelen ciklus is véget ér egyszer, csak erős hardver kell hozzá!

Az SFTP nem a miénk, máshol van, egy usert kérhetek.

Köszi szépen!

rakj be egy másik szervert közzé. a user sftp-n feltolja a saját szereveredre, a saját kulcsával, onnan pedig auton küldöd tovább a cél felé, akár incrontabbal.

Ez mondjuk egy piszok jó ötlet.

Kössz, kipróbálom.

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

De ha van white listed akkor nem egyszerűbb egy tűzfal szabályt kreálni?
(Tulajdonképpen a Fail2ban is ezt csinálja)

A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!

Igazából nem az a cél, hogy ne tudjanak hozzáférni, mert az meg van oldva* az allow hosts opcióval, hanem arra vagyok kiváncsi, hogy mely egyéb gépek próbálnak hozzáférfni, mert ott valami beragadt beállítás lesz.
Időről időre ránézek a logokra, de jobb lenne, ha automatán jönne valami csatornán, ha valamelyik gép hozzá akart férni.

* - gyanítom, hogy a samba beállításai a kliens oldalon kezelődnek le, és a szerver nem tudja elvenni a jogot a már csatlakozott kliensektől;

Egy androidos klienssel megnyitottam a korábban megosztott /home/juzer/ mappát, és később hiába korlátoztam le a megosztást egy belső mappára, amíg újra nem indítottam a klienst, addig simán hozzáfértem mindenhez, pedig volt samba restart.
Mindezt smb3 protokollal.

Majd tanulmányozom még a lehetséges biztonsági szigorításokat a samba server-ben, hogy ezt, és a hasonlókat (gyanítom, hogy más is van) hogy lehet kiküszöbölni, mert az engedélyezett gépeken is több júzer lehetséges, akiknek különböző jogosultságuk kell, hogy legyen.

[ Szerkesztve ]

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

Adott sw RAID5 tömb, kb. 2T. 5x500GB HDD.
Mivel olvasom, hogy a mdraid nem véd bit rot ellen, váltanék valamire, ami véd diszk halál ellen is, meg bit rot ellen is.
Ki mit használ? Van olyan, akinek régebb óta van btrfs-e, vagy ZFS-e? (És stabil?)
Olyan megoldást keresek, ami 1 winyó halálát túléli, és rendes checksum számítás van...

[ Szerkesztve ]

Mutogatni való hater díszpinty

tizenéve használok ZFS-t, eddig a legnagyobb megelégedésemre, azóta a ZFS Kisegyház elkötelezett híve vagyok
öt lemezzel pont faszán össze tudsz rakni egy RAID-Z tömböt, az egy lemez kihalását gond nélkül átvészeli. havonta automatikusan fut egy scrub, az átvakarja a tömböt, szól ha gebasz van.
egyébként meg fasza snapshot kezelés, stb stb. szóval forrón ajánlom a ZFS-t

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Köszi!

Havonta automatikusan - na itt ezzel lesz gond, ugyanis nem megy 0-24 a NAS Ez ugye a NAS-om, és általában off van.
De gondolom scrub futtatható cron-ból is, azaz ilyesmit olvastam.
Az a bajom, hogy 5 SATA-s a lap, tehát nem tudom, bele tudok-e dobálni még egy 500-as winyót; akkor lehetne Raid-Z2, vagy mezei RAID6 is.
Még annak utánanézek, hogy mennyire macera pl. kicserélni alatta a diszketet, meg méretezni. (Alapvetően 250GB-os winyókkal kezdte ez a tömb, és 2x lett alatta mind cserélve.)

Illetve; sebességben milyen a viszonya ennek egy mezei md RAID5-höz?

Mutogatni való hater díszpinty

a scrub indítható akár kézzel is
hdd csere nem nagy truváj, elfaileled a diszket, amit ki akarsz venni, kicseréled, aztán azt mondod, hogy zpool replace kötetNév régiHDD újHDD
átméretezést egyszer csináltam (miután kicserélgettem a diszkeket), úgy rémlik kifejezetten fájdalommentes volt az is, de a konkrét parancsokra már nem emlékszem.
az ArchWikin sokmindenre kiterjedő leírás van a ZFS-ről, érdemes átböngészni

sebesség tekintetében viszont passz. nem rémlik, hogy valaha lett volna tapasztalatom RAID5-tel

[ Szerkesztve ]

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Köszi Ez Raid5-ön is kb. így megy

Mutogatni való hater díszpinty

Kipróbáltam mindkettőt, és a Btrfs mellett tettem le a voksom.
A ZFS-nek van 2, számomra viszonylag nagy limitációja (hasonló gyökérből fakadnak):
- nincs defrag (pedig ha kvázi-állandóan írsz rá, akkor de, igen, töredezik... lalalalááá...)
- nem lehet RAID profilt váltani, beleértve, hogy nem tudsz pl. 3-ról 5 lemezre bővíteni.
Ami ZFS-ben jobb, az a saját scheduler és cache management, beleértve a most már tudtommal akár perzisztens (reboot-ot túlélő) L2 cache (de ahhoz külön vdev kell, tehát pl. egy dedikált SSD). Illetve ott elvileg nem fordulhat elő, hogy áramszünet/pánik miatt félbemarad egy olvas-módosít-ír ciklus, de ez úgy tudom, hogy csak szinkron írás módban igaz, és ha nem adsz hozzá külön vdev-et (sőt, ezt javasolt 2 lemezre tükrözni, mert átmenetileg csak ezen él egy példányban az inten log, vagyis ami majd írva leszen a tömbre - ennek megfelelően olyan SSD-t javasolnak, amin van áramtartalék kondenzátor), akkor az lassú művelet (ezért kapásból át is lehet irányítani a szinkront aszinkronná, ha nincs hozzá külön vdev-ed, és jobban érdekel a sebesség, mint adatbiztonság).
Szeirntem Btrfs-ben is tök egyszerű lenne kiküszöböni, ha manuálisan állítható lenne a stripe size (de valamiért még mindig nem az), és beállítanál pl. 5x 512n HDD-kkel 4k szektor és 4k leaf size-t (akkor eleve sohasem lenne részleges felülírás).
A Btrfs-nél 10+ éve "majd egyszer" mindkettő. A kézi stripe size és a vdev-szerűség is. A "write-hole" dolgot meg akarták egyszer oldani Btrfs-ben a Microsoft Storage Spaces-hez hasonló módszerrel, csak rájöttek, hogy az lassú (viszont SS-el el lehet játszani a stripe size / sector size trükköt, és akkor gyors, Btrfs-el nem engedik), ha nincs külön vdev (és azt sem akaródznak bevezetni).

[ Szerkesztve ]

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Köszi

Ezek kisebb gondok. Írva ritkán van, tömb bővítés nincs tervben, max. nagyobb diszkekre költözés néha. (Ahogy muszáj.)

Btrfs-el a RAID 5 jellegű kiosztás lenne macera, az elég instabil, ahogy olvasom.

Mutogatni való hater díszpinty

Üdv Mindenkinek!

Érdeklődnék, hogy van-e olyan Linux(BDS, ...) program(pl: Boot-menedzser, GRUB, bármi), ami bootoláskor létrehoz egy virtuális meghajtót a RAM-ban(Ramdisk), oda bemásolja a Linux-ot, az ott elfutkározik, majd kilépéskor szinkronizálja magát az lévő eredetivel és kilép!

Van a vasnak UPS-e, vagy Noti/lapostop lesz, tehát akkor is "van".

Előre is:

[ Szerkesztve ]

Nem a Dockert keresed? Bár az nem egészen ez.

Mutogatni való hater díszpinty

Nem tudom. Mi/ki az? Van (esetleg) magyar leírása?
Kb ezt tudják a Live LINUX-ok, amik RAM-drive-ban futnak, 10-20-éve.
Azért gondoltam, hogy van erre megoldás. Van?

[ Szerkesztve ]

A docker egesz mas.

https://www.coreinfinity.tech

Amúgy mi a cél? Hátha az segítene. (@Sh4d0w, ezért mondtam a Dockert, mert hátha igazából az a funkcionalitás kell neki.)
Openwrt fut hasonlóan, overlayben. Lehet az overlaynek kéne utánagugliznod.

Egyklikkes megoldás amúgy nem hiszem, hogy lesz.

Itt valami olyan a megoldás, hogy RAID1-el a meglevő diszkhez a Ramdisket.

[ Szerkesztve ]

Mutogatni való hater díszpinty

Tedd egy gyors SSD-re (akár Optane-ra, az random is gyors és alacsony késésű), és kész.

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Van/volt vmi bootmanager, aminek a korábbi változata lemezről inditva BIOS-t javitott kiegészitett USB-boottal. Az egyik újabb változat mintha tudna már UEFI-t nem UEFI-s alaplapra, REBAR-t, stb...
Mintha annak lenne ilyen boot alatt ramdisket felépitő, majd használó funkciója.
Talán egy francia/holland egyéni programozó csinálgatta régen.
Évekkel ezelőtt mér volt ilyen RAM-disk funkció, vagy volt tervben.

A régi floppy-ról is futott, az ujabbak már a gépek belső pendrive/SD-kártya helyre rakhatók, "örökre"...

Ennyire emlékszem!

Például: max 64 GB-os rendszert akarok pendriveon cipelgetni a gépeim között, amiknek 128(+)GB RAM-ja van, tehát fussa belőle a teljes 64 GB-ot akár másolgatni, de nem akarom mindig megbontogatni a gépeimet SSD, egyéb megoldások miatt.
BOOT-oljon be, kérdezze meg, hogy akarok-e RAMdrive-ban futtatni(mekkorában) a pendrive-on lévő OS-ek közül vmelyiket, vagy marad a hagyományos, pendriveról vánszorgó csiga-biga üzemmód.

[ Szerkesztve ]

Akkor volt talán némi értelme, mikor lassú HDD-ről futott a rendszer.
Vagy még akkor lehet, ha egy tömörített file-ból boot-olsz (pl. pici és lassú NAND flash, agyontömörített tartalommal, de viszonylag sok RAM egy embedded kütyün).
Egy másik: /etc/sysctl.conf fie-ba: vm.vfs_cache_pressure = 1 (vagy 0, ha sok a RAM), és akkor mindig pagecache-ben marad a filesystem metadata (így hamar rátalál az adatra lemezen).

[ Szerkesztve ]

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Plop bootmanager-re emléxek ilyen svájcibicskának, de az nem erre való volt, csak bármiről tudott indítani. A Super GRUB Disk pl. ilyen bootjavítós cucc.

BTW ha csak annyi kell, hogy megmaradjanak a Live CD-ről az adatok, akkor pl. lehet ilyet, hogy pendrive-ra teszed, és azon van egy partíció, amire lehet menteni. (Preserved space.)

[ Szerkesztve ]

Mutogatni való hater díszpinty

Alkalmazási példa: max 64 GB-os rendszert akarok pendriveon cipelgetni a gépeim között, amiknek 128(+)GB RAM-ja van, tehát fussa belőle a teljes 64 GB-ot akár másolgatni, de nem akarom mindig megbontogatni a gépeimet SSD, egyéb megoldások miatt.

BOOT-oljon be, kérdezze meg, hogy:
akarok-e RAMdrive-ban futtatni,
mekkorában,
a pendrive-on lévő OS-ek közül melyiket,
vagy maradok a hagyományos, pendriveról vánszorgó, RAM-drivehoz képest csiga-biga üzemmódban.

Nem akarnék erre a kis részfeladatra egy (VMWare, ...)virtuális gépet használni.

Igeeen, a PLOP az, beugrott a neve, így, hogy láttam leírva!!!

janos666: Egy pendrivenál bármelyik RAMdrve sokkal gyorsabb lesz, ha van hozzá elég RAM. Ezért használnám ki a lehetőséget, ha van ilyen.

Van?

[ Szerkesztve ]

USB-ről lehet futtatni Linuxot, ha USB3, akkor kb. ugyanaz a sebesség, mint a beépített SSD-ről (amíg nem swappel).
USB2-n gondolkodósabb, de használható.
Mondjuk pendrive-ről nem is érdemes, hamar megöli, én is SSD-t használok.

Mehet ez is akár RAM-ból, csak minek; én ilyet használok utazáshoz, de asszony is ilyenről nyomja a gépeit

Illetve : nem kell neked ehhez visszafele szinkron; a home könyvtáradat kell visszamásolni egy megfelelő partícióra a pendrive-on.

Ha nagyon kell, mondj egy tárhelyet, és diszk image-ként tudok adni egy belakottat. (16GB)

[ Szerkesztve ]

Mutogatni való hater díszpinty

Ez is érdekes lehet neked.

De tkp. tényleg annyi kell, hogy egy telepített OS-t behúzz a RAM-ba, és mielőtt lelövöd, kiírod a /home/usered -t mondjuk egy külön partícióra az USB eszközön.

Mutogatni való hater díszpinty

Tessék, van egy raklap.
SSD-k óta nem érdekel senkit. Az USB boot distro-k, mind nagyrész RAM-ban futnak, egyszerűen csak csinálj egy persistens USB boot installt és pont ezt fogja csinálni, amit leírtál. Extrába csinálhatsz temp RAM driveokat.

Vannak már USB4 / ThunderBolt4 <-> M.2 NVMe SSD házak is, de nem kell olyan messzire menni, USB 3.x is elég lesz. Tehetsz bele pl. Optane P1600X-et. Le merem fogadni, hogy ezerszer gyorsabb lesz a boot, mint ha meg kéne várnod a RAMdisk-be másolást (illetve leállításkor a visszaírást), futtatás közben pedig nem hiszem, hogy észre tudnád venni a különbséget (talán kimérni is nehéz lenne még hagyományos SATA AHCI SSD-vel is).
De nem muszály Optane-nal építeni (csak azért javasoltam ezt, mert jobb random műveletekben, mint a NAND és szinte elnyűhetetlen írással ahhoz képest). Ha a méret is számít, vagy magasabb szekvenciális sebességre vágysz, lehet NAND M.2 SSD is.

[ Szerkesztve ]

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

BOOT-managerek között nincs olyan, amelyik tudja ezt, amire szükségem van?

hcl: Az az ubuntu-s jó, ott mi csinálja meg a feladatot?

Teljesen lényegtelen, egy értelmes NAND-os ~100MB-t tudó USB-n se fog egy "live" rendszer gyorsabban menni, mert RAM-ban lesz alapból. Az hogy presistens rész kiírásához kikapcsoláskor 20mp-t vagy 50mp-t kell várni már édes mindegy valószínűleg.
Amiket irkáltok ezer éve megoldott problémák.

Lehet, hogy felületesen olvastam. Tudom, hogy a Live! eleve RAM-ból fut, ezért gondoltam, hogy nem Live! rendszerről van szó.

TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

Na azt jól benéztem, mert 11.x-hez volt

Ez jobb lesz
A mkusb tudja, arrafelé gugliznék.

"várom annak a GRUB/LILO/... programnak a nevét ami ezer éve tudja a "bármi-telepitett-OS" RAMdrive másolását majd indítását!"
GRUB, meg a Linux kernel. Ott is van az USB-s Debianos cikkemben, csak azt elég macera összerakni a nulláról

[ Szerkesztve ]

Mutogatni való hater díszpinty

"... Amiket irkáltok ezer éve megoldott problémák."

Nagyszerű hír : várom annak a GRUB/LILO/... programnak a nevét ami ezer éve tudja a "bármi-telepitett-OS" RAMdrive másolását majd indítását!

Egy XOSL és a grub4Dos-nál olvastam valami reménykeltő dolgokat, de nem vagyok benne ezekben (még) a szükséges mélységben.

Valaki hallott ezekről?

Grub4DOS pl. az ős-Hiren's Bootcd-ken volt.
De nézd meg a #33597 -t.

Mutogatni való hater díszpinty