«Best practiсe» для системных администраторов Samba

Мы будем настраивать только доступ к серверу GNU/Linuxс внедрением Samba. Авторизация юзеров остается локальной, с внедрением /etc/passwd.

Присвоим нашему новенькому серверу статический Айпишник. Пусть им будет 192.168.7.9.

Для начала необходимо проверить, какой сервер у нас употребляется в качестве DNS. Им в нашей сети должен быть контроллер домена. У нас адресок сервера определен как 192.168.7.2. Правим файл /etc/resolv.conf. Он должен смотреться последующим образом:

«Best practiсe» для системных админов Samba

Препядствия, выставленные на нижних уровнях этой «пирамиды», являются «фундаментом» для более больших уровней. Не умопомрачительно, что Windows-клиент не может получить доступ к файловому северу на Samba, если сервер отключен от сети. Естественно, не стоит принимать этот набросок практически, как управление к действию (скажем, лог-файлы можно поглядеть всегда), но начинать стоит все-же с заморочек нижних уровней. Чем выше мы поднимаемся, тем больше углубляемся в механизмы работы Samba.

В поисках решения препядствия с Samba стоит сначала обратиться к последующим ресурсам:

HOWTO, размещенные на веб-сайте http://www.samba.org/;
направленные на определенную тематику веб-сайты и форумы, к примеру: http://samba-doc.ru/, http://citforum.ru/operating_systems/linux/samba/;
разделы документации по Samba для того либо другого дистрибутива (к примеру, http://help.ubuntu.ru/wiki/samba, http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-samba.html либо http://wiki.russianfedora.ru/index.php?title=Samba);
http://stackoverflow.com/— не запамятовывайте про этот веб-сайт, если у вас есть определенный вопрос либо неувязка;
вспомогательные утилиты, входящие в состав Samba, также разные программы-анализаторы трафика (к примеру, Wireshark).

Мы сначала разглядим самостоятельное решение возникающих заморочек, но не следует забывать про вероятную помощь общества. Это может серьезно сберечь вам время и силы.

Описание испытательной среды

Для начала — несколько слов о испытательной среде. Условия последующие:

Samba-сервер именуется TROUBLE и имеет Айпишник 192.168.7.75 и маску 255.255.255.0.
smbd и nmbd запускаются как бесы.
Windows-клиент именуется win-client.
Windows-клиент употребляет адресок 192.168.7.135 с сетевой маской 255.255.255.0.
И win-client, и TROUBLE находятся в одной сабсети, так что широковещательный запрос дойдет с 1-го хоста на другой.
И win-client, и TROUBLE являются членами рабочей группы LAB.
Samba-сервер употребляет следуюший smb.conf:
[global] netbios name = TROUBLE
workgroup = LAB security = user encrypt passwords = yes
[public] path = /tmp
read only = no

УРОВЕНЬ 1

Работоспособность сетевого соединения и файла конфигурации

Основание нашей «пирамиды» составляют три главных препядствия:

корректно работающее TCP/IP подключение;
соответствие маски и широковещательных адресов на серверах и клиентах;
работоспособность файла smb.conf.

TCP/IP

Для проверки TCP/IP сначала употребляется команда ping. Если обрисовать протокол ICMP очень упрощенно, то хост посылает запрос на сервер и спрашивает «Ты живой?». Если сервер не отвечает, хост приходит к выводу, что тот не подключен к сети и, как следует, недоступен.

$ ping win-client
PING win-client (192.168.7.135) from 192.168.1.74 : 56(84) bytes of data.
64 bytes from win-client (192.168.7.135): icmp_seq=0 ttl=255 time=2.138 msec
64 bytes from win-client (192.168.7.135): icmp_seq=1 ttl=255 time=2.181 msec
64 bytes from win-client (192.168.7.135): icmp_seq=2 ttl=255 time=2.263 msec
— ping statistics — 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/mdev = 2.138/2.194/2.263/0.051 ms

Также очень принципиальным является правильное функционирование DNS. Если не получится разрешить имя, появится сообщение вроде этого:

$ ping win-client
ping: unknown host win-client

Если такое происходит, 1-ое, что стоит сделать — это повторить команду ping, но используя уже не имя, а адресок:

$ ping 192.168.7.135

Если команда выполнится удачно, то стоит направить внимание на конфигурацию DNS. Более всераспространенные предпосылки ошибки:

неправильное содержание файла конфигурации DNS /etc/resolv.conf;
на сервере DNS нет записи, связанной с win-client;
сервер DNS недоступен на этот момент.

Если же ping по Айпишнику удачно не производится, то стоит проверить работоспособность сетевого оборудования на сервере, клиенте и меж ними.

Широковещательный адресок на сервере и клиенте

Может быть, ping выполнится и удачно, но при всем этом сетевая маска (netmask) и широковещательный адресок (broadcast address) будут сконфигурированы ошибочно.

В NetBIOS очень принципиально для правильного разрешения имени и поиска машин в сетевом окружении, чтоб сервер и клиент находились в одной сабсети, т.е. использовали одну маску сабсети и широковещательный адресок.

В нашем случае сетевая маска должна быть 255.255.255.0, а широковещательный адресок — 192.168.7.255.

Если вы используете Linux, то можно проверить, какие употребляются широковещательный адресок и маска, с помощью команды ifconfig с именованием интерфейса в качестве аргумента:

$ /sbin/ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:04:5A:0C:1C:19
inet addr:192.168.7.75 Bcast:192.168.255.255 Mask:255.255.255.0
inet6 addr: fe80::204:5aff:fe0c:1c19/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:68006 errors:0 dropped:0 overruns:0 frame:0
TX packets:100783 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:12186135 (11.6 Mb) TX bytes:121642120 (116.0 Mb)
Interrupt:3 Base address:0×100
1

Если в выводе этой команды вы увидите, что широковещательный адресок либо сетевая маска заданы ошибочно, следует зайти под учетной записью root и установить верные значения, используя команду ifconfig:

root# ifconfig eth0 192.168.7.75 netmask 255.255.255.0 broadcast 192.168.7.255

В Windows аналогичную информацию можно получить информацию, выполнив команду ipconfig /all.

Проверка правильности файла smb.conf

Потому что Samba употребляет неограниченное количество характеристик из файла smb.conf, разработчики сделали утилиту командной строчки, которая инспектирует синтаксис этого файла. Утилита именуется testparm, она очень полезна при поиске ошибок в конфигурационном файле.

Можно использовать утилиту testparm с параметром -s для анализа определенного конфигурационного файла. Эта функция прекрасно подходит для проверки файла конфигурации перед его «боевым» внедрением.

$ testparm -s /usr/local/samba/lib/smb.conf.new
Load smb config files from /usr/local/samba/lib/smb.conf.new
Processing section “[public]”
Loaded services file OK.
# Global parameters
[global]
coding system =
client code page = 850
code page directory = /usr/local/samba/lib/codepages

После анализа данного конфигурационного файла testparmвыводит все значения файла smb.conf, включая значения по дефлоту. Это помогает убедиться, что употребляются ожидаемые значения характеристик конфигурации smbd и nmbd.

Необходимо отметить, что значения по дефлоту изменяются от версии к версии, так что нужно использовать версию Samba, подобающую версии testparm.

УРОВЕНЬ 2

Серверное и клиентское ПО

2-ой уровень предполагает проверку конфигурации клиентского и серверного ПО. Наша цель — убедиться, что и клиент, и сервер корректно отвечают на запросы NetBIOS и CIFS. Пока мы рассматриваем изолированно любой из хостов. (На 3-ем уровне мы уже начнем рассматривать их взаимодействие.)

smbd

Сначала, smbd должен быть запущен. Проверить это можно, используя команду ps. Аргументы этой команды могут отличаться зависимо от версии Linux.

$ ps -ef | grep smbd
root 28592 1 0 12:37 ? 00:00:00 /usr/local/samba/bin/smbd -D

Убедившись, что smbd запущен (либо, по мере надобности, запустив его), используем утилиту smbclient для проверки работоспособности сервера. Параметр -L употребляется для вывода перечня ресурсов сервера. Ключ -N употребляется для анонимного подключения к серверу, чтоб не создавать излишних заморочек с авторизацией. Все эти деяния должны производиться локально на Samba-сервере.

smbclient -L TROUBLE -N added interface ip=192.168.7.75 bcast=192.168.1.255 nmask=255.255.255.0
Anonymous login successful Domain=[LAB] OS=[Unix] Server=[Samba 2.2.2]
Sharename Type ——— —- public Disk IPC$ IPC
Comment ——-
IPC Service (Samba 2.2.2)
smbclient -L TROUBLE -N added interface ip=192.168.7.75 bcast=192.168.1.255 nmask=255.255.255.0
Anonymous login successful Domain=[LAB] OS=[Unix] Server=[Samba 2.2.2]
Sharename Type ——— —- public Disk IPC$ IPC
Comment ——-
IPC Service (Samba 2.2.2)
ADMIN$
Server ——— TROUBLE
Workgroup ——— LAB
Disk
IPC Service (Samba 2.2.2)
Comment ——- Samba 2.2.2
Master ——- TROUBLE

Есть две всераспространенные ошибки, которые могут появиться при выполнении этой проверки.

1-ая ошибка смотрится последующим образом:

error connecting to 192.168.7.75:139 (Connection refused) Connection to failed

Она появляется, если smbd не запущен либо не может подключиться к порту 139. Предпосылкой этому могут быть ранее установленные и неправильно удаленные составляющие Samba. Сначала следует убедиться, что smbd стартует как бес и не заканчивается здесь же с ошибкой. Особенность в том, что nmbd не выводит ошибки в консольное окно, так что следует поглядеть последние несколько строк log-файла. Позднее мы разглядим анализ логов более тщательно.

2-ая нередко встречающаяся ошибка смотрится так:

session request to failed (Not listening for calling name)

Можно помыслить, что предпосылкой этой ошибки является неправильное NetBIOS-имя, но это не так. Эта ошибка не может быть вызвана «битой» установкой nmbd, nmbd в этом случае даже не непременно должен быть запущен.

Предпосылкой появления этой ошибки при локальном подключении в большинстве случаев являются ошибочно сконфигурированные характеристики hosts allow либо hosts deny в файле smb.conf. Сервер разрывает создающуюся NetBIOS-сессию.

Если нам удалось узреть перечень общих ресурсов, мы можем проверить возможность Samba авторизовать юзеров. В этом тесте акк с именованием юзера user1 и паролем secret подключается к общему ресурсу [public].

$ smbclient //TROUBLE/public -U user1%secret added interface ip=192.168.7.75 bcast=192.168.1.255
nmask=255.255.255.0 Domain=[LAB] OS=[Unix] Server=[Samba 2.2.2] smb: >

Если Samba не сумеет авторизовать юзера, вы увидите сообщение об ошибке:

session setup failed: ERRSRV – ERRbadpw (Bad password -
name/password pair in a Tree Connect or Session Setup are invalid.)

Обстоятельств этой ошибки может быть много. Это может быть неправильное имя либо пароль, либо отсутствующая запись smbpasswd для юзера, если задан параметр encrypt password = yes, либо недействительная учетная запись guest, если разрешен доступ без аутентификации.

Если юзер корректно авторизовался, но не сумел получить доступ к запрошенной службе, smbclient выведет последующее сообщение:

tree connect failed: ERRDOS – ERRnosuchshare (You specified an invalid share name)

Это может быть вызвано ошибочно написанным именованием службы, опциями доступа к общему ресурсу либо неправильным выражением path в описании общего ресурса в файле smb.conf.

nmbd

Чтоб проверить, запущен ли nmbd, мы опять используем команду ps.

$ ps -ef | grep nmbd
root 29054 1 0 15:53 ? 00:00:00 /usr/local/samba/bin/bin/nmbd -D

Если ps покажет, что nmbd не запущен, стоит зайти под учетной записью root и запустить его (/usr/local/samba/bin/nmbd -D).

Для теста мы будем использовать утилиту Samba —nmblookup. У каждого Samba-сервера есть особенное имя, _Samba_, на которое они отзываются всегда. Отправив запрос по этому имени, мы можем проверить работоспособность nmbd. Ключ -U употребляется для того, чтоб выслать запрос на определенный адресок.

$ ./nmblookup -U 127.0.0.1 __Samba__ querying __Samba__ on 127.0.0.1 192.168.7.75 __Samba__

Если nmbd при всем этом не запущен, результатом будет ошибка:

name_query failed to find name __Samba__

Также предпосылкой ошибки может быть тот факт, что loopback-интерфейс не включен в smb.conf при включенном параметре bind interfaces only = yes.

После чего мы проверим, может ли nmbd зарегистрировать имя TROUBLE.

$ nmblookup -U 127.0.0.1 TROUBLE querying TROUBLE on 127.0.0.1 192.168.7.75 TROUBLE

Сообщения об ошибках, к примеру, “name query failed”, вероятнее всего, вызваны плохим запросом к имени _Samba_. Другой предпосылкой может быть то, что сервер не может зарегистрировать имя NetBIOS. В данном случае стоит отыскать сервер, которому принадлежит данное имя, послав широковещательный запрос.

$ nmblookup -B 192.168.1.255 TROUBLE querying TROUBLE on 192.168.1.255 192.168.1.98 TROUBLE ошибка

К примеру, в этом случае это имя принадлежит посторонней машине, а не нашему Samba-серверу. Разумеется, решением данной препядствия является переименование этой машины либо сервера.

NetBIOS-интерфейс Windows

Утилита, использующаяся в Windows для NetBIOS-запросов — nbtstat.exe — имеет еще несколько опций, которых нет в nmblookup. Одна из их (-n) позволяет «спросить» у NetBIOS-интерфейса, какие имена он удачно зарегистрировал:

C:WINDOWS> nbtstat -n
Node IpAddress: [192.168.7.135] Scope Id: [] NetBIOS Local Name Table
Name Type Status ———————————————
WIN-CLIENT LAB WIN-CLIENT
UNIQUE GROUP UNIQUE
Registered Registered Registered

Если компонент “Client for Microsoft Networks” не был установлен, nbtstat.exe скажет последующее:

Failed to access NBT driver 1

Более узкая ошибка появляется, когда Windows-клиент докладывает что он зарегистрировал имя рабочей группы, хотя это должно быть уникальное имя рабочей станции.

Name Type Status ——————————————— LAB GROUP Registered

Нередко предпосылкой этого является наличие машины с таким же NetBIOS-именем. Windows-клиенту нужно уникальное имя, чтоб установить NetBIOS-сессию с сервером. Пока клиент не сумеет зарегистрировать имя рабочей станции, он будет неспособен, скажем, просматривать сетевое окружение либо подключать сетевые диски.

УРОВЕНЬ 3

Удаленный доступ к общим ресурсам

Итак, мы уже узнали, что и клиент, и сервер имеют доступ к сети, и локально ПО на их работает. На данном уровне мы перебегаем к диагностике работоспособности их взаимодействия.

Разрешение имен

Мы вновь будем использовать утилиты nmblookup и nbstat.exe, чтоб узнать, может ли клиент разрешить имя сервера и напротив. Тест будет состоять из 2-ух фаз. В первой мы будем использовать широковещательный запрос, чтоб протестировать отклики сервера и клиента. Это делается методом задания широковещательного адреса (-B 192.168.7.255) в утилите nmblookup при запросе, что использует сетевое взаимодействие меж сервером и клиентом.

Поначалу мы попробуем разрешить имя сервера:

$ nmblookup -B 192.168.1.255 TROUBLE querying TROUBLE on 192.168.1.255 192.168.7.75 TROUBLE

После чего мы попробуем разрешить имя клиента, используя тот же широковещательный адресок.

$ nmblookup -B 192.168.1.255 win-client querying win-client on 192.168.1.255 192.168.7.135 win-client

Если до сего времени все шло отлично, этот тест, вероятнее всего, отработает корректно. Если же результатом будет ошибка, стоит снова поверить соответствие широковещательного адреса на всех машинах.

После чего мы выполним NetBIOS Node Status Lookup, проверим статус узла. На этом шаге делается прямое воззвание к Айпишнику, в каком запрашивается перечень уникальных и групповых NeBIOS имен, зарегистрированных этим хостом. Начнем с запроса к Samba-серверу от Windows-клиента.

C:WINDOWS> nbtstat -A 192.168.7.75
NetBIOS Remote Machine Name Table
Name Type Status ———————————————
TROUBLE UNIQUE TROUBLE UNIQUE TROUBLE UNIQUE ..__MSBROWSE__. GROUP
Registered Registered Registered Registered Registered Registered Registered
LAB LAB LAB
GROUP UNIQUE GROUP
MAC Address = 00-00-00-00-00-00

Можно выполнить те же деяния на Samba-сервере, чтоб собрать информацию о клиенте. Функции для запроса через утилиту nmblookup, в целом, такие же как и в nbtstat.exe.

$ nmblookup -A 192.168.7.135 Looking up status of 192.168.7.135
WIN-CLIENT LAB WIN-CLIENT
- B – B – B

Если некий из этих запросов не производится, следует снова провести проверки сетевого подключения и NetBIOS-интерфейсов, которые мы рассматривали ранее.

Просмотр общих ресурсов с Windows-клиента

Мы уже использовали smbclient для просмотра перечня общих ресурсов. Тут мы проделаем то же самое, только удаленно с Windows-клиента.

Утилита net.exe — это универсальная утилита для работы с CIFS. Эта утилита является эквивалентом Linux-команды smbclient -L. Опиция view позволяет просмотреть общие ресурсы рабочей группы, либо, если указать конкретное имя сервера (к примеру, \TROUBLE), покажет перечень общих ресурсов на нем.

Удаленное подключение к общим ресурсам

По сути, этот шаг является не столько тестом, сколько целью всего процесса. Если мы зашли в консоль с правильным именованием и паролем, то последующая команда подключит диск P: локального клиента к общему ресурсу [public] на сервере TROUBLE.

C:WINDOWS> net use p: \TROUBLEpublic

The command completed successfully.

Чтоб найти, под каким именованием подключаться, можно использовать опцию /user::

C:WINNT>net use \TROUBLEpublic /user:user1

The password or user name is invalid for \TROUBLEpublic.

Type the password for \TROUBLEpublic:

The command completed successfully.

Существует неограниченное количество заморочек, связанных с аутентификацией. Часто они могут быть обнаружены только методом анализа лог-файлов, что будет рассмотрено позднее.

УРОВЕНЬ 4

Сетевое окружение

Решение заморочек с корректной работой Сетевого окружения — очень непростая тема. Вероятнее всего, если вы добрались ранее уровня, а сетевое окружение не работает либо работает неправильно, вам следует снова проверить маску сабсети и широковещательный адресок, и опять повторить все испытания нижних уровней: ошибка возможно кроется там.

УРОВЕНЬ 5

Лог-файлы и анализ трафика

Время от времени корень препядствия трудно найти даже при помощи специализированных исследовательских утилит. Тогда на помощь приходят логи. 1-ые четыре уровня нашей «пирамиды» можно использовать для доказательства корректности исходной установки Samba и решения обычных заморочек. Начиная с 5-ого уровня, начинается решение суровых заморочек. В какой-то момент вы столкнетесь с неувязкой, которая востребует работы с логами.

Лог-файлы Samba

Ниже приведена таблица, в какой описаны уровни детализации логов.

Уровень Описание
0 Критичные ошибки (не удалось открыть файл, разрыв соединения и т.д.)
1 Информация о соединении и сессии
2,4 Отладочная информация для системного администрирования
5,6,7,8,9 Отладочная информация для разработчиков различного уровня детализации
10 Полная отладочная информация для разработчиков

Чтоб выяснить текущий уровень логирования smbd (к примеру, с pid 1234), выполним последующую команду из-под учетной записи root:

root# smbcontrol 1234 debuglevel

Current debug level of PID 1234 is 0

Если мы желаем прирастить уровень логирования до 10, чтоб получить всю вероятную информацию, используем последующую команду:

root# smbcontrol 1234 debug 10

root# smbcontrol 1234 debuglevel

Current debug level of PID 1234 is 10

Последующий вопрос: «Что же делать с логами?»

Вот вам наглядный пример, в каком логи посодействовали решению трудности. Мы пробуем подключиться с Windows-клиента к общему дисковому ресурсу. Но smbd не воспринимает пароль для соединения. Когда мы используем smbclient для теста, мы получаем ошибку:

$ smbclient //TROUBLE/public -U testuser%test

session setup failed: ERRSRV – ERRbadpw (Bad password – name/password pair in a Tree Connect or Session Setup are invalid.)

Мы совсем убеждены, что значение smbpasswd правильно, и пароль — test. Попробуем подключиться снова, добавив

log level = 10 log file = /usr/local/samba/var/log.%m

в секцию [global] файла smb.conf, и мы увидим новые строки в файле log.TROUBLE:

pdb_getsampwnam: search by name: testuser startsmbfilepwent_internal:
opening file /usr/local/samba/private/smbpasswd getsmbfilepwent: returning passwd entry for user root, uid 0
getsmbfilepwent: returning passwd entry for user jerry, uid 786 getsmbfilepwent: returning passwd entry for user guest1, uid 782
getsmbfilepwent: returning passwd entry for user testuser, uid 791 endsmbfilepwent_internal: closed password
pdb_getsampwnam: found by name: testuser build_sam_account: smbpasswd database is corrupt! username testuser
not in unix passwd database! Couldn’t find user ‘testuser’ in passdb.

Последняя строчка и есть ответ на наш вопрос. Samba не смогла отыскать учетную запись testuser. А это вышло, потому что кто-то закомментировал строчку в файле /etc/passwd:

#testuser:x:791:100::/dev/null:/bin/false

После того, как мы уберем символ комментария (#) перед строчкой с учетной записью, попробуем подключиться опять. И сейчас удачно.

$ smbclient //TROUBLE/public -U testuser%test Domain=[LAB] OS=[Unix] Server=[Samba 2.2.2] smb: >

Это всего только один пример. Вывод в логах может быть запутанным, но можно использовать grep, чтоб отыскивать последующие ключевики:

fail
error
unsuccessful
corrupt
unknown

Мониторинг сетевого трафика

Очередной метод отыскать корень трудности — это просматривать содержимое пакетов, ходящих по сети меж сервером и клиентом. Для этого можно использовать такие программы-анализаторы, как Wireshark. С помощью их можно просмотреть и проанализировать в довольно читаемом виде содержимое пакетов.

УРОВЕНЬ 6

Внутренние задачи Samba

Если ничего из вышеприведенного не посодействовало — может быть, вы столкнулись с любым багом Samba. Перечень узнаваемых можно поглядеть на официальном веб-сайте. Чтоб свести к минимуму возможность возникновения подобного рода заморочек, используйте животрепещущую и размеренную версию Samba, также смотрите за выходом исправлений: исправляются разведанные баги довольно стремительно.

Заключение

Итак, мы разобрали методологию поиска и решения заморочек Samba. Препядствия были разнесены по уровням, и каждый уровень находится в зависимости от удачной работоспособности более малого уровня. Снова взглянем на их:

Уровень 1. Сетевое соединение и работоспособный smb.conf.
Уровень 2. Серверное и клиентское ПО.
Уровень 3. Удаленный доступ к ресурсам.
Уровень 4. Сетевое окружение.
Уровень 5. Логи и анализ трафика.
Уровень 6. Внутренние задачи Samba.

Не следует забывать, что, может быть, с вашей неувязкой уже кто-то сталкивался. В данном случае просмотр профильных форумов и других ресурсов может вам сберечь драгоценное время. Не зацикливайтесь на единственно вероятной по вашему воззрению причине. Постарайтесь поглядеть на делему с другой точки зрения. В конце концов решение хоть какой задачи может быть найдено!

Работа выполнена на базе Информационно-вычислительного центра МЭИ.

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.