CentOS 4.2 (diskuse)

[Radek Hladik]

Zkusil jsem u zakaznika nasadit CentOS 4.0 a uprimne receno: neni to spatna distribuce, ale zustanu u Fedory (i na serverech). Nekolik malo postrehu:

* adduser nechtel pridat uzivatele s $ ve jmene, takze nefungovalo spravne pridavani machine accounts pres sambu. Doporuceny workaround je nainstalovat userutils z FC4 :)

* potreboval jsem prelozit modul pro bttv kartu, ale nepodarilo se mi zdrojaky jadra ukecat k tomu, aby prelozeny modul fungoval s puvodnim supported kernelem (mozna kvuli podepisovani modulu, mozna kvuli necemu uplne jinemu). Kazdopadne jsem si musel nainstalovat unsupported kernel.

* Modul pro appletalk to same

* Nefungovaly lm_sensors, u FC4 na tom stejnem pocitaci chodily bez problemu

Kdyz to shrnu, tak vykonove a stabilitou to vypada na velmi dobrou distribuci, ale predevsim pro "standardni" sluzby.

[tezkatlipoka]

* adduser nechtel pridat uzivatele s $ ve jmene, takze nefungovalo spravne pridavani machine accounts pres sambu. Doporuceny workaround je nainstalovat userutils z FC4 :)

tahle chyba ale obevila o vsech RH klonu, a i u Redhatu, pouziti vbalicku z FC4 bylo nouzove reseni, prisla oprava.

[Abraxis]

No, workaround pro uzivatele je pridat je s jinym jmenem a potom vyeditovat /etc/passwd apod. Nevim, jak CentOS 4.0 (a RHEL), ale mel jsem problemy s minulym RedHatem, ze nechtel pridavat uzivatele s teckou ("jmeno.prijmeni") (grrrrrrrrr) (resil jsem upravou zdrojaku a rekompilaci RPMka ))

[honza]

ja pouzivam jiny workaround. Zakaznik, ktery chce $ nebo tecku v loginu, tak toho nejdrive nakopnu poradne do zadku. A budto svuj nazor zmeni, nebo si muze najit jineho dodavatele - to me neboli, protoze o takove zakazniky neni co stat ....

[Abraxis]

A duvod? Tecka ve jmenu uzivatele je podle mne normalni regulerni znak (navic hodne firem ma emaily ve tvaru "jmeno.prijmeni@firma.cz", takze je dobre mit i stejne pojmenovane uzivatele).

$ v loginu jsou specialni loginy pro Sambu - tomu se nevyhnes!

Navic - obecne UNIXove loginy muzou obsahovat libovolne znaky krome : a NULLu

[Michal Kubeček]

A duvod? Tecka ve jmenu uzivatele je podle mne normalni regulerni znak (navic hodne firem ma emaily ve tvaru "jmeno.prijmeni@firma.cz", takze je dobre mit i stejne pojmenovane uzivatele).

To je sice populární a hojně rozšířené, ale nepříliš prozíravé. Login name je identifikátor, a kombinace jména a příjmení nesplňuje zcela zásadní požadavek jednoznačnosti. Chcete-li mermomocí někam nacpat jméno a příjmení, existuje v tabulce uživatelů položka, která je k tomuto účelu daleko vhodnější, už proto, že právě k tomuto účelu byla zřízena: full name. Chcete-li uživatelům zřizovat módní e-mailové adresy, i na to existuje standardní nástroj: aliasy.

[Abraxis]

Dle teto logiky je nejlepsim loginem rodne cislo uzivatele nebo nahodne vygenerovany string. Cokoliv jineho je nejednoznacne.

Full name i aliasy samozrejme znam. Mel jsem na mysli male firmy s par desitkami uzivatelu max.

Ja jsem jenom argumentoval na to, ze zakazovat v loginu apriori nejake relativne korektni znaky je blbost. Navic - pokud tahas uzivatele z winbindu nebo LDAPu, tak se ti tam velmi casto ve velkych sitich objevi veci, ze bys nad nimi rostl (diakritika, hvezdicky apod.) - a pak se teprve pozna spravne napsany nastroj pro praci s uzivateli

[Michal Kubeček]

Ja jsem jenom argumentoval na to, ze zakazovat v loginu apriori nejake relativne korektni znaky je blbost.

A priori korektní znaky jsou písmena anglické abecedy (raději jen malá) a číslice. Čislice raději až od druhého znaku. Podle okolností ještě možná podtržítka a pomlčky. Na cokoli jiného si raději nechte zajít chuť, protože s tím můžete někde narazit. Například ta tečka: představte si, že existují uživatelé abc a abc.def a skupina def (povolíte-li tečku v login name, je něco takového naprosto korektní); co má podle vás potom udělat příkaz

  chown abc.def file

?

[Abraxis]

Co by delal? Nastavi vlastnika "file" na uzivatele "abc.def". Alespon v mem Linuxu ma chown syntaxi "chown user:group file" - cili stejne jako v passwd - tedy opet muze byt ve jmenu uzivatele cokoliv krome NULLu a dvojtecky.

Cislice ne "radeji az do druheho znaku", ale URCITE az od druheho znaku (vyzkouseno) - hromada utilit pak nepozna, zda zadavas UID nebo jmeno.

[Michal Marek (twofish)]

Pokud uživatel abc.def neexistuje, tak nastaví vlastníka na abc a skupinu na def.

[Michal Kubeček]

Alespon v mem Linuxu ma chown syntaxi "chown user:group file" - cili stejne jako v passwd - tedy opet muze byt ve jmenu uzivatele cokoliv krome NULLu a dvojtecky.

To je standardní chování. Ale všechny mně známé verze chown (včetně GNU verze) kvůli zpětné kompatibilitě stále akceptují i dříve používanou tečku.

[honza]

[...] A duvod? [...]

loginm je zasadne neco co sestava z ascii 'a' - 'z' a eventuelne '0' az '9'. Vsechno ostatni je zakazane, protoze se muze stat, ze budu chtit nekdy v budoucnu nainstalovat nejaky OS (napr. Centos 4.X) a ono by to nemuselo funguvat ....

Rika se tomu zdravy rozum a vsechno ostatni je kraulovani v technickych problemech, ktere musi nekdo platit. Jestize zamestnavatel nebo zakaznik tyto zaliby plati, pak jsou povoleny i jine znaky.

Jinak nasazuji linux se sambou od roku 1994 a jeste nikdy jsem nepotreboval login s $. Clovek musi mit halt stesti....

[Johny z Podoli]

to jste asi nikdy na sambe nedelal PDC, pak by vam bylo jasne, že $ je fakt třeba. Jedná se o specialni account clenttova pc...

[honza]

a kazdy takovy client ma zaznam v /etc/passwd ??

[tezkatlipoka]

ano, kazdy ucet pro Win2k a WinXP musi mit zaznam v passwd a to s $ nakonci. Podle toho se pozna co je ucet cloveka a co je trusted account pro pocitac. Viditelne Samba neni z tveho kralovstvi.

[Michal Kubeček]

Nějak ale nevidím důvod, proč by ho měl mít v /etc/passwd. Proč ho raději nedáte do smbpasswd, kam patří?

[Abraxis]

To, co je v passwd, tak MUZE byt v smbpasswd. To, co je v smbpasswd, tak MUSI byt v passwd (nebo LDAP/winbind...).

[Michal Kubeček]

Dobře, vyjádřil jsem se nepřesně. Prostě jméno, pod kterým se přihlašuje klient, nemusí být stejné jako jméno lokálního unixového uživatele, kterému odpovídá. Můžete si ho přemapovat.

[tezkatlipoka]

ano, nemusi, klient muze mit jine jmeno v smbpasswd a jine v passwd, ale tady se bavime o uctu pocitace. Dava se jednou s $ na konci do passwd a jedno bez nej do smbpasswd. Davat pokazde jine jsem nezkousel, a prijde mi to divne, vzhledem k tomu ze se vlastne jedna o jmeno PC.

[Abraxis]

Povolene znaky pro login u UNIXu je obecne cokoliv krome : a NULL a login nesmi zacinat cislem. Tot, AFAIK, pravi standard.

[honza]

jak ale OP referoval, Centos se o ten standard tak nejak nestara ?? Zdravy rozum a normy jsou rozdilne veci

[Miloslav Trmac]

To (aspon jeden) standard rozhodne nepravi :)

Jak Vas (na nekterych distribucich) presvedci (man 1p chown), standard IEEE 1003.1-2003 ("POSIX") pocita i s moznosti uplne numerickeho loginu.

Standard rika (3.426): To be portable across ..., the value is composed of characters from the portable filename character set. The hyphen should not be used as the first character of a portable user name.

"portable filename character set" je [-._a-zA-Z0-9]

[VícNežNic]

Fuj, to jsou taky takoví fašisti co chtějí loginy maximálně osm znaků dlouhé protože podobné řeči.

[bhy]

no, já jsem si o sobě nemyslel, že jsem fašista, spíš naopak, cítím se být anarchistou :) krátké loginy (a nejen loginy ale obecně řetězce, co na počítači opakovaně a často zadáváte) se mi líbí nikoliv protože podobné řeči, nýbrž protože to je pohodlnější (méně času zabere práce se psaním loginu, více času zbude na zábavu a jiné věci). do standardu bych to netahal, je to otázka priorit. :)

[Radek Hladik]

Tak to pak prichazite zbytecne o hodne zakazniku, coz me vzhledem k vasemu pristupu k zakaznikum ani moc nemrzi :)

Kazdopadne $ ve jmene je potreba, pokud chci provozovat PDC pro WindowsNT+, protoze klient si zalozi machine account, coz je temer normalni systemovy ucet, pomoci ktereho se pocitac prihlasuje do domeny. A je standardne ve tvaru jmenopocitace$. A rucni editace resi jen cast problemu, protoze pak nefunguje automaticke pridavani novych pocitacu do domeny. Resp. fungovalo by, kdyby se na to napsal nejaky skript, protoze samba na to ma volbu add machine account script (nebo tak nejak), ktera vola primo prikaz adduser. Takze jednoduchy workaround by byl napsat skript, ktery usera prida bez $ a pak prida ten $.

Radek

[Pavel 'lingeek' Szalbot]

Instalace a "poinstalace" ~ Fedora. Škoda, že se článek nevěnuje binární kompatibilitě s distribucí severoamerického výrobce, která na mě působí rozporuplným dojmem (něco funguje, i když by nemuselo, co by mělo zase nefunguje vůbec).

[xkesh]

Škoda, že se článek nevěnuje binární kompatibilitě s distribucí severoamerického výrobce

Souhlasim, skoda. Treba se toho nekdo ujme a napise pokracovani na zaklade vlastnich zkusenosti, kde uz se nemusi venovat trivialnostem zminenym v tomto clanku.

[amnesiac]

Jaká je pravděpodobnost, že jedním rozhodnutím v RedHatu přestanou veřejně uvolňovat zdrojové balíčky svého RHEL a tím zlikvidují tuto distribuci ?

Podle podmínek GPL, kterou je licencována většina sw v RHEL, jsou povini umožnit přístup ke zdrojákům pouze zákazníkům a hlavně to nemusí být v podobě připravených a funkčních balíčků, takže to co dělají je jenom čistě dobrovolná záležitost, která může ze dne na den skončit. Tak to alespoň vidím já.

[Honza Král]

mozna (nevim, jestli se nezavazali nejakym prohlasim atp), ale kozdopadne to muze vzdy nekdo prevzit...

osobne povazuju byt i nejistou podporu firmou RedHat za spolehlivejsi nez podporu tisicem dobrovolniku (brano z hlediska cilovych zakazniku CentOSu - tzn podniky lakany kompatibilitou s RHEL - treba kvuli ORACLE ci jinym proprietarnim app, ktere podporuji pouze RHEL), protoze kdyz se nenajde dobrovolnik kdtery by se chtel hrabat v balicku XY, tak se proste nic neudela, naproti tomu RH dalo sve slovo a ma zamestnance, kterym rekne: hrab se!

[hyperion]

AFAIK CentOS narozdil od RHEL NENI certifikovanym OS pro Oracle, takze muze byt "kompatibilni" jak chce, ale pri prvnim problemu od toho daji lidi z Oraclu ruce pryc.

[Michal Kubeček]

treba kvuli ORACLE ci jinym proprietarnim app, ktere podporuji pouze RHEL

(váš příspěvek)

Oracle's Unbreakable Linux Support offering includes Linux operating system support for Red Hat Enterprise Linux AS/ES (RHEL), Novell SUSE LINUX Enterprise Server (SLES), and Asianux. Oracle customers running RHEL, SLES or Asianux, can call Oracle directly for any Oracle or OS issue.

(web Oracle)

[Petr Špatka]

Podle mě, v tomto případě bude stačit pokud někdo z CentOS týmu koupí 1 kus příslušného RHEL a tím získá přístup ke zdrojákům oprav. Podle mě GPL licence pak nebrání vydávat tyto opravy zkompilované pro CentOS. A že by zákazníkům místo src.rpm dali jenom nějaká torza snad až tak nehrozí.

Jinak CentOS používám a jsem s ním spokojen. Prioritně jsem se nesnažil ušetřit, ale nechtěl jsem kupovat zajíce v pytli.

[Jiří Lisický]

Rád bych sem doplnil informaci, kterou jsem sám nedávno hledal (v článku je to naznačeno):

CentOS 4.2 = CentOS 4 + updaty

Ad instalace z prvního CD. Pokuď budete instalovat ze sítě a nechce se vám vypalovat (stahovat) celé CD, stačí použít image z adresáře os/i386/images. boot.iso (4.8 MB) je CD image, diskboot.img (6MB) se dá použít třeba na nabootovaní z USB flash disku.

[xkesh]

Ad instalace z prvního CD. Pokuď budete instalovat ze sítě a nechce se vám vypalovat (stahovat) celé CD, stačí použít image z adresáře os/i386/images. boot.iso (4.8 MB) je CD image, diskboot.img (6MB) se dá použít třeba na nabootovaní z USB flash disku.

Ano, diky za doplneni, tuhle moznost jsem opomnel popsat. Prvni CD jsem stahoval, protoze jsem byl zvedavy, jestli je mozne instalovat pouze z nej. Neni.

[Lukáš Zapletal]

pro ty uživatele, kteří si profesionální (placené) řešení RHEL nemohou či z principu nechtějí dopřát.

Co je to proboha za "princip"? Buď si jej nemohou dovolit, nebo ho nepotřebují. Nějak mi uniká význam. Pěkný článek.

[xkesh]

pro ty uživatele, kteří si profesionální (placené) řešení RHEL nemohou či z principu nechtějí dopřát.

Co je to proboha za "princip"? Buď si jej nemohou dovolit, nebo ho nepotřebují. Nějak mi uniká význam. Pěkný článek.

Diky :) Vyznam je ciste ironicky a znamena totez, co jste napsal vy. Je to princip neplatit za neco, co (jeste) nepotrebuji :)