Re: VM+NFSD bug

2018-07-30 bef zés Ferenc Wágner
Szima Gábor  writes:

> Hogyan lehetne megtrace-elni?

Például tcpdump/wireshark.  Initramfs csatolná fel az NFS rootot, vagy
közvetlenül a kernel?  MTU probléma nincs?
-- 
Feri
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: titkositott particio tapasztalatok

2017-08-11 bef zés Ferenc Wágner
Lajber Zoltan  writes:

>> hanem minden titkos, ami az lehet.  A boot partíció sajnos nem lehet,
>> azon ne tarts érzékeny adatot, és tudj róla, hogy azt rosszindulatúan
>
> http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/

Ez azért megtévesztő: a GRUB (eleje) nem a titkosított partíción lakik,
ezért normális esetben nem biztonságosabb ez a setup, mitha
titkosítatlanul hagytad volna a boot partíciót.  Ha tartasz bármiféle
titkot a boot partíción, akkor természetesen más a helyzet, de miért
tennél ilyet?

> -kulso (usb, sdkartya) dev-en tartom a kulcsot, es ezt kiveszem,
> amikor elrakom a laptoptot.

Akkor már érdemesebb lehet az egész boot partíciót (vagy legalább a boot
loadert, ha a boot partíciót titkosítod) a külső eszközön tartani.  Vagy
secure bootot használni, de ez messzire vezet...
-- 
Feri
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: titkositott particio tapasztalatok

2017-08-09 bef zés Ferenc Wágner
Zsolt Gádori  writes:

> Azt szeretném megkérdezni, hogy:
> - tapasztalat szerint egy titkosított partíció használata mekkora plusz
>   teljesítményt (cpu-memória) igényel?

A laptopjaimat kizárólag titkosítva használtam, ezért változásról nem
tudok beszámolni.  De normál használat mellett nem okozhat észrevehető
lassulást, mert a kódoláshoz nem szükséges számottevő CPU teljesítmány,
a diszk meg egyébként is lassú.

> - érdemes-e a rendszer partíciókat is titkosítani, vagy elég csak a
>   userekét?

Az egyszerűség kedvéért én két partíciót használok: egy kis bootot a
diszk elején, és egy másodikat a maradék területnek, amit titkosítok,
aztán LVM-mel tovább darabolom.  Lehetnek érzékeny adatok a /etc és a
/var alatt is, a /usr-t pedig már nem szokás külön partícióra tenni.  A
swapre (szinte) bármi kimehet, így azt is titkosítani kell (különösen,
ha hibernálni is akarsz).  Legjobb, ha nem kell esetenként gondolkodni,
hanem minden titkos, ami az lehet.  A boot partíció sajnos nem lehet,
azon ne tarts érzékeny adatot, és tudj róla, hogy azt rosszindulatúan
lehet módosítani, ha egy időre kikerül az adathordozó az ellenőrzésed
alól.

> - egyáltalán, melyik partíciókat érdemes titkosítani?

Lásd fent.

> - meg mondjuk ha ez a disk egy usb-n időnként felcsatlakoztatott
>   dolog, akkor ott mennyi idő a mount?

Érdemi lassulás csak a jelszópromptból fog származni.  Azt elkerülheted,
ha a jelszót a (szintén titkosított!) / partíciódon tárolod.

> - rendszer upgrade esetén mennyire kompatibilis a régi bútor az új
>   házzal?

Nem értem a kérdést, de a dm-crypt egyáltalán nem új találmány.
-- 
Feri
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: Frissítési probléma

2017-05-09 bef zés Ferenc Wágner
Kovács Gábor  writes:

> # apt-get -f install
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Correcting dependencies... failed.
> The following packages have unmet dependencies:
>  libxrandr2 : Depends: libx11-6 (>= 2:1.6.0) but 2:1.4.99.1-0ubuntu2.3 is 
> installed
>   Breaks: libxrandr2:i386 (!= 2:1.4.2-1) but 2:1.3.2-2ubuntu0.3 
> is installed
>  libxrandr2:i386 : Breaks: libxrandr2 (!= 2:1.3.2-2ubuntu0.3) but 2:1.4.2-1 
> is installed
>  xbase-clients : Depends: xinit but it is not installed
> E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
> held packages.

És vannak esetleg tartott csomagjaid?

aptitude search "~ahold"
dpkg --get-selections | grep 'hold$'
-- 
Feri
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: Shell trace

2017-05-05 bef zés Ferenc Wágner
Attila Rajmund Nohl  writes:

> Egy shell (elég ha csak bash-ra megy, de ha ksh-ra is működik, még
> jobb) scriptben szeretném logolni, hogy milyen parancsok hajtódnak
> végre milyen kimenettel úgy, hogy közben minden kimenetet a user is
> lásson. Nagyjából a 'set -x' kimenetét szeretném elmenteni. Amit
> próbáltam:
>
> exec &> >(tee $LOGFILE)
> exec 2>$TRACEFILE
>
> Elakad, ha a script meghívja önmagát még akkor is, ha a második
> futásnál a LOGFILE értéke más (gondolom a két tee akad össze). Továbbá
> a hibaüzenetet (ami stderr-re megy) nem látja a user. És nem megy ksh
> alatt sem (valamiért ezt a tee-s subshell-t nem szereti). Ha csak az
> stderr-t irányítom át, akkor működik ksh-val is és az is megy, hogy a
> script meghívja önmagát, de a kimenet ugye nincs meg. Ötlet?

Mit jelent az, hogy "elakad"?  Nekem ez működik (csak megtévesztő, hogy
a prompt visszaadása után is ír még egy kicsit):

#!/bin/bash

logfile="${1:-debug}.log"
exec 3>&2 2> >(tee "$logfile" >&3)

set -ex

echo $USER to stdout
echo $HOME to stderr >&2

[ "$1" = break ] && exit

echo calling myself
./debug break

echo exiting

Külön is logol a break.log fájlba, meg egybe is a debug.logba.  Persze
az stdout és az stderr szinkronja elveszik, mert az utóbbi áthalad a
független tee processzen is.
-- 
Feri
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: backscatter?

2017-01-09 bef zés Ferenc Wágner
Salamon Attila  writes:

> Van egy Postfix levelező szerver, ami fogadja az example.hu -ra érkező
> leveleket.
> Vírus/spam szűrés után továbbküldi a céges Exchange -nek.
> Ha nem létezik a címzett, akkor az Exchange 5xx -es hibakódal eldobja a
> levelet, amikor a Postfix megpróbálja továbbítani neki.
> Ezért a Postfix visszaküld egy levelet a feladónak, hogy nem
> kézbesíthető a levél. Szerintem ez így korrekt is.
> Szerintem most azért került az IP spam listára, mert az egyik feladó
> spam-trap cím volt. Nem is lett volna baj, ha a Postfixet futtató gépen
> az amavisd felismerte volna, hogy spam és eldobja a levelet, de nem,
> ezért kerülthetett a spam csapdába a visszapattanó levél.
>
> Hogy kezelhető az ilyen helyzet?

Csinálj a spamszűrő relayen címellenőrzést (recipient address
verification), és akkor ellenőrzés helyett rögtön visszautasítod az
ilyen leveleket.  (Sosem használtam Postfixet, de a doksi bíztató:
http://www.postfix.org/ADDRESS_VERIFICATION_README.html)
-- 
Feri
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: problem linux

2016-10-17 bef zés Ferenc Wágner
dr. Zana János  writes:

> A linuxom már egx éve kifogástalanul működik. Ma reggel bekapcsolás
> után a karbantartási üzemmód jött fel.

Én olyannal próbálkoznék, hogy systemctl --failed, aztán systemctl
status -l azokra, amelyeket az előző kidobott.  Ha a less levágja a
sorok végét, akkor -S neki.
-- 
Feri
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: ulimit ubuntun

2016-10-10 bef zés Ferenc Wágner
"Magosányi, Árpád"  writes:

> Szeretnék a chrome-omnak ulimitet adni: dögöljön meg ha sok memóriát eszik.
>
> Mindezt úgy szeretném, hogy bárhogyan indíthassam, és az upgrade se
> rontsa el.
>
> Egyelőre csináltam egy scriptet, ami beállítja a limiteket, és az
> alternative mechanizmust használom.
>
> Az update-alternatives --install mondta, hogy nem csinál semmit a
> /usr/bin/chromium-browser binárissal,
>
> azt kézzel átneveztem, és egy symlinket tettem a helyére.
>
> Az a gyanúm, hogy az upgrade ezt felül fogja vágni, azt meg biztosan nem
> fogja tudni, hogy mire neveztem át az eredeti binárist.
>
> Mi lenne a korrekt megoldás?

dpkg-divert --local --rename /usr/bin/chromium-browser
-- 
Feri
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: revoke key

2016-06-29 bef zés Ferenc Wágner
Kiss Gabor  writes:

> On 06/29/2016 09:11 AM, Lajber Zoltan wrote:
>
>> On Wed, 29 Jun 2016, Kiss Gabor wrote:
>> 
>>> Ha létezik "biztos hely", akkor miért ne magát a titkos kulcsot
>>> tárolná ott? :-)
>> 
>> Egyik biztos helyen a privat kulcs, másik biztos helyen a revoke key
>> szerintem jó ötlet.
>
> Mennyivel jobb, mint egyik biztos helyen a privát kulcs és a másikon
> is? :-)

A privát kulcs inkább semmisüljön meg, minthogy más kezébe kerüljön.  A
visszavonó tanúsítványnál ez pont fordítva van.  Vagyis a kettő
különböző feltételeket támaszt a "biztos hellyel" szemben.
-- 
Feri
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: revoke key

2016-06-28 bef zés Ferenc Wágner
Zana János  writes:

> Úgy jártam, mint az egyszeri ausztrál őslakos, aki új bumerángot
> készített, én nem tudja eldobni a régit.
> 
> Készítettem magamnak új kulcsot, és most visszavonnám a régit. Sajnos,
> nem megy. A régit 16 évvel ezelőtt készítettem, azóta többször új
> számítógépet telepítettem. A private (secret) key ott lapul valamelyik
> sarokban porosodó régi winchesteren. A jelenlegi private key csak a
> jelenleg érvényes kulcsom visszavonására lenne alkalmas.
>
> Végignéztem a man gpg teljes szövegét, de nem találtam olyan utalást,
> amely leghetővé tenné akár a név, akár az ujjlenyomat, akár a
> kulcsszerver nevének használatával visszavonni a régi kulcsot.
>
> Vagy van ilyen lehetőség, csak én nem találom?
> (A régi passphrase-re valósznűleg emlékszem.)

Egy kulcs visszavonásához visszavonó tanúsítványra (revocation
certificate) van szükség.  Ilyet csak a privát kulcs ismeretében tudsz
készíteni.  Ha nem készítetted el előre, akkor most kell előásnod a régi
kulcsodat.  Egyébként javasolt új kulcs készítésekor rögtön visszavonó
tanúsítványt is készíteni hozzá, és eltenni biztos helyre, hogy ne
legyél bajban, ha elveszíted a privát kulcsod.  Vagy másra is ruházhatod
a kulcsod visszavonásának jogát (addrevoker), de természetesen ehhez is
kell a privát kulcs.
-- 
Feri
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

Re: usb portot soros portnak láttatni

2016-05-20 bef zés Ferenc Wágner
Gádori Zsolt  writes:

> Az van, hogy fejlesztek egy programot, ami /dev/ttySX-et fog használni
> a cél környezetben. Az asztali gépemen van hw soros port, ott semmi
> gond, de a laptopomon már nincs, itt csak USB van. Nomost a laptopon
> nem bírom fejleszteni/tesztelni az adott programot, mert leáll azzal a
> hibaüzenettel, hogy nincs ilyen hw eszköz.
>
> A kérdés az volna, hogy van-e valami módszer arra, hogy "becsapjam" a
> programot? Az nem szükséges, hogy a fejlesztés során tényleg használni
> is tudja a portot (ezt meg tudom oldani, hogy ne legyen rá szükség) de
> sokat segítene, ha legalább "felismerés", tekintetében rá tudnám
> szedni őkelmét.

Nézd meg ezeket:
http://stackoverflow.com/questions/52187/virtual-serial-port-for-linux
-- 
Feri
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux