Dotaz: Samba ma problem s velkym poctom uzivatelov

[miro1]

Caute Nedavno sme sa tu bavili o probleme s 3 sietovkami(3podsietami) kde mi pripajalo iba jednu. To je uz vyriesene, ale nastal este vacsi problem. Zapojili sme ten server(suse 10 enterprise server) naostro a spustili na nom informacny system(pouzivame sambu). Funguje to tak, ze uzivatel ma primapovany disk a na svojom PC ma vlastne len odkaz. Ak to spusti, tak PC si ho stiahne a spusta uz u seba. Je to robene este vo FOXke a pouziva dbf. Roky to bezalo s Novellom a asi tristvrte roka na win2003. So Suse ma vsak problemi ked sa pripaja viacero uzivatelov. Skoro rano, ked este nebolo v robote tolko ludi to slo bez problemov, avsak medzi 7:15 a 8:00 ked zacinal byt vacsi napor(50-100ludi) zacal akoby stracat spojenie. Proste informacny system spadol a v pripadoch ked pisal hlasku, bolo to nieco na sposob, ze stratil spojenie(podla OS klienta a podla toho kto co robil). A to este neboli pripojeny vsetci. Teoreticky by sa tam mohlo pripojit az 150 ludi. Jedine obmedzenie na pocet userov v sambe je nastavene na unlimited. Ani len netusim kde moze byt problem a co s tym moze suviest, takze netusim ake vseliake informacie mam este napisat. Teraz este prezeram logy, tak skusim potom aj dopisat nieco z nich. Ak mal niekto podobny problem, alebo tusi kde je pes zakopany, prosim pomozte. Som zufaly. S Linuxami mam uplne minimalne skusenosti a vkuse zakopavam o nejaky problem.

Odpovědi

[Filip Jirsák]

Napadají mne dvě možnosti

• problém se zamykáním souborů
• používají se přihlašovací profily, lidé mají v profilech mnoho věcí a když se řpihlásí hodně lidí naráz, musí se přenášet najednou stovky MB pro každého uživatele – přetíží se síť nebo server (nebo obojí)

Další možnost by byla, že jde o slabý stroj (ale asi máte srovnání se strojem, na kterém běžel Novell), nebo je prostě SMB protokol nebo samotná Samba pro takovýhle typ zátěže nevhodná. Ale nejdřív bych se pokusil vyloučit obě dříve zmíněné možnosti.

[miro1]

takze ten prvy problem riesi priamo foxka. A ak by bol problem so zamykanim v sambe, tak ten informacny system by vyhodil hlasku, ze ma problem s pristupom na ten subor. Jedine, ze by to zamklo tak, ze ho vobec nevidi. Ono sa to spravalo ako by spadlo spojenie. Niekedy sa obnovilo samo, inokedy to bolo treba premapovat.

Ta druha moznost sa mi nezda. Ak by to bolo tak, potom by isiel informacny system nenormalne pomaly. A stroj to stiha tiez. Tuto problem nevidim. A predtym bol novell na ovela slabsej masine. Ten win2003 je na o trochu slabsej masine.

[Jan Forman]

Problém se zamykáním neřeší FOXka, protože u sdílených prostředků existuje nekolik druhů zámků. Nevím jak moc to pokročilo, ale před časem jsem si s tím hrál, a když jsem nastavil zamykání alá Windows Server tak se občas poškodily data, v normálním režimu aplikace ve foxce čuměla a čuměla - trvalo to i minutu (klient - windows se neobtěžoval uvolnit zámek). V Novell Netware to fungovalo perfektně, na Windows Server to fungovalo... Zkusil bych se podívat přes SMBstatus co to vlastně píše.

[miro1]

Ja to uz nemozem skusat. Blbne to iba ked je tam vela ludi. Skoro rano ked tam robilo 15-30 ludi to slo, ale neskor ked ich bolo tak 50 a viac, tak to zacalo jednoducho odpajat. Vobec sa nedalo dostat na primapovany disk. Este chcem pozret nejake logy, ale to az ked budem mat cas. Neviem, ale ako to budem testovat kedze to nemozem pustit naostro a prehodenie servrov(skopirovanie, zmenit nastavenia a fyzicky presunut) mi trva minimalne hodinu. A ani to nemozem urobit hocikedy- koli ludom co tam robia. Takze v realnom case sa to sledovat neda. ten smbstatus nema logy pokial viem. Ci sa mylim?

Potrebujem si byt aspon na 90% isty, ze je to vyriesene a az potom to zapojit do ostrej prevadzky. Viem,ze to nebude jednoduche, ale bezia tam databazy, ktore sa mozu pri vypadkoch lahko poskodit a tak isto by som v praci brzdil desiatky ludi. Ked zozbieram dalsie informacie tak ich tu napisem.

[OndraZX]

takze ten prvy problem riesi priamo foxka.

Hmm, aplikace ve Foxce - uprimnou soustrast. Bohuzel tato aplikace je tak zastarala, ze jsou s ni problemy vsude (na zacatku 90 let to byla spicka). Bohuzel v Ceske republice byla velmi rozsirena (CR se rikalo Foxland) a jeste stale se mnoho vyrobcu software nedovede odprostit od aplikace, ktera je jiz 10 let mrtva. Jsou to "garazovi zoufalci", kteri nezvladli prechod na moderni databazove technologie a ja jim preji co nejblizsi konec - bohuzel jeste mnoho firem pouziva tyto jejich produkty a veri svym dodavatelum software, ze ma jejich software budoucnost. Radim se co nejdrive poohlednout po novem informacnim systemu. Mluvim z vlastni zkusenosti. Foxka je pocitacovy pravek - byla super, ale dnes je naprosto "pase".

Ja osobne bych tento problem resil tak, ze bych virtualizoval Novel + Fox aplikace v napr. VMware na novem hardware. Bude to spolehlive a Foxka bude mit to co potrebuje (on ten Novel byl pro ni velmi vhodny)

PS: Foxka vs. velky pocet uzivatelu - to opravdu nejde k sobe, kdyz vite jak Foxka pracuje.

[OndraZX]

napr:

http://usenet.jyxo.cz/cz.comp.linux/0708/samba-a-dbf-soubory.html

http://samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html

Odkazu pro reseni je plno - je to znamy problem

[miro1]

skusim. diky

[miro1]

No. Podobnych clankov som cital uz hrozne vela. Predtym to bolo na Ubuntu 7.04 server a na win98 tak Foxka mrzla v jednom kuse. Ked som siel na NET, tak vsetci pisali o tych oplockoch a podobne. Vtedy to, ale vobec nepomohlo.

