Jaderné noviny - 19. 4. 2006

2. 5. 2006 | Robert Krátký

Články - Jaderné noviny - 19. 4. 2006  

Aktuální verze jádra: 2.6.16.9. Citát týdne. Virtuální čas. Thread-safe write() a POSIX. Budoucnost API pro linuxové bezpečnostní moduly (LSM). Linux: 2.6.17-rc2, Na jaderné frontě klid.

Aktuální verze jádra: 2.6.16.9

Aktuální verze stabilního jádra je 2.6.16.6 2.6.16.7 2.6.16.8 2.6.16.9. Byla oznámena 19. dubna. Obsahuje opravu chyby, která umožňovala únik informací na některých AMD procesorech. Co se týče předchozích verzí, tak 2.6.16.6 přinesla poměrně dlouhou řádku oprav, zatímco 2.6.16.7 a 2.6.16.8 obsahovaly pouze po jedné bezpečnostní opravě.

Aktuální předverze je 2.6.17-rc2. Linus ji oznámil 18. dubna. Je tam hodně oprav, ale také zjednodušená forma patche pro předcházení hladovění scheduleru, vyladění algoritmu používaného při přetížení paměti [memory overcommit], odstranění zastaralých ovladačů blkmtd a qlogicfc, odstranění nespravovaných ovladačů Sangoma WAN, systémová volání splice() a tee() a dotazovatelné atributy sysfs. Vizte dlouhý changelog.

Stojí za zmínku, že prototypy metod splice() ve struktuře file_operations byly opět změněny. Verze tohoto týdne výpadá takto:

ssize_t (*splice_write)(struct pipe_inode_info *pipe, struct file *out, 
                        loff_t *offset, size_t len, unsigned int flags);
ssize_t (*splice_read)(struct file *in, loff_t *offset, 
                        struct pipe_inode_info *pipe, size_t len, 
                        unsigned int flags);

Nový je parametr offset, který popisuje, kde by měl proud I/O začít.

Od vydání -rc2 bylo do hlavního stromu začleněno několik desítek patchů.

Aktuální -mm strom je 2.6.17-rc1-mm3. Mezi nedávné změny patří začlenění ovladače pro ACPI dock, podpora virtuálního adaptéru i2c, pár úprav správy paměti, aktualizace ovladače TPM a nová verze knihovny zlib.

Citát týdne

Neřekl bych, že by někdo mohl zvládnout nakonfigurovat Apache s SELinuxem. Já už Apache instaloval tak dvacetkrát, což je dost, ale nakonec jsem si uvědomil, že problém je v SELinuxu. Hodinu jsem to zkoušel opravit a pak jsem tu zatracenou věc prostě vypnul.

-- Dave Aitel

Nezapomínej, že "komplikovanost" SELinuxu pouze odráží komplikovanost Linuxu; SELinux jen ukazuje existující interakce a umožňuje je ovládat. Sám o sobě je mechanismus SELinuxu docela prostý.

-- Stephen Smalley

Virtuální čas

Vývojáři, kteří se zajímají o kontejnery a virtualizaci debatovali o rozhraních, pomocí kterých by virtualizovali přístup k různým systémovým zdrojům. Nikdo však nemluvil o virtualizaci přístupu k systémovému času. Tedy až doposud. S patchi pro virtualizaci času od Jeffa Dikea může mít každý strom procesů svou vlastní představu o tom, kolik je hodin.

Jeffův patch přidává do struktury úloh novou strukturu "time namespace" [časový jmenný prostor]. Ve výchozím nastavení sdílejí všechny procesy čas hostitelského systému. Ale nová volba (CLONE_TIME) v systémovém volání unshare() procesům umožňuje odpojení od systémového času. Po takovém volání je proces - a všechny potomky, které vytvoří - schopen mít vlastní hodnotu času. Pro nastavení hodnoty virtualizovaného času nejsou - na rozdíl od běžného systémového času - potřeba speciální práva.

Interně je virtualizovaný čas uložen jako obyčejný offset; kdykoliv proces požaduje aktuální čas, připočte se offset k aktuálnímu systémovému času a je vrácen výsledek. Tento přístup má výhodu v jednoduchosti a rychlosti; proces, který běží s virtualizovaným časem, také nepřijde o úpravy času, které provede například NTP. Na druhou stranu tato implementace nepodporuje možnost zmást procesy tím, že by se krutě zahrávalo s jejich představou o čase - například spuštěním času jinou rychlostí nebo dokonce pozpátku. Je však pravděpodobné, že tento nedostatek nebude trápit více než malé procento potenciálních uživatelů virtualizovaného času.

Jeffův cíl je urychlení systémového volání gettimeofday() v instancích User-mode Linuxu. Umožní-li jádro podstromům procesů mít vlastní hodnoty času, mohl by User-mode Linux prostě používat hostitelovo volání gettimeofday(), místo aby ho zachytával a pak implementoval sám. A protože gettimeofday() je jedno z nejčastěji používaných volání, mohlo by to znamenat výrazný rozdíl.

Aby však mohl z této změny User-mode Linux těžit, je potřeba ještě jedna změna. UML ovládá většinu procesů pomocí ptrace(); konkrétně zachytává a interpretuje systémová volání pomocí operace PTRACE_SYSCALL. Aby bylo gettimeofday() opravdu rychlé, je potřeba zařídit, aby toto konkrétní volání nebylo zachytávané. Takže Jeffův patch zároveň rozšiřuje ptrace() o operaci PTRACE_SYSCALL_MASK. Tato nová operace může nastavit bitmask značící, která systémová volání mají být zachytávána, a která mají být provedena bez zastavení.

