Příspěvky

Najjednoduchsie riesenie:
1. Nainstaluj Virtualbox
2. Do Virtualbox-u nainstaluj 32-bitovu verziu systemu
3. Skompiluj 32-bitove baliky v tom virtualnom stroji

Pokial sa dobre pamatam, v multiarch (zatial) nejde kompilovat baliky inej nez hlavnej architektury. Na kompilaciu 32-bitoveho balika na 64-bitovom systeme by si preto potreboval cross-compiler => ta virtualizacia je jednoduchsia.

Este skus pozriet aj logcheck. Spusta sa cez cron, teda sa da jednoducho nastavit, ako casto chces tie maily posielat. Ale ako uz napisal Petr, pravdepodobne budes musiet trocha poladit pravidla, aby to nehlasilo prilis vela veci - logcheck totiz funguje tak, ze v nastaveniach su regexp takych zaznamov, ktore su "v poriadku", vsetky ostatne polozky su povazovane za "anomaliu" a odreportovane.

Pre logovanie (obzvlast kompilacie) odporucam skor:

Kód [Vybrat] Rozbalit

prikaz_pro_kompilaci 2>&1 | tee /cesta_pro_soubor/log_kompilace.txt

Ale v pripade make-kpkg by som asi ako prve skusil:

Kód [Vybrat] Rozbalit

find /cesta_k_build_adresaru/ -name \*build\*.log -print
(make-kpkg som nespustil uz niekolko rokov, tak si presne nepamatam, ci ten log niekde nie je vytvoreny automaticky)

Dalsia moznost je skompilovat si verziu 2.6. Je sanca, ze sa ti to skompiluje aj s aktualnymi verziami kniznic (tj. Gimp bude jedine, co musis kompilovat).

Najjednoduchsie bude skusit stiahnut zdrojovy balik zo Squeeze a zbuildovat ho na Wheezym. Nemusi to vzdy ist hladko, niekedy su vyssie verzie kniznic problematicke a niekedy to je nemozne (ak je tam nekompatibilita). A treba vediet zaklady, ako v Debiane funguje kompilacia zo zdrojovych balikov (debuild) a ako stiahnut a rozbalit zdrojovy balik manualne (kedze repozitar nebudes mat v sources.list). Osobne tieto veci robim vo virtuale (na buildovanie je treba vela balikov a dev kniznic, ktore inak nepotrebujem, tak si s nimi nemusim zahadzat hlavny system).

Ak to z debianovskeho zdrojoveho balika nezaberie, tak treba pouzit zdrojovy archiv gimpu (v takom pripade ale treba citat README/INSTALL atd.) a skompilovat to samostatne, ale je mozne ze najprv budes musiet skompilovat a nainstalovat aj tie nizsie verzie niektorych kniznic (tu by som odporucal neinstalovat to pod rootom, ale pri kompilacii zmenit cestu do nejakeho oddeleneho adresara, napriklad do /opt ale kludne aj pod domacim adresarom uzivatela a nainstalovat to pod tym uzivatelom (nerozbijes si system - ak to cele nevyjde, tak len ako ten uzivatel zmazes patricny adresar a tym sa toho kompletne zbavis).

V kazdom pripade sa ti pri kompilacii Gimp-u moze stat, ze s tym budes mat tolko roboty (ak si nikdy nekompiloval, tak pripocitaj aj ucenie sa) a pripadne sa niekde zaseknes, ze si nakoniec povies, ze ti to za to nestoji a az tak velmi netrvas na verzii 2.6...

když se hlasím buď do systému jako domain user a nebo přes ssh musím zadávat dvakrtát to samé heslo?

This is not a bug, it's a feature :P. Prihlasenie do systemu je jedna vec, ziskanie ticketu z Kerbera druha. Nastastie existuje riesenie ako to zjednodusit a nepisat dvakrat to iste heslo 8).
Teraz nie som pri stroji a uplne detaily si z hlavy uz nepamatam, ale pozri si man pam_krb5 a man pam_unix, hlavne parametre try_first_pass a use_first_pass. Potom pozri v /etc/pam.d/, ako to mas na stroji nastavene (ake je poradie tychto PAM modulov), snad by to malo byt v subore common_auth. Druhemu autentikacnemu modulu v poradi by si mal dat jeden z tych parametrov (tj. aby pouzil to iste heslo, co uz bolo zadane). Pri rovnakom hesle by potom nemal prist druhy prompt, ale sa pouzije heslo, ktore si zadal do prveho promptu...

Ak chces mat hesla synchronizovane (teda pri zmene jedneho hesla sa zmeni aj druhe), skontroluj nielen auth, ale aj password (pravdepodobne sa nachadza v subore common_password) - ale zafunguje to len vtedy, ak budes heslo menit na danom linuxovom stroji (ak zmenis heslo na Windozackom DC, tak linuxovy stroj to samozrejme nebude vediet a v /etc/shadow bude nadalej to stare heslo).

Dalsia moznost by bola, nemat pre daneho domenoveho uzivatela heslo na linuxovom stroji vobec (vykricnik v /etc/shadow) - ale v tom pripade ak je DC nedostupny, tak ten uzivatel sa neprihlasi vobec :-\, pripadne len cez ssh s klucom, ak to ma dany uzivatel nastavene. Teoreticky by to sice malo byt mozne s pomocou modulu pam_ccreds z balika libpam-ccreds, ale v mojich podmienkach mi to nikdy nepomohlo (pretoze ja mam uzivatelov v LDAP a hesla v Kerberovi, vsetko na tom istom serveri, takze ked je ten server nedostupny, tak mi vypadne nielen autentikacia, ale aj samotna databaza uzivatelov a libnss-ldapd ju zjavne necachuje). Mozno v tvojom pripade to fungovat bude (ale asi to umozni len na prihlasenie do linuxu, ked bude DC nedostupny tak pri prihlaseni neziskas TGT a ked neskor DC nabehne, stale nebudes prihlaseny do domeny).

Cez PAM sa da nastavit rozlicny vysledny efekt, podla toho ako potrebujes... Napriklad sa da nastavit, ci Kerberovske heslo vyzaduje pre vsetkych uzivatelov (ak nie je uzivatel v domene, tak ho neprihlasi), alebo je to len "pridavok" (skusi vyziadat TGT, ale ak to zlyha, tak sa stale moze autentikovat inym sposobom).
Z toho vsetkeho vyplyva ista dan za flexibilitu: vyzaduje to iste porozumenie fungovania, aby si mohol dosiahnut nastavenie ake zamyslas...
Maly tip na zaver: Okrem standardneho 'man 8 pam_krb5' si pozri aj 'man 5 pam_krb5'

Skus do DNS (na domain controleri) pridat ten linuxovy stroj rucne...

Co sa tyka toho caps-lock: Ja meno domeny pri kinit ani nepisem, len meno uzivatela (kedze ho vzdy ziadam z default realm), alebo ani meno nie (pouzije sa meno prihlaseneho uzivatela). Takze ani neviem, ze je to case-sensitive... Navyse samotny kinit explicitne pisem len velmi zriedka, pretoze mam cez Kerbera aj prihlasovanie (a teda TGT sa vyziada automaticky pomocou PAM uz pri prihlaseni).

Vidim to podobne ako Roman:

• Neviem sice presne, kedy cron spusta @reboot (nikdy som to nepotreboval pouzit), ale pravdepodobne je to v momente ked sa sam startuje - a vtedy s vysokou pravdepodobnostou este nebezi X-server (mozno ani siet a mozno dokonca nie su este pripojene vsetky disky), takze darmo nastavujes premennu DISPLAY, nema sa na co pripojit.
• Takisto este nemusi byt spustene pulseaudio (navyse PA je standardne nastavene tak, ze demon sa nespusta pri starte systemu, ale az po prihlaseni uzivatela), takze ti to moze zhucat aj kvoli tomu, ze nema zvukovy vystup ktory by mal ovladat.
• Ak je ten volumeicon nieco, co moze/ma bezat v ramci desktop managera (tj. login screenu, neviem ktory pouzivas: gdm, kdm, atd...) este pred prihlasenim, tak bude najlepsie pridat start niekam do konfigurakov toho desktop managera. Tam, kde sa davaju take veci, ako zapnutie capslock-u, vypnutie touchpadu pri pripojenej USB mysi a pod. Napriklad pre kdm by to mohlo byt /etc/kde4/kdm/Xsetup...
• Naopak, ak ma volumeicon vyznam len pre daneho uzivatela (napriklad bezi len v systrayi), tak ho treba spustit az po prihlaseni - teda v Mate najlepsie naklikat. Pripadne dat do spolocneho Xsession (vtedy sa to bude spustat pre kazdeho uzivatela)

Celkovo, "spustit po starte" je dost siroky pojem, kedze pri starte sa deje vela veci a neda sa spustit hocico hocikedy (a okolo zavislostneho spustania sluzieb je cela veda). Ale ak je to X-kova zalezitost (co predpokladam, kedze si pouzil premennu DISPLAY), tak sa na to cron vobec nehodi.

Skus dat do /etc/hosts polozku pre dane KDC ale tak, aby cele domenove meno bolo ako prve, tj. by si tam mal mat nieco ako:

Kód [Vybrat] Rozbalit

192.168.1.55 mn-nadsc003.filip.local mn-nadsc003
192.168.1.56 mn-sdc02.filip.local mn-sdc02

Mne to pomohlo pri obycajnom Kerberovi (server tiez Debian), bez tej polozky mi tiez Kerberos nefungoval (napriek tomu, ze mena KDC serverov boli v DNS a aj sa to spravne resolvovalo pomocou dig, nslookup a host).

Ja nepouzivam apticron, ale unattended-upgrades. Na desktope mam nastaveny len archiv security (ostatne upgradujem manualne), na serveroch mam nastavene vsetky archivy (a aj automaticky reboot v pripade potreby). Posiela mi to mail standardne len so zoznamom balickov, changelog bezne neposiela, ale uz sa mi stalo, ze prisiel mailom aj changelog (myslim, ze to bolo php, nieco sa menilo v umask nejakeho konfiguracneho suboru a maintainer balicka asi nejako vynutil zobrazenie changelog-u). Konfigurak je v /etc/apt/apt.conf.d/ (ma rovnaku syntax nastaveni ako v standardnom apt.conf, akurat pridava svoj namespace). Kedysi som na to pouzival cron-apt, ale unattended-upgrades sa mi zda "integrovanejsi" do apt, vsetko sa konfiguruje na jednom mieste rovnakym sposobom...
Spustenie apt-listchanges podla vsetkeho tiez zabezpecuje konfigurak v /etc/apt/apt.conf.d/, pravdepodobne to ale zobrazi/posle changelog az pri spusteni dpkg (teda len ak dojde k instalacii/aktualizacii balicka, ale mozno aj pri --dry-run).

Ak by som chcel len pridat posielanie changelogu (a ponechat automaticky upgrade bez mojho zasahu), tak by som si asi len pridal apt-listchanges (malo by to fungovat tak ako doteraz, len ten changelog by bol poslany navyse). Asi najelegantnejsie riesenie, vsetko spustane cez apt.conf.d/.
Ak by som chcel len poslat changelog (a nerobit upgrade automaticky, ale az manualne po precitani changelogu), tak by som skusil spustit apt-get --dry-run, snad by apt-listchanges aj v takom pripade poslali mail s changelogom (mozno to bude treba v kaskade, najprv apt-get -d dist-upgrade na stiahnutie balikov a az potom apt-get --dry-run dist-upgrade na poslanie changelogov), ale nic by sa v systeme neaktualizovalo (a keby to zafungovalo, tak by som odinstaloval balik unattended-upgrades a automaticky spustal apt-get --dry-run cez cron/cron-apt len za ucelom posielania changelogov, kedze by som vzdy dal upgrade balikov az manualne po precitani changelogu). Ak by --dry-run nezafungoval, tak by som si trocha zaskriptoval a spustil apt-listchanges postupne pre vsetky baliky, ktore by sa mali aktualizovat...
A asi by to islo skombinovat aj s unattended-upgrades: security by sa instalovalo automaticky cez unattended-upgrades, bez ohladu na changelog (predpokladam, ze cislo verzie by sa aj tak nemenilo, bol by to "len" bezpecnostny update, kde je urychlena aktualizacia predsa len dolezitejsia) a pri ostatnych aktualizaciach balikov by to zase len poslalo changelog. Kedze ja mam vsade len stable a oldstable, tak to pre mna az take zaujimave nie je, ale pri testingu ci unstable by to mohlo byt celkom uzitocne.

IMHO by s apt-get changelog bolo prilis vela roboty, standardne to zobrazuje changelog k momentalne nainstalovanej verzii, takze by ho bolo treba nakrmit este aj cislom verzie, na ktoru sa ide aktualizovat... na to asi ziaden balik kde by sa to dalo len nejako nakonfigurovat nie je a muselo by sa skriptovat (niezeby som sa toho bal, len vzdy sa moze stat, ze clovek v skripte urobi nejaku chybicku a potom by mu to namiesto changelogu posielalo stderr, ze?). Jednoduchsie je preto nechat stiahnut cely balik s tym, ze niektore z nich mozno po precitani changelogu nebudem chciet nainstalovat (predpokladam, ze ak mam nastavene automaticke aktualizacie, tak ma objem dat snad nebude trapit).

Vo Wheezym je Xfce 4.8, v titulku je 4.10, tak asi chce novsiu verziu (Jessie a Sid maju 4.10).

Osobne by som to v pripade desktopoveho prostredia nerobil: plno zavislosti (velka sanca, ze bude treba novsie verzie kniznic), straca zmysel drzat sa stable vetvy...
A uz vobec by som to neodporucal niekomu, kto hlada "jednoduchsi postup nez cez konzolu".

Podla tych vypisov sa moje podozrenie nepotvrdilo. Mas nainstalovane aj hlavicky jadra a DKMS modul pre jadro 3.14 sa uspesne skompiloval a aj nainstaloval do /lib/modules/...

Zda sa mi ale divne, ze pre jadro 3.11 (kde ti to funguje) dkms status hlasi, ze nainstalovany modul (mal by byt v /lib/modules/3.11-4.slh.2-aptosid-686/updates/dkms/nvidia.ko alebo tak nejak) je iny ako skompilovany (ten by mal byt v /var/lib/dkms/ ale takto z hlavy nedam presnu cestu - pre kazdy DKMS modul a jeho verziu a v nom pre kazdu verziu jadra je tam samostatny podadresar).
A pre jadro 3.14 tam taka hlaska nie je. To by mohlo indikovat, ze ten DKMS zdrojak ovladaca je nejaky chybny a nechodi to s nim, ale "nieco" pri verzii jadra 3.11 ten modul nainstalovany do /lib/modules/ prepisalo inou binarkou, s ktorou to chodi...

Ako sa to tam ale dostalo, to naozaj netusim. Nerobil si tam pred casom nejake divociny, napriklad spustenie binarky stiahnutej zo stranky Nvidie? Pretoze tie vedia kvalitne rozhasit system cez vselijake diversions (prepisu rozne kniznice z distribucnych balikov svojimi verziami, mozno aj tie z balika xserver-xorg-video-nvidia) a byva dost problem to vratit naspat (pretoze treba najprv zistit, co vsetko sa v systeme prepisalo/presmerovalo)...

Tazko presne radit takto na dialku, navyse ked ten Aptosid priamo nepoznam. Napriklad som pozrel na ich stranku, ale zistil som, ze tie baliky k nvidii vobec nie su v ich repozitari (http://debian.tu-bs.de/project/aptosid/debian/pool/main/), takze sa musia tahat z ineho miesta - odkial? Nepouziva sa napriklad standardny repozitar sid na vacsinu veci (s tym, ze aptosid repozitar ma vacsiu prioritu, takze co je v nom sa taha odtial)? Lebo v tom pripade mas jadro z aptosid repozitara, ale nvidiacky modul z debian repozitara a moze sa stat, ze to spolu nefunguje (aj ked by tam stale nemal byt rozdiel medzi skompilovanym a nainstalovanym DKMS modulom). A takisto je mi divne, odkial sa ti tam zobrali tie baliky nvidia-kernel-3.11-4.shl.2-aptosid-686 a nvidia-kernel-3.14-4.shl.3-aptosid-686 (kedze v tom aptosid repozitari nie su a v klasickom sid samozrejme tiez nie).

Tak len par vystrelov do tmy:

Kód [Vybrat] Rozbalit

ls -al /usr/src
find /lib/modules/ /var/lib/dkms/ -name nvidia.ko -exec ls -l '{}' ';'
find /lib/modules/ /var/lib/dkms/ -name nvidia.ko -exec md5sum '{}' ';'
ls -alR /usr/lib/nvidia/
m-a -t list
dpkg -l \*nouveau\* \*nvidia\*
No a potom este skus (pri oboch verziach jadra):

Kód [Vybrat] Rozbalit

lsmod | grep -E '(nvidia|nouveau)'
Neviem, ci z toho budeme mudrejsi, ale mozno sa vo vypisoch nieco objavi.

Len tak mimochodom, ked sem davas vypisy, pouzi tlacidlo mriezky (generuje phpbb tag code) a nie tlacidlo B (phpbb tag b, tucne pismo).

Podla mna by si mal odinstalovat baliky nvidia-kernel-<verzia_jadra>-* (teda nvidia-kernel-3.11-4.shl.2-aptosid-686 a nvidia-kernel-3.14-1.shl.2-aptosid-686 z tvojho starsieho vypisu, pripadne ich nejake novsie verzie, ak doslo medzicasom k update).
Staci ponechat si balik nvidia-kernel-dkms, ktory obsahuje zdrojaky jadroveho modulu a pri zmene jadra (pri update verzie jadra ci priinstalovani novej verzie jadra) sa pre danu verziu jadra vzdy skompiluje nvidiacky modul - deje sa to automaticky, sam to spustat nemusis a ak je DKMS modul spravne pripraveny (co by v pripade, ze ide o balicek z distribucie, rozhodne mal byt), tak vsetko funguje v pozadi.
Pripadne si mozes pozriet stav jednotlivych DKMS modulov pre jednotlive verzie jadra prikazom:

Kód [Vybrat] Rozbalit

dkms status

DKMS moduly by aj tak mali mat prioritu (ten mechanizmus sa da pouzit napriklad aj na to, aby si si dal novsiu verziu ovladaca, ktora je uz v jadre - bez toho, aby si prekompilovaval cele jadro), ale kedze nemas Debian, ale nejaky jeho derivat, prave balickovanie moze pokrivkavat a mozno ti to nejako koliduje s tym novsim jadrom...

Este jedna dolezita vec: Tym, ze sa DKMS modul vzdy skompiluje s danou verziou jadra, tak potrebuje aj hlavicky jadra. Takze sa ti mohlo stat, ze mas nainstalovane linux-headers-3.11-4.slh.2-aptosid-686 a modul pre jadro 3.11 sa spravne skompiloval, nainstaloval a pouziva, ale nemas nainstalovane linux-headers-3.14.-1.shl.2-aptosid-686 (len binarku jadra linux-image-3.14.-1.shl.2-aptosid-686), vtedy kompilacia modulu jadra pre 3.14 zlyhala. K tejto situacii mohlo dojst, ak si mal nainstalovany len priamo konkretny balik hlaviciek (linux-headers-3.11-4.slh.2-aptosid-686), ale nie metabalik hlaviciek (linux-headers-aptosid-686), ale zato mas metabalik jadra samotneho (linux-image-aptosid-686) - v tom pripade sa ti priinstalovalo nove jadro 3.14 pri nejakom upgrade, ale uz sa ti nepriinstalovali hlavicky pre 3.14 a kompilacia DKMS modulu zlyhala.
Takze este pre istotu aj skontroluj, ako je to s balikmi jadra a hlaviciek:

Kód [Vybrat] Rozbalit

dpkg -l linux-image\* linux-headers\*

Poznamka: Tie nazvy balikov som si z velkej casti domyslal, takze to neber ako istu vec. Medzicasom mozu byt aj novsie verzie a podobne.


Alternativne riesenie je samozrejme odinstalovat naopak nvidia-kernel-dkms a nechat si len tie predkompilovane moduly (a spolahnut sa, ze su skompilovane fakt dobre), ale DKMS je podla mna elegantnejsie riesenie (ono totiz funguje s kazdym jadrom, aj ak si napriklad skompilujes vlastne) a vyhadzoval by som ho len v pripade, ze by prave v konkretnom DKMS zdrojaku bol nejaky problem (a aj tak by to padalo na hlavu distribucie, ze vypustila von nove jadro bez patricnej upravy vsetkych DKMS modulov).

Len pre istotu, ked budes odinstalovavat tie baliky, pouzi purge (nie remove), aby sa zmazali aj konfiguracne subory odinstalovanych balikov (obzvlast pri ovladacoch je to uzitocne a niekedy aj nevyhnutne).

Ale applet se zprovoznil jen z půlky. Už tam sice není napsáno nespravováno a dostanu se do síťového nastavení, ale nejde nic nastavit všechny nabídky v drátovém nastavení jsou zašedlé.

No tak to je pravdepodobne kvoli tomu, ze nastavenie je v /etc/network/interfaces a do toho suboru NetworkManager nerype (aj ked NetworkManager ten interface uz moze vypnut/zapnut, kedze na to do daneho suboru rypat netreba).

Takze ak chces cele nastavenie mastit len v NM, tak aplikuj moznost 1 (teda zakomentuj alebo uplne vyhod rozhranie z /etc/network/interfaces, podobne ako to ma Valsin).

Pravdepodobne mas sietove rozhranie definovane v /etc/network/interfaces a tych sa NetworkManager standardne nechyta.
Mas dve moznosti:
1. Uplne vyhodit nastavenie rozhrania z /etc/network/interfaces
2. Ukecat NetworkManager, aby ovladal aj tie rozhrania definovane v /etc/network/interfaces: https://wiki.debian.org/NetworkManager#Enabling_Interface_Management

Baliky su network-manager-gnome alebo network-manager-kde (podla toho, ake mas desktopove prostredie).

Ja musim za seba povedat, ze najvacsie problemy som mal prave s testingom. To bolo prave v case, kedy sa do Debianu natlacilo PulseAudio (uz si nepamatam co bolo vtedy testing, ci Etch alebo Lenny). Chvilu testing bezal celkom fajn, az do toho osudneho updatu, kedy sa to celkom rozhasilo a to tak, ze som to nevedel vratit naspat (pretoze starsie verzie balikov z repozitarov zmizli). Po par dnoch, ked sa neobjavili novsie verzie, ktore by to opravili, tak som to poriesil tak, ze som cely system upgradol na unstable (downgrade z testingu na stable nie je podporovany, takze hrozila aj tak cista instalacia, tak som si povedal, ze ked bordel, tak uz riadny). V unstable to ale napodiv uz bolo opravene a vsetko fungovalo. Ale chodili v kuse vselijake updaty na vsetko mozne (omnoho viac nez v testingu) a aj ked sa uz nic nepokaslalo, citil som sa velmi neisto, akoby stale nado mnou visel Damoklov mec, ze nejaky update nieco zase rozhasi v tom najmenej vhodnom momente... takze som vtedy na desktop nainstaloval Ubuntu (tusim to vtedy bolo 9.04 - v tych casoch to na desktop nebola zla volba v porovnani s Debian stable) a zapovedal som sa, ze testing nikdy viac - rozhodne nie na hlavny stroj, ktory bezne pouzivam (fakt nepotrebujem, aby mi pri nejakom update prestali fungovat X-ka a ja by som musel spekulovat, ako si precitat maily a pozriet nejake info na webe). Mozno som prave vtedy "vychytil" nevhodny cas s PulseAudio a inak s testingom nebyvaju problemy... aj ked onedlho by mohlo nastat nieco podobne (ak nie horsie) so systemd.

Na serveroch som samozrejme mal vzdy Debian stable, tam nie je o com (nemam tolko casu, aby som pri zmene verzie balika musel aktualizovat konfiguraciu sluzby).

A teraz s Wheezym na desktope ani nepocitujem potrebu novsich verzii cohokolvek, navyse novsie verzie by sa pravdepodobne dali pohodlne pokryt pomocou backports, takze mne stable plne vyhovuje. Testing a unstable su skor pre ludi, ktori bud prispievaju k vyvoju (napriklad aj len reportovanim chyb), alebo aspon chcu ten vyvoj priebezne sledovat.

Tie mena stable/testing/unstable su fakt zavadzajuce, este sa mi ani s unstable nestalo, ze by bol system samotny nejako nestabilny (ze by sa to nejako nahodne restartovalo alebo ze by nejaky program padal uprostred cinnosti).