Ked som presiel na Suse, tak to uz nerobilo. Som si myslel, ze to je koli distribucii(lepsie vyladene jadro, alebo take nieco).

Ja viem, ze FoxPro je hnus, ale s tym nic neurobim.

Narazil niekto niekedy na clanok/diskusiu kde sa to podarilo vyriesit? Ale uplne. S tym, ze sa stale pouziva FoxPro a klienti maju vsetky OS od Win95 az po Vista.

[miro1]

Dobre, to vsetko viem, ale tento problem sa riesit teraz neda. Je to prost na FOXke a treba to na nej rozchodit. Informacny sytem nekupujeme, ale je nas vlastny. Teraz sa pracuje na uplne novom(c#), ale dovtedy to treba rozchodit na Linuxe. Z novellu sme migrovali, lebo nam uz dochadzaju licencie a samozrejme, ze rovnaky problem je aj na windows. Linux vybrali moji sefovia, lebo je zadara. S tym nic neurobim. Rozhodlo sa vyssie a ja mam ulohu to zrealizovat. A Foxka vs. vela uzivatelov nieje problem. V spicke tam byva, teraz na win2003, predtym na Novel, aj vyse 100 ludi. Myslim, ze Novel mal kupenych 103, alebo 108 licencii a raz za cas sa stalo, ze sa niekto nepripojil koli ich nedostatku. Problem bude niekde v konfiguraci Linuxu, ci Samby. Lebo HW stiha, siet tiez a infor. system nema problemi s inymi OS.

[kuto]

Tak takovéhle řeči mám moc rád. Tazateli určite moc pomohou. Nevím s jakými verzemi Foxky máte zkušenosti, já skoro se všemy, včetně starých pro DOS i nových VFP. Se starou pro DOS bývají problémy pouze na pracovních stanicích z důvodu DOSovského prostředí, v žádném případě z důvodu přístupu na server a sdílení souborů. Ono je prostě někdy nutné používat starý software. Pokud jde o garážové zoufalce - souhlasím že održovat stále software na DOS verzích Foxky je k ničemu, ale nové VFP prakticky nemají konkurenta v programování databázových aplikací. Dělám s více jazyky a technologiemi, ale VFP si s databázemi poradí nejlépe ze všeho. Takže 90. leta se týkají pouze Dos verze. Navíc stará Foxka (jeste ne VFP) existovala i pro windows.

Kdybyste věděl jak Foxka pracuje, nemohl byste nikdy napsat tu poslední větu ;)

[OndraZX]

Tak takovéhle řeči mám moc rád. Tazateli určite moc pomohou. Nevím s jakými verzemi Foxky máte zkušenosti, já skoro se všemy, včetně starých pro DOS i nových VFP. Se starou pro DOS bývají problémy pouze na pracovních stanicích z důvodu DOSovského prostředí, v žádném případě z důvodu přístupu na server a sdílení souborů. Ono je prostě někdy nutné používat starý software. Pokud jde o garážové zoufalce - souhlasím že održovat stále software na DOS verzích Foxky je k ničemu, ale nové VFP prakticky nemají konkurenta v programování databázových aplikací. Dělám s více jazyky a technologiemi, ale VFP si s databázemi poradí nejlépe ze všeho. Takže 90. leta se týkají pouze Dos verze. Navíc stará Foxka (jeste ne VFP) existovala i pro windows.

Od te doby co Microsoft koupil Foxku to s ni jde z kopce (je to uz cca 10 let) - ano sice ji oficialne podporuje, ale vsichni vime, ze vydavani novych verzi je tak 1x za 5 let. Vyvojari kazdy rok resi, jestli Microsoft vyvoj a podporu ukonci, nebo ne. Foxka je proste dnes totalne out - bohuzel.

Kdybyste věděl jak Foxka pracuje, nemohl byste nikdy napsat tu poslední větu ;)

Ja mluvim o klasickych "souborovych" databazich v *.dbf souborech - snad nechcete tvrdit, ze je to v dnesni dobe pouzitelna databazova technologie pri vetsim zatizeni a vice uzivatelich. Netvrdim ze jako frontend oproti SQL serveru je Foxka pouzitelna.

[miro1]

Takze to, ze mi to odpaja sposobuje zamykanie suborov? To sa mi nezda. Ono to odpoji uplne. Nie len konkretny subor, ale cely primapovany disk. Niekedy nabehne sam, ale niekedy to treba primapovat odznova. Ako to moze byt zamykanim?

[StanV]

Není problém, že by bylo otevřených příliš mnoho souborů? Zkuste se mrknout na tuto diskuzi a možná že by to stálo za vyzkoušení.
Samba vyčerpání zdrojů

[cinco]

Vymenil si sietovku? Aky tam mas momentalne typ (chipset)? Deaktivuj vsetky sietovky a daj tam najskor nejaku znackovu kartu. Diskusia u nas vo firme - kazdy ako prve doporucuje vymenit sietovku, potom hladat problem v SW.

[miro1]

Sietovky su nic moc. Realtek. Ale zatial s nimi problem nebol. Napr. teraz su na tom windowse a fici to.

[cinco]

Prave o tom hovorim - problem moze byt v tom, ze sietovka sice funguje, ale nefunguje :) Odvezies sa aj v Skode 120, ale Octavia je o niecom inom. Takze tam skus dat nejaky 3com alebo intel, to by som robil ako prve. Lacny chipset je na domace hranie CS a nie na seriozny server. O SW zatial nehovorim.

[Rx]

Problém je v konfiguraci Samby, Linuxu nebo HW. Ve foxce problém opravdu nehledejte. Jestliže s ní někdo má na Linuxu problém, tak je to problém opravdu nastvení či HW. Foxka je bez problémů na Linuxu ověřená, že chodí a to jak v režimu file-server, tak client-server.

[miro1]

O tej Foxke som cital hrozne vela clankov a vraj na Sambe je to naozaj problem. Potreboval by som teda poradit od niekoho kto to uz rozchodil. Kde mam zacat? Co mam konfigurovat? Ako to mam testovat? Ako mam vobec zacat?

[miro1]

toto pise log.nmbd

  Unable to sync browse lists in this workgroup.
[2007/11/29 06:27:48, 0] nmbd/nmbd_namequery.c:query_name_response(109)
  query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.12 for name ELTECOZA<1d>.
  This response was from IP 192.168.1.20, reporting an IP address of 192.168.1.20.

a tu je nieco z log.smbd. Asi tu bude najlepsie hladat chybu.

[2007/11/29 07:29:04, 1] smbd/service.c:make_connection_snum(950)
  smrzo (192.168.1.10) connect to service isp initially as user user (uid=1188, gid=100) (pid 8571)
