tomld - mentors

Szerintetek miért nem tudom bejuttatni Debian-ba tomld csomagom (ugye kell egy hivatalos Debian fejlesztő, aki mentor-ként feltölti)? Most már több hónapja is van, hogy spammeltem az IRC csatornákat, levlistát, de semmi mozgás. Szeretnék több user-t teszteléshez.

Mi lehet a gond? Nagyon szar a cucc? Vagy érdektelen a téma? Vagy nincs annyi kapacitása a fejlesztőknek, hogy átnézzék és feltolják experimentalba? Nem lenne sok dolguk. Másik progimat pl. gyorsan betolták szó nélkül (sajnos az a mentor-om nem vállalta ezt, de nem írta hogy miért, bár pozitív dolgot írt vissza).

Megcsináltam a teljes csomagot is lintian hiba mentesen:
http://mentors.debian.net/package/tomld
http://lists.debian.org/debian-mentors/2011/10/msg00233.html

Debian-ba szeretném juttatni, onnét úgyis átcsorogna Ubuntu-ba is, és akkor két helyről lenne lehetőségem bugreport-okat meg egyéb visszajelzést kapni.

Értetlenül állok a kérdés előtt.

( trey | 2011. 10. 22., szo – 09:49 )

Vannak itt Debian maintainer-ek. Ha jól tudom algernon és GCS is az. Esetleg velük vedd fel a kapcsolatot, hátha tudnak tanácsot adni.

--
trey @ gépház

( uid_2716 | 2011. 10. 23., v – 21:44 )

Részvétem. Esetleg privátban megírod, hogy az aaphoto-s szponzorod miért nem vállalta? (Meg azt, hogy ő konkrétan ki is volt :))

A debian szvsz eljutott arra a szintre, amikor személyes kapcsolatok nélkül már semmit sem lehet elintézni.

A rendszer egyrészt óriásira hízott, másrészt nagyon neves és stabil. Ez csak úgy tartható fenn, ha a DD-k száma kicsi (olyan 1000 körüli még mindig?), másrészt nagyon szigorúak a követelmények, mind az új DD-kkel szemben, mind a meglévő DD-k tevékenységével szemben. Enélkül lényegében lehetetlen volna elkerülni a folyamatos regressziókat és ütközéseket.

Szerintem egyébként a tomld érdektelen is a mezei debian felhasználó számára. Ezzel nem akarlak megbántani; azért jött ki ilyen könnyen a számon, mert anno 100%-os bizonyossággal meggyőződtem arról, hogy az lbzip2 is tökéletesen érdektelen. Ez egyrészt fájdalmas volt, másrészt felnyitotta a szememet. Az általános felhasználói igények diktálnak, az lbzip2 nem oda esik. Úgyhogy én fel is adtam akkor pl. az alternatives-be bejutást -- a debian-users listára beküldtem egy felmérést (asszem kb. 3200-an voltak akkor feliratkozva), összesen három választ kaptam (volt "nem érdekel" opció is :), de akit nem érdekelt, az inkább nem is válaszolt :))

Azóta rátaláltam a dpkg-divert-re, ami személy szerint kifejezetten boldoggá tett, mert így a saját rendszerem rendben maradt. A többivel már nem foglalkozom.

A mentors.debian.net-en már 2008-ban is saccra 50-szeres / 100-szoros túljelentkezés volt. A DD-k túl vannak terhelve, kizárólag akkor foglalkoznak egy csomaggal, ha valamiért felcsigázza őket, vagy a szponzorálandó maintainer-rel való személyes kapcsolatuk ráviszi őket. A Debian ilyen szempontból már nem látszik "skálázódni".

Az Ubuntu-t nem ismerem. A Gentoo-ba könnyebben be lehet jutni talán, csak ugye ki használ Gentoo-t... Én nem :) Az lbzip2-t asszem lassan bele fogják nyomni a build rendszerükbe is, de ennek az alapja egy olyan Gentoo-specifikus patch volt, amivel én nem értettem egyet :)

Az Arch Linux (remélem, így írják a nevét) AUR-ja, ill. a Slackware SlackBuilds-e jó példa arra, amikor a közösség csomagol. (Talán az Ubuntu-nál a multiverse ilyen? Fogalmam sincs.) A közösségi repo-ból aztán mindenki azt az egy-két csomagot teszi fel, amire szüksége van.

Lenne néhány apróság, amit az lbzip2-0.23-ba talán nem volna túl néhéz belebarkácsolnom, de az egyik legnagyobb visszatartó erő, hogy utána újra át kellene küzdenem magamat a csomagoláson. A mentorom megvan, a checklist-em megvan... A Debian Policy azóta kijött verzióival azonban nem vagyok hajlandó foglalkozni.

Ha megnézem a popcon-on, jelenleg kemény 439 a visszajelzett lbzip2-0.23 telepítések száma. 2011. októbere van, a 0.23-at 2010. márciusában adtam ki. Ne vicceljünk már, a stable felhasználóit (én is az vagyok :)) nem is érdemes célba venni. Mire bejelentenek egy új bugot, szinte már magam sem értem a forrást. Felhasználói oldalról azonban én sem vagyok hajlandó rolling distro-t használni, mert nekem nem kell a sok fos feature, csak a bugfix-ek. (Nem csak security, hanem bármilyen bugfix.) Ahhoz ugye upstream oldalon vagy distro maintainer oldalon külön backporter / maintenance programmer szerepkör kell, ami meglehetősen agypusztító tevékenység, így eléggé meg szokták kérni az árát. (Azok az ügyfelek, akiknek ez fontos, meg is adják az árát, lásd nagyvállalati disztrók.)

Na ez elég zagyva lett. Szerintem az egyetlen megoldás a közösségi csomagolás, lásd AUR/SlackBuilds, amiből a felhasználó kizárólag azt az 1-2 csomagot teszi fel, ami kell neki. Hogy Debian-nál van-e ilyen, arról gőzöm sincs. (A debian-multimedia.org és a backports.debian.org léte azért elég beszédes.) Számomra valamennyire ebbe az irányba mutat az EPEL is.

Na akkor sorban :)

A mentorom csak annyit mondott, hogy vissza kell utasítania, mert nem érdekli különösebben tomld, sem Tomoyo, ellentétben aaphoto-val.

A Debian minőségével kapcsolatban csomag készítő szemszögből azt gondolom, hogy olyan sok kritériumnak meg kell felelnie, hogy ez lényegesen megnehezíti a csomag készítést (viszont ezért hordoz egy nagyobb minőséget is). Konkrétan 20 db levelet váltottam a fejlesztővel az első aaphoto csomagomnál (20 db újra generálással) ahhoz, hogy elfogadja, pedig lintian hiba mentes volt :) A Debian policy-t követni meg tényleg erőn felülinek tűnik, nem beszélve a nulla doksiról, meg az agyament dh script-ekről.

Tomld-t pedig nem is a desktop felhasználóknak szántam igazán, és nem is venném bántónak amit mondasz, ha eredetileg sem így gondolnám. Egyrészt a kritika, vagy más vélemény mindig építő szerintem ilyen vagy olyan módon (önámítás eleve felejtős imho), másrészt pont a szervereket szerettem volna megcélozni.

Ugye majdnem mindegyik fő disztrónak meg van a maga gyárilag szállított MAC rendszere (RHEL selinux / Suse apparmor / Ubuntu apparmor). Debian-nak viszont semmi. Tomoyo ráadásul gyárilag bele van fordítva a kernelbe. Tomoyo-t relatíve könnyebben érthetőnek és kezelhetőnek találtam a többihez képest, ráadásul izgalmas is a dolog szerintem, hogy a teljes Linux meg Unix jogosultsági struktúra megváltoztatására tett próbálkozás nélkül tehetnénk valamit egy már mainline-ban elérhető technológia felhasználásával. A lehetőség az utcán hevert és adott lett, mondhatjuk. Persze nagy cég, meg nálam jobban hozzáértők eleve jobban / szebben / gyorsabban / hamarabb lefejleszthetnének egy hasonló megoldást.

Mageia / Mandrivát nem említettem fent. Ahogy az Ubuntu egyik IRC channel-jén megtudtam, elvileg Tomoyo-t szállítanak gyárilag MAC megoldásként. Hoppá. Tesztelni és megnézni nem lett időm. Főként azért sem, mert egyetlen visszajelzést sem kaptam a levlistájukról és IRC-jükön sem. Ez megint meglepő volt nekem.

A Tomoyo-s arcok jó fejek voltak. Áldását adta a fő fejlesztő, hogy ha nem sűrűn ;), akkor nem zavarja a levlistájukon a saját release-emmel kapcsolatos bejelentés. Sajna innét sem jött semmi mozgás, kivéve a legeslegelső python-os pre alfa verziómról tett infóval kapcsolatban. Viszont twitter-re meg egy Japán oldalukra feltették az oldalam linkjét.

Egy érdekesség egy live disztróval kapcsolatban, ahol említik a cuccomat:
http://tails.boum.org/todo/Mandatory_Access_Control/

