RE: kompilovat ci nekompilovat
s ohladom na debatu predchadzajucom threade o vlastnom vs GENERIC kerneli sa chcem spytat kto z vas pouziva/nepouziva generic kernel a preco? Rovnaka otazka je aj porty vs package. Pouzivam GENERIC na vetsine stroju z nasledujicich duvodu: - unix neni nenazrany ohledne pameti - hardware to bez problemu zvlada - v pripade poruchy hardware se snadneji prechazi na jine zelezo Porty kompiluji, minimalne kvuli nastaveni v make.conf -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: kompilovat ci nekompilovat
> (hlavni duvod je "nekompilovat zbytecne veci ktere nevyzaduji"). ^-- AFAIK, kompilovat sa tak ci tak bude vsetko, akurat sa to nenalinkuje do kernelu, ale urobi sa modul; teda ak z daneho niecoho modul vyrobit ide. Ovladace su prave tento pripad. J. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: kompilovat ci nekompilovat
Jan Poctavek wrote: > Zdravim, > > s ohladom na debatu predchadzajucom threade o vlastnom vs GENERIC > kerneli sa chcem spytat kto z vas pouziva/nepouziva generic kernel a > preco? Rovnaka otazka je aj porty vs package. Na strojich s vyssi zatezi a specifickymi naroky pouzivam vlastni kernel, na tech "obycejnych" strojich mam klidne GENERIC / SMP-GENERIC, protoze vytvarenim vlastniho bych nic moc neziskal. A pokud se nepletu, tak ten GENERIC se da pak aktualizovat pres freebsd-update > Ide mi hlavne o to aby sa veci upgradovali co najviac samy bez mojho > pricinenia a to si pri kompilovanych veciach nedovolim... a potom este > na kompilovane veci treba hoodne viac casu. Na vsech strojich kompiluji vlastni porty pres portinstall/portupgrade a options mam nastavene v pkgtools.conf. Ze kompilace trva nejaky cas mi vubec nevadi, ja u toho nemusim tocit klikou, zkratak to spustim a delam na necem jinem, za par minut se kouknu, jak co probehlo a je to. O interaktivite to u me v podstate vubec neni, diky nastaveni pkgtools.conf ale umoznuje mi to na kazdem stroji pouzit v podstate uplne jine options. Miroslav Lachman -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: kompilovat ci nekompilovat
Jozef Babjak wrote: >>(hlavni duvod je "nekompilovat zbytecne veci ktere nevyzaduji"). > > > ^-- AFAIK, kompilovat sa tak ci tak bude vsetko, akurat sa to > nenalinkuje do kernelu, ale urobi sa modul; teda ak z daneho > niecoho modul vyrobit ide. Ovladace su prave tento pripad. Ano, u ovladacu a nekterych dalsich veci plati to, ze co se vyhodi z kernelu, zkompiluje se jako modul. (da se tomu zabranit v make.conf atp.) Jeste bych dodal, ze je celkem zajimavou volbou nastaveni KERNCONF v /etc/make.conf tak, ze obsahuje vice jmen kernelu. Ono se jich pak vic zkompiluje, ale nainstaluje se jen prvni (kdyz se pak pouzije make installkernel bez definovani KERNCONF). Takze tam, kde mam vlastni kernel mam napriklad KERNCONF=MUJKERNEL SMP GENERIC a mam tak k dispozici k nainstalovani vsechny tri pro pripad, ze by to bylo nekdy potreba kvuli problemum / testovani a uz v ten okamzik nebyl cas / moznost kompilovat. Samozrejme to znamena, ze se make buildkernel dela trikrat tak dlouho, ale v tom nevidim problem, to je prace pocitace, ne moje. ;) Miroslav Lachman -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: kompilovat ci nekompilovat
> > Experimentalne jsem zjistil ze custom kernel je jen o 4MB mensi, coz > ^-- Velkost kernelu na disku fakt nie je issue. Mam vsak pocitace, kde > velkost programov v pamati issue stale je. ty 4 mb jsem myslel v pameti. ale ja ho davam i na pocitace s 32mb ram (routery nebo pocitace pro zalohovani dat), a mene nez 32 nikde uz dnes nemam. 16mb ram je fakt nepouzitelny a to jak pod linuxem tak pod bsd, pokud se nepouzije nejake specialni distro. > ^-- Mozes upresnit, ake to boli benchmarky? Testovat "optimalnost" > kernelu mi pride dost tazke; ak existuju nejake plusminus spolahlive > benchmarky s plusminus vypovednou hodnotou, mam o ne zaujem. no ja jsem pouzil realnou aplikaci. naimportovat + fulltext index http://filez.com (cca 600m ftp souboru, 4m rapidshare souboru, 55m web souboru, 5m mp3) a pouziti custom kernelu nemelo zadny meritelny efekt. Naopak accf_http.ko zvedlo vykon ve spickach az o 20%. Optimalizovat vykon se da taky hardwarem. doporucuji multicore amd64 + adaptec scsi raid + co nejvic (optimalni pocet je cca 5-6) disku (nemusi byt ani rychly), rozumna pamet + rozumna sitovka. Rekl bych nejlepsi pomer vykon/cena pro levny severy. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: kompilovat ci nekompilovat
Dan Lukes wrote / napÃsal(a): > > No, kupodivu, od urciteho poctu stroju je update skoro jednodussi (v > prepoctu na jeden stroj) nez u mala stroju. Jeden stroj slouzi jako > "centralni repository" - tam se prelozi world, vsechny ruzne kernely, > ktere se pouzivaji a vsechny porty, ktere se kde pouzivaji - a z tech se > vyrobi packages. Pak se /usr/src, /usr/obj a /usr/ports vyexportuje pres > NFS a na kazdem updatovanem stroji se namountuje a pak uz "jen" > make KERNCONF= installworld installkernel > mergemaster > portupgrade -RiaPP Celkom fajn postup.. ale pokial mam medzi servermi aspon jeden i386 tak na ia64/amd64 mozem asi zabudnut, nie? Package sa daju na rozdiel od kernelu vybuildovat len s jednou optimalizaciou. BTW: oplati sa vobec 64bit kernel? Jan Poctavek -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: kompilovat ci nekompilovat
Radim Kolar napsal/wrote, On 03/05/07 11:08: >> > Experimentalne jsem zjistil ze custom kernel je jen o 4MB mensi, coz >> ^-- Velkost kernelu na disku fakt nie je issue. Mam vsak pocitace, kde >> velkost programov v pamati issue stale je. > ty 4 mb jsem myslel v pameti. ale ja ho davam i na pocitace s 32mb ram > (routery nebo pocitace pro zalohovani dat), a mene nez 32 nikde uz > dnes nemam. Nejsem si uplne jisty, ale neni to tak, ze bez ohledu na "velikost binaru" je neswapovatelne kernel-space vyhrazeno stale stejne ? > 16mb ram je fakt nepouzitelny a to jak pod linuxem tak pod > bsd, pokud se nepouzije nejake specialni distro. Je pravda, ze na 16MB uz se snad neda spustit ani instalace, ale kdyz se tam "na dobu unstalace" pamet pujci, tak bezet to na nich pak uz dokaze. Jeste jeden takovy na jedne pude mame ;-) Tedy - plain-router (maximalne tak s prekladem) - zadny WWW server s PHP, samozrejme. Ale je pravda, ze na tom nejde spustit uz ani portupgrade -PP. nejdriv to pul dne chrousta a pak to spadne na "out of swap space" (je pravda, ze je tam swap jen 100MB, kdyz si ho docasne zvetsim na dvojnasobek, tak upgrade behem dvou dnu dobehne). Dan -- Dan Lukes SISAL MFF UK AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: kompilovat ci nekompilovat
Jan Poctavek napsal/wrote, On 03/05/07 11:25: >> No, kupodivu, od urciteho poctu stroju je update skoro jednodussi (v >> prepoctu na jeden stroj) nez u mala stroju. Jeden stroj slouzi jako >> "centralni repository" - tam se prelozi world, vsechny ruzne kernely, > Celkom fajn postup.. ale pokial mam medzi servermi aspon jeden i386 tak > na ia64/amd64 mozem asi zabudnut, nie? Package sa daju na rozdiel od > kernelu vybuildovat len s jednou optimalizaciou. > > BTW: oplati sa vobec 64bit kernel? Ja mezi amd64 a i386 nerozlisuji. Ta debata uz tu byla - viz archiv. Zatim jsem nepotreboval pocitac nasazovat an takovem miste, kde by pouzivani amd64 jako amd64 prinaselo vyhody "ktere za to stoji". Takze, hardware takovy mame, ale software na tom bezi i386. Your mileage may vary. Co se ia64 tyce - to je skutecne jina architektura a pro tu by musel byt vybudovan druhy master - za predpokladu, ze jich clovek ma v siti tolik, aby se "centralni update" jiz vyplatil. Dan -- Dan Lukes SISAL MFF UK AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: kompilovat ci nekompilovat
> Co se ia64 tyce - to je skutecne jina architektura a pro tu by musel > byt vybudovan druhy master - za predpokladu, ze jich clovek ma v siti > tolik, aby se "centralni update" jiz vyplatil. fbsd umi cross compiling takze nemusis mit druhy master ve smyslu "neco zcela jineho" staci jen trosicku pozmenit ten prikaz na buildovani worldu/kernelu aby includoval tusim TARGET_ARCH nebo tak neco -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: kompilovat ci nekompilovat
On Mon, Mar 05, 2007 at 01:35:20AM +0100, Jan Poctavek wrote: > Zdravim, > > s ohladom na debatu predchadzajucom threade o vlastnom vs GENERIC > kerneli sa chcem spytat kto z vas pouziva/nepouziva generic kernel a > preco? Rovnaka otazka je aj porty vs package. > Ide mi hlavne o to aby sa veci upgradovali co najviac samy bez mojho > pricinenia a to si pri kompilovanych veciach nedovolim... a potom este > na kompilovane veci treba hoodne viac casu. pouzivam svuj vlastni kernel protoze mam rad ten vlhky slastny pocit ze to mam o 0.1% rychlejsi nez ostatni ;) -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Upgrade pri behu
Zdravim, kdyz jsem cetl debatu o kompilaci kernelu, tak me napadla jedna otazka ohledne upgradu balicku pri jejich vlastnim behu. Dejme tomu, ze budu upgradovat nejaky port spolecne s jeho zavislostmi, ktere ale v dobe upgradu (napr. pomoci portupgrade) budou bezet (napr. gtk). Je to bezpecne? Karel -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
crontab - mailto
Zdravim Vas, obraciam sa na Vas mozno s blbostkou, ale neda mi, aby som sa neopytal skusenych harcovnikov. V root-ovskom crontabe mam zadefinovane spustanie prikazov. Prvy prikaz (P1) sa spusta raz za tyzden, druhy prikaz (P2) sa spusta kazdych 15 minut. Okrem ineho, je v crontabe zadefinovana direktiva "MAILTO". Oba prikazy sa musia spustat pod root-om, ale maily o vykonani/nevykonani by som chcel dostavat len od aplikacie prikazu (P1). Kedze mam dve root-ovske konta (pre jednoduchost "root" a "root1"), tak som to urobil tak, ze mam crontaby pre "root" a pre "root1". "root" je s "MAILTO", "root1" bez "MAILTO". Samozrejme, funguje to. Predsa len, neda sa to sklbit do jedneho crontab-u s tym, ze by to bolo len v tom crontabe pre "root" a aby som pre (P1) dostaval mail a pre (P2) nie? Mam na mysli nejaku finesu, o ktorej som sa v dokumentacii nedocital, ...ze ci sa napriklad neda rozvetvit direktiva "MAILTO" pre prikazy typu (P1) a prikazy typu (P2)? -- LuMaX -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: crontab - mailto
> Kedze mam dve root-ovske konta (pre jednoduchost "root" a "root1"), tak > som to urobil tak, ze mam crontaby pre "root" a pre "root1". "root" je s > "MAILTO", "root1" bez "MAILTO". Samozrejme, funguje to. ^-- Toto riesenie je spravne, dokonca podporovane priamo systemom; na tieto ucely sluzit pouzivatel "toor", ktory je standardne v passwd. J. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: crontab - mailto
Zdravim, > Predsa len, neda sa to sklbit do jedneho crontab-u s tym, ze by to bolo > len v tom crontabe pre "root" a aby som pre (P1) dostaval mail a pre > (P2) nie? Mam na mysli nejaku finesu, o ktorej som sa v dokumentacii > nedocital, ...ze ci sa napriklad neda rozvetvit direktiva "MAILTO" pre > prikazy typu (P1) a prikazy typu (P2)? a co takto zadat: 0 0 * * * P1 */15 * * * * P2 > /dev/null 2>&1 Takto sa vsetok vystup P1 bude mailovat a vsetok vystup P2 pojde do... -- Peter Rosa -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Upgrade pri behu
Kaminar wrote: > Zdravim, > > kdyz jsem cetl debatu o kompilaci kernelu, tak me napadla > jedna otazka ohledne upgradu balicku pri jejich vlastnim behu. > > Dejme tomu, ze budu upgradovat nejaky port spolecne > s jeho zavislostmi, ktere ale v dobe upgradu (napr. > pomoci portupgrade) budou bezet (napr. gtk). Je to bezpecne? Nevim jak u GTK, ale bezne upgraduji MySQL za "plneho provozu" (delam to v noci, ale daemon bezi a vyrizuje par desitek requestu za sekundu), jelikoz bezi pres daemontools a na pres rc.d skripty, tak pri upgradu nedojde k jeho zastaveni. To znamena, ze portupgrade zkompiluje noveho daemona, smaze (odinstaluje) stareho (vcetne vsech knihoven atd.) a nainstaluje noveho. Po celou tuhle dobu MySQL zustava v provozu i kdyz nema na disku puvodni soubory (respektive ja vim, ze interne tam jsou, dokud je proces neuzavre ;]). Pak jen provedu restart daemona a to uz nabehne nova verze, puvodni soubory na disku se uzavrou a dojde tim k uvolneni mista, ktere do ted zabiraly. Mozna v tom je skryte nejake nebezpeci... ale kde neni? Podobne probiha u me i upgrade Apache, nebo PHP. Nedavno mi dokonce na serveru bezel Apache s PHP asi hodinu a pul bez toho, aby napriklad pkg_info vypsalo jakoukoliv zminku o PHP, protoze jsem ho odinstaloval a pak mel problemy s instalaci noveho baliku. (jednalo se o downgrade) Miroslav Lachman -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: crontab - mailto
Lubomir Majersky wrote: [...] > Predsa len, neda sa to sklbit do jedneho crontab-u s tym, ze by to bolo > len v tom crontabe pre "root" a aby som pre (P1) dostaval mail a pre > (P2) nie? Mam na mysli nejaku finesu, o ktorej som sa v dokumentacii > nedocital, ...ze ci sa napriklad neda rozvetvit direktiva "MAILTO" pre > prikazy typu (P1) a prikazy typu (P2)? Pokud nechci dostavat maily o spusteni / chybe nejakeho prikazu, tak jeho stdout a stderr presmeruji do /dev/null takze neco jako: # tady endostanu zadnou zpravu * * * * * /path/to/my/script.sh > /dev/null 2> /dev/null # tady dostanu zpravu jen pri chybe * * * * * /path/to/my/script.sh > /dev/null Nebo si ty vystupy mohu presmerovat do souboru spomoci >> a pak budu mit log, ze ktereho se pripadne zpetne dozvim, ze neco probehlo / neprobehlo. Miroslav Lachman -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: crontab - mailto
Miroslav Lachman wrote: > Lubomir Majersky wrote: > [...] >> Predsa len, neda sa to sklbit do jedneho crontab-u s tym, ze by to bolo >> len v tom crontabe pre "root" a aby som pre (P1) dostaval mail a pre >> (P2) nie? Mam na mysli nejaku finesu, o ktorej som sa v dokumentacii >> nedocital, ...ze ci sa napriklad neda rozvetvit direktiva "MAILTO" pre >> prikazy typu (P1) a prikazy typu (P2)? Prirazeni do MAILTO se da v crontabu pouzit vicekrat a plati pro vsechny definice, ktere po nem nasleduji az do dalsiho vyskytu prirazeni do MAILTO. Kdyz nechci nic posilat tak MAILTO="" v. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: crontab - mailto - OK
Peter Rosa napsal(a): > a co takto zadat: > 0 0 * * * P1 > */15 * * * * P2 > /dev/null 2>&1 > > Takto sa vsetok vystup P1 bude mailovat a vsetok vystup P2 pojde do... > ...jezis maria, normalne sa hanbim... Vitezslav Novy napsal(a): > Miroslav Lachman wrote: > > Prirazeni do MAILTO se da v crontabu pouzit vicekrat a > plati pro vsechny definice, ktere po nem nasleduji az do dalsiho > vyskytu > prirazeni do MAILTO. > > Kdyz nechci nic posilat tak > MAILTO="" ...a tu tiez, poslednych 10 dni som ako mechom ovaleny. Neviem, ale cital som ten "man 5 crontab" asi 3 krat a toto som tam predtym nevidel MAILTO may also be used to direct mail to multiple recipients by seperating recipient users with a comma. If MAILTO is defined but empty (MAILTO=""), no mail will be sent. Vdaka a ospravedlnujem sa... ...asi starnem -- LuMaX -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: kompilovat ci nekompilovat
Divacky Roman napsal/wrote, On 03/05/07 13:30: >> Co se ia64 tyce - to je skutecne jina architektura a pro tu by musel >> byt vybudovan druhy master - za predpokladu, ze jich clovek ma v siti >> tolik, aby se "centralni update" jiz vyplatil. > > fbsd umi cross compiling takze nemusis mit druhy master ve smyslu "neco zcela > jineho" > staci jen trosicku pozmenit ten prikaz na buildovani worldu/kernelu aby > includoval > tusim TARGET_ARCH nebo tak neco To je trochu otazka duvery. Mam podezreni, ze cross-compiling nebude prilis siroce pouzivany a tak bych se obaval, ze bude primerene tomu neodladeny. A dokonce i kdyz pominu tuhle neduveru, stejne si to nedovedu moc predstavit. S;ousta prace bude zajistit kompletni oddelenost stromu - ruzne architektury musi sve veci instalovat do ruznych stromu a take je tamodsud brat. Kde si vubec nedovedu predstavit, ze by system nenarazil jsou pripady, kdy se pri prekladu pozdeji pouzivaji programy vznikle behem prekladu drive. Jako jednoduchy priklas si muzeme zvolit program "install" - ten se za normalnich okolnosti prelozi a nasledne nainstaluje, k cemuz se pouzije on sam. U cross-compilingu by se ale musel prelozit dvakrat - pro obe platformy, pricemz pro "nainstalovani" do spravneho ciloveho mista se musi pouzit binar pro host-platformu, al enainstalovat se musi binar pro target-platformu. Obdobny problem vznikne i u nekterych portu. Mam urcite pochybnosti, ze je cely kompilacni system kompletne pripraveny na cross-compiling. Jednotlive komponenty vetsinou mozna ano, ale v celek moc duveru nemam ... Ale nezkousel jsem to. Jestli tu nekdo napise "pouzivam to bezne", prekvapi me to. Prijemne. Dan -- Dan Lukes SISAL MFF UK AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
Re: Upgrade pri behu
Kaminar napsal/wrote, On 03/05/07 15:33: > Dejme tomu, ze budu upgradovat nejaky port spolecne > s jeho zavislostmi, ktere ale v dobe upgradu (napr. > pomoci portupgrade) budou bezet (napr. gtk). Je to bezpecne? Obecne ? Samozrejme, ze ne. Pokud program v prubehu sve cinnost muze nacitat nove knihovny, nebo treba jen konfiguraci, muze dojit k tomu, ze "stary" program zhavaruje proto, ze nove knihovne/konfiguraci nebude rozumet. A lze vytvorit i dalsi scenare. Konkretne ? Delam to bezne a verim, ze vazne problemy nastanou spise vyjimecne, coz ony zatim vetsinou take ochotne delaji. Dan -- Dan Lukes SISAL MFF UK AKA: [EMAIL PROTECTED], [EMAIL PROTECTED],[EMAIL PROTECTED] -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
ipfw & ftp
Dobry den, rad bych "umravnoval" provoz na lince a krome nekterych protokolu (http,ftp,smtp,pop3) bych chtel vse ostatni hnat pres pipe. U vetsiny problem neni, staci jenom definovat typ portu, ktery bude pipe "obchazet". Problem vsak nastava u ftp. Netusim presne jak zachytit, kdyz klient navaze spojeni na portu 21 a pote zacne stahovat data pres nejaky predem neznamy druhy port - jak tento "zjisit" a vytvorit pro nej (nejspise pouze docasne) pravidlo, ktere tento provoz pusti mimo pipe. Dekuji za pripadne nasmerovani, kudy se v reseni takove situace ubirat. Diky, Pepa. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