[2007/11/29 07:29:07, 1] smbd/service.c:make_connection_snum(950)
  otk3-vystup (192.168.2.40) connect to service isp initially as user hornis (uid=1046, gid=100) (pid 8572)
[2007/11/29 07:29:12, 0] lib/util_sock.c:read_data(534)
  read_data: read failure for 4 bytes to client 192.168.1.165. Error = Connection timed out
[2007/11/29 07:29:12, 1] smbd/service.c:close_cnum(1150)
  pcpinakova (192.168.1.165) closed connection to service isp
[2007/11/29 07:29:16, 0] lib/util_sock.c:read_data(534)
  read_data: read failure for 4 bytes to client 192.168.1.8. Error = Connection reset by peer
[2007/11/29 07:29:16, 1] smbd/service.c:close_cnum(1150)
  fileservervs (192.168.1.8) closed connection to service isp
[2007/11/29 07:29:19, 0] smbd/oplock.c:oplock_timeout_handler(351)
  Oplock break failed for file infor/FOXPRO.INT -- replying anyway
[2007/11/29 07:29:40, 1] smbd/service.c:make_connection_snum(950)
  bistarova (192.168.1.136) connect to service isp initially as user bistarova (uid=1018, gid=100) (pid 8577)
[2007/11/29 07:29:45, 1] smbd/service.c:make_connection_snum(950)
  dobsinsky1 (192.168.1.180) connect to service isp initially as user dobsinsky (uid=1005, gid=100) (pid 8579)
[2007/11/29 07:29:45, 0] smbd/oplock.c:oplock_timeout_handler(351)
  Oplock break failed for file infor/KRYPHES.FXP -- replying anyway
[2007/11/29 07:29:49, 0] smbd/oplock.c:oplock_timeout_handler(351)
  Oplock break failed for file infor/CONFIG.FP -- replying anyway
[2007/11/29 07:29:59, 1] smbd/service.c:make_connection_snum(950)
  bistarova (192.168.1.136) connect to service isp initially as user bistarova (uid=1018, gid=100) (pid 8577)
[2007/11/29 07:29:59, 1] smbd/service.c:close_cnum(1150)
  bistarova (192.168.1.136) closed connection to service isp
[2007/11/29 07:30:04, 0] lib/util_sock.c:read_data(534)
  read_data: read failure for 4 bytes to client 192.168.1.206. Error = Connection reset by peer
[2007/11/29 07:30:04, 1] smbd/service.c:close_cnum(1150)
  janickova (192.168.1.206) closed connection to service isp
[2007/11/29 07:30:06, 1] smbd/service.c:close_cnum(1150)
  lekova (192.168.1.154) closed connection to service isp
[2007/11/29 07:30:20, 0] smbd/oplock.c:oplock_timeout_handler(351)
  Oplock break failed for file infor/UKAZ_SA.FXP -- replying anyway
[2007/11/29 07:30:25, 0] lib/util_sock.c:read_data(534)
  read_data: read failure for 4 bytes to client 192.168.2.72. Error = Connection timed out
[2007/11/29 07:30:25, 1] smbd/service.c:close_cnum(1150)
  mihalik (192.168.2.72) closed connection to service vykresy
[2007/11/29 07:30:25, 1] smbd/service.c:close_cnum(1150)
  mihalik (192.168.2.72) closed connection to service isp
[2007/11/29 07:30:26, 0] lib/util_sock.c:read_data(534)
  read_data: read failure for 4 bytes to client 192.168.2.76. Error = No route to host
[2007/11/29 07:30:26, 1] smbd/service.c:close_cnum(1150)
  janicek1 (192.168.2.76) closed connection to service isp

Je tu niekto kto to chape a vidim tam problem?

Najcastejsie som videl v logu:
"...Error = Connection reset by peer"

[miro1]

a toto povedal kernel:

Nov 29 07:30:54 eltecof kernel: martian source 192.168.1.255 from 192.168.1.219, on dev eth0
Nov 29 07:30:54 eltecof kernel: ll header: ff:ff:ff:ff:ff:ff:00:13:8f:13:b2:13:08:00
Nov 29 07:30:59 eltecof kernel: printk: 31 messages suppressed.
Nov 29 07:30:59 eltecof kernel: martian source 192.168.1.12 from 192.168.2.71, on dev eth3
Nov 29 07:30:59 eltecof kernel: ll header: 00:17:31:c4:64:fc:00:13:8f:3a:6e:c4:08:00
Nov 29 07:31:05 eltecof kernel: printk: 44 messages suppressed.
Nov 29 07:31:05 eltecof kernel: martian source 192.168.1.255 from 192.168.1.248, on dev eth0
Nov 29 07:31:05 eltecof kernel: ll header: ff:ff:ff:ff:ff:ff:52:54:ab:19:56:25:08:00
Nov 29 07:31:05 eltecof smbd[8618]: [2007/11/29 07:31:05, 0] lib/util_sock.c:write_data(562)
Nov 29 07:31:05 eltecof smbd[8618]:   write_data: write failure in writing to client 192.168.1.219. Error Connection reset by peer
Nov 29 07:31:05 eltecof smbd[8618]: [2007/11/29 07:31:05, 0] lib/util_sock.c:send_smb(769)
Nov 29 07:31:05 eltecof smbd[8618]:   Error writing 4 bytes to client. -1. (Connection reset by peer)
Nov 29 07:31:08 eltecof smbd[8169]: [2007/11/29 07:31:08, 0] lib/util_sock.c:read_data(534)
Nov 29 07:31:08 eltecof smbd[8169]:   read_data: read failure for 4 bytes to client 192.168.0.16. Error = Connection timed out
Nov 29 07:31:09 eltecof kernel: printk: 44 messages suppressed.
Nov 29 07:31:09 eltecof kernel: martian source 192.168.2.12 from 192.168.0.3, on dev eth3
Nov 29 07:31:09 eltecof kernel: ll header: ff:ff:ff:ff:ff:ff:00:0f:ea:01:cc:67:08:06
Nov 29 07:31:12 eltecof smbd[8165]: [2007/11/29 07:31:12, 0] lib/util_sock.c:read_data(534)
Nov 29 07:31:12 eltecof smbd[8165]:   read_data: read failure for 4 bytes to client 192.168.1.167. Error = Connection timed out
Nov 29 07:31:15 eltecof kernel: printk: 49 messages suppressed.
Nov 29 07:31:15 eltecof kernel: martian source 192.168.1.12 from 192.168.0.16, on dev eth3
Nov 29 07:31:15 eltecof kernel: ll header: 00:17:31:c4:64:fc:00:30:4f:06:d0:74:08:00
Nov 29 07:31:19 eltecof kernel: printk: 53 messages suppressed.
Nov 29 07:31:19 eltecof kernel: martian source 192.168.1.255 from 192.168.1.193, on dev eth0
Nov 29 07:31:19 eltecof kernel: ll header: ff:ff:ff:ff:ff:ff:00:0b:6a:be:85:6a:08:00
Nov 29 07:31:21 eltecof smbd[3840]: [2007/11/29 07:31:21, 0] lib/util_sock.c:get_peer_addr(1229)
Nov 29 07:31:21 eltecof smbd[3840]:   getpeername failed. Error was Transport endpoint is not connected
Nov 29 07:31:21 eltecof smbd[8624]: [2007/11/29 07:31:21, 0] lib/util_sock.c:get_peer_addr(1229)
Nov 29 07:31:21 eltecof smbd[8624]:   getpeername failed. Error was Transport endpoint is not connected
Nov 29 07:31:21 eltecof smbd[8624]: [2007/11/29 07:31:21, 0] lib/util_sock.c:write_data(562)
Nov 29 07:31:21 eltecof smbd[8624]:   write_data: write failure in writing to client 0.0.0.0. Error Connection reset by peer

