Samba - špatná odezva

[kamil]

Už podruhé se mi vyskytnul problém s odezvou při procházení sítě - než se zobrazí obsah sdílení tak to trvá i několik minut; práce se soubory už je potom svižná. Možná je to náhoda, ale vždy nebylo funkční připojení do internetu.
V logu jsem nic podezřelého nenašel.
OS je CentOS 5, Samba v3. Vytížení RAM i CPU zanedbatelné.

[Fox!MURDER]

Už podruhé se mi vyskytnul problém s odezvou při procházení sítě - než se zobrazí obsah sdílení tak to trvá i několik minut; práce se soubory už je potom svižná. Možná je to náhoda, ale vždy nebylo funkční připojení do internetu.
V logu jsem nic podezřelého nenašel.
OS je CentOS 5, Samba v3. Vytížení RAM i CPU zanedbatelné.

tipl bych to na problem s DNS. zkus si do hosts pridat hostnamy tech stroju, ktere spolu komunikuji (na obou) ...

[kamil]

no, to mě napadlo taky, ale zase jsem měl za to, že samba si seznamy sestavuje sama, bez návaznosti na DNS; momentálně jsem mimo firmu - až tam budu, vyzkouším...

[Fox!MURDER]

vubec bych na to nespolehal, naopak mam ten pocit, ze nektere veci (napr. logovani) jede podle dns ...

[kamil]

a pmohlo by zprovoznění vlastního DNS? Funkčnost vnitřní sítě závislá na připojení k internetu mě děsí...

[Fox!MURDER]

pokud bude autoritativni pro vsechny interni adresovy prostory a zaroven pro vsechny interni hostnames, tak by to pomoct mohlo (ale napred bych to vyzkousel s tim /etc/hosts, abys neblbnul s dns zbytecne)

[kamil]

jo, dopil jsem dama kafe a jdu na to, pak dám vědět...

...ale mezi tím už zprovoznili inet, tak to budu muset nějak nasimulovat

[kamil]

no tak jsem do hosts (...\Windows\system32\drivers\etc a /etc) na obou stranách zapsal co bylo třeba, ale výsledek se nedostavil...

ještě dodám, že pokud odpojím internet, tak při startu serveru se výrazně déle spouští:
- zaznamenávání systému
- NFS statd
- cups

Doplněno:
když do adresního řádku zadám \\server, tak v logu naskočí
/var/log - messages
Sep 22ep 22 18:27:41 data smbd[2437]: [2008/09/22 18:27:41, 0] lib/util_sock.c:ge 18:27:41 data smbd[2437]: [2008/09/22 18:27:41, 0] lib/util_sock.c:get_peer_addr(1224)
Sep 22 18:27:41 data smbd[2437]: getpeername failed. Error was Koncový komunikační bod není připojen
Sep 22 18:27:41 data smbd[3658]: [2008/09/22 18:27:41, 0] lib/util_sock.c:get_peer_addr(1224)
Sep 22 18:27:41 data smbd[3658]: getpeername failed. Error was Koncový komunikační bod není připojen
Sep 22 18:27:41 data smbd[3658]: [2008/09/22 18:27:41, 0] lib/util_sock.c:write_data(562)
Sep 22 18:27:41 data smbd[3658]: write_data: write failure in writing to client 0.0.0.0. Error Spojení zrušeno druhou stranou
Sep 22 18:27:41 data smbd[3658]: [2008/09/22 18:27:41, 0] lib/util_sock.c:send_smb(761)
Sep 22 18:27:41 data smbd[3658]: Error writing 4 bytes to client. -1. (Spojení zrušeno druhou stranou)

smbd.log
[2008/09/22 18:27:41, 0] lib/util_sock.c:get_peer_addr(1224)
getpeername failed. Error was Koncový komunikační bod není připojen
[2008/09/22 18:27:41, 0] lib/util_sock.c:get_peer_addr(1224)
getpeername failed. Error was Koncový komunikační bod není připojen

[Fox!MURDER]

no tak jsem do hosts (...\Windows\system32\drivers\etc a /etc) na obou stranách zapsal co bylo třeba, ale výsledek se nedostavil...

ještě dodám, že pokud odpojím internet, tak při startu serveru se výrazně déle spouští:
- zaznamenávání systému
- NFS statd
- cups

Doplněno:
když do adresního řádku zadám \\server, tak v logu naskočí
/var/log - messages
Sep 22ep 22 18:27:41 data smbd[2437]: [2008/09/22 18:27:41, 0] lib/util_sock.c:ge 18:27:41 data smbd[2437]: [2008/09/22 18:27:41, 0] lib/util_sock.c:get_peer_addr(1224)
Sep 22 18:27:41 data smbd[2437]: getpeername failed. Error was Koncový komunikační bod není připojen
Sep 22 18:27:41 data smbd[3658]: [2008/09/22 18:27:41, 0] lib/util_sock.c:get_peer_addr(1224)
Sep 22 18:27:41 data smbd[3658]: getpeername failed. Error was Koncový komunikační bod není připojen
Sep 22 18:27:41 data smbd[3658]: [2008/09/22 18:27:41, 0] lib/util_sock.c:write_data(562)
Sep 22 18:27:41 data smbd[3658]: write_data: write failure in writing to client 0.0.0.0. Error Spojení zrušeno druhou stranou
Sep 22 18:27:41 data smbd[3658]: [2008/09/22 18:27:41, 0] lib/util_sock.c:send_smb(761)
Sep 22 18:27:41 data smbd[3658]: Error writing 4 bytes to client. -1. (Spojení zrušeno druhou stranou)

smbd.log
[2008/09/22 18:27:41, 0] lib/util_sock.c:get_peer_addr(1224)
getpeername failed. Error was Koncový komunikační bod není připojen
[2008/09/22 18:27:41, 0] lib/util_sock.c:get_peer_addr(1224)
getpeername failed. Error was Koncový komunikační bod není připojen

nastav si lokaly na C a zkus to znova prosimte. lustit tyhle cesky bazmekty je fakt za trest

[kamil]

musíš mi to nastavení lokalu na C popsat trochu podrobněji a česky...

[Fox!MURDER]

musíš mi to nastavení lokalu na C popsat trochu podrobněji a česky...

ciste teoreticky by melo stacit

export LC_ALL=C
export LC_MESSAGES=C
<restart samby - zalezi, co mas za distro>

pokud to bude v cestine, tak potes koste

[Marty]

DNS procházení sítě nijak neovlivňuje, tam se aplikuje WINS.
Třeba v Sambě aktivovat WINS server:

# Windows Internet Name Serving Support Section:
# WINS Support - Tells the NMBD component of Samba to enable its WINS Server
   wins support = yes

# WINS Server - Tells the NMBD components of Samba to be a WINS Client
# Note: Samba can be either a WINS Server, or a WINS Client, but NOT both
;   wins server = w.x.y.z

a jeho adresu rozdistribuovat klientům. Buď natvrdo nebo přes DHCP (příklad z dhcp3)

subnet 192.168.1.0 netmask 255.255.255.0 {

        range 192.168.1.128 192.168.1.254;                   # Range of IP addresses to be issued to DHCP clients
           option subnet-mask              255.255.255.0;    # Default subnet mask to be used by DHCP clients
           option broadcast-address        192.168.1.255;    # Default broadcastaddress to be used by DHCP clients
           option routers                  192.168.1.1;      # Default gateway to be used by DHCP clients
           option domain-name              "your-domain.org";
           option domain-name-servers      40.175.42.254, 40.175.42.253;           # Default DNS to be used by DHCP clients
           option netbios-name-servers     192.168.1.100;    # Specify a WINS server for MS/Windows clients. 
                                                             # (Optional. Specify if used on your network)

- je to tedy parametr netbios-name-servers <adresa>;

Dále pokud možno sjednotit jméno pracovní skupiny.

Good luck.

[Fox!MURDER]

DNS procházení sítě nijak neovlivňuje, tam se aplikuje WINS.

Nemam nastudovanej kod ani samby ani MS SMB klienta, abych tohle mohl vyvratit, ale vzhledem k tomu, ze se to projevuje pri odpojenym internetu, tak to dost odpovida. Pokud tu teorii totiz vemu z druhy strany, tak odpojenej internet by nemel prodluzovat odezvy WINS.

Ale je pravda, ze ty hlasky nasvedcuji nejakym pokusum o komunikaci nekam, jen z nich neni poznat co a kam ... a nejsem si jistej tim prekladem.

[Marty]

No, já bych primárně pořešil ten WINS, pokud se to bude projevovat dál podobně, tak to bude asi opravdu nějaká závada.
Ostatně, při enablovaným WINS serveru v Sambě je defaultní konfig taková, že si bere jména i z DNS a hosts (a dalších), takže IMHO i kdyby byl problém s DNS, tak by se to tímto řešilo.

[Fox!MURDER]

Marty: z toho cos napsal podle me vyplyva presnej opak ...

[kamil]

Tak jsem se dostal k dalším pokusům - s vyplou podporou WINS aj se zaplou, kontroloval jsem nastavení klientů, zrušil volbu "Zaregistrovat adresy tohoto připojení v systému DNS", přepl na "Povolit rozhraní NetBIOS nad protokolem TCP/IP", ale výsledek furt stejný - při odpojeném internetu je doba procházení sdílených složek v desítkách sekund, či spíše v minutách. Po připojení to jede rychlostí blesku, se zaplou podporou WINS ještě rychlejší...

Už su z teho celý zoufalý...

Pro úplnost dodám, že stanice nejsou v doméně, ale ve skupině...

[Fox!MURDER]

tak zkus tcpdump/wireshark - co kde tece, kdyz to zrovna nejede ...

[Marty]

Mno a kdyby to teda bylo v souvislosti s DNS, tak co nainstalovat bind a nastavit ho aspoň na cachování?

[Fox!MURDER]

pokud to dela jen ta samba a pouziva glibc volani na to, tak by mel stacit nscd ... pokud to funguje jinak, tak ten bind. a nebo zjistit, ktera cast to dela a vypnout ji ...

[kamil]

no, už su zase doma, už budu zase v práci, vyzkůšám - jdu pro desítku burčáku a dnes už na to kašlu...

[Lukas L.]

BTW SMB pouziva pro hledani jmen broadcast nebo wins. Pak pokud vim - existuje jeste stroj, ktery ma nastarosti drzet seznam (browse master), ktery se urcuje volbou v siti (na to ma vliv nastaveni samby os level a preffered master). Ja bych se podival kdo je tim masterem - mam zkusenost, ze pokud se stane masterem (..__MSBROWSE__..) napr. WinXP s FW a pres FW se to nedostane k sambe - pak muze enumerace jednotlivych PC trvat dost dlouho...

viz. napr. nastroj nbtstat pod winxp, adresar /var/cache/samba, utility smbclient, smbtree a nastaveni FW na stroji se sambou

[Gargamel]

Potvrzuju pouziti broadcastu pro name resolving. Nic jineho tady nakonfigurovane nemam, ale hlasky (lib)smbclienta jsou myslim jasne:

added interface eth0 ip=10.34.32.28 bcast=10.34.35.255 netmask=255.255.252.0
.... (zjisti si vsechny interfacy v systemu, ipv4 + ipv6)

<tady je jeste resolve z cache>
resolve_lmhosts: Attempting lmhosts lookup for name win7.englab.brq.redhat.com<0x20>
resolve_wins: Attempting wins lookup for name win7.englab.brq.redhat.com<0x20>
resolve_hosts: Attempting host lookup for name win7.englab.brq.redhat.com<0x20>

Takze problem s dlouhou dobou odezvy bych videl na spatne nastavenych maskach v siti a ve firewallech - ty jsou kamenem urazu cele samby.

Pro debug doporucuju napr.

smbclient -L <nazev_stroje> -d 99

[Paolo]

Praktická zkušenost - odsledováno tcpdumpem.

Pro provoz SMB sdílení se při hledání PC používá prvně dns následovaná sadou UDP broadcast paketů - vyhledávání dle jména PC.

Pokud nemáš vlastní DNS server, který je nastaven jako autoritativní pro doménu ve které máš sdílení, tak jde DNS dotaz směrem do internetu a hledá se právě ta tvá interní doména na internetu. Když funguje připojení, tak root server odpoví negativně téměř ihned a tak se zkusí vyhledání přes SMB.

Když nejede internet, tak se čeká než vyprší platnost dotazu na DNS což bývá běžně 4-8 sekund.

[Marty]

Praktická zkušenost - odsledováno tcpdumpem.

Pro provoz SMB sdílení se při hledání PC používá prvně dns následovaná sadou UDP broadcast paketů - vyhledávání dle jména PC.

Pokud nemáš vlastní DNS server, který je nastaven jako autoritativní pro doménu ve které máš sdílení, tak jde DNS dotaz směrem do internetu a hledá se právě ta tvá interní doména na internetu. Když funguje připojení, tak root server odpoví negativně téměř ihned a tak se zkusí vyhledání přes SMB.

Když nejede internet, tak se čeká než vyprší platnost dotazu na DNS což bývá běžně 4-8 sekund.

A chová se to takhle i když zná klient WINS server (který existuje a odpovídá)?

[Paolo]

A chová se to takhle i když zná klient WINS server (který existuje a odpovídá)?

Ano, i když je zadaný WINS server, tak se prvně dotazuje přes DNS. Jednou jsem se dostal do podobné situace, když umřelo připojení k internetu a všechno strašně dlouho trvalo, tak sem si pustil tcpdump na routeru a hledal, co se vlastně po síti posílá...