Výsledkem je - při použití vhodně opatchovaného UML - volání gettimeofday(), které běží na 99 % rychlosti nativního procesu. To by mohlo být dost dobré na to, aby byl patch zařazen do rozrůstající se sady rozhraní podporujících virtualizaci a kontejnery.

Thread-safe write() a POSIX

Dan Bonachea nedávno nahlásil problém. Vypadá to, že má program, ve kterém zapisuje na stejný popisovač souboru více vláken současně. Čas od času něco z tohoto výstupu zmizí - přepsáno jinými vlákny. Náhodné vytrácení dat není obecně považováno za žádoucí a Dan tvrdí, že POSIX vyžaduje, aby byla volání write() thread-safe [pracovala spolehlivě i při současném spuštění více vlákny]. Takže by rád, aby byl problém napraven.

Andrew Morton rychle poukázal na příčinu tohoto chování. Podívejte se, jak vypadá implementace write():

    asmlinkage ssize_t sys_write(unsigned int fd, const char __user *buf, 
                                 size_t count)
    {
	struct file *file;
	ssize_t ret = -EBADF;
	int fput_needed;

	file = fget_light(fd, &fput_needed);
	if (file) {
	    loff_t pos = file_pos_read(file);
	    ret = vfs_write(file, buf, count, &pos);
	    file_pos_write(file, pos);
	    fput_light(file, fput_needed);
	}

	return ret;
    }

Tuto funkci nelze zamykat, takže dvě (nebo více) vlákna provádějící současný zápis mohou získat stejnou hodnotu pos. Obě pak zapíší svá data na stejné místo souboru a vlákno, které zapisovalo poslední, vyhraje.

Obalení celé funkce nějakým zámkem (například zámek inode) by problém vyřešilo a volání write() by bylo thread-safe. Cena takového řešení by však byla vysoká: další zamykací vrstva, kterou přitom téměř žádná aplikace nepotřebuje. Takové zřetězení write() operací by také znemožnilo současné zapisování do stejného souboru - schopnost, která se některým aplikacím může hodit.

Takže si někteří vývojáři nebyli jisti, jestli by toto chování vůbec mělo být napravováno. Není to věc, která by způsobovala potíže více než 99.9 % aplikací, a pro ty, které potřebují provádět tento typ současného zapisování, jsou k dispozici jiné možnosti. Například zamykání v uživatelském prostoru nebo použití volby O_APPEND. Proč tedy do jádra přidávat zbytečnou režii?

Linus odpověděl, že tu jde o "kvalitu implementace", a že pokud existuje nenáročné řešení, jak systém přimět, aby fungoval tak, jak to uživatelé očekávají, není důvod se tomu bránit. On sám navrhoval aplikovat zámek přímo na pozici v souboru. Jeho patch přidává mutex f_pos_lock do struktury file a využívá tento zámek k zřetězení jednotlivých použití a změn pozice v souboru. Tato změna způsobí zřetězení volání write(), zatímco další formy (asynchronní I/O, pwrite()) zůstanou nezřetězené.

Patch nebyl příliš komentován a v současné době už je začleněný. Jeho osud bude pravděpodobně záležet na tom, jestli bude předcházení problémů v takto neobvyklém případě považováno za dostatečně důležité ve srovnání s cenou, kterou za to zaplatí ostatní uživatelé.

Budoucnost API pro linuxové bezpečnostní moduly (LSM)

V roce 2001 proběhla v rámci prvního Linux kernel summitu diskuze o bezpečnostních politikách. Na setkání bylo rozhodnuto, že není zájem o začlenění několika konkurenčních implementací, které byly v té době dostupné. Místo toho měli vývojáři, kteří se zajímali o bezpečnost, vytvořit obecné rozhraní, aby ho mohla využívat kterákoliv bezpečnostní politika. Výsledkem bylo API Linux Security Modules (LSM) - dlouhá řada háčků [hooks], které lze použít k zachycení téměř jakékoliv operace v jádře.

Minulý rok začali někteří vývojáři mluvit o tom, že by možná bylo lepší LSM z jádra odstranit. Od doby, kdy bylo LSM začleněno, se objevil pouze jediný bezpečnostní mechanismus, který jej skutečně využívá: SELinux. A protože SELinux má pouze jednoho uživatele, a lze o něm také uvažovat jako o poměrně obecném a samostatném bezpečnostním řešení, není jasné, jestli je rozhraní LSM vůbec potřeba. Diskuze se však minulý rok vytratila a o vyhození LSM se příliš nemluvilo.

Až do teď. V reakci na aktuální diskuzi o LSM háčcích poslal James Morris patch přidávající LSM na seznam věcí k odstranění. A ne za dlouho. Navrhované datum je tento červen - neboli jádro 2.6.18. Pokud patch projde, LSM velmi brzy zmizí.

Nejprve to vypadalo, že by projít mohl: několik vývojářů jádra se postavilo za odstranění LSM, přičemž nikdo nebyl proti. Jediné, na čem se neshodli, bylo datum odstranění, protože někteří považovali 2.6.18 za příliš brzy. Ostatní však argumentují tím, že diskuze z minulého roku by se měly počítat do obvyklé jednoroční lhůty pro podobný druh změny, a proto už není nutné déle čekat.

Člověk by si řekl, proč ten spěch. Kromě argumentu "jen jeden uživatel" je toho však ještě víc. Jamesův patch obsahuje tento text:

[LSM] také přitahuje pravidelný přísun nepovedených a nefunkčních bezpečnostních modulů, např. BSD Security Levels [bezpečnostní úrovně BSD] a vývojáři v LSM vidí odpověď na úplně všechno, místo aby přemýšleli, co doopravdy potřebují, a jak kód správně a obecně navrhnout.

Takže LSM představuje pokušení, jak problémy řešit špatným způsobem. Kromě modulu bezpečnostních úrovní (který je, kromě jiného, považován za dveře otevřené dokořán bezpečnostním chybám, ale bez zájmu vývojářů) jde o epizody jako debata o realtime bezpečnostním modulu nebo Integrity Measurement Architecture [architektura pro měření integrity], z nichž ani jedna nebyla implementována jako bezpečnostní modul. Hlavním problémem je však možná toto:

Máme také stále větší počet proprietárních modulů využívajících LSM háčky způsobem, který není bezpečný; dokonce to nemusí být ani pro bezpečnostní účely. Sémantika LSM rozhraní je příliš slabá a takové API do jádra nepatří.

Jádro 2.6 - záměrně - neposkytuje natahovatelným modulům přístup k tabulce systémových volání. Ale rozhraní LSM je skoro stejně dobré - dává natahovatelnému modulu příležitost zachytit téměř jakoukoliv operaci, kterou se jádro může pokusit provést. LSM háčky by se měly omezovat na udržování interních záznamů a vracení stavu povoleno/zakázáno jádru - ale neexistuje způsob, jak podobné omezení vynutit. Status GPL-only [pouze GPL] také LSM API příliš nepomáhá.

Zainteresovaným lidem se příliš nechce ukazovat prstem na společnosti, které rozhraní LSM zneužívají. Jedním z příkladů však může být modul pro zobecněnou správu událostí [kernel generalized event management], který byl minulý rok poslán do konference kernel-mentors. Při nahrání vyhodil KGEM právě nahranou bezpečnostní politiku a nainstaloval na její místo sebe. Pak začal dodávat události týkající se bezpečnosti (proprietární) uživatelské aplikaci, která prováděla rozhodování zaměřené na ochranu linuxových uživatelů před vzrůstající hrozbou virových útoků. Kolem implementace tohoto modulu bylo hodně otázek, avšak využití LSM k přebití aktuální bezpečnostní politiky a poskytnutí háčků proprietárnímu kódu bylo považováno za zvláště nechutné.

Přes to všechno i přes tlak vývojářů zatím není jasné, jestli nakonec LSM půjde pryč nebo ne. Zatím nepanuje shoda o tom, že by SELinux měl být chápán jako jediná Správná Bezpečnostní Politika; hodně potenciálních uživatelů se těžko srovnává s jeho komplikovaností a často jej prostě vypnou. Síla SELinuxu je zřejmá, ale snadnost použití věc jiná.

Existují i jiní uživatelé LSM, jen ještě nebyly předloženy k začlenění do hlavního jádra. Například:

• AppArmor od Novellu, což je bezpečnostní politika, kterou v současné době používá SUSE. AppArmor je svobodný software, ale nikdy nebyl předložen k prohlédnutí. Diskuze o odstranění LSM zjevně nakopla několik zadních částí v Novellu a první předložení AppArmor je prý na spadnutí. (Bylo odesláno těsně po vydání tohoto článku.)

  Některé z dřívějších diskuzí však naznačují, že AppArmor možná bude mít do jádra těžkou cestu. Konkrétně používání názvů souborů jako základu bezpečnostní politiky bylo silně zpochybňováno. Na systému, který umí pevné a symbolické odkazy, vícero jmenných prostorů, sdílené podstromy a ještě více, není název souboru zdaleka jednoznačný. Proto SELinux využívá rozšířené atributy k aplikování značek přímo na soubory místo spoléhání na jejich názvy.

• Linux Intrusion Detection System (LIDS - systém pro odhalování průniku) také využívá LSM. Vývojáři LIDS žádají, aby LSM nebylo odstraněno, ale nevyjádřili se příliš k tomu, jestli a kdy by mohli svůj modul předložit k začlenění.
• Modul Dazuko využívají nástroje jako ClamAV. Dazuko vypadá trochu podobně jako KGEM, protože exportuje rozhraní pro uživatelské programy, které provádějí rozhodování. Není jasné, jestli má podobné rozhraní vůbec šanci projít kontrolním procesem.
• Multiadm je modul, který umožňuje přidělení práv i dalším uživatelům kromě roota.

Vzhledem k tomu, že bezpečnost rozhodně není vyřešený problém, bylo by překvapivé, kdyby existoval jediný přístup, který by vyhovoval všem uživatelům. Takže je docela dobře možné, že se vynoří něco, co se kvalifikuje jako druhý uživatel, a zachrání LSM API před odstraněním.

Nebo alespoň udrží nějaké API. Pokud zůstane LSM, provedou pravděpodobně vývojáři změny, které ztíží jeho zneužívání. To může zahrnovat nalezení způsobů, jak omezit činnost LSM háčků, a poskytnutí možnosti zadrátovat do jádra při kompilaci jedinou bezpečností politiku. Takže ačkoliv je reálná šance, že budoucí jádra budou obsahovat LSM rozhraní, může se od toho dnešního dost lišit. Všichni vývojáři bezpečnostních modulů, kteří chtějí mít vliv na to, jakým způsobem se bude rozhraní vyvíjet, by se měli k diskuzi brzy přidat.