Szóval visszatérve az eredeti célhoz; inkább arra számítottam volna, hogy olyan szempontból kapok érdeklődést, hogy felismernék a rengeteg időt és energiát megspóroló automatizmus segítségével gyorsan összerakható policy lehetőségét. (Mivel mindenképp korlátoz, ezért a semminél policy-től függően egyre biztonságosabb). Ugye megpróbálok véletlen nevekre is megoldást adni, de nem probléma ha visszatérnek bizonyos megtagadás bejegyzések, mert az általam kialakított tomld.conf-ban egyszerűen lehet egyetlen mappa név megadásával lekezelni ezeket. Tehát bár nem szeretnék engedni az 1 click solution-ből, a config fájlal is egyszerű a megoldás - szemben azzal, mintha pl. 3 ezer sort kell taknyolni rendszer update-enként kézzel - további erőfeszítést viszont csak akkor fektetnék bele, ha official csomag lenne, vagy más módon lenne felhasználása a dolognak expert user-ek részéről.

Kis megjegyzés ide: akárkivel beszéltem, mindenki úgy kezdi RHEL meg Fedora, CentOS vonalon, hogy kilövik a selinux-ot, hosszú magyarázattal hogy miért jobb az úgy, vagy miért nem tudnak saját policy-t csinálni (most voltam Ausztriában, és egy rendszer mérnök mondta ezt, aki cluster-eket épít). Ez azért gáz.

A desktop vonalat az itt jelen lévő felhasználók miatt erőltettem csak ikonokkal meg menüvel. Egyrészt nagyon hasznosak voltak az innét kapott visszajelzések, másrészt elvégre desktop-on is használunk sok hálózatos cuccot, pl. böngészőt (talán a legfontosabb biztonsági aggodalmat képviselő rész), illetve chat meg egyebet, ami hálón kommunikál. Tehát ugyanolyan hasznos lehetne, ha hamar beállítható, és mégis szükség esetén könnyen igazítható lenne a megoldás a MAC beállítására.

Legnagyobb őszinteséggel mondom, hogy egyszerűen csak meglepett az érdektelenség. Pedig az IRC csatikon és levlistákon (számos debian és ubuntu, mandriva meg egyéb) visszatérően szórtam az infót. Sok linux-os oldalnak is küldtem egy rövid leírást, de semmi. Nem is arra számítanék, hogy konkrétan a munkám eredménye keltsen érdeklődést, hanem maga a megvalósítás módja. Vagy pedig legalább negatív kritikát vártam volna a célzott megkereséseimre.

Lehet hogy csak én láttam egy olyan dologban fantáziát, amihez tartozó technológiát elkezdtem használni, és hozzáfejlesztettem valamit a dolog megkönnyítésére. Egyebet nem t'ok elmondani :)

lbzip2-hez meg annyit, hogy aki nem használ párhuzamos tömörítőt, az megérdemli :) És tényleg nehéz a csomagolás ennyi rendszerhez (habár atya-val vitatkoztam egyszer, hogy csak a mainstream-hez kell megcsinálni), az ilyen projekthez, mint a te tömörítőd, igazán jöhetne fejlesztő vagy karbantartó, aki az upstream verziódat becsomagolja szabadidejében. Nehogy már egy ilyen fontos core cuccnak a csomagolásával az upstream-nek kelljen foglalkoznia. De erről félek hosszú flame-et lehetne nyitni.

nem beszélve a nulla doksiról, meg az agyament dh script-ekről

Ja. Ez egy élő rendszer, ahol természetesen nincs erőforrás a dokumentáció karbantartására. (A policy-t mondjuk frissítik, de azt meg elolvasni kínszenvedés... :)) Alkalmi csomagolóként valszeg nincs annál jobb módszer, hogy levelezzük agyon a dolgot valakivel, aki napi szinten benne van. (Napi szinten én pl. egyáltalán nem szeretnék benne lenni, van elég dolgom.)

Ugye majdnem mindegyik fő disztrónak meg van a maga gyárilag szállított MAC rendszere (RHEL selinux / Suse apparmor / Ubuntu apparmor). Debian-nak viszont semmi. Tomoyo ráadásul gyárilag bele van fordítva a kernelbe.

Korrekt. Ez az összehasonlítás meglepetésként ért.

Kis megjegyzés ide: akárkivel beszéltem, mindenki úgy kezdi RHEL meg Fedora, CentOS vonalon, hogy kilövik a selinux-ot, hosszú magyarázattal hogy miért jobb az úgy, vagy miért nem tudnak saját policy-t csinálni (most voltam Ausztriában, és egy rendszer mérnök mondta ezt, aki cluster-eket épít). Ez azért gáz.

