Misc.

Egyrészt tegnap tömegközlekedtem (autóval, utána villamossal), és megállapítottam, hogy ennek a városnak igazából egy Critical Mass ide vagy oda már tökmindegy. Lehet minket utálni érte, de a valóság az, hogy a város ebben a formában közleked- és élhetetlen. (Az, hogy autóval az, megszokott, de hogy a villamossínre is rámászik az autós közlekedés, és emiatt az is döglött, számomra új. Persze amennyit én villamosközlekedek…)

Mindeközben a hétvége folyamán elvilg belekerült némi tuti a gépházba, és most pattanósabb a site. Kisebb leállásokra most mindegyik vason számíthatunk, mert frissítek ezt-azt. (Apache, PHP, stb.)

Az ellenpóluson elérhető közelségbe került, hogy mintegy 5 hónap után pénz álljon a házhoz a Leonból. (Amit, ugye, városban minek vezetni, lásd fent; de arra már nagyon vágyom, hogy kocsibbabee, ablakotlee, könyökötkii, kettesbebee, aztán inet Horvátország, vagy valami.)

Na aztán: keresek 12x12x8 cm méretű (mini ATX szabvány tán?) tápegységet, barebone gépbe (nem a Shuttle). Ha tudsz üzletet, ahol van, vagy hajlandók berendelni, ne habozz szólni: a gepbolt.hu és az Aqua már határozott nemet mondott, és a Qwerty és Edigital felől érkező válasz tekintetében sem táplálok vérmes reményeket. (Huh.)

Hoppá, megvan a táp, a Qwerty-től, bigup.

Kis reggeli szerverpara.

A Critical Massba is beférkőzött a korrupció: ma reggel a CM oldal alatti adatbázis cache_filter táblája meglehetős csúnyán, MySQL szerver-, vagy fileszinten korrumpálódott (majd megnézem, hány dokumentumot vett át), úgyhogy hajnali backupból vissza kellett állítani.

Jelenleg a (valószínűleg utolsó) CHECK TABLE megy, utána megint lesz CM. Ja és persze ha bármi parát tapasztalsz, drop me a line.

Gutsy vs. Samba, Gutsy vs. nyomatók, IPTables vs. DHCP: projektmargó.

Címszavakban:

  • Ha Gutsy server fölötti Sambával akarsz Windowsos (de végülis bármilyen) SMB hálózatot tolni, beware: a Gutsy alapból megszavazza a /etc/hosts-ban a 127.0.1.1 bejegyzést a géped FQDN-jének (a réges-rgi default 127.0.0.1-es localhost bejegyzés mellett), ami egy hálózatban problémákat okozhat — nekünk kokrétan 1 nap csúszást és finoman szólva is fejvakarást okozott. Ha ugyanis úgy marad, és aztán Sambában beállítod, hogy WINS kiszolgálóként is üzemeljen a Samba kiszolgáló, az összes Windowsos gép tőle fog megpróbálni feloldani. A [samba server] query-re pedig 127.0.1.1 választ fognak kapni, ergo saját magukhoz fognak megpróbálni kapcsolódni, te pedig gondolkozhatsz, hogy miért nem sikerül a (szerinted) szerverhez kapcsolódni. (Triviálisnak tűnik, de mire rájöttünk!…)
  • Ilyen nyomtatókkal találkoztam ma, hogy Canon LBP5000, meg Samsung SCX-4521F. Egyik sem működik out-of-the-box CUPS alatt, ami eleve röhej, de amit a Canon csinál, az külön említést érdemel (itt van a full Gutsy howto egyébként): a CUPS mellé elindít egy ccpd nevű saját daemont, ami egy saját FIFO-ba pakolja az adatot, a természetesen proprietary ppd-ken keresztül. Ezt aztán végülis össze lehetett hegeszteni CUPS-szal, de miután minden megvolt, újra kellett indítani a gépet. Itt tartunk 2008-ban, hogy egy nyomtató telepítése miatt újra kell indítani egy Linuxos szervert?
  • És egy side note: DHCP helyi hálózaton hiba kizárni azokat a csomagokat, amik nem a helyi hálóról/-ra jönnek-mennek. Amíg egy gépnek nincs IP-je, nem fog tudni helyi hálózatos IP-ről/-re küldözgetni, azokat a broadcast csomagjait viszont, amivel IP-t kérne, kizártad.

NTP vs. Xen.

root@hapu:~# cat /proc/sys/xen/
independent_wallclock permitted_clock_jitter
root@hapu:~# cat /proc/sys/xen/independent_wallclock
0
root@hapu:~# echo 1 > /proc/sys/xen/independent_wallclock
root@hapu:~# ntpdate ntp.ubuntu.com
9 Dec 13:55:10 ntpdate[7032]: step time server 91.189.94.4 offset -198.264053 sec
root@hapu:~# ntpdate ntp.ubuntu.com
9 Dec 13:55:13 ntpdate[7034]: adjust time server 91.189.94.4 offset 0.000111 sec
root@hapu:~#

A fenti kód kell ahhoz, hogy Xen domainben tudd állítani az órát.