---

Následující obsah je © KernelTrap

Linux: 2.6.17-rc2, Na jaderné frontě klid

19. dub, originál

Linus Torvalds připravil jádro 2.6.17-rc2 a vysvětlil, že ačkoliv obyčejně vydává -rc verze každý týden, tentokrát čekal kvůli cestování a všeobecnému klidu déle: Předpokládám, že odteď přejdu zpátky na týdenní rozvrh, i kdyby byl i nadále klid (což doufám). Linus také připojil krátké shrnutí změn:

Nic moc extra zajímavého, protože velkou část diffu zabírá aktualizace MIPS a obrovský diff z dlouho odkládaného odstranění ovladačů Sanoma WAN, které byly už dlouhou dobu nefunkční. Totéž platí pro ovladač qlogicfc (nahrazený ovladačem qla2xxx).

Díky tomu má diff tuny výmazů, i když ostatní změny moc velké nejsou. Ale jsou tam opravy netfilteru, další práce na splice a hromada náhodných věcí: usb, scsi, knfsd, fuse, infiniband...

Diskuse k tomuto článku

[al-Quaknaa]

Děkuju za další díl Jaderých novin, hlavně za část ohledně bezpečnostních mechanismů a LSM. Jiank pokud by se někdo z uživatelů SELinuxu chtěl vyjádřit, přemýšlím, jestli kamarádovi nasadit na comp OpenSuSE nebo Fedoru, FEdora se mi zdá lepší a navíc má SELinux (SuSE asi zase AppArmor), tak se můžete projevit a taky mi tím pomůžete :D

al-Quaknaa

[Robert Krátký]

V dalším čísle Jaderných novin bude více o "AppArmor vs. SELinux".

[Drom]

Vyborne, docela me to povidani chytlo i ve vztahu k tomu, ze sem si ted pokusne nainstaloval OpenSuSE a hrabal jsem se v tom apparmor :)

[Michal Kubeček]

Jaderná podpora SELinuxu je i v SuSE (aby ne, když je i ve vanilla jádrech), ale user space podporu a dokumentaci vzali docela hákem…

[Drom]

No ohledne SELinuxu vs. AppArmor nevim, nicmene nainstlaoval jsem si na zkousku na jeden komp suse a naprosto me zklamal yast (instalace balicku). Nejen ze je to nechutne pomaly (ok, neni to supr komp :) ale i tak), to bych prekousl, kdyby ten seznam balicku nesestavoval po kazdy akci.
Dost dobre nechapu, ze si nemuze strom udelat jednou a pak uz s tim neotravovat (a kontrolovat zavislosti "online"). Clovek si naklepe a odklepe co chce a nechce a pak ceka na vyhodnoceni zavislosti, pak musi zavislosti vyresit a zas ceka na vyhodnoceni zavislosti od tech zavislosti a pak je vyresi a zas ceka (a nebo si sledovat zavislosti rucne a vybrat si je sam, protoze system zavisly balicky sam neoznaci) a tak porad dokola, dokud se to (samo ale ne :)) nevyresi. Uplne stejny to bylo v instalaci RedHat 6.2 :(.
Podarilo se mi tam, i pres odpor rpm :) (nj, yast to nenasel, tak sem googlil a rpm -i), nacpat apt, tak se chystam, ze to zkusim tak, ale jinak bych tu distribuci (osobne) nebral.
Chapu, ze sem si nainstaloval 10.1RC3, nicmene necekam, ze se zlepsi i predvyber balicku (clovek chce Gnome desktop, ze kteryho tam sice system nepredvybere ani pulku, zato je tam pulka KDE). A pak si stejne stahl milion balicku navic, co sem vubec nechtel (instalace ze site). Jestli to byly zavislosti, tak mi to jaxi zapomnel rict...
BTW: docela neslusnost nepockat na me, kdyz jsem pryc, a po doinstalovani zapsat zavadec na disk a restartovat se. (i kdyz detekoval vse spravne - mam tam jeste Red Flag linux). Proste docela velky zklamani z pohledu spravy, jinak desktop (z uzivatelskyho klikaciho hlediska) se jevi super.
P.S.: Ten yum v FC taky neni extra rychlik :)

[Michal Kubeček]

Nebylo by lepší přestat si vymýšlet a kritizovat jen věci, které jsou pravda?

Dost dobre nechapu, ze si nemuze strom udelat jednou a pak uz s tim neotravovat (a kontrolovat zavislosti "online"). Clovek si naklepe a odklepe co chce a nechce a pak ceka na vyhodnoceni zavislosti, pak musi zavislosti vyresit a zas ceka na vyhodnoceni zavislosti od tech zavislosti a pak je vyresi a zas ceka (a nebo si sledovat zavislosti rucne a vybrat si je sam, protoze system zavisly balicky sam neoznaci) a tak porad dokola

Máte na výběr ze dvou možností. Buď si zkontrolujete závislosti kliknutím na příslušné tlačítko (plus jednorázově na konci) nebo si zapnete automatickou kontrolu po každé změně. Z vašeho poněkud zmateného popisu jsem nepochopil, kterou variantu jste používal, ale zkoušel jste i tu druhou?

Ještě poznámka: ne, závislosti se opravdu nemohou vyřešit samy. Když vytvoříte omylem kolizi, jak by měl instalátor poznat, který z těch balíčků má instalovat. Když A závisí na B a vy zvolíte instalovat A a neinstalovat B, jak má instalátor poznat, jestli má nainstalovat B nebo neinstalovat A? Když program vyžaduje MTA a vy žádný nemáte, jak má podle vás instalátor poznat, který z nabízených chcete?

clovek chce Gnome desktop, ze kteryho tam sice system nepredvybere ani pulku, zato je tam pulka KDE

Ten základní výběr je desktopový systém s Gnome jako primárním desktopovým prostředím. Nikde není řečeno, že tam bude celé Gnome (pokud po něčem takovém toužíte, je to otázka jednoho kliknutí navíc) ani že tam nebude absolutně nic z KDE (je to distribuce pro rozumné uživatele, ne pro GUI šovinisty).

A pak si stejne stahl milion balicku navic, co sem vubec nechtel

Na základě svých zkušeností jsem skálopevně přesvědčen, že instalační program neinstaloval nic, co jste si buď sám nevybral, nebo na co vás výslovně neupozornil, že bude instalovat také. Ano, ty automatické závislosti jsou trochu nepříjemné, ale na konci výběru balíčků se vám zobrazí seznam, kde jsou všechny automaticky přidané balíčky vypsány, a vy tento seznam musíte potvrdit (nebo to samozřejmě odmítnout a výběr ještě upravit). Jestli nedáváte při konfiguraci instalace pozor, nestěžujte si na instalátor, ten za to nemůže.

docela neslusnost nepockat na me, kdyz jsem pryc, a po doinstalovani zapsat zavadec na disk a restartovat se

Považuji za velmi podstatnou výhodu, že instalační program vás nechá nakonfigurovat celou první fázi instalace a pak ji celou najednou provede. Do toho samozřejmě spadá i instalace zavaděče. Že jste si jeho konfiguraci nezkontroloval (a případně neupravil), to je jen váš problém, na instalační program to, prosím, nesvádějte.

P.S.: nechápu, proč své stesky na instalátor SuSE (nebo spíš na své problémy při jeho používání) píšete ke článku o něčem úplně jiném.

[Drom]

Vzhledem k tomu, ze mam SuSE tremi dny, tak ho tezko muzu znat. Sdeluju svoje bezprostredni dojmy.

1] Nevim, jaka varianta je vyhozi nebo zda tam jsou jine varianty. Zadne nastaveni v tom nastroji nevidim. Je to snad nekde jinde? Abych si kontroloval kazdej balicek (jeho zavislosti) extra klepanim na tlacitko, mi prijde dost zbytecny. To by mohl delat system sam. Ted vidim, ze nesestavuje seznam pri klepnuti na tlacitko "Prekontrolovat", ok. Ale vadi mi, ze vyresi zavislost a nic nerekne (jen ze vsechny zavislosti jsou v poradku). A prida k tem balickum nejakej trojuhelnicek. A instalator mi muze nabidnout variantu, ja od nej nechci, aby neco "poznal sam".

2] Necekam, ze tam bude vsechno, ale predpokladal bych prohlizec pdf (evince) nebo evolution, gnome-themes a tak. Veci z KDE jsem nasledne odebral, protoze na nich nezaviselo nic, jediny, co tam zbejva je Qt kvuli Yastu (a mozna par malickosti), ostatni KDE veci tam byly k nicemu (nic na nich nezaviselo).

3] Nevim, instalator ukazoval, ze bude stahovat (nevim presne) do 3.5 GB (resp. ze tolik bude obsazeno na disku), vysledek byl cca 4300 MB. Nejsem si vedom toho, ze bych potvrzoval nejake baliky navic.

4] Ja jsem zavadec nenastavoval, kdyz jsem se vratil domu, bzl system restartovan po instalaci a pak zbyvala jen konfigurace HW a podobne. Na nastaveni zavadece jsem nikde nenarazil.

P.S.: Reagoval jsem na uzivatele al-Quaknaa a jeho premysleni o nasazeni linuxu u kamarada. No ok, jdu si opravit podpis.

[Michal Kubeček]

Ad 1: Buď si čas od času kliknete na tlačítko zkontrolovat závislosti, instalátor zkontroluje závislosti a zobrazí vám seznam problémů vždy s dvěma až třemi variantami řešení. Totéž se pak samozřejmě provede automaticky ještě jednou na konci. Nebo si dole zaškrtnete kontrolovat automaticky a pak se instalátor chová, jako byste na to tlačítko kliknul po každé změně. Opravdu nechápu, jak lépe byste si představoval, že to bude vyřešeno.

Ad 2a: Při jakémkoli předvýběru se stane, že tam budou chybět věci, které někdo považuje za "naprosto nezbytné", a naopak tam budou věci, které někdo považuje za "naprosto zbytečné" Kdyby nic jiného, tak už proto, že pro spoustu balíčků existují jak lidé, kteří je považují za "naprosto nezbytné", tak lidé, pro které jsou "naprosto zbytečné". Ono je to totiž subjektivní hodnocení. Právě proto máte možnost si ten počáteční výběr upravit tam, kde vám nevyhovuje.

Ad 2b: Opakuji, že ne každý je takový GUI-šovinista, aby musel ze svého počítače za každou cenu odstranit cokoli, co má něco společného s jiným desktopovým prostředím, než které primárně používá. Pokud jím jste, fajn, máte možnost si ten výběr upravit. Prostě vezměte na vědomí, že autoři toho předvýběru jsou tolerantnější a "desktop s Gnome" pro ně neznamená "desktop bez jakékoli stopy KDE", stejně jako "desktop s KDE" pro ně neznamená "desktop bez jakékoli stopy Gnome".

Ad 3: Pokud jste žádné balíčky navíc nepotvrzoval, pak tam žádné nejsou. Je samozřejmě logické, že odhad spotřebovaného místa je pouze orientační. Navíc záleží na tom, co vlastně přesně znamená ta hodnota 4300 MB, o které mluvíte.

Ad 4: Pokud jste konfiguraci zavaděče nenastavoval, pak jste byl asi spokojen s tím, co vám instalátor navrhnul. Pokud jste s tím spokojen nebyl, měl jste si ji přenastavit. Promiňte, ale nechápu, v čem vidíte problém: instalátor vám navrhnul nějakou konfiguraci zavaděče, vy jste ji beze změn odsouhlasil a ta konfigurace vám funguje; tak na co si vlastně stěžujete? Na to, že se vás na konfiguraci zavaděče zeptal před tím, než začal rozdělovat disk a instalovat RPM a ne až potom?

[Drom]

1] Aha, tedy beru zpet. Drive jsem si te volby nevsiml, ted jsem to pustil a vidim, ze tam je, ma chyba. nj, jsem slepej :)

2a] Nevim, ale zakladni aplikace Gnome, jako Evince, bych v predvyberu ocekaval. Tusim, ze tam nebyl ani fileroller nebo gnome-terminal, ale uz si presne nevzpominam, za par dni to zkusim nainstalovat znovu. Naprosto nesouvisejici knihovny, na ktere nic nema zavislost, bych necekal.

2b] Mozna jsem sovinista, nicmene pokud mam omezene misto, na ktere muzu instalovat, tak se snazim nepotrebny veci vyhazet. A opet opakuji, nevidim zadny vyznam v baliccich z KDE, na kterych nic neni zavisle a ani nic neposkytuji. Naprosto zbytecne.

3] cca 4300 MB mel system po instalaci. Nechce se mi verit, ze by ses instalarot seknul o nejakych 700-800MB v odhadu.

4] Zadne nastaveni zavadece me necekalo, v tu dobu jsem nebyl u pocitace. A ani zadne nastaveni zavadece pred rozdelenim disku. Odchazel jsem cca hodinu pred koncem instalace, vratil jsem se a system byl zrestartovany, zavadec (asi) nainstalovany a ja nastavoval hardware a uzivatele a tak podobne. K zavadeci jsem nedosel behem instalace nikde nedostal.

[Michal Kubeček]

Ad 2a: vy byste je tam očekával, ale pochopte, že to neznamená, že je za stejně nepostradatelné budou považovat všichni. Právě proto máte možnost defaultní výběr upravit, pokud vám v něčem nevyhovuje. Všem stoprocentně prostě vyhovovat nemůže.

Ad 2b: pokud máte omezené místo, pak je logické, že nepoužijete defaultní výběr, ale ořežete ho. Nechápu, proč se tak divíte, že vám v takovém případě defaultní výběr nevyhovuje.

Ad 3: neodpověděl jste na otázku, nezbývá mi tedy, než ji zopakovat. Co přesně znamená ta vámi uváděná hodnota?

Ad 4: zavaděč se konfiguruje společně se vším ostatním ještě před definitivním potvrzením instalace. Tedy ve stejnou chvíli, jako vybíráte software, konfigurujete časovou zónu, defaultní runlevel, rozdělení disku atd. Stejně jako u všeho ostatního i u konfigurace zavaděče vám instalátor navrhne nějakou konfiguraci a vy máte možnost ji změnit. Pokud jste to neudělal, je to jen a jen váš problém a nechápu, proč to vyčítáte instalačnímu programu; zejména nechápu, na co si stěžujete, když sám uvádíte, že vám ten jeho návrh vyhovoval.

[Drom]

2a] Ptam se: K cemu tam jsou baliky, ktery jsou k nicemu? Knihovny prostredi, ktere tam neni? Proc jsou takove veci v predvyberu? A proc tam nejsou daleko relevantnejsi veci typu prohlizec pdf a (pokud si vzpominam, nejsem si jist) fileroller nebo gnome-terminal?

2b] To jsem samozrejme udelal, ja se nedivim, ze mi nevyhovoval, ja se divim, proc tam jsou balicky, na kterych nic nezavisi, k nicemu nejsou a nic neposkytujou. Proc je tam pulka jineho prostredi, ktere tam neni (nema byt - dle vyberu defaultniho desktopu) a ktere samo o sobe v tehle konfiguraci balicku nefunguje a v takove podobe tyhle soucasti jsou k nicemu? Proc mam v garazi vedle sveho auta pul motoru, dvere a dve pneumatiky z letadla?

3] Nechapu, co ocekavate za odpoved. System po instalaci zabiral cca 4300 MB z celkove kapacity /, odhad pred instalaci byl o 700-800MB mensi. Kde se tam vzal takovy rozdil? Neco se doinstalovalo? Nevidel jsem zadne okno s potvrzenim... Zajima me, jak je to mozny, ze odhad zabraneho mista byl o tolik mensi nez nakonec ve skutecnosti zabraneho mista bylo. Kde se vzalo 20% objemu dat na disku navic?

4] To, ze mi, shodou okolnosti, nastaveni zavadece vyhovovuje, neznamena, ze jsem nekde takove nastaveni potvrdil. Zadne nebylo a nebo bylo schovane pod nejakou volbou kdesi. V okne "Nastaveni zavadece" nebo podobne, jsem, pokud si vzpominam, nebyl. A vychozi run level? To ma bejt v instalaci taky? :)