Én foglalkoztam valamennyit SELinux-szal. NagyZ majd kijavít, én annyit tudok/akarok most mondani róla, hogy borzasztóan erős és sokoldalú eszköz, de dedikált képzés kell hozzá. Vagy tanfolyam, vagy célzott önképzés rendes dokumentációból. A CentOS/Fedora nem lep meg, de szerintem aki a RHEL-t igazán komolyan veszi és éles környezetben pénzkeresésre használja, az nem lövi ki az SELinux-ot, hanem megtanulja használni.

elvégre desktop-on is használunk sok hálózatos cuccot, pl. böngészőt (talán a legfontosabb biztonsági aggodalmat képviselő rész)

Teljesen jogos, de az emberek nagy része önként van a facebook-on is :)

Egyébként az külön nehezíti a helyzetedet, hogy biztonsági komponenst készítettél. Akit nem érdekel a biztonság, az nem fog vele foglalkozni (ez a többség), akit pedig érdekel a biztonság, az esetleg nem lesz 100%-ban meggyőződve arró, hogy a tomld nem konfigurálja félre a tomoyo-t. (Pusztán azon az alapon, hogy egyfejlesztős projekt, feltételezhetően kicsi audittal / code review-val; ilyesmi.) Önmagában a tomoyo sem túl széles körben használt szerintem.

Pedig a "tanuló mód" önmagában biztosan jó ötlet; ha jól tudom, windows-on tűzfalak szoktak így működni.

aki nem használ párhuzamos tömörítőt, az megérdemli

Fene tudja. Ad-hoc napi használatra tök mindegy a többségnek. Rendszeres archiválásra / backup-ra elvileg van valami felettes szoftvered (vagy kellene lennie), joggal mondható, hogy tömörítsen okosan az, amivel tud.

Amúgy is, egy ideje tudatosabban kezdtem figyelni a rendszeremet, és rájöttem, hogy a párhuzamos (ki)tömörítéssel igazából kevés időt takarítok meg. A várakozás túlnyomóan a dög lassú diszkből és a rengeteg kicsi file-ból fakad. Az interaktív munkafolyamatomat mindig az ezerrel seek-elő diszk borítja fel. Mindig a diszk az, legyen akár munkahelyi laptop vagy otthoni gép, amely miatt toporzékolni és az asztalt verni van kedvem. 

apt-get update && apt-get upgrade

? Agybaj! Első 

git checkout

vagy 

git status

kernelfán? Agybaj! 

du -sh /usr

? Agybaj!

Itt egy példa: 


# echo 3 >/proc/sys/vm/drop_caches \
  && for I in 1 2; do time -p du -sh /usr; done

4.2G    /usr
real 92.11
user 0.34
sys 3.86

4.2G    /usr
real 0.83
user 0.10
sys 0.47

111-szeres különbség. Ugyanez git status-ra: 


$ time -p git status
# On branch master
nothing to commit (working directory clean)
real 22.57
user 0.35
sys 0.65

$ time -p git status
# On branch master
nothing to commit (working directory clean)
real 0.32
user 0.11
sys 0.11

Kb. 70-szeres különbség.

Ha eljutok odáig valamikor, hogy a gépemre költsek, akkor biztosan SSD-t fogok venni, kimagasló random write teljesítménnyel. Mivel ezek azonban ma aranyárban vannak, pár évig garantáltan nem fogok ilyesmit vásárolni :)

"Én foglalkoztam valamennyit SELinux-szal. NagyZ majd kijavít, én annyit tudok/akarok most mondani róla, hogy borzasztóan erős és sokoldalú eszköz, de dedikált képzés kell hozzá. Vagy tanfolyam, vagy célzott önképzés rendes dokumentációból."

Én is nehéznek gondolom. És azt még érdemes nem elfelejteni, hogy a szoftver használhatósága igenis meghatározó hosszú távon a nagy átlagnak, és akármilyen jó dolgokat tud, nem lesz aki használja. Ez a nagy átlag fontos: nyilván a legelterjedtebb biztonsági megoldásokat fogja érni a legtöbb és legintenzívebb támadás, illetve arra lesz mindig érdemes berendezkedni a támadóknak. Gondolom leginkább mindig a nagy átlag általi sebezhetőség mértéke hathat ki ránk is olyan mértékben globálisan.

"..esetleg nem lesz 100%-ban meggyőződve arról, hogy a tomld nem konfigurálja félre a tomoyo-t.".