[David]

"kernel: martian source" - a jsme doma. některé počítače na tvé síti posílají nekorektní IP adresy. Viz strýček google . Hned ten první odkaz podává obšírné vysvětlení.

kernel: martian source 192.168.1.255 from 192.168.1.219 - stroj 192.168.1.219 o sobě tvrdí, že má zpáteční adresu 192.168.1.255 - to ovšem nejde, to je broadcast.

kernel: martian source 192.168.2.12 from 192.168.0.3 - stroj 192.168.0.3 o sobě tvrdí, že má zpáteční adresu 192.168.2.12 - to je ale jiná podsíť a na jiné síťové kartě.

Tohle se nejčastěji stává, když chytíš nějaký Windows virus. Nebo když máš totálně rozbité síťování, což zjevně není tvůj případ. Takže přeju šťastný lov nakažených strojů.

[miro1]

Preco to zjavne nieje moj pripad? Kludne moze byt zle nakonfigurovana siet. Mam tam 3 sietovky, ktore idu na tu istu fyzicku siet a este maju tak sialene urobene masky, ze... .
Je tam 192.168.0.xxx s maskou 255.255.255.0 ale niektore stanice maju 255.255.252.0
dalej 192.168.1.xxx s maskou 255.255.255.0
a 192.168.2.xxx s maskou 255.255.252.0

Nemoze byt problem, ze napr. stroj 192.168.1.10/24 vidi viac ako jednu kartu?
On je v tom trochu bordel ale s tym neviem nic urobit. Su tu take podsiete a musia
mat vsetky pristup na ten server.
Moze byt to odpajanie sposobene tymto?

[David]

Mam tam 3 sietovky, ktore idu na tu istu fyzicku siet - pokud jsou ty podsítě na "jednom drátě" (všechno je nastrkané do jednoho switche), tak bych osobně nechal v serveru jen jednu kartu a na ní bych nastavil víc ip adres s příslušnými maskami (to jde snadno, ale se suse musí poradit někdo jiný než já).

Pokud je síť opravdu v tak hrozném stavu ("ale niektore stanice maju 255.255.252.0"), a pokud nejde síť předělat (rozdělit, přidat routery, ty jsou právě od toho), tak je potřeba vypnout kontrolu "marťanských" paketů v linuxovém jádru. Z hlavy to nevím, podívám se doma, tam to naopak zapínám. Není kvůli tomu potřeba měnit jádro ani nic kompilovat.

To odpojování bych teď opravdu viděl jako důsledek tohohle chaosu na síti. Když jádro dostane "marťanské" pakety (např. v jednom spojení smíchané ze dvou stanic nebo na neodpovídající síťové rozhraní), tak spojení ukončí.

Jako nejlepší a dlouhodobé řešení bych viděl předělat síť - fyzicky rozdělit na podsítě a přidat routery a nastavit pravidla kdo kam vidí.

[miro1]

Dobre a ak vypnem tych martanov tak to bude fungovat? Nevadi, ze su tie packety take popletene(behaju na ine karty/IPcky)?

[trekker.dk]

Samozřejmě, že to vadí. Kdyby to nevadilo, nikdo by asi do jádra nepřidával tu kontrolu, že jo.

Dobre a ak vypnem tych martanov tak to bude fungovat?

Problém řešit nebudeme, za to zabijeme posla špatných správ. Tím se všechno vylepší.

Člověče, když se v sítích takhle zjevně nezvyznáš, proč ti dali za úkol nastavit síťový server?

Jinak jsem kouknul na tvůj dotaz o třech síťovkách - nebylo by jednodušší ušetřit si problémy s více podsítěmi, nechat tam jenom jednu, koupit gigabitový switch a do serveru kvalitní gigabitovou síťovku? Pokud teda ty podsítě opravdu nutně nepotřebuješ...

[miro1]

Takze by sa mi stracali packety, ale neodpajalo by ma to?

Skusim tam vymenit tu sietovku za gigovu. 

Sietovi server nastavujem, lebo tu nikoho na to nemaju. Prisiel som tu
ako technik, ale casom zo mna zacali robit spravcu siete a teraz mam 
rozbehat Linux(moja prva skusenost s Linuxami). Iba teraz som zacal
studovat cisco.

[trekker.dk]

Takze by sa mi stracali packety, ale neodpajalo by ma to?

Třeba ten případ, který ti popsal David nahoře.

stroj 192.168.0.3 o sobě tvrdí, že má zpáteční adresu 192.168.2.12 - to je ale jiná podsíť a na jiné síťové kartě.

Se serverem chce komunikovat stroj s adresou 192.168.0.3, ale ten o sobě tvrdí, že má zpáteční adresu 192.168.2.12. Pokud se server tedy rozhodne věřit této informaci, tak 192.168.0.3 nikdy nedostane odpověď, tu odpověď dostane jiný stroj s adresou 192.168.2.12, který se ale na nic neptal.

Zkrátka a dobře jediné správné řešení je udělat si pořádek na síti, dokud tam budeš mít takovýhle bordel, tak se ti tam budou objevovat podivné chyby, nebude ti nic fungovat pořádně a nakonec tě odvezou k doc. Choholouškovi do Bohnic.

Sietovi server nastavujem, lebo tu nikoho na to nemaju. Prisiel som tu ako technik, ale casom zo mna zacali robit spravcu siete a teraz mam rozbehat Linux(moja prva skusenost s Linuxami). Iba teraz som zacal studovat cisco.

Hodili tě do vody a uč se plavat. To ti nezávidím.

