Distro kérdés!

Fórumok

Üdv!

Disztrot akarok választani szerverre, mert eddig csak desktop linuxokat használtam.

Otthoni szerver ami igazából csak tanulás céljából röffentem fel.

HW: integrált COMPAQ celeron 300mhz 128mb ram 4GB hdd cd-rom

egy olyan distrot keresek melyet sok helyen használnak mégis elfut egy ilyen low-end gépen

szolgáltatások amiket el kellene birnia
email szerver ftp szerver webszerver(php-mysql)
dhcp, és valami böngészős admin felület, pl webmin.

egy igény még hogy találjak leírásokat az adott rendszer bekonfigurálásához

Debianra gondoltam... csak visszariaszt a 12 cd-s változat.. meg gondolom régebbi verziót kellene abból is használnom.. passz ehez már nem értek mi lenne nekem jó..

szóval egy linket szeretnék ahonnan tudom tölteni az ajánlott rendszert!
cd-s legyen mindenféle képpen!

üdv és köszi!

Hozzászólások

A Debian is jó, nem kell mind a 12 CD, isten ments! :)
Az első CD-vel vagy a floppy installer változattal elkezded a telepítést, utána már megfelelően beállítva csak netes forrásból dolgozik.
Különben a CD-k sorszámának növekedésével csökken a tartalmazott csomagok letöltésszáma, tehát pl. a 12-es CDn már csak kertészeti és nyúltenyésztési szoftvereket találsz, míg az elsőn kapott helyet az apache-mysql-php, graf.felület, főbb fordítók-értelmezők, stb.

sajnos a webmin kikerult minden olyan disztrobol amiben benne volt es a benne levo modulok is egyre inkabb elavulnak tapasztalatom szerint. fel lehet rakni a webmin oldalarol letoltott csomagbol is de az nem ugyanaz mint amikor egy disztro supportalja sztem. a webminen kivul letezik vmi soft amivel tavolrol lehet egyszeru grafikus feluleten adminolni a gepet?
--
Tuddd gi: A Dörrög Zuldán, te hűjje!
(Rejtő Jenő: Az elátkozott part)

A webmint ne sírd vissza ;)
Valaki elkezdett egy HGW projectet (Debian Home Gateway) a SF-en, keresd meg! Bár nem tudom, asszem webes felülete akkor még nem volt amikor néztem.

A webes felület különben mire kéne?
Egy routergépen interakcióra pont hogy nincs szükség (a pppd/dhcpd magától reconnectol, ha gond van), kivétel talán tűzfal, de az iptables kezelésére a Webmin sosem volt alkalmas (igen, iptables modul volt, de holtakról vagy jót vagy semmit :p).

a webmin arra jo, hogy egy adott modult akarsz beizzitani gyorsan a config fileok szintaktikajanak megtanulasa nelkul akkor gyors eredmenyt ersz el vele. egy mukodo configon konnyebb utanna modositani szovegszerkesztovel, mint nullarol megtanulni a beallitasokat sztem
--
Tuddd gi: A Dörrög Zuldán, te hűjje!
(Rejtő Jenő: Az elátkozott part)

A beállítások nagy részét a Debconf is megcsinálja helyetted telepítéskor.
A kivételt összvissz a DHCP démon és a tűzfal konfigurációja képzi, de a DHCP-nek nem nehéz a konfigja és agyon van kommentezve, a Webmin iptables modulja pedig annyiban "könnyítette" meg a konfigurálást, hogy az általad agyatlan legördülő menükkel és kézzel szenvedve megadott paramétersor elejére beírta helyetted hogy "/sbin/iptables".
Tehát Webminnel ugyanott vagy, sőt még hátrébb, mintha megtanulnád használni az adott funkciót.

az iptables-t es a dhcp configjat mar megtanultam azokkal nincs gondom. segitsel legyszives egy windowsXP->linux es egy linux->windows2k3 pptpd kapcsolat beallitasaban. se webminnel se webmin nelkul nem akar osszejonni ubuntu edgy alatt
--
Tuddd gi: A Dörrög Zuldán, te hűjje!
(Rejtő Jenő: Az elátkozott part)

