OpenBSD bound-checking -gel kiegészített
string kezelő függvényeit kellett _sima_ Linux -os változatukra lecserélni,
és a kizárólagos lock-olást is máshogy hívják linux alatt.
Továbbá a =db.h= header fájlról =db_185.h= -ra kellett váltani.
_Igazából nem tudom mi a különbség a kettő között._
Régen kivadásztam, hogy az utóbbiban van az a függvény definiálva, ami a relaydb -nek kell.
A relaydb csak a libdb -nek a kettes változatával működik, debian alatt ez azt jelenti, hogy:
=apt-get install libdb2-dev=
A patch itt van nálam, és azt hiszem elküldöm Daniel Hartmeier -nek is.
[/openbsd]
permanent link
2005-04-01
Félelmünkben (ha kiesik mégegy lemez az teljes adatvesztés)
mindent megtettünk, hogy kapjuk egy lemezt, ha más nem csak
átmenetileg.
Sikerült is, így mikor hazajöttünk a Networkshop 2005 konferenciáról
nem haza, hanem kapásból az egyetemre jöttünk. Beraktuk a tartaléklemezt,
de előtte (Miklós biztatására) varázsoltunk egy *új* storcon-t.
Ez képes volt a 2.6-os kernellel is együttműködni.
Tapasztalatlanul újrabootoltuk a gépet és kis bíztatás után megettetük vele
az új lemezt, ami nagyobb volt a kelleténél. kb 12óra kellett a tömb teljes
újraépítéséhez.
[/ppke/host/digitus]
permanent link
2005-03-16
Miklós előző hétvégén (szombaton mikor úton voltam hazafele),
bejött és félholt állapotban találta a digitus-t.
Engem meg elárosztott a nagios SMS-kkel, de tehetetlen voltam.
A gép hibásnak találta az egyik disket és kivette a RAID-ből,
a második újraindításra szó nélkül megette.
De a disk tényleg hibás volt, pár nappal később elárasztotta
a logokat hibaüzenetekkel és reggel megfagyott.Inkább mondhatjuk
hogy félholt állapotba ment át, a hálókártya watchdog-ja teleírta a
képernyőt hibaüzenettel és látszott, hogy valami interrupt összekeveredett.
(be is mentem volna a szervert újraindítani, de a portás kikosorazott,
meg kellett várni Pétert)
Egy biztos, ez nem kernel bug volt.
[/ppke/host/digitus]
permanent link
2005-03-14
Hasznos linkek, amiket majd megnézek:
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/manual/ %BR%
http://www.cuddletech.com/articles/rrd/ar01s02.html %BR%
http://remstats.sourceforge.net/release/datapage-cgi.html %BR%
Panic (egy szinttel feljebb xen vmm): http://eyck.forumakad.pl/~eyck/log/Howto/Reboot.On.Panic.html
[[http://www-106.ibm.com/developerworks/linux/library/l-adfly.html proc fs paraméterek (IBM)]]
[/ppke/links]
permanent link
Amikor hazafelé jöttem szombaton a Dux -on futó nagios elárasztott SMS-kkel,
_Host DOWN altert for Digitus!_
Az eset 13órakor történt, Miklós este jött be életrelehelni.
Bugos a kernel én erre gyanakszom, még a grsec-ben is [[http://grsecurity.net/news.php security bugok]] .
A digitus új kernelt kap majd. Addig is tüneti kezelés: =echo 360 >/proc/sys/kernel/panic=
[/linux/kernel/cstamas]
permanent link
Szegény Ákos-t elárasztották olyan lehetettlen kérésekkel mint PHP + Realserver körüli bajok.
Valaki, valószinűleg Robi rebootolta a gépet, annyi a ~150 napos uptime-nak. :-(
[/katradio]
permanent link
Szinte hihetetlen de úgy tűnik lesz Sarge!
[[http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html Release plan]]
[/linux/debian]
permanent link
Eddig jó véleménnyel voltam az Invitel-ről mondván támogassuk az alternatív szolgáltatókat stb..
De az M$ és az Invitel szemétsége után kicsit megváltozott a véleményem.
Valaki úgy gondolta [[http://www.geekguild.co.uk/invitel/ meg is bünteti őket]]
No comment.
[/opinion]
permanent link
Itt voltam egy hétig, kényelmes a sífelvonótól 5percre található *pályaszállás* -on
laktunk. (nem volt túl tágas, de pályaszállás)
1. Sajnos az időjárás nem volt olyan olyan kedvező, az első nap az időjárás jó volt, de a ratrak-ok nagy ívben elkerülték a pályát (hóbuckás volt, nem volt _megcsinálva_ ). Egész jó volt az infrastruktúra, 4 személyes kabinos felvonó, viszont fent csak csákányos felvonók. Negyedóra felfele, és 30 - 45 perc alatt lehet lecsúszni. :-)
2. nap: napközben elkezdett esni a hó, nem lehetett igazán jól látni.
3. nap: annyira komoly mennyiségű hó esett, hogy ezt a napot kihagytuk, inkább pihentünk és szaunztunk
4. mégtöbb hó esett, 3 szintűre emelték a lavinakészültésget a hegyen továbbra is -7 C fok körüli a hőmérséklet csak 4 órát síztünk így volt kényelmes.
5. mostmár kezdtem kicsit megszokni/megszeretni ezt a pályát. Van aki szereti a szűzhavas területeket, de én nem.
6. Átmentünk Kitzbühel -be. Ez tette igazán élvezetessé az egész hetet, csodálatos pálya amin megállás nélkül jár a ratrak(Több is!) Óriási pályarendszer több hegyen széles pályákkal (több feketpálya)
7. nap: Haza
[/me]
permanent link
2005-03-03
Szinten softwaretechnologiabol a verziokovetes tamogatasara
felraktam egy [[http://subversion.tigris.org subversion]] -t.
%BR% [[http://svnbook.red-bean.com/ Dokumentacio]]
Mar csak a tobbieket kell _betanitani_ .
[/ppke/sw-tech]
permanent link
Ma reggel megcsinaltam a *pioneer-l* @digitus.itk.ppke.hu levlistat.
Ezt a szoftvertechnologia csoportunk tamogatasara keszitettem.
[/ppke/sw-tech]
permanent link
2005-02-27
Miután csináltam ilyet a Dux-on (szép, stílusos) utána csináltam egyet
a digitus-ra is. A régi [[http://to.itk.ppke.hu TO]] honlapján található
"logo" alapján. Sajnos ez már nem lett olyan szép, kis felbontású képet
lehet csak idetenni (15x15), de ha lekicsinyítem akkor nagyon homályos lesz.
Most nagyobb kép van berakva, a böngésző kicsinyíti le, most se az igazi, de
talán jobb mint a semmi.
[/ppke/host/digitus]
permanent link
Már kezdek hozzászokni ahhoz, hogy a Bind állanó hibáival találkozok.
Egyszerűen csak azt nem értem, hogy lehet hogy még mindig vannak emberek,
akik ezt használják.
(Most dns-server -ről mint resolverről beszélek.)
A Bind a DNS Microsoft-ja.
host smarden.org
;; Warning: ID mismatch: expected ID 54863, got 46665
;; Warning: ID mismatch: expected ID 54863, got 46665
;; Warning: ID mismatch: expected ID 54863, got 14935
;; Warning: ID mismatch: expected ID 54863, got 14935
Host smarden.org not found: 2(SERVFAIL)
# host smarden.org
;; connection timed out; no servers could be reached
# host hup.hu
hup.hu has address 195.228.252.138
# dnsqr a smarden.org
1 smarden.org:
temporary failure
Ezzel szemben dnscache:
2005-02-26_22:56:15.99272 starting
2005-02-26_22:56:26.73475 query 1 7f000001:fc66:de31 1 smarden.org.
2005-02-26_22:56:26.73479 tx 0 1 smarden.org. . 8009006b c1000e81 c021040c ca0c1b21 80080a5a c629000a c00505f1 c0702404 c0249411 c6290004 c620400c 803f0235 c0cbe60a
2005-02-26_22:56:27.06930 rr 8009006b 172800 1 tld1.ultradns.net. cc4a7001
2005-02-26_22:56:27.06938 rr 8009006b 172800 1 tld2.ultradns.net. cc4a7101
2005-02-26_22:56:27.06939 rr 8009006b 172800 1 tld3.ultradns.org. c7074201
2005-02-26_22:56:27.06944 rr 8009006b 172800 1 tld4.ultradns.org. c7074301
2005-02-26_22:56:27.06944 rr 8009006b 172800 1 tld5.ultradns.info. c0643b0b
2005-02-26_22:56:27.06945 rr 8009006b 172800 1 tld6.ultradns.co.uk. c685c70b
2005-02-26_22:56:27.06946 rr 8009006b 172800 ns org. tld1.ultradns.net.
2005-02-26_22:56:27.06947 rr 8009006b 172800 ns org. tld2.ultradns.net.
2005-02-26_22:56:27.06948 rr 8009006b 172800 ns org. tld3.ultradns.org.
2005-02-26_22:56:27.06948 rr 8009006b 172800 ns org. tld4.ultradns.org.
2005-02-26_22:56:27.06949 rr 8009006b 172800 ns org. tld5.ultradns.info.
2005-02-26_22:56:27.06950 rr 8009006b 172800 ns org. tld6.ultradns.co.uk.
2005-02-26_22:56:27.06951 stats 1 417 1 0
2005-02-26_22:56:27.06951 cached 1 tld1.ultradns.net.
2005-02-26_22:56:27.06952 cached 1 tld2.ultradns.net.
2005-02-26_22:56:27.06953 cached 1 tld3.ultradns.org.
2005-02-26_22:56:27.06954 cached 1 tld4.ultradns.org.
2005-02-26_22:56:27.06954 cached 1 tld5.ultradns.info.
2005-02-26_22:56:27.06955 cached 1 tld6.ultradns.co.uk.
2005-02-26_22:56:27.06956 tx 0 1 smarden.org. org. c7074201 c0643b0b c7074301 c685c70b cc4a7101 cc4
a7001
2005-02-26_22:56:27.52889 rr c7074201 172800 1 a.ns.smarden.org. d4154c46
2005-02-26_22:56:27.52893 rr c7074201 172800 1 b.ns.smarden.org. d463de01
2005-02-26_22:56:27.52894 rr c7074201 172800 ns smarden.org. b.ns.smarden.org.
2005-02-26_22:56:27.52895 rr c7074201 172800 ns smarden.org. a.ns.smarden.org.
2005-02-26_22:56:27.52896 stats 1 576 1 0
2005-02-26_22:56:27.52896 cached 1 b.ns.smarden.org.
2005-02-26_22:56:27.52897 cached 1 a.ns.smarden.org.
2005-02-26_22:56:27.52898 tx 0 1 smarden.org. smarden.org. d463de01 d4154c46
2005-02-26_22:56:28.61526 rr d4154c46 600 1 smarden.org. 82e1f75c
2005-02-26_22:56:28.61532 rr d4154c46 259200 1 a.ns.smarden.org. d4154c46
2005-02-26_22:56:28.61533 rr d4154c46 129600 1 b.ns.smarden.org. 8d104a29
2005-02-26_22:56:28.61533 rr d4154c46 259200 ns smarden.org. a.ns.smarden.org.
2005-02-26_22:56:28.61534 rr d4154c46 259200 ns smarden.org. b.ns.smarden.org.
2005-02-26_22:56:28.61535 stats 1 774 1 0
2005-02-26_22:56:28.61536 sent 1 45
Az eredmény? az adott gépen is dnscache-t fogok beállítani.
[/ppke/dns]
permanent link
2005-02-24
Túl korai volt az öröm. A Dux kernele látszólag jól müködött, viszont másnap
délután hirtelen csinált egy ugrást az idöben ~13:30 -ra.
Ezután megállt az óra, söt még a =gettimeoftheday()= sem tért vissza!!
A kernel ezt mondta:
2005-02-16_13:57:52.75005 kern.warn: Losing too many ticks!
2005-02-16_13:57:52.75008 kern.warn: TSC cannot be used as a timesource.
2005-02-16_13:57:52.75009 kern.warn: Possible reasons for this are:
2005-02-16_13:57:52.75010 kern.warn: You're running with Speedstep,
2005-02-16_13:57:52.75011 kern.warn: You don't have DMA enabled for your hard disk (see hdparm),
2005-02-16_13:57:52.75013 kern.warn: Incorrect TSC synchronization on an SMP system (see dmesg).
2005-02-16_13:57:52.75014 kern.warn: Falling back to a sane timesource now.
Annyira megbolondult szerencsétlen, hogy még reboot-olni se lehetett :-Z
Még jó, hogy az ldap redundáns, nem történt csúnya dolog.
Csak másnap reggel lehetett újraindítani. Kis keresés után arra jutottam, hogy =noapic= opcióval
érdemes a rendszert indítani. Úgy tünik ez tényleg segített. Azóta jó.
[/ppke/host/dux]
permanent link
Beállítottam a (elöször a digitus-on) a [[http://lcamtuf.coredump.cx/p0f.shtml P0F]] -ot.
Passive TCP fingerprinting-et végez, így a bejövö leveleknél elég jó megbízhatósággal
megállapíthatjuk a távoli gép operációs rendszerét.
Még nem teljesen látom az elönyét, hiszen a Nemo úgyis tiltja a Win9x -töl jövö leveleket
IP szinten... (AFAIK a két program szerzöje kapcsolatban áll egymással).
Azért lehet, hogy innen származó információkat is be lehetne venni a Spamassassin pontozásba.
Ha másra nem arra jó, hogy lássunk milyen op rendszerü gépeket használnak levelezésre.
[/ppke/mailscanner]
permanent link
2005-02-15
Ma Tamással átállítottuk a dux-ot is a fenti kernelre, az egyetlen csapda a LSI MegaRAID vezérlő volt:
%BR%az új ajánlott driverrel nem működött egyáltalán csak a *legacy* -val. Ez egy kicsit becsapás,
mert azt hinné az ember, hogy újabb jobb, de ez nem igaz, az új _nem működik_.
[/ppke/host/dux]
permanent link
Javasoltam, hogy sorban upgrade-jük a gépeket erre a kernelre. Egyelőre jónak tűnik, hiszem még a digitus se omlott
össze alatta ;-) Sorbamegyek és minden gépre fordítok egy ilyen kernelt. Csak ott kell majd lenni a hálókártyákon
a kábelezést felcserélni (biztos ez is feature :cool:
[/linux/kernel/cstamas]
permanent link
2005-02-08
Végül csak áttértünk =2.6= -os kernel-re. Tegnap este fordítottam egy kernelt és Miklóssal újrabootoluk.
Attól a dologtól eltekintve, hogy felcserélte a hálókártyákat minden rendben ment.
Még annyi, hogy a grsec paranoia-ja miatt nem ment a socklog (mert log user nem tudta a /proc/kmsg-t olvasni).
Megpróbáltam abba a csoportba berakni, ami a log primary group-ja de ez se segített. Mindegy ennyi még belefér,
most root-ként fut.
Nem kellett anyon-patch-elni, mert alapból volt benne LVM2, DM, XFS POSIX ACL, csak egy as2 és grsec patch kellett,
amit hibátlanul lehetett alkalmazni.
Lásd még: [[http://digitus.itk.ppke.hu/~cstamas/cgi-bin/blosxom.cgi/2005/01/09#cstamas200501 2.4 patchelése]]
[/linux/kernel/cstamas]
permanent link
2005-02-07
Találtam egy-két olyen programot leírást ami a djbdns-t jól kiegészíti.
http://www.hungry.com/~fn/dnscache-log.pl.txt
http://www.campin.net/DNS/
[/ppke/dns]
permanent link
Miklós javaslatára kicsit helyrepofoztam, a tripwire-t. Még nem teljes de legalább 1 policy alapján
dolgozik. A jövőben ezt az egy pélányt akarom úgy finomítani hogy minden gépre
jó legyen. (Host specifikus bejegyzések.)
Ha valahol javítani kell mindig ezt a *master* példányt fogom frissíteni.
Osiris-szel is ismerkedtem de végül nem nyerte el a tetszésemet. Nem elég robosztus, és kicsit feleslegesen
komplikált, bár ha kiszámíthatóan működne a központi menedzsment miatt előnyös lenne.
[/ppke]
permanent link
2005-02-06
Három hete megcsináltam, hogy a spamd ne csak 10 sort fogadjon el a levél testéből (body),
hanem többet. Később rájöttem, hogy hasznos lenne ha egy command line kapcsolóval
lehetne ezt szabályozni, meg is csináltam most így működik a Nemo-n.
Két hete elküldtem a patch-et a [[http://archives.neohapsis.com/archives/openbsd/2005-01/1743.html misc@]]
openbsd listára, de nem válaszolt rá senki.
Ma Nagy Róberttel összeütöttünk egy full-featured patch-et, ő elsősorban a manpage-n
szépített. A patch nem tetszett Theo -nak ez a fő oka annak, hogy nem kerül be a current CVS
fába.
Az ok a következő (Bob Beck): _spamd is not about false positives. You feed it correct data, or you lose. Checking in the logs means you cannot trust it at all, even to begin with. It means you are running it wrong._
Én továbbra is használom és ha más valaki is szeretné [[http://digitus.itk.ppke.hu/~cstamas/spamd.diff itt]] a patch.
[/openbsd]
permanent link
Miklós alapvetően beállította ezt a (új) router-t.
Én csak azt adtam hozzá, hogy a Nemo-ra küldje a logokat akárcsak a többi hálózati eszköz.
[/ppke/cisco]
permanent link
2005-02-05
Mindig is érdekelt, hogy mit jelent a "weird ra" a dnsq kimenetében.
Hát most megtaláltam a [[http://www.faqts.com/knowledge_base/view.phtml/aid/9288 megoldást]].
Arról van szó, hogy a dnsq nem kapcsolta be a Recursion Desired (RD)
bitet, mégis olyan választ kapott amin a Recursion Available (RA)
be volt kapcsolva. Ez az RFC-k szerint nem hiba, de a furcsa (weird) jó szó lehet rá.
A fenti oldalt idézve:
Smart quote from Al Lipscomb (Mar, 2001):
I think it would be weird if I asked you "Do you know his name?"
and you answered "Yes his name is Bob, but I would be willing to go ask
someone else for you if you would like me to." :)
Persze, ha egy publikusan elérhető szerver mond ilyet akkor az hibát jelent hiszen,
ez azt jelenti, hogy hajlandó rekurzív kéréseket végrehajtani a részünkre.
A Bind szokása az RA bit beállítása, tinydns nem _(már a felépítési elvéből fakadóan sem)_ mond ilyet.
[/ppke/dns]
permanent link
2005-02-04
Hihetetlen! Persze már szinte mindenütt van új modutils,
így feltételeztem, hogy itt is van. Hát nem volt :roll: egy =apt-get install module-init-tools=
egycsapásra megoldotta a problémát. Előtte unresolved symbols-szal szenvedtem.
Azt még most sem értem, hogy alap confignál miért nem lehet részeket kikapcsolni.
(sebaj, majd máskor)
[/linux/kernel]
permanent link
Nem konnyu az élete annak aki, biztonságos kernelt akar hasznalni.
Most probálkoztam a Grsec-kel 2.6 alatt, az alap konfigurácio átszabása,
hát nem igazán sikerult...
Vannak részek amit a gyári konfigban nem is sikerult kikapcsolni,
most azzal probálkozok, hogy make allnoconfig után bekapcsolgatom azokat a
részeket amelyek szoba jöhetnek. (grsec nem tud security labeleket kezelni??)
Találtam egy-két érdekes cikket (majd elolvasom):
[[http://www.cs.virginia.edu/~jcg8f/GrsecuritySELinuxCaseStudy.pdf grsec vs selinux]]
[[http://dev.gentoo.org/~tseng/kernel/0000_README grsec+selinux]]
[/linux/kernel]
permanent link
2005-02-03
A Katradio.hu is bekerült a dux-on futó munin statisztikájába.
Ugyanolyan [[http://digitus.itk.ppke.hu/~cstamas/cgi-bin/blosxom.cgi/2005/01/12#nagios-1 állandó ssh]]
kapcsolatot tart fenn a katradio.hu -val, mint a Lex. Itt az ssh kulcs csak a 4949 -es
port forwardolását engedi a többi más _(pl shell)_ tiltott.
Az ssh-forward -ert a runit tartja életben, azaz ha a kapcsolat megszakad akkor
az ssh timeout-ja után a kapcsolat újra felépül.
Ezekhez a statisztikákhoz, megfelelő jelszóval a katradio-tól is hozzáférnek (majd).
[/ppke/munin]
permanent link
ED telefonált, hogy nem érhető el a sirius.hu. Az volt az első dolgom, hogy átváltottam a megnyitott ssh kapcsolatomra,
de a gép teljensen süket volt. ping-elni se lehetett.. Szóltam is neki.
Későb kiderült, hogy a sztaki egy részében áramszünet volt, állítólag a BIX egy része is elérhetetlenné vált
egy pillanatra. A gép rendesen felbootolt, úgy tűnik ezzel nem volt probléma.
[/sirius]
permanent link
Miklós szólt, hogy Vető István is használná a wiki-t,
csak még egy két dolgot javítani, fejleszteni kéne rajta.
Az authentikáción kéne fejleszteni (ez LDAP-os dolgot fog jelenteni),
illetve a PDF és esetleg DOC fájlok kezelése is előnyös lenne.
Most túrok a [[http://www.twiki.org TWiki.org]] mélyén, úgyhogy ide is rakok
egy-két linket.
(Nem csak az adott téma, de amiket érdemes lesz majd megnézni...)
http://twiki.org/cgi-bin/view/Plugins/BeautifierPlugin
%BR% http://twiki.org/cgi-bin/view/Plugins/EmbedPDFPlugin
%BR% http://twiki.org/cgi-bin/view/Plugins/EmbedTopicPlugin
%BR% http://twiki.org/cgi-bin/view/Plugins/LaTeXToMathMLPlugin
%BR% http://twiki.org/cgi-bin/view/Plugins/LdapPlugin
%BR% http://twiki.org/cgi-bin/view/Plugins/MathModePlugin
%BR% http://twiki.org/cgi-bin/view/Plugins/MsOfficeAttachmentsAsHTMLPlugin
%BR% http://twiki.org/cgi-bin/view/Plugins/PdfPlugin
%BR% http://twiki.org/cgi-bin/view/Plugins/WeatherPlugin
Ma azt hiszem elrontom az ldapot és a twiki-t is...
legalábbis remélem lesz rá időm. (elsőre sose sikerül :cool:
[/ppke/twiki]
permanent link
2005-01-25
Sajnos titkon ettől féltem, Linux helyett Window$ -ra installálta Zoli az
Oracle-t, hmm, nem túl szimpatikus. Valószínűleg ezzel nincs mit tenni.
[/ppke/oracle]
permanent link
powered by blosxom
and twiki