[miro1]

Ta 192.168.2.12 je ten server.

Ano, hodili ma do vody a este mi priviazali kotvu. Takto sa, ale vraj ucili viaceri linuxaci a sietovi admini.

[František Ryšánek]

Ano, proděláváte intenzivní praktický rychlokurz administrace sítě a serverů Časem určitě dojdete k závěru, že to je zkušenost k nezaplacení. Držím palce.

[miro1]

dakujem. ... uff ... Som naozaj rad, ze stale narazam na viacej a viacej ludi co sa ucili ako ja.

[František Ryšánek]

> Je tam 192.168.0.xxx s maskou 255.255.255.0 ale niektore stanice maju 255.255.252.0
> dalej 192.168.1.xxx s maskou 255.255.255.0
> a 192.168.2.xxx s maskou 255.255.252.0
>

Pokud je to všecko na jednom fyzickém Ethernetu, tak je to dost binec. Obecně všechny stroje, které používají adresy ze stejného subnetu, by měly mít nastavenu navzájem stejně velkou (tj. shodnou) masku. Pokud mají různé stroje různě velkou masku a jejich představy o subnettingu se všelijak částečně překrývají, tak dosáhnete jenom toho, že při některých kombinacích se navzájem nedomluví. Stroj s menší maskou bude dostávat přímé dotazy (na svou MAC a IP adresu) od zdrojové IP adresy, která je mimo jeho masku, a bude je ignorovat.

Nepochybuji o tom, že v tom heterogenním maskování je nějaký geniální nebo i vcelku přízemní záměr, ale dost možná ne zcela domyšlený - podle mého si nakonec jenom zbytečně přiděláváte problémy.

Tj. třeba by Vám pomohlo sjednotit masku na 255.255.252.0 a zredukovat větší počet IP adres na jednom klientském stroji na jedinou IP adresu. Nebo si udělejte košer subnety, s jednotnou maskou v rámci subnetu, a proroutujte. Pokud potřebujete, aby server přímo viděl do tří subnetů, třeba kvůli Windowsímu síťování, které v určitých případech spoléhá na to, že se server vidí se stanicemi přímo na svém subnetu/Ethernetu, dá se to udělat třemi síťovkami v serveru nebo třemi IP adresami na jediné fyzické síťovce (pokud provozujete paralelně více DISJUNKTNÍCH subnetů na jediném ethernetovém segmentu).

Pokud budete mít na W98 klientech a podobně obskurních operačních systémech víc IP adres (víc síťovek, víc IP rozhraní), ani bych se nedivil, pokud se s tím jejich IP stack a další síťoviny nesrovnají úplně dobře, a například bude používat zdrojovou IP adresu mimo daný subnet, na který se paket skutečně dostane. TCP asi chodit bude, ale u jakéhokoli provozu na bázi UDP a jiných protokolů (popř. přes raw socket) by mě nepřekvapila všelijaká zvěrstva.

Pokud potřebujete dohnat konkrétní stroj, ze kterého chodí neznámá zvěrstva, tady velmi pomůže managovatelný switch. Ten je pro takhle velkou síť beztak prakticky nutností, už kvůli potřebnému počtu portů. Po managovatelném switchi budete chtít, aby Vám ukázal, na kterém portu se naučil MAC adresu, která dělá binec. A ten port vypnete / odpojíte.

[AraxoN]

Ak niektoré stanice majú masku 255.255.252.0, tak tá bude najskôr správna a mali by ju mať VŠETKY stanice v sieti. V tom prípade by sieť bola tvorená jedinou podsieťou o rozsahu 192.168.0-3.* a IP 192.168.0.255 by bola úplne regulérnou adresou a nie broadcastom (broadcastom by bola až 192.168.3.255). Osobne by som si tipol, že pôvodne tam bola maska 255.255.252.0, ale neskôr keď pôvodný správca odišiel, tak tam prišiel nejaký "brainiac" bez potrebných fundamentov a začal to opravovať v domnienke, že to je chyba. Ak to zdieľanie funguje s Novellom, tak len preto, že sa používa iný protokol - IPX/SPX a nie TCP/IP.

[miro1]

Povodne tu boli podsiete 192.168.1.xxx/24 a 192.168.10.xxx/24, ale fyzicky oddelene. Bolo ich treba spojit tak vznikla iba jedna 192.168.1.xxx/24. Potom kolega prisiel s napadom, ze kedze nam dochadzaju IPcky mozme urobit druhu podsiet a tym vlastne rozlisovat budovi. Tak vznikla 192.168.2.xxx. Ale aby videla servre bolo treba zmenit masku. Tretia podsiet tu bola odjakziva, ale ta sa nas moc netykala. Teraz sa uz ale zacala tykat aj nas. Lenze PCckam a najma win98 to dost vadilo, napr. zo siete 192.168.2.xxx ...252.0 trvala komunikacia zo servrom 192.168.1.20 ...255.0 hrozne dlho. A kedze tu bol odjakziva zvyk pchat vsade druhu sietovku, tak sa to aj teraz tak vyriesilo. Komunikaciu to dost urychlilo a vsetko sa zdalo byt ok. Az pokial nebolo treba urobit ten Linux. Vraj windows si s takymito vecami vie poradit nejak sam, ale linux treba dobre vyladit aby to fungovalo aj na nasej sieti.

[AraxoN]

"192.168.2.xxx ...252.0 trvala komunikacia zo servrom 192.168.1.20 ...255.0" - ale veď práve v tom je ten problém - tá sieť je zle nastavená. Počítač 192.168.2.xxx ...252.0 si myslí, že so servrom 192.168.1.20 sa spojí priamo a tak to aj urobí, ale server keď mu ide odpovedať, tak v tom má mišung, lebo z jeho pohľadu to nie je tá istá podsieť (podľa masky ...255.0). Ak tam majú byť oddelené siete, tak to chce pridať nejaké routre a fyzicky nimi oddeliť segmenty siete, a ak to má byť jedna sieť, tak treba opraviť masku na všetkých strojoch, vrátane servra. Celé prideľovanie IP, masiek, a pod. by bolo najlepšie riešiť centrálne cez DHCP... Každopádne na každom stroji, ktorý nemá slúžiť ako router má byť len jedna sieťovka.

[František Ryšánek]

1) v tom logu je vidět několik hlášek okolo oplocků. Určitě bych především řekl Sambě, aby nepoužívala oplocky, jak už tady někdo uvedl.

2) přimlouvám se velmi důrazně za výměnu síťovky, Realtek->Intel. To rozhodně neuškodí. S Realtekem mám jednu či dvě specifické špatné zkušenosti i s poměrně triviálním FTP provozem (jediná TCP relace). Záhadná průchodnost cca 30%. 3com je taky lepší než drátem do oka, ale Intel gigabit, desktopový nebo lépe serverový, to je sázka na jistotu. BTW, ten Realtek je stovka nebo gigáč? Mít fileserver pro 150 uživatelů se stovkovou síťovkou, to mi přijde jako masochismus. Zejména, když nad tím má chodit starožitná databáze.

3) vám se podařilo donutit Windows 98, aby chodily uspokojivě na třech subnetech najednou? Jako že tři síťovky v jedné krabici? (Pokud se nepletu tak W98 neuměly víc subnetů na jediné síťovce.) To je dost divočina. Takhle jsem je netrápil snad ani ve svých hovězích letech, kdy jsem měl sklon ke zbytečným experimentům

4) není na čase ty sítě nějak přečíslovat a učesat? Používáte DHCP? Pokud už to musí být různé subnety, což určitě často dává smysl, tak jistě není problém propojit to přes router. Jestli to bude Linux nebo Cisco, to je dost jedno. Fakt je, že přes router neprolezou wokenní workgroupy, ale pokud Vám samba funguje jako WINS nebo provozujete "NT doménu", tak se sambou napříč subnety není problém.

5) Marťanský filtr není vlastností kernelu, ale podle mého bývá realizován jako normální IPtables pravidla. Hledal bych ho v nějakém skriptu, který startuje IPtables, tj. který se týká firewallu. Souhlasím, že bych se snažil spíš zjistit, proč ta mašina tu broadcastovou adresu používá (jako source) a pokusil bych se ten problém odstranit, tj. např. učesat konfiguraci sítě (vč. klientských mašin). Možná by ani nepomohlo vyřadit ten marťanský filtr. Možná tenhle úkaz vůbec nesouvisí se Sambou a Foxkou.

Podle té složité adresace to vypadá, že Vaše síť není úplně triviální. Zkusil jste si sednout a tu síť v hrubých rysech nakreslit na papír? Jak vypadá teď, a jak by se dala rozmotat? Uvařte si kafe/kakao nebo podobnou pochutinu, odložte příručku syntaxe Cisco IOSu, a malujte si barevnými pastelkami různé subnety... Nemáte třeba maličko mezery v obecných pravidlech IP adresace? Cisco má na webu vcelku hezké barevné obrázky. Někdy nejsou moc přehledné a jejich příklady adresních bloků jsou takové starosvětsky velkorysé / rozmáchlé, ale princip se vcelku pochytit dá

[miro1]

1) Na ubuntu nepomohlo vypnut oplocky a preto som ich teraz uz nechal zapnute. Ale skusim.

2) Sietovku to asi naozaj chce novu. Len u nas je vecne problem s kupovanim veci. A ak sa kupi, tak len to najlacnejsie. Preto tu este nieje cisco router. A vlastne nikto kto by ho nastavil- takeho cloveka nezaplatia. Tak sa tu radsej topia vo vlastnych srackach.

3) Win98 nema 3 karty/podsiete. To su len stanice. 3 karty ma len ten novy server co teraz robim. Potom je tu este jedno ubuntu kde je samba, ale to je len cisto na odkladanie a zdielanie dokumentov. Mame tu este terminal(win2000server), skusobny win2000server a win2003 kde je teraz ta FOXka. Na tychto su 2 karty/podsiete a ficia v pohode. Ubuntu aj 2003 som robil ja a nemal som s tym ziadny problem

4) DHCP je na jednej podsieti. Dalsia ma staticke adresy a aj tretia, ale tu spravuje niekdo iny. Rad by som tu dal Cisco router, ale to budem moct az ked dokoncim kurz. Iba som zacal prvy semester.

5) Tak tych martanov tam zatial necham. Aj tak by som to nenasiel.

Tie podsiete su tu, ale dost premiesane. Jedna je v jednej budove a v druhej su dve podsiete, pricom jedno oddelenie si ju spravuje samo. Ibaze casto treba aby bolo niektore PC v dvoch podsietach(alternativna adresa), pripadne si casto menia podsiete. Cize fyzicky ich neoddelim. A do toho servre kde chcu mat pristup vsetci a ak nie, tak do buducnosti budu chciet. Na to bude treba Cisco, ale to teraz este nezvladnem. Mam v plane to, ale urobit a hned aj zmenit tie masky. Masky 255.255.252.0 tam vtedy vznikli koli tomu aby sa videli niektore PC(napr. PC 192.168.2.11/24 nemohlo vidiet PCcka v podiseti 192.168.1.xxx/24, tak sa na sieti 192.168.2.xxx postupne menili masky). Ten problem vsak vyriesi ten router. Na to si, ale este pockam a dovtedy potrebujem rozbehat ten server na sieti ako ju mame teraz.

[František Ryšánek]

Jasně, takhle od stolu už Vám asi žádnou hraběcí radu neudělím Je možné že ta Vaše síť za to opravdu tak docela nemůže.

Osobně jsem svého času přísahal na Cisco, ale nakonec docela spokojeně routuju a firewalluju v Linuxu na PCčkách. Základní routing uvnitř interní sítě je určitě v pohodě. Jenom bych se snažil, mít v routeru něco lepšího než Realtek. Ale to jsme zpátky u Intelu. Taky je dobré mít na to nový stroj, který má směrem k síťovkám něco lepšího, než PCI 32@33. Nejlíp PCI Express, nebo aspoň PCI-X. A to jsme zase u peněz. Ale pořád mi přijde, že nějakých cca 25 kKč za mini-server pro použití jako router+firewall je docela OK. Mělo by to mít větší výkon než SoHo Cisco za podobnou cenu.

Viz třeba tyhle kousky od SuperMicra:
* porty klasicky vzadu
* porty vpředu
Dá se do toho vrazit ještě třeba dual-port Intel Gb do PCI-X nebo PCI-e.

Pro optimální výkon to chce dostatečně nové jádro, jehož ovladač e1000 podporuje message-signaled interrupty. MSI v kombinaci s NAPI resp. "interrupt amalgamation" by měly znamenat nejlepší možný výkon v paketech za sekundu na PCčkovém routeru...

[miro1]

To routovanie tu urobim raz urcite. Sa tu o tom uz dlho hovori. To, ze si robim cisco kurz neznamena, ze to budem robit na cisco routeroch. Ak si budem mysliet, ze to zvladnem na linuxe tak to urobim aj tam. Mam jednu distribuciu zameranu na routovanie- vyatta, len som ju akosi este nerozchodil. Nieco ako to Supermicro by som tu chcel- najradsej by som nahadzal takto vsetky servre, ale ako som spominal je tu problem s financiami.

[František Ryšánek]

Pokud ten router bude ve vnitřní síti, tak bych na to doporučil klidně nějaké univerzální distro. Do těch mrňavých skříněk se jeden disk vejde (nebo 2x 5.25" v mirroru). Třeba já jsem odkojený Kloboukem, takže bych se nebál použít třeba Fedoru 8 nebo Centos (i kvůli novému jádru) - vy si tam dejte takové distro, ve kterém jste doma. Říkal jste SuSE? Ten je sice v některých ohledech "německý" (svůj), ale pokud se týče základního routingu, tak proti němu apriori nic nemám.

Nehleďte na to, že základní routing holýma rukama znamená 3x ifconfig + párkrát route + `echo 1 >/proc/sys/net/ipv4/ip_forward'` . Hlavně abyste to dokázal ve zvolené distribuci nakonfigurovat - buď prostředky distribuce, nebo nacpat do custom skriptu a ten zavěsit někam do /etc/rc* .

Třeba mě posledních pár routerů startuje z flashky v read-only režimu, ale já byl vždycky "jinej" a hlavně mě stálo dost času se k tomu dopracovat...

Škoda že potřebujete, aby Vám to chodilo na první pokus naostro pro takhle velký počet uživatelů. To je docela infarktová situace Nejde o samotný routing, ale o to, že kvůli němu budete potřebovat zároveň učesat konfiguraci klientů, řekl bych i zprovoznit DHCP (právě kvůli tomu učesání), a třeba zrovna wokenní sdílení skrz router není úplně houska na krámě (chce to WINS nebo lépe doménu). Ale když to jednou rozchodíte, tak to bude znamenat výrazný vzrůst "štábní kultury" ve Vaší síti.

Pokud dokážete zařídit, aby všechny SMB servery měly přímou síťovku do všech subnetů, ve kterých mají klienty, tak nemusíte řešit průchod wokenního sdílení na úrovni workgrupy skrz router. Máte nějaké další aplikace, které vyžadují "přímou viditelnost" na ethernetu?

Možná začněte tím, že si zprovozníte DHCP a překlopíte na něj klienty - a přes DHCP budete dávat "starou" nebo kompatibilní konfiguraci IP adres klientů, ještě než rozchodíte router. Udělejte si nějaká pravidla pro číslování uvnitř subnetu - třeba jednička router, první desítka další routery a servery, od dvaceti výš stanice se statickými adresami (podle MAC adresy), od stovky do konce subnetu dynamické přidělování... takto si snadno oddělíte známé klientské stanice od případných cizáků.

Ještě mě napadá, že na tom serveru byste si mohl zlepšit průchodnost síťového stacku tím, že úplně vypnete firewall. Netuším, jak moc je Vaše interní síť nebezpečná, zda si to můžete dovolit. Podle mého by s tím neměl být problém.

[trekker.dk]

3x ifconfig

ip! Není důvod začátečníky učit příkaz, který je v Linuxu několik let obsolete.

[miro1]

Tieto zmeny tak skoro robit nebudem. Rozmyslam, ze z tych 3 subnetov urobim iba 2, tak, ze zmenim tie masky aby vsetky boli 255.255.252.0. Ten treti subnet bude oddeleny routrom a vsetky brany(internet, VPN) a servre budu tiez oddelene. Ten treti subnet musi byt mimo, lebo si ho spravuju sami a niekedy sa stane, ze sposobia konflikt adries, alebo rovno zacyklia siet. Brany a VPNku nepotrebuju ostatny(VPNku musia vidiet len servre)a brany do internetu su pre nas a ako zalozny internet. Ak sa nemylim tak vsetky cisca maju iba jeden eth port na nastavovanie + dalsie 2. Cize ja budem musiet dokupovat este minimalne jeden. Este rozmyslam ci sa nevyplati dokupovat optiku(jeden subnet je vo vedlajsej budove a ide cez optiku) a budem to mat rozdelene routrom az na 4 siete. To bude, ale asi dost komplikovane vyladit. Ci nie? Robil niekto z vas cisco kurz? Co myslite, kolko semestrov potrtebujem na to aby som to zvladol? Zatial robim len prvy.

[František Ryšánek]

To už je opravdu zralé spíš bavit se nad obrázky sítě, řešit zcela konkrétní zadání. Odrazit se od přesně zakresleného a popsaného současného stavu a naplánovat, co s tím dál. Obrázek má hodnotu tisíce slov. Z pochopitelných důvodů není vhodné, abyste zveřejňoval detailnější informace v takto širokém fóru.

Třeba já jsem formální Cisco kurz nikdy neabsolvoval, nepotrpím si na certifikáty, možná ke své smůle. Základy mě naučili kolegové ve firmě, kde jsme Cisca denně konfigurovali zákazníkům. Mám za sebou pár velice příjemných "necertifikovaných" školení na konkrétní specializované oblasti od firmy Alef0. Fakt je, že u lidí s certifikovaným školením od Cisca je vcelku spoleh, že mají odpovídající schopnosti (podle úrovně certifikátu) - pár takových lidí jsem potkal, od CCNA po CCIE.

Můj soukromý dojem je tento: jakýkoli certifikovaný kurz třeba u Cisca nebo Microsoftu Vás naučí potřebnou teorii a pak průřezově/encyklopedicky všechno, co daný výrobek umí. "IOS umí tohle, tohle, tohle a tohle. Problém tohoto typu se řeší takto." Takové vědomosti nejsou vůbec špatné - jenom pozor, že když držíte kladivo, každý problém vypadá jako hřebík. Záleží na přednášejícím, jestli se případně dozvíte taky "informace mezi řádky": co školený výrobek neumí, co umí konkurence, co by šlo udělat jinak, případně v konkrétní situaci třeba i lépe. A záleží na Vaší denní praxi, kolik Vy sám nasajete "alternativního kontextu okolo"

Cisco nabízí docela širokou paletu produktů, a to i u dolního konce cenového spektra, který Vás patrně zajímá. Za mých mladších let měly routery a switche Cisco jeden konzolový port (tuším RJ-48 nebo RJ-45), což je RS232 sériáč. A pak minimálně dvě další rozhraní. Dneska už se synchronní sériače asi moc nenosí, PDH/SDH bude možná mimo Vaši zájmovou kategorii - takže bych to viděl na dva a více Ethernetů. Některé jsou natvrdo zabudované, jiné mohou být modulární (na výměnných kartách/kartičkách). Pokud máte nějakou stávající optiku, může být skutečně vhodné, pořídit si modul optického nebo SFP rozhraní (pro SFP GBIC) - jenom pozor na kompatibilitu se stávajícím hardwarem. Modularita a povolené kombinace přídavných rozhraní u různých rodin routerů a switchů Cisco, to je téma na celoživotní studium. Jsem v zásadě už mimo obor, nemám aktuální informace. Cisco má tradičně výbornou dokumentaci na webu. Pokud potřebujete větší počet routovaných ethernetových portů, zkuste "router on a stick" s VLANovým switchem.

[miro1]

Viem, ze nieje dobre sa bavit o detailoch na otvorenych forach. Neplanujem uz pisat viac info ako som sem dal.

Ja len zacinam CCNA, ale to som tu uz pisal.

Skusam si nasimulovat tu siet Packet Tracerom od Cisca a nasiel som tam jednu konkretnu kartu co mi to rozsiri o ethernetove porty.

[michich]

5) Marťanský filtr není vlastností kernelu, ale podle mého bývá realizován jako normální IPtables pravidla.

Ne, marťanský filtr je zcela jistě přímo v kernelu (net/ipv4/route.c).

[František Ryšánek]

Fakt že jo Třeba ve 2.6.22.6 je to řádek 1698.

Díky za update. Svého času jsem viděl konfiguraci, kde v kernelu byl jenom rp_filter, který nic nelogoval, a marťani se detekovali explicitní sadou IPtables pravidel. Teď vidím v /proc filesystému dvě položky:

   /proc/sys/net/ipv4/conf/eth0/rp_filter

a

   /proc/sys/net/ipv4/conf/eth0/log_martians

Po pravdě řečeno, když koukám na ty pravidla, tj. hlavně na fib_validate_source() v souboru fib_frontend.c, tak ten explicitní marťanský filtr byl silnější, protože kontroloval i "dobře známé zakázané" subnety podle seznamu, tj. privátní sítě a nepřidělený prostor.

Ale máte pravdu, že ta hláška v logu pochází z Vámi uvedeného kernelového zdrojáku.

To by mě zajímalo, jestli by našemu tazateli pomohlo

   echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

a/nebo

   echo 0 > /proc/sys/net/ipv4/conf/eth0/log_martians

[romank]

Dobry vecer, necital som to cele, ale ja som mal na sieti cca 150 uzivatelov, ktory mali na fox-ke databazu na samba serveri a nemal som problem. Je dolezite si uvedomit ako mate nakonfigurovanu sambu a aky mate hardware. Cize aky mate server, ak mate DNS server tak ako Vam funguje a ci mate zapnutu podporu pre wins ..... V pripade ak zajtra sa k mojmu prispevku prihlasite tak sa Vam pokusim pomoct cez icq alebo inac
. Roman K.

[_ijkl]

Skor nez zacnes nieco riesit, tak si zapni loglevel na 10 a skus nieco vycitat z logov (mozno si to spravil, ale nenapisal si to).

[radekpv]

Na jakém HW to provozujete? Jaká je zátěž serveru ? Jaké další démony na serveru běží? Měl jsem problémy podobné vašim. Při 50 uživatelích OK, při 100 byla samba pomalá, při 150 uživatelích jsem měl problémy. Samba 3.X a CUPSd na PIII 800MHz, 512MB. Když jsem snížil prioritu CUPSd, dostal jsem se na 300 uživatelů a potom se začala samba chovat stejně - odmítala připojení, ti co už měli namapované disky je ztráceli ... BTW: Tu síť si opravdu "ukliďte" a přejděte na DHCP.

[miro1]

Nieje to server. Je to obycajne PC-AMD Athlon X2 3800+, 2GB DDR2 a 80GB WD, 2*250GB Seagate ES(SW zrkadlene). Ale vykonom urcite stiha. Kedysi to bolo na asi o polovicu slabsom stroji a vtedy tam robilo kolo 100 ludi. Teraz bezi na P4(este nie dual core), 2GB s win2003 a stiha uplne v pohode. Chodi tam tak 120 ludi v spicke. Tych 150 je celkovy pocet uzivatelov.

[romank]

Zdravim SW raid je oproti scsi diskom v HW radici pomaly, (NO FLAME), tam by som dal HW RAID a SCSI disky, myslim si ze cca 150 uzivatelov si to zasluzi.
Lenze aj na tejto konfiguracii by to mohlo fungovat celkom svizne. Ten konfigurak co som poslal nepomohol? Je nutne sambu restartrnut .... (reloadnut aby ludia nenadavali) ....
Roman K.

[miro1]

Konfigurak neprisiel. Ani ziadny mail.

[romank]

a este jedna vec http://de.samba.org/samba/docs/using_samba/ch08.html

[miro1]

uff. Taketo clanky je dobre si precitat, ale keby ich robili strucnejsie. Si to precitam asi az doma po robote.

[romank]

Poslal som Vam 3 e-maly. Dosli?

[miro1]

ano. mam ich a citam ten smb.conf. Trochu pogooglujem co znamenaju niektore veci a vyskusam. zatial dakujem

[František Ryšánek]

CPU bude výkonově v pohodě. Ta deska bude mít určitě nějaké PCI-expresové sloty, ne? Tam by se daly nacpat intelí síťovky. Je možné, že do grafického slotu nepůjde síťovka, třeba Intel si u výrobců BIOSu prosazuje, aby to na desktopových boardech naschvál nešlo (přestože hardware north bridge to umí). Vnitřní průchodnost NB->SB bude dostatečná (dostatečně nová generace čipsetu).

SW RAID 1 nebo 10 je v pohodě, HW RAID by rychlejší nebyl, byl by jenom komfortnější při havarijní situaci. RAID 5/6 by byla jiná píseň. 250GB, to je nějaký obyčejný SATA disk => nic moc rychlost a seeky. Že ho Seagate prodává jako ES, to je spíš obchodní trik. Ale možná to stačí. Nemělo by to způsobovat drolení Samby. SCSI disky mají rychlejší seeky a řádově dvakrát větší sekvenční průchodnost, ale o tu tady asi nejde. 2 GB RAM jsou dost slušné (spousta cache).

=> v hardwaru toho PC bych asi problém nehledal. Dělení na servery a desktopy je z větší části věc obchodnické strategie prodejců hardwaru, případně věc formátu desky, konstrukce skříně apod. Váš čipset "na to má".

[miro1]

Prepacte, ze som dlho nereagoval. Podla toho to som pocul, cital, videl na tomto webe a inych je jasne, ze FOX, FOX PRO nemoze fungovat na Linuxe. Ak sa aj rozbehne tak casom mozu vzniknut problemi, preto to uzavrem ako vyriesene- Jednoducho nespustat FOXku na Linuxe. Funguje dobre na Novelloch a Windowsoch.