Szerintetek én milyen disztrót javaslok a célra :)

~Végtelen sok gentoo howto-wiki van, már lassan magyarul is.
hupwiki
------
gentóhuszár

Jöjön egy kis propaganda anyag:
* Az OpenSource igazi előnyét akkor élvezeted, ha biztosítják számodra "nyers anyagot" (raw material) (Source Code).
* Gentoo feltepítése közben rengeteg mindent tanulhatsz egy linux rendszer felépítéséröl.
* Rendkívül flexibilis, te választod ki CFLAGS -eket vagyis, hogy milyen processzoron működjön optimálisan.
* A forrásból való bíbelődést segíti egy nagy közösség által fejlesztett/tesztelt rendszer (portage - emerge -ebuild )

Nos mennyire flexibilis?
* pl. mplayer -nek több, mint 50 féle USE -flagje van, a useflegek befojásolják a képességeit, és azt, hogy hány csomagot kell még felrakni, hogy mükködjön.
Ez 2^50 féle végterméket jelent. Ha ehhez hozzá számoljuk, még hogy hány féle gcc opciót lehet használni ... (egy bináris disztró nem tud ilyet)
* init scriptek jolszervezettek

"programnév gentoo howto" (vagy wiki) google -be esetek többségében jó találatot, ad és meg van a válasz a problémádra.

Forráskódból feltenni valamit idő igényes, vannak csomag CD-k is neten, ill. másik erősebb gépe(ke)t rávehetsz, hogy segítsék a fordítást (distcc,icecream)

Ha gentoo még sem tetszik, a knoppix live CD, nagyon gyorsan felmegy egy gépre és szerverré alakítható.

Ha az sem tetszik, http://distrowatch.com/search.php -itt találhatsz cél specifikus disztrót.

szerk:
Naprakész,pl. napokban jan 4. megjelent egy biztonsági javitás az OOo -hoz, gentooba aznap belekerült.

Knoppix ill. Gentoo tekinthető két végletnek a distrók között. (Ez persze nem teljesen igaz)
------
gentóhuszár

Jó, elmélet szépjó, de gyakorlat:
Egy i686-ra optimalizált Apache mennyivel gyorsabb egy PII-n mint egy i486-ra optimalizált (Debian)?
A mysql, a netfilter, vagy pl. a python értelmező mennyivel jobb teljesítményt produkál?

Ha jól értettem A'rpi kommentjét a témában, akkor nem az "optimalizált" gcc-paraméterezés a lényeg, hanem hogy a kód mennyire használja ki a fejlettebb processzorok képességeit. Ez pedig erősen alkalmazásfüggő, és szerintem ez alapján csak ott éri meg, ahol valóban szükséges, és az optimalizálatlanság képzi a szűk keresztmetszetet, mondjuk egy matematikai számításokat végző tudományos célszoftverben.

$ gcc -m32 -march=i486 -O2 gfact.c -o i486.bin
$ gcc -m32 -march=i686 -O2 gfact.c -o i686.bin

$ time ./i486.bin
real 0m23.744s
user 0m23.329s
sys 0m0.095s

$ time ./i686.bin
real 0m4.268s
user 0m4.200s
sys 0m0.001s

5 ször gyorsabb.
És ez a kód nem használ FPU-t :)
Kód innen van: http://hup.hu/node/33811

gcc: gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3)
family/model : 15/12
model name : AMD Athlon(tm) 64 Processor 2800+
cpu MHz : 1800.000
cache size : 512 KB

szerk:
Optimalizálás nélküli i686 kód:
$ gcc -m32 -march=i686 -O0 gfact.c -o i686-O0.bin
$ time ./i686-O0.bin
real 0m16.913s
user 0m16.600s
sys 0m0.088s

------
gentóhuszár

A dokumentációból http://gentoo-portage.com/USE .
megteszi:


CFLAGS="  -O2 -march=<tied arhitektura>  -m<uatitas keszlet>  -pipe"