Igen, ez joggal állítható. Habár annyi előnye van a megoldásnak, hogy mivel engedő módú Tomoyo és a szabályok csak korlátoznak, ezért mint írtam, még ha félre is konfigurálnám, maximum is csak biztonságosabb lehet Tomoyo-val a rendszer :). Persze egyet értek azzal amit írsz, teljesen így van.

"Fene tudja. Ad-hoc napi használatra tök mindegy a többségnek. Rendszeres archiválásra / backup-ra elvileg van valami felettes szoftvered (vagy kellene lennie), joggal mondható, hogy tömörítsen okosan az, amivel tud."

Hát én csak azt tudom, hogy napi szinten akár fél órát is spórol nekem csak ez az egy folyamat. Ez sokat ér nekem. Igazából sok admin munkához kell(ene), tehát szerintem igenis van létjogosultsága, még úgy is, hogy low level user meg admin task-okhoz. Egyébként más backup szoftverekről nem tudsz, amelyek beépítették esetleg?

"..akkor biztosan SSD-t fogok venni.."

SSD-t már (talán) most is érdemes meggondolnia annak, akinek sok az I/O. Én bruttó ~60k-ért vettem 120 GB-osat, abból is kb. a legjobb minőséget, ami elérhető volt (az IO/sec votl itt nagyobb és ez SATA3-as 600 MB/s-el, de sajnos csak SATA2-es a vezérlőm a notiban): 

# echo 3 >/proc/sys/vm/drop_caches && for I in 1 2; do time -p du -sh /usr; done
6.4G    /usr
real 6.59
user 0.37
sys 3.72
6.4G    /usr
real 0.69
user 0.12
sys 0.57

engedő módú Tomoyo és a szabályok csak korlátoznak

Hm, érdekes, ezt sem tudtam. Ez mondjuk a paranoiásoknak helyből kizáró ok. Tudatos desktop felhasználónak azonban jó lehet. A "privát" doksikat amúgy is feltételezhetően egyetlen fában tárolja.

Hát én csak azt tudom, hogy napi szinten akár fél órát is spórol nekem csak ez az egy folyamat.

Nahát! Ezt örömmel hallom.

Egyébként más backup szoftverekről nem tudsz, amelyek beépítették esetleg?

Sajnos nem tudok másról, csak a GNU tar-ról és a clonezillá-ról, amely tudatában van az lbzip2 létezésének (illetve általában támogatja a "pluggable" tömörítőket).

Amit igazán sajnálok, az az, hogy az rpmbuild és az rpm közvetlenül van linkelve a libz-vel és a libbz2-vel, pedig legalábbis az rpm-ben elvileg benne van a tar-féle child process/pipe móka. Tehát nem lett volna lehetetlen a gz ill. bz2 (sőt, akár xz) tömörítésű payload elkészítését / kibontását subprocess-szel megoldani. Az ugye (majdnem) automatikusan párhuzamosíthatóvá tenné a (ki)tömörítési folyamatot. Ehelyett most egy szálon küzd az rpm(build) a tömörítve 170-230 MB-os (tömörítetlenül minimum 1.4 GB körüli) kernel debuginfo RPM-mel.

Egyszer belenéztem az rpmbuild ill. az rpm forrásába. Elképzelhető, hogy nem lenne túl nehéz egy "rpm-recompress"-t írni, de annyira szerteágazó az rpmlib és annyira használhatatlan a (generált...) doksija, hogy fél óra után letettem róla.

... Rémlik ugyanakkor, hogy az RPM5-nek van kifejezetten filter-t meghívó üzemmódja. (Csak az RPM5-öt meg ki a csuda használja, ugye...)

bruttó ~60k-ért vettem 120 GB

Mondom, hogy aranyárban van! :)

real 6.59

Ugyanakkor a teljesítménye lenyűgöző. Ez milyen típus volt? Kisebb nincs belőle óccsóbbér'? :)

"engedő módú Tomoyo és a szabályok csak korlátoznak"

Jajj, elnézést, közben hülyeséget írtam a párhuzamos task-jaim egyidejű kezelése miatt :)

Úgy akartam fogalmazni, hogy ha egy binárisnak létezik domain-je, akkor semmit nem tehet meg, maximum csak amit engedünk neki. Tehát Tomoyo nem negedő, hanem tiltó alapból. Ezért ahhoz képest lesz mindenképpen biztonságosabb, mintha nem lenne a binárisnak domain-je vagy egyáltalán a Tomoyo aktív, mert egyébként ugye mindent megtehet.

Az SSD-nek utánanézek pontosan.