[Michal Kubeček]

2a: Už jsem jsem vám to vysvětlil několikrát: zda je balík "k ničemu" nebo "nepostradatelný", je ryze subjektivní záležitost. To, že vy něco považuje za "k ničemu", neznamená, že to tak budou hodnotit všichni (a naopak). Knihovny jsou tam zcela překvapivě proto, aby je mohly využívat aplikace. Prohlížeč PDF v tom výběru samozřejmě je - že to není zrovna ten, který vy osobně máte nejraději, to se holt nedá svítit…

2b: Pochopte konečně, že "desktop s Gnome" neznamená "desktop, kde je jen Gnome (a nic jiného)". Oba standardní výběry jsou velmi podobné, pouze v jednom je trochu zdůrazněno KDE (a nastaveno jako defaultní WM), zatímco ve druhém Gnome. V obou jsou ale základy obou desktopových prostředí a několik dalších jednodušších window managerů.

3: Je mi líto, ale pořád jste neodpověděl. Až konečně řeknete, co přesně ta vaše hodnota 4300 MB znamená, tedy jak přesně jste k ní došel (du? df? nějak jinak?), můžeme se bavit o tom, čím ten rozdíl může být. Pro začátek pár tipů: jednak 1 GB není 1000 MB, jednak ne všechny soubory, které v systému máte, pocházejí z instalace. Např. u mne zabírá ~/.kde 13 MB a ~/.mozilla dokonce 168 MB… Také nezapomeňte na prostor rezervovaný pro roota, žurnál a nastavení velikosti bloků filesystému.

4: Říkám vám, že jste ho potvrdil (spolu se vším ostatním) a hlavně že jste si ho nakonfigurovat mohl, pokud byste o to stál; instaloval jsem ten systém tolikrát, že mi můžete věřit. Pokud nedáváte pozor a nevšiml jste si toho, je to jen a jen váš problém. Je tam nastavení defaultního jazyka a rozložení klávesnice, typu myši, rozdělení disku, výběr software, nastavení zavaděče, časové zóny a defaultní runlevel (snad jsem na nic podstatného nezapomněl). U všech těchto nastavení vám instalační program něco navrhne a vy máte možnost to buď nechat podle jeho návrhu nebo si to udělat po svém. Pak musíte zvolenou konfiguraci potvrdit a teprve potom se začne instalovat ((pře)rozdělí se disk, vytvoří se filesystémy a nainstalují se balíčky). Takže pokud si stěžujete, že jste nekonfiguroval zavaděč, je to stejné, jako byste si stěžoval, že jste nenastavil defaultní jazyk, nerozdělil disk nebo nevybral balíčky k instalaci.

[Drom]

2] Pokud nema v systemu zadnou funkci a je k nicemu, nevim, proc by tam nekomu k necemu byl. Je k nicemu a pokud by ho nekdo potreboval, tak si ho snad nainstaluje. to tam muze bejt taky vsechno (kdyby to nekdo potreboval). A nejde mi o to, ze nejakej program mam nebo nemam rad, ale kdyz uz tam teda je predvyber desktopu, ocekavam, ze bude seznam balicku prednastaven tak, aby tomu co nejvice vyhovoval. A ne asi tak, jako kdybych vybral KDE a nebyla tam kon[z,s]ole (nevim, co tam je za pismenko) nebo konqueror (coz asi dost dobre nejde, ale je to priklad), ale za to libgnomeui-common a gtk-engines. Ja necekam, ze tam budou JENOM Gnome veci, ale ocekavam zakladni nastroje pro Gnome, kdyz uz si teda Gnome vyberu. To, ze tam je zaklad jineho prostredi ja osobne povazuju za zbytecnost, to je muj nazor (ale to jsem takhle nerekl). Ja se ptam, proc tam nejsou zakladni veci z gnome (a vzhledem k tomu, ze prohlizecu PDF a terminalu pro gnome moc neni, tak logicka jednoducha volba), ale zato pulka prostredi, co tam neni?

3] Cca 4300MB ukazuje Yast, kdyz chci instalovat balicky (a df to potvrzuje - jak rikam, uz si presne nepamatuju, kolik to bylo po instalaci, delal jsem par uprav, ale tusim 4300 MB a odhad Yastu pred instalaci byl o takovych 700-800 MB mene). To, ze 1GB != 1000MB vim, ale to neni ted vubec podstatny, to takovej rozdil neudela, i kdyby pri instalaci ukazoval MB a ted GB nebo libovolne jinak. Domaci adresare jsou na jinem disku, adresar uzivatele root nezabira prakticky nic, ten ucet nepouzivam. Tak maximalne par kB.

4] No rikam, ze to tam mozna nekde bylo, ale rozhodne to nebylo pred instalaci. Prvni (po konfiguraci site) se stahovaly balicky a rovnou je Yast instaloval. Pak jsem se vratil a system byl zrestartovan. Pak vim, ze jsem nastavoval HW a podobne, na zavadec si nevzpominam.

No v tejdnu to preinstaluju a napisu krok za krokem, co Yast dela a uvidime.

[Michal Kubeček]

2. Pokud vám třikrát zopakuji, že to, co vy považujete za naprosto základní a nepostradatelné, nemusejí nutně za naprosto základní a nepostradatelné považovat všichni (a že zrovna tak ostatní mohou využít věci, které vy považujete za zbytečné), a vy to stejně pořád nedokážete (nebo nechcete) pochopit, pak je mi líto, ale asi nemá smysl vám to dál vysvětlovat. Srozumitelněji už to napsat nedokážu.

3. Několik hintů, čím to může být, jsem vám naznačil - rezervované bloky, žurnál, soubory vzniklé až po instalaci (nemusejí být jen v domácích adresářích)…

4. Konfigurace zavaděče se provádí před tím, než systém začne instalovat balíčky. Tečka. Přesvědčí vás aspoň tohle, nebo mi budete tvrdit, že jsem si to nakreslil v GIMPu? (No dobře, nakreslil, ale jen ty šipky.)

Už mne to začíná unavovat, pokud dál chcete opakovat nepravdivá nebo zavádějící obvinění na adresu distribuce, která vám nepadla do oka, klidně si v tom pokračujte, všichni ostatní už snad pochopili, jak se věci mají.

[Hynek (Pichi) Vychodil]

Panebože, proč jsi dal dušu do barana. Tak polopatě. Soubor .so který žádný z nainstalovaných programů nevyužívá je k ničemu bez ohledu na preference. To se vám asi někdo snaží sdělit.

[Michal Kubeček]

Není řeč o jednotlivých so souborech, je řeč o balíčcích. Pro kohokoli, kdo není GUI-šovinista, jsou balíčky s KDE knihovnami užitečné. Proto v defaultním výběru distribuce jsou, ne proto aby provokovaly ortodoxní gnomisty, kteří při každé zmínce o KDE vidí rudě.

Ale i kdyby šlo o jednotlivé so soubory, tak s vámi naprosto nemůžu souhlasit. Co třeba starší verze základních knihoven pro zpětnou kompatibilitu? Co 32-bitové verze knihoven pro kompatibilitu? A samozřejmě i další knihovny, které je dobré mít v systému k dispozici, přestože je zrovna teď žádný program nevyužívá.

Navíc, upřímně řečeno, ohledně toho, zda ty knihovny opravdu k ničemu potřeba nejsou, považuji za směrodatnější názor těch, kdo u SuSE distribuci dávali dohromady, než názor člověka, který sám přiznává, že má celé tři dny zkušeností a který sám dal najevo, že při instalaci nedával pozor, co vlastně nastavil…

[DjAARA]

Kdyz ja instaloval svou distribuci, tak jsem rekl, ze chci gnome dekstop a tak jsem dostal funkcni gnome destop. Knihovny ktere by mi byly v systemu uplne k nicemu a nic na nich nezaviselo se mi nenainstalovaly. Proc taky.

Jasne, nemam a neznam SUSE a vim co potrebuji a co ne. V me distribuci s tim neni problem a je tu jen to co tu mit chci. Stejne jako mam pocit, ze toho sameho by slo dosahnout nejakym peclivym vyberem pri instalaci. Ale to by se muselo jit asi do detailnejsiho vyberu nez GNOME x KDE desktop :o.

Ono je samo o sobe dost tezke rict co je to GNOME ci KDE desktop. Spousta lidi si neumi predstavit GNOME bez aplikaci z KDE a naopak. Ten defaultni vyber je udelan tak aby pri instalaci pripadnych dalsich programu nebyl problem s tim ze nejaka knihovna chybi, ale to by stejne mel resit balickovaci system a v pripade ze je nejaka knihovna potreba tak ji doinstalovat a ne mi hned pri instalaci cpat neco co fakt nepotrebuju. Mozna zatim. Mozna na porad.

Porad ale mate moznost volby a ten komu SUSE svym chovanim pri instalaci nevyhovuje at pouzije neco jineho. Stejne nejcastejsi chyba byva mezi zidli a klavesnici a ne v distribuci. Teda ne ze by v distribuci chyby nebyly

[Michal Kubeček]

To je přesně to, co se tu celou dobu snažím vysvětlit: že v pojetí té distribuce (a v pojetí většiny uživatelů) termín "desktop s Gnome" neznamená "desktop beze stopy KDE" (a samozřejmě ani naopak). Jenže asi marně… :-(

[DjAARA]

[Michal Ludvig]

Pred par mesici jsem se snazil SElinux nakonfigurovat takzvane "od podlahy", tedy ne pomoci RedHatiho SElinux on/off, ale pekne od zacatku na cisty system zacit vytvaret pravidla pro nektere procesy (nebo objekty nebo jak tomu rikaji). Tenhle masochismus mi vydrzel asi tyden, pak uz jsem mel lepsi veci na praci.

Pro me je SElinux zbytecne komplikovany. Sice nejspis umoznuje omezit / nastavit uplne vsechno, ale z toho duvodu jsou i trivialni upravy politik neskutecne slozite a nachylne k chybam. Nepovedlo se mi vyzkouset si zaklady konfigurace na jednoduchych prikladech. Proste tam neni nejaky "easy mode" a "expert mode", misto toho musite zacit rovnou v "hyper expert NSA mode". Holt to neni system vzesly z potreb praxe, ale od paranoidnich bezpecnostniku NSA, cimz neni v praxi ani prilis dobre pouzitelny.

PS ovsem nevylucuju ze jsem proste hloupej a ze SElinux je vzor uzivatelske pritulnosti. Jen jsme si nejak nesedli...

[Vašek Lorenc]

To je jak tvrdit, že autoři manuální převodovky jsou blázni, neb v praxi je přeci mnohem pohodlnější na naučení automatické řazení.

"Praxe" je široký projem. A pro specializovaný server s pár málo procesy je konfigurace SELinuxu od začátku ještě zkousnutelná, byť si to člověk asi nemusí užívat každý den.