Hi!
Na, mivel már sokadszor kerül szóba: A /dev/random lassú. Onnan
kiolvasni sok száz gigát nem hatékony.
Egyetértünk, ezért is volt az eredeti hozzászólásban /dev/urandom.
Azzal mi a baj?
Üdv
Zsolt
_
linux lista - linux@mlf.linux.r
On 01/22/2016 06:20 PM, Volarics István wrote:
> A VG szabad helyén csinálsz egy LV-t azt ezt telenyomod
> dd if=/dev/random of=/dev/vg/lv
> és ha végzett letörlöd az LV-t és így amíg új PV-t nem raksz be
> nem is kell foglalkoznod a dologgal.
Na, mivel már sokadszor kerül szóba:
A /dev/random la
Kiss Gabor írta (2016. január 22. 18:03):
> Akkor nincs semmi gond. Szokták is.
Mindenkinek köszönöm a válaszokat.
Üdv:
Viktor
>
> g
> _
> linux lista - linux@mlf.linux.rulez.org
> http://mlf.linux.rulez.org/mailman/listinfo/linux
___
Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
dd-vel telirakni a titkosított kötetet egy óriásfile segítségével,
amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés
A VG szabad helyén csinálsz egy LV-t azt ezt telenyomod
dd if=/dev/random of=/dev/vg/lv
é
On 01/22/2016 04:53 PM, Keller Viktor wrote:
>>> Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
>>> dd-vel telirakni a titkosított kötetet egy óriásfile segítségével,
>>> amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés
>>
>> -> Known plaintext attack
>> (
Kiss Gabor írta (2016. január 22. 12:59):
>
> On 01/22/2016 10:42 AM, Keller Viktor wrote:
>> Zs írta (2016. január 22. 0:41):
>>> precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az
>>> öntökönlövés szigorú esetét állítjuk elő!!!
>>
>> Csak kíváncsiságból, a partvonalról kér
On Thu, Jan 21, 2016 at 04:30:03PM +0100, Kiss Gabor wrote:
> On 01/21/2016 03:28 PM, Kosa Attila wrote:
> > Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
> > legalabb az online meretnoveles mukodjon.
>
> Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.
>
>
On 01/22/2016 10:42 AM, Keller Viktor wrote:
> Zs írta (2016. január 22. 0:41):
>> precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az
>> öntökönlövés szigorú esetét állítjuk elő!!!
>
> Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
> dd-vel telirakni a
On 01/22/2016 09:56 AM, Kosa Attila wrote:
> On Thu, Jan 21, 2016 at 04:30:03PM +0100, Kiss Gabor wrote:
>> On 01/21/2016 03:28 PM, Kosa Attila wrote:
>>> Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
>>> legalabb az online meretnoveles mukodjon.
>>
>> Az LV-n található block device-
Zs írta (2016. január 22. 0:41):
> precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az
> öntökönlövés szigorú esetét állítjuk elő!!!
Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után
dd-vel telirakni a titkosított kötetet egy óriásfile segítségével,
amit rö
Hi!
Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
legalabb az online meretnoveles mukodjon.
Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.
Es egy snapshot is csak a titkositott eszkozt fogja
"lefenykepezni", ugye? Tehat jelszo nelkul az sem lesz olvash
On Thu, Jan 21, 2016 at 04:30:03PM +0100, Kiss Gabor wrote:
> On 01/21/2016 03:28 PM, Kosa Attila wrote:
> > Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
> > legalabb az online meretnoveles mukodjon.
>
> Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.
Es
On 01/22/2016 12:41 AM, Zs wrote:
> Az új terület random adattal feltöltése elhagyható, de security szempontból
> nem szerencsés - elkövetése esetén viszont *nagyon* észnél kell lenni és
> precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az
> öntökönlövés szigorú esetét állítj
Hi!
Megoldás lehet a cryptsetup is, bár amiatt, hogy ez már nem
filerendszert titkosít, hanem egy teljes kötetet, az utólagos
beüzemelése nem feltétlen, egyszerű - cserébe viszont olyan
fs tehető rá, amilyet akarunk.
Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
legalabb az online
On Thu, 21 Jan 2016, Kosa Attila wrote:
Nekem a lenyeg az lenne, hogy Debianon minel kevesebb
barkacsolassal mukodokepes legyen, a rendszerindulas folyamataban
a leheto legkevesebb fennakadast okozza, a performanciaban ne
okozzon jelentos visszaesest az alkalmazasa.
Johetnek a tippek, hogy mer
On 01/21/2016 03:28 PM, Kosa Attila wrote:
> Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni,
> legalabb az online meretnoveles mukodjon.
Az LV-n található block device-t kell titkosítani, és menni fog a bövítés.
Tizensok éve a loop-aes a kedvencem, de már kivették a Debianból.
A dm-c
2016-01-21 14:40 keltezéssel, Kosa Attila írta:
Hello!
Egy szolgaltato virtualis gepen kellene egy adatbazisban olyan
adatokat tarolni, amelyekhez nem kellene hozzaferniuk attol, hogy
esetleg direktben elerik a diszket. Emiatt valamilyen titkositott
fajlrendszerre gondoltam. Meg nem kezdtem el ny
On Thu, Jan 21, 2016 at 03:11:00PM +0100, Zs wrote:
>
> >Egy szolgaltato virtualis gepen kellene egy adatbazisban olyan
> >adatokat tarolni, amelyekhez nem kellene hozzaferniuk attol, hogy
> >esetleg direktben elerik a diszket. Emiatt valamilyen titkositott
> >fajlrendszerre gondoltam. Meg nem kez
Hi!
Egy szolgaltato virtualis gepen kellene egy adatbazisban olyan
adatokat tarolni, amelyekhez nem kellene hozzaferniuk attol, hogy
esetleg direktben elerik a diszket. Emiatt valamilyen titkositott
fajlrendszerre gondoltam. Meg nem kezdtem el nyomozni, hogy
mely megoldasok a legelterjedtebbek
Hello!
Egy szolgaltato virtualis gepen kellene egy adatbazisban olyan
adatokat tarolni, amelyekhez nem kellene hozzaferniuk attol, hogy
esetleg direktben elerik a diszket. Emiatt valamilyen titkositott
fajlrendszerre gondoltam. Meg nem kezdtem el nyomozni, hogy
mely megoldasok a legelterjedtebbek m
20 matches
Mail list logo