Jump to content

Samba servera problēmas


HTC
 Share

Recommended Posts

Apraksts:

Tātad ir servera kaste uz kura griežas xen un savukārt uz tā divi virtuāli serveri, viens no tiem ir debiānis. Debiānis darbojas gan kā lokāls webserveris, gan kā sambas serveris, kur sambai piešķirts viens cietais disks, kas pieejams tikai lokālajā tīklā. Visas darbstaciju os ir ubuntu. Tiklīdz startējas darbstacija tā piemontē sev sambas servera cieto disku līdz ar to visas darbstacijas savus darbus (audio strīmingu) saglabā pa tiešo serverī. Ilgu laiku nebija nekādu problēmu. Tagad sambas logā katrai ip adresei, kas pieslēgusies ik pa laikam izmet erroru, pēc errora izmešanas notiek normāla piekonektēšanās un datu ierakstīšana, tiesa errora izmešanas brīdī audio strīmingā ir klusums uz 3-4 sekundēm... :(. Jauns audio fails tiek veidots ik pēc pāris minūtēm, kuru garums ir mainīgs.

Kļūda no sambas loga:

[2011/12/14 11:46:49,  0] lib/util_sock.c:read_socket_with_timeout(939)
[2011/12/14 11:46:49,  0] lib/util_sock.c:get_peer_addr_internal(1683)
 getpeername failed. Error was Transport endpoint is not connected
 read_socket_with_timeout: client 0.0.0.0 read error = Connection reset by peer.



[2011/12/14 11:51:33,  0] lib/util_sock.c:get_peer_addr_internal(1683)
 getpeername failed. Error was Transport endpoint is not connected

 

Ir mēģināts dažādos veidos problēmu atrisināt, viss neveiksmīgi :/ Lokālajā tīklā pakešu zudumu nav. Darbstaciju ip adreses piesietas pēc mac adreses, kā arī darbstacijas un serveris atrodas citā sabnetā.

Aparatūra tīklā, kur pieslēgtas šīs darbstacijas:

serveris (xen (debian,windows))

mikrotik rūteris,

hp 24 portu swičs

~12 fiksētas darbstacijas zem ubuntu

Sambas konfigā nav norādīts: smb ports , cik atceros to biju norādījis, bet izmaiņas nebija.

 

IDejas, ieteikumi?

 

P.S. neesmu admins, kas tur ņemās. Es šo sistēmu izveidoju pirms ~ gada, bet tagad novembra vidū parādījās šī problēma, teorētiski var piedāvāt citu risinājumu, bet tas nav forši, jo uzskatu, ka problēma jāatrisina nevis jābēg no tās prom.

 

Teorētiski var aizbraukt un samainīt tīkla karti serverim, kā arī nomainīt swičam portu , bet šaubos, ka tas ko līdzēs jo uz porta errori nerēgojas, piekam pings vairāk kā 10'000 paku ar timeout 100ms izgāja cauri bez kļūdām kur tajā pašā laika posmā atkal parādījās viens sambas errors.

Labots - HTC
Link to comment
Share on other sites

Kāda noslodze tajā brīdī procim/atmiņai? Mikrotikā ir salikts darbstacijām Make Static pie DHCP servera?

IMHO dīvaini, ka samba rāda client 0.0.0.0

Link to comment
Share on other sites

Paskatījos uz arī diezgan noslogota Samba servera logiem un man arī ir pilns ar identiskām kļūdām ar visu 0.0.0.0, bet tas reāli neko neitekmē. Tiesa gan man visi klienti ir Windows 7 / XP.

 

Būtībā izskatās ka kļūda logos parādās, jo Samba klients slēdzas pie 139 un 445 porta vienlaicīgi un kurš ports pirmais atbild - ar to sāk sarunu un otru konekciju dropo - tad arī parādās tie log ieraksti neizmantotajai konekcijai. Ja tā tiešām ir, tad tas, kas ir logos ir normāla parādība reconnectam, bet kapēc notiek reconnects jāmeklē citur - iespējams pat klientu galā.

 

Identisks logu piemērs no servera bez problēmām (tik samba versija cita - 3.4.7)

 

[2011/11/03 08:46:10,  0] lib/util_sock.c:539(read_fd_with_timeout)
[2011/11/03 08:46:10,  0] lib/util_sock.c:1498(get_peer_addr_internal)
 getpeername failed. Error was Transport endpoint is not connected
 read_fd_with_timeout: client 0.0.0.0 read error = Connection timed out.

 

Google saka, ka kļūdu var apiet liekot sambai klausīties tikai uz 139 portu, bet cik noprotu tavus disconnectus tas neizlabos.

Labots - optron
Link to comment
Share on other sites

Optron, a gadijumā nevajag radikālāku pieeju? Piemēram, ja gan serveris gan klienti ir Linuxi tad lietot kautkādu NFS? vai to caur SSH mountējamo, nu... fuse, kā tu viņu?

Jo tas tā jocīgi starp 2 Linuxiem sazināties ar Windows failu apmaiņas veidu.

Link to comment
Share on other sites

Bohf, raksta autors pats teica, ka "uzskatu, ka problēma jāatrisina nevis jābēg no tās prom." es tam arī piekrītu un, pie kam, ir daudzas vietas kur CIFS starp Linuxiem strādā ļoti labi un ir pareizāks risinājums nekā ar NFS, Sshfs :bad: vai citi.

Labots - optron
Link to comment
Share on other sites

it.kroplis

Domāju vajag izmantot 445 jo neadmins raksta ka serveri un klienti atrodās dažādos subnetos. netb over TCP derētu labāk.

Bet NFS domāju būtu labāk (oft.)

Link to comment
Share on other sites

atbildot uz jautājumiem:

a) servera noslodze minimāla (neskatoties, ka tiek ierakstīti dienā ~200*12 audio faili), rūterim tieši tāpat . Servera noslodze palielinās naktī, kad jāapstrādā visi audio ieraksti, jāsaliek kartotēkā, jānoarhivē un t.t.

b) uzliku atkal statisko 139 portu, paklausīšos kas notiek , bet to vēlāk redzēs, jāsakrāj logi

c) nī, serveris un lokālās kastes ir kopējā subnetā, kas atdalīts ir no grāmatvedības, bezvadnieka un pārējās aparatūras

d) debiāņa versiju brīvdienās atjaunināju uz pēdējo, nācās arī kerneli pamocīt, sambas versija arī pēdējā.

 

googlēts ir ticis daudz, un dažādi risinājumi izmantoti

 

By def, šo kļūdu ietekmi es nejustu, bet te iet runa, ka serverī dati rakstās strīmveidīgi un katrs diskonekts = klusums ierakstā, piekam tas parādījās ne no šā ne no tā. (darbstacijas un serveri netika upgreidoti, kad parādījās). Pirmīt ienāca ziņa, ka pirms neilga laika iekšējais tīkls pārbūvēts un serveris izvietots citā telpā... hmm , bet te atkal tad parādītos paku zudumi.. ehh, jāturpina googlēt :)

Labots - HTC
Link to comment
Share on other sites

Izveido kontu, vai pieraksties esošajā, lai komentētu

Jums ir jābūt šī foruma biedram, lai varētu komentēt tēmas

Izveidot jaunu kontu

Piereģistrējies un izveido jaunu kontu, tas būs viegli!

Reģistrēt jaunu kontu

Pierakstīties

Jums jau ir konts? Pierakstieties tajā šeit!

Pierakstīties tagad!
 Share

×
×
  • Izveidot jaunu...