Napi hápé

Beszólt nekem a HP valami szutyok aszisztantja, hogy lám, szoftverfrissítés érkezett. Jól van akkor, legyen tánc, frissüljél.

Neki is állt bőszen letölteni a százmegákat, majd legott telepítette is őket. Akkor jött az első meglepetés, miszerint hogy már frissebb a rendszer mint a frissítés.

– Hát jó, akkor ne telepítsd –, mondtam neki. Nem is telepítette, ezzel még nem is volt gond. Az igazi meglepetés akkor ért, amikor jó pár másodperc töprengés1 után visszakérdezett a masina, hogy oké, de most akkor most mi van? Sikerült amit akartál vagy nem? Vagy ki tudja?

És ezt kétszer is.

  1.  i7-7700HQ, 16G, NVME SSD

Raspberry PI3 NAT sebességteszt (NAT speedtest)

Nagyobb tesztet terveztem, de az összecsapott is annyira meggyőző volt, hogy nem láttam értelmét tovább küzdeni vele.

Röviden: átnatol ~ 100Mbit/s sebességet, és könnyedén.

A részletek:

root@gw:~# lsusb
Bus 001 Device 004: ID 0b95:772b ASIX Electronics Corp. AX88772B
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Az iperf (3.1.2, 64 bit) vagy a windows (két windows gép között teszteltem, az egyik laptop) nem bírta az elvileg lehetséges 128 konkurrens kapcsolatot, sőt, ötvennél is problémák voltak, ezért négy szervert és négy klienst indítottam, az alábbi paraméterekkel (20 szál, 200 másodperces futás):

 iperf3.exe -P 20 -t 200 -p 5201 -c 172.16.123.195
 iperf3.exe -P 20 -t 200 -p 5202 -c 172.16.123.195
 iperf3.exe -P 20 -t 200 -p 5203 -c 172.16.123.195
 iperf3.exe -P 20 -t 200 -p 5204 -c 172.16.123.195

Ahol a 172.16.123.195 a szerver címe. A teszt végén az alábbi összegzést kaptam (egy a négyből, a többi is kb. ennyi volt):

iperf3 - raspberry pi NAT results

iperf3 – raspberry pi NAT results

Some errors during testMenet közben akadt pár gyanús sor, amit nem tudok hová tenni, de kicsit gondolkodva, kár hogy nem futtattam újra a tesztet, hosszabb interval-lal, mert ránézésre 128k-s egységekben mért, és lehet hogy szimplán nem jutott át a dróton a delej az interval (1s) ideje alatt.

Érdekes paraméter lehet még a PI CPU terhelése, ami a ksoftirqd volt úgy nagyjából 13-17% közötti értékkel. Alighanem ez lehet a konkrét szűk keresztmetszet gigabit esetén. Sajnos a sar-t elfelejtettem időben telepíteni, ez már eleve megásta a rendes teszt sírját.

És jobb lett volna gigabit ethernet adaptert vennem (meg direktbe kötni a gépeket, nem switch-en át), de mivel a saját tapasztalataim ugyanazok, mint a neten megtalálható többi teszt, ezért nem nagyon stresszelek ezen. A lényeg, hogy a PI frankón natol, annyira, hogy a korlát már a teszre használt gépek és/vagy az USB – ethernet adapter képessége.

Igen, egy korrekt teszt úgy nézne ki, hogy kb. 100 különböző címről, 100 különböző címre nyitok többszálú kapcsolatot, de ahhoz nagyon más holmi kellene mint ami itthon van. És amikor hasonló teszteket csináltunk, akkor mindig a tesztforgalom generálására használt eszköz limitjeit értük el, a szerverek, hálózati elemek fel se melegedtek.

Szóval RPI3:  jó routernek is 😀

Ne csak nézz…

A közelmúltban két érdekes és összecsengő dologba futottam bele. Az egyik egy Canon nyomtató reklámja, ami azon túl, hogy egyértelművé teszi, hogy aki nem ezt használja az egy lúzer, állítja, hogy egy profi fotográfus sokkal több figyelmet fordít a részletekre mint egy átlagember:

Ez még mondjuk annyira nem is lenne érdekes, hiszen anno elég sokszor elmondták az öregek is, hogy tessék látni is, ne csak nézni. Megfigyelni a részleteket, mi miért és hogyan van, miért jó egy jó kép, és miért vacak egy vacak. Nomeg egyáltalán, nem egy hihetetlen dolog.

Nagyon tetszett viszont, az a hír, amibe kicsivel a fenti reklám után botlottam. Egy múzeum felvette a harcot a katt — következő festmény — katt– következő festmény — katt — következő festmény — katt, anyád, lemerült, megtelt, ménnemmegy „múzeumlátogatókkal”, akik végignéznek akár száz képet vagy műtárgyat is anélkül, hogy akár egyet is látnának.

hierteekenenÍgy még nyilván nem lesz mindenki fotóművész, de egy-egy képben (mert többre úgyse lesz ideje :D) több érdekességet fog felfedezni mint mások egy egész napos kattogás és rohanás után az egész múzeumban.

Így tényleg élmény lehet a múzeumbam galériába menni, nem pedig kötelesség mert a Julikájék (sic!) is voltak tavaly és megnézték a Lúvrot és mondták hogy milyen csodálatos.

Még ha tényleg az is 😀

És nem kell messzire menni pár érdekes múzeumi esemény miatt: www.szepmuveszeti.hu/muzeumplusz

Kis színes: a SEO plugin szerint a FK pontja az írásnak 24.1, ami szerint ezt jobb ha csak olyan olvassa, akinek legalább diplomája van. Csak azért, mert összetett mondatokat használok és nem olyanokat mint egy gép

NBP filesize is 0 Bytes – pxe + uefi

Ha már blog, akkor következzen a mai napra rendelt tanulság.

Laptopot kellett lementeni, ebben semmi macera nincs általában. Hálózati boot, clonezilla, szia. A probléma akkor kezdődött, amikor kiderült, hogy ez egy UEFI-s laptop. Eddig nem volt ilyen modern berendezésünk – jó, volt, de azt nem akartam így menteni – így ezidáig szintén ingerküszöb alatt maradt a hálózatos mentés beállítása.

Alapvetően ezzel se volt baj. A következők kellettek a dhcp konfigba (dhcp3, a dhcp4 elvileg már fejből tudja):

option architecture-type code 93 = unsigned integer 16;

Illetve pár feltétel ellenőrzése:

if option architecture-type = 00:00 {
 filename "BIOS/pxelinux.0";
 } elsif option architecture-type = 00:09 {
 filename "EFIx64/syslinux.efi";
 } elsif option architecture-type = 00:07 {
 filename "EFIx64/syslinux.efi";
 } elsif option architecture-type = 00:06 {
 filename "EFIia32/syslinux.efi";
 } else {
 filename "BIOS/pxelinux.0"; 
}

 A régi, „bios” holmit egy az egyben átrámoltam a BIOS/ alá, és csináltam egy EFIx64 könyvtárat. A kernel.org-ról letölthető a komplett syslinux, abból ki lehet mazsolázni a szükséges darabkákat. Minden nagyon vidám és boldog volt, egész addig, amíg ki nem derült, hogy a nyomorult laptop azértse akar bootolni. Azt, hogy miért kiírta ugyan, de kb. 0.25 másodpercig, utána az el is tűnt. A technika csodája – 60 FPS-sel rögzíteni képes telefon – segített az elvillanó felirat elolvasásában. És lám, ez volt a hibaüzenet:

NBP filename is EFIx64/syslinux.efi
NBP filesize is 0 Bytes
Downloading NBP file...

PXE-E99: Unexpected network Error.

A megoldás végül is csak annyi volt (kihagyom a sok google–zsákutcát), hogy a meglévő tftpd csomagot kellett leszedni, és a tftp-hpa csomagot feltenni helyette (apt-get remove tftpd && apt-get install tftpd-hpa).

Amúgy is, kb. minden leírás a tftp-hpa csomagot javasolja, én persze anno azért se azt tettem fel. Eddig működött is, csupán most szerzett egy-két órányi bosszankodást.

A tanulság: ha azt írják hogy használj tftp-hpa-t, mert az jó, akkor használd azt, vagy előbb-utóbb meg fogsz lepődni és jöhet apt-get remove tftpd && apt-get install tftpd-hpa.


[zotpress collection=”A5SQEJ7T”]

Exim autoreply LDAP csoport alapján

Mivel ezt amúgy is le kellene írnom a belső dokumentációba, egyszerűbb, ha már eleve ide (is) elkészítem, akár még másnak is hasznos lehet.

A dolog lényege az, hogy tőlünk is távoznak munkatársak néha. Szerencsére elég ritkán ahhoz, hogy eddig ingerküszöb alatt maradjon a globális megoldás kitalálása (ez volt a hosszasabb) és megvalósítása is.

Az egyik fontos lépés az az volt, hogy ha olyan kolléga kap levelet, aki már távozott a cégtől, akkor a feladó kapjon tájékoztatást, hogy a levele bizony nem ért célba, és a jövőben már más címen tud elérni minket. Ehhez talán a legjobb megoldás az exim autoreply használata.

Az dolog lényege a következő: érkezik egy levél, ami végigfut az exim routereken, egészen addig, amíg nem talál olyat, amire illeszkedik. Ha talál, akkor egyrészt nem folytatja a következő routerre, másrészt átadja a levelet a routerben meghatározott transport-nak. Persze a dolog nem volt ennyire egyszerű, bár tény, hogy annyira rettenetesen bonyolult sem. Lássuk az első lépést, magát a router-t:

usergone:
  driver = redirect
  allow_filter
  allow_fail
  domains = +YOURDOMAINS
  hide_child_in_errmsg
  debug_print = "R: autoreply for $local_part"
  reply_transport = olduser_reply
  file = /etc/exim4/autoreply.txt
  require_files = /etc/exim4/autoreply.txt
  condition = ${lookup ldapm {user=userid=userdn PASS=userpass \
  ldap:///cn=nothere,ou=Groups,dc=YOURDC?memberUid?sub?(memberUid=$local_part)}{true}{false}}
  user = Debian-exim
  group = Debian-exim
  no_expn

Eléggé szokványos dolog, egy ügyesség van benne, mégpedig a condition sor. Az ott szereplő LDAP lookup igazzal tér vissza, ha a „nothere” csoportban szerepel a címzett, azaz oda kell felvenni azokat a felhasználókat, akik már nincsenek a cégnél. A router az olduser_reply transportra dobja a leveleket:

olduser_reply:
  debug_print = "T: olduser reply for $local_part@domain"
  driver = autoreply
  file = /etc/exim4/autoreply.txt
  file_expand
  from = $local_part@c3d.hu
  to = $sender_address
  subject = "Re: $h_subject"
  text = "Automatic reply"

Ez is egy tök egyszerű dolog, egyetlen trükk van benne, hogy az autoreply.txt az egy filter (lásd az allow_filter sort feljebb), ami így néz ki:

# Exim filter
if ($h_subject: does not contain "SPAM?" and personal) then
 seen mail
 expand file /etc/exim4/autoreply.txt.data
 once /var/spool/exim4/$local_part.$domain-vacation.db
 log  /var/spool/exim4/$local_part.$domain-vacation.log
 once_repeat 7d
 to $reply_address
 from $local_part\@$domain
 subject "Autoreply...[Re: $h_subject:]"
endif

Ami fél napot elvett az életemből az a „seen” szócska. Ugyanis két fajta kézbesítés létezik, a significant és ami nem. Nekünk arra van szükségünk hogy a már nem itt dolgozók ne kapják a leveleket, ezért a mail elé, ami alapból nem significant be kell tenni a „seen” szócskát, hogy az exim tényleg ne foglalkozzon tovább a levél továbbításával. Hurrá.


[zotpress collection=”7D3RRNDM”]