ez általában biztonságos és elég jó kódot eredményez, lehet kisérletezni mással. ( -funroll-loops)
man gcc, olvass forumokat.


emerge -pv <csomag-nev> 

ir hasznos infot


equery h <flag_name> 

kiirja mely csomagok hasznalhatjak az adot flaget

Van alapértelmezése a flagek használatának, tehát, ha make.conf -ba nem írsz egyet sem akkor is mükszik a rendszer. (Le is tilthatod őket -flag)
Csomagonként is megadhatsz flageket, /etc/portage/package.use -ban (van itt még egy két hasznos file)

mplayer extrém péda, többség jóval kevesebb flaggel rendelkezik.

szerk:
Nem kell megijedni a sok useflagtöl, nem kell mindet ismerni, ha egy program nem tudja azt amit szerinted tunia kéne neki akkor nézd meg a flageket. (pl. ha mplayer nem vinne egy formatumot, vagy video kimenetet)

------
gentóhuszár

Azert en ebbol a tesztbol nem vonnek le messzemeno kovetkezteteseket ;) Az mindenkepp fura, hogy az optimalizalt i486-os kod lassabban fut a gepeden, mint a "nyers ;)" i686-os kod. Ezt sem a C-kod "termeszete", sem a targetek kozotti kulonbseg nem indokolja. Nalam (munkahely) ez a teszt igy nez ki:

Command being timed: "./build/i486-O2.bin"
User time (seconds): 12.18
System time (seconds): 0.00
Percent of CPU this job got: 96%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:12.61

Command being timed: "./build/i686-O2.bin"
User time (seconds): 6.41
System time (seconds): 0.00
Percent of CPU this job got: 97%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:06.60

Command being timed: "./build/i686-O0.bin"
User time (seconds): 17.73
System time (seconds): 0.00
Percent of CPU this job got: 96%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:18.41

gcc: gcc version 3.2.3
cpu: Intel(R) Pentium(R) 4 CPU 2.80GHz

Szoval az altalad emlitett 5-os szorzo enyhen szolva is tulzasnak tunik, bar lehet, hogy a te rendszered eseteben ez igaz, mivel a 486-ra optimalizalt kodot lassabban futtatja, mint esetleg kellene :p

ritkan olvasni ennyi ostobasagot.

pl. mplayer -nek több, mint 50 féle USE -flagje van, a useflegek befojásolják a képességeit, és azt, hogy hány csomagot kell még felrakni, hogy mükködjön.

ennyi? es akkor mar mükködik is? es ez amugy megis mi a francert a gentoo ficsorje? nezd mar meg mplayert (vagy barmilyen mas gentooban is levo szoftvert) egy kicsit kozelebbrol

Ez 2^50 féle végterméket jelent. Ha ehhez hozzá számoljuk, még hogy hány féle gcc opciót lehet használni ... (egy bináris disztró nem tud ilyet)

mondhatom tok zsir... ja es kihagytad azt a reszt ahol az mplayer, glibc, firefox etc forditas sikit, ha a sajat okos kis compilation breakelo gcc opcioidat beirod. abban meg nem igazan bizok hogy a gentusok jobban tudjak mi kell a stuffnak, mint az author. lasd a kovetkezot:

init scriptek jolszervezettek

azok teljesen, csak epp a funkciojuk ellatasara alkalmatlanok, pl egy pidfile-process osszehasonlitas sincs bennuk mert vmi okos kitalalta hogy az tok szar mert az user szeret mukodo daemonok helyett "already running" uzeneteket olvasni, helyette voltak olyan kedvesek mellekelni egy "zap" opciot az osszes scripthez, hogy jol ala tudj nyulni a by-design-unworkable rendszernek.

get gentoo, or get a life instead

> pl. mplayer -nek több, mint 50 féle USE -flagje van, a useflegek befojásolják a képességeit, és azt, hogy hány
> csomagot kell még felrakni, hogy mükködjön.
> Ez 2^50 féle végterméket jelent. Ha ehhez hozzá számoljuk, még hogy hány féle gcc opciót lehet használni ...
> (egy bináris disztró nem tud ilyet)

Vagy egy HDD Hexa editorral akár felmehetsz 2^(100000000000)-re is. És akkor még nem vetted meg a legnyagobb diszket.

Szerény erőforrású gépre ("celeron 300mhz 128mb ram 4GB hdd") otthoni használatra szervert üzemeltetni tanulás céljából ideális a Slackware.

Ha otthonra kell, akkor valószínűleg kevésbé security-kritikus a dolog, így a Slackware is megfelelő lehet, mert az alatt mindent meg lehet oldani (már amit egyáltanlán Linux alatt meglehet oldani), viszont lehet, hogy mással kevesebb melóval meg lehet oldani. Ha nagyon security-mániás vagy, vagy valami szabályosabb disztró kell, akkor meg Debian stable esetleg Ubuntu LTS. A Gentoo-t nem ismerem annyira. És ha itt tartunk, akkor FreeBSD is számításba jöhet: stabilabb, mint a Linux (turul16 majd erre azt mondjam, hogy a Gentoo/FreeBSD is legalább olyan stabil), ports rendszer hasonló a Gentoo portage-hez, de vannak bináris csomagok és arra is depency resolution.

Ezt a "szabályosabb disztró" kifejezést kifejtenéd részletesebben? A Slacky szabálytalan?
Egyébként régi gépre mindenképp ajánlatos a Slackware, főleg ha szerver. Nekem itthon fut egy ilyen egy AMD K6-2 vel 8 gép routereként, mysql+apache+samba, tökéletesen. Havonta egyszer szoktam nyomni neki egy frissítés+rebootot és eddig még nem volt baj vele, pedig már lassan másfél éve műkszik.
Sok sikert!
____________________________________________________________________________________________
powered by Slackware 11 linux-2.6.19.1 - droplineGnome 2.16.2 @ Fujitsu-Siemens Amilo Pi1505

A Debian egy nagyon szabályos disztró. Általános, konkrét és letisztult módszerek ill. szabályok. Rendszerszintű beállítások mind az /etc-ben vannak, az /usr-ben csak statikus adatok (nyugodtan lehet ro-ban mountolni), és a változó adatok a /var-ba mennek, az /opt-ba semmi (ha kiveszed az /usr-t, /var-t és /home-ot, akkor a /-nek elég 500 MB is, nem kell a kde-nek helyet hagyni, vagy külön /opt partíciót csinálni, mert a kde is az /usr-be megy). Ha kell, megpatchelik a csomagokat, hogy jól illeszkedjen a rendszerbe. Letisztult csomagkezelés, nagy hivatalos csomagarchívum. A Slackwareben ha depency resolutiont akarsz, még a csomagkezelőd is 3rd party lesz, a repo-ról meg ne is beszéljek. Van módszer arra is, hogyan illeszd a házi kerneled a Debian csomagok közé, a legtöbb kernelmodult könnyedén lefordíthatod module-assistent-tel még a házi kerneledhez is. De ott van még DFSG, social contract is. A Debiannak szilárd, szabályos és letisztult szerkezete van. A Slackware nem szabálytalan, a Slackware nyers. Ez persze előnyt jelent olyan esetekben, amikor a szabályok nem segítenek vagy éppen hátráltatnak és akadályoznak.

Üdv!
"Rendszerszintű beállítások mind az /etc-ben vannak, az /usr-ben csak statikus adatok (nyugodtan lehet ro-ban mountolni), és a változó adatok a /var-ba mennek" Ez nincs másként a Slackwarenél sem. Ami pedig a KDE-t illeti, nagyon is szabályos, hogy a grafikus felhasználói felület összes adata elkülönítve található a rendszer többi részétől /opt -ban. Ez egy sokkal letisztultabb és átláthatóbb rendszert eredményez. Emellett sokkal átgondoltabb, átláthatóbb és letisztultabb a BSD típusú initszkriptek rendszere (/etc/rc.d) a Debian-féle System V etc/init.d -hez képest, persze ez örök flame-téma marad.
"Ha kell, megpatchelik a csomagokat, hogy jól illeszkedjen a rendszerbe" Nem hiszem, hogy egy rendszernek a letisztultságát az jelzi, hogy "házi" patchekkel milyen jól bedrótozhatók a különböző alkalmazások. A pachelés legtöbb esetben plusz bugforrást jelent a "gyári" kódhoz képest. Véleményem szerint (és ezzel osztom Pat Volkerding elképzelését) tisztább rendszert eredményez, ha az eredeti kódot felhasználva készít az ember csomagokat, és nem kell patch ahhoz, hogy az a csomag illeszkedjen a rendszerbe. Erre tökéletes a makepkg, amivel a lefordított programok csomagolhatók, hogy aztán a pkgtool - lal kezelhetők legyenek.
A csomagkezelőkről meg annyit, hogy az apt-get méltán híres a Debianban, viszont nagyon könnyű vele teljesen összekutyulni a rendszert. Az apt-hez hasonló Slackware-es alkalmazások valóban "3rd party" szoftverek, mivel gyakorlatilag nincs rájuk szükség. Pontosan ezért a Slackware egyik azon ritka rendszerek közül, melyeknél a dependency hell nem téma.
Másrészt a security-mánia sem zárja ki a Slackware-t, ugyanis az egyik, ha nem a legbiztonságosabb disztribúció, ami létezik (jó derivációja a netsecl Linux).
Ezért a szabályos illetve szabályosabb kifelyezést nem tartom helyénvalónak a Debian esetében, viszont a Slackwarere a nyers kitűnő. A Slackware nyers és szabályos. A két rendszer kb olyan mint a Lego és az fa építőkocka (persze nagyon eltúlozva a különbségeket). A Slackware-rel sokat lehet legózni, az szabályokat betartva (a rücskös vége megy a lyukas végébe), míg a Debian fakockáinál ha éppen probléma lép fel, hogy az egyik nem illik, ahova kellene, akkor elő lehet venni a bicskát, és lehet farikcsálni. Viszont a debian előnye, hogy szinte végtelen mennyiségű kocska áll rendelkezésre, Slackwarenél pedig sokszor nekünk kell a műanyag legokockákat "önteni" forrásból (makepkg).
Konklúzió tehát: Sok szemszögből a Slackware szabályosab disztró, mint a Debian, jobban forráskódcentrikus, letisztult és szimpla (KISS = Keep It Simple Stupid), Einsteini konvención (Everything should be as simple as possible, but not simpler)alapuló rendszer, a Debian pedig sok esetben, ahogy említetted akadályozott az összetettsége és bonyolultsága miatt, a letisztultsága ezáltal vitathatató, semmivel sem szabályosabb, kivéve, ha a "szabályos"="bonyolult". (És nem azért tartom bonyolultnak, mert nem tudom konfigurálni, mert akkor Ubuntut használnék, hanem egyszerűen, mert túlbonyolít mindent, ahelyett, hogy az egyszerű megoldásokra törekedne.) Tagadhatatlan előnye az apt-get és az óriási repo, no meg a kiforrott derivációi: Ubuntu, Knoppix, Elive, Nexenta OS, stb...
Slackware=LEGO
Debian=építőkocka
Ezt nem flamenek szántam, csak úgy gondolom, hogy ezáltal az eredeti probléma, az "otthoni szerver tanuláshoz milyen disztro" kérdésének megválaszolásához is több információ áll rendelkezésre.
Szép napot mindenkinek!
____________________________________________________________________________________________
powered by Slackware 11 linux-2.6.19.1 - droplineGnome 2.16.2 @ Fujitsu-Siemens Amilo Pi1505

Gentoo RC Wiki
Gentoo initscript Handbook

Használtam sok más disztrót, de ennek az init scriptjeit tartom a legkulturáltabbnak.

/etc/conf.d/ az init script konfigurációs adatai
/etc/init.d/ maga script
/etc/runlevels/ runlevelek (sim-link)

rc-update, rc-status, rc-config hatékény eszközök a scriptek managelésére.

(Ne ezen flameljünk, leírtam, hogy mi a véleményem, de egy distró megítélésénél nem ez a fő szempont.)
------
gentóhuszár

Ami pedig a KDE-t illeti, nagyon is szabályos, hogy a grafikus felhasználói felület összes adata elkülönítve található a rendszer többi részétől /opt-ban.
Lehet, hogy a KDE fejlesztői így látják helyesnek. A különböző szoftverfejlesztőknek különböző elképzelésük van arról, hogy hova kell tenni a saját programjukat, és hogy ne legyen zavaros, hogy az egyik program itt van, a másik meg ott, a Debian a saját elképzeléseit illeszti rá minden programra.

grafikus felhasználói felület != KDE
Miért nincs az /opt-ban az xfce pl.?

Az oké, hogy a BSD típusú initszkripteket könnyebb olvasni, de lehet, hogy az Debian-féle csomagkezelés könnyebben tudja karbantartani System V init scripteket. Bár ebben nem vagyok biztos, mert ehhez annyira nem értek.

Ami a patchelést illeti: valóban nem jó, amikor úgymond kibeleznek bizonyos programokat. Ez azonban nem jelenti azt, hogy minden esetben káros.

nagyon könnyű vele (apt-get) teljesen összekutyulni a rendszert
Ezt nem tudom, hogy csinalod, masfel eve Debianom van, de nekem meg nem sikerult.

Az apt-hez hasonló Slackware-es alkalmazások valóban "3rd party" szoftverek, mivel gyakorlatilag nincs rájuk szükség.
Ez igaz, csak igy a programok telepitese tobb idot vesz igenybe, mint ha van egy tool ami megcsinalja a depency resolutiont.

dependency hell nem téma.
Attol, hogy az installpkg nem anyazik, attol meg az egyik csomagnak kell a masik.

az egyik, ha nem a legbiztonságosabb disztribúció
Lehet, azert tartok tole, mert a Slackware forumon (itt a hupon), volt tema hogy rendszertelenek a security update-ek (most a patches konyvtarban levo csomagokra gondolok) a Slackware-hoz. A Debiannak meg az Ubuntunak mas a hattere.

"szabályos"="bonyolult"
Ja hat ezert mondod hogy a slack szabalyosabb. Akkor nem egyforman definialjuk a fogalmakat, innen a felreertes. "szabályos"="bonyolult" en ezt tartom. olyan mint vim vs. mcedit. mcedit-et mindenki tudja hasznalni, az "egyszeru". vim-et meg "bonyolult", de aki megtanulja, az gyorsabb lesz vele mint mcedittel.
mcedit vs. vim pelda nem identikus a debian vs. slack esettel.
"szabályos"="bonyolult" Ezt ugy ertem, ha megtanulod a szabalyokat, gyorsabban megcsinalod azt, amit segitenek a szabalyok. Mashol meg lehet hogy hatraltatnak. Hogy a szabalyok jok-e vagy sem, az attol fugg, milyen aranyban csinalsz olyat amit tamogat a szabaly es amit nem ill. amit hatraltat.

Azért a FreeBSD az FreeBSD, a patchelt meg kernel továbbra is Linux marad. De a Linuxról inkább Gabucinot kérdezzük meg. Azért szerintem nem véletlen, hogy a FreeBSD-s szervereknek van a leghosszabb uptime-juk meg a HUP is FreeBSD-n van. Ez azonban nem jelenti azt, hogy egy otthoni szerverre ez a legegyszerűbb megoldás.

Szervernek én CentOS szoktam használni, ez egy RedHat EL. klón, csak ingyenes a frissítése, nem kell hozzá előfizetés.
Tűzfalhoz kezdetben használj egy iptables script generátort mondjuk Shorewall-t. És ha van ambíciód, majd kitanulod az iptables beállítását.

PC-BSD-hez mit szoltok?

Gépigénye?
Mi a különbség a freeBSD és a PC-BSD közöt?

Ja meg a PC-BSD-t is lehet céges környezetbe ingyenesen használni?

üdv

Ezen a konfigon már csaknem minden disztribúció hajlandó működni. Bármelyiket választhatod, kb. ugyanolyan jó lesz a célra.