Анонимный FTP-сервер Vsftpd на Hp proliant microserver

Настройка ftp сервера VSFTPD

VSFTPD - FTP сервер, с развитыми возможностями аутентификации пользователей, посредством цифровых сертификатов.
Однако, использование цифровых сертификатов - дело хорошее, но требующее тщательного продумывания, поэтому, настроим ftp-сервер без их использования, для простого анонимного обмена файлами.

Установка ftp сервера на микросервере, под Ubuntu 12.04.

$sudo apt-get install vsftpd

Главный конфигурационный файл /etc/vsftpd.conf
Главный конфигурационный файл в системе  Fedora 32: /etc/vsftpd/vsftpd.conf
Файл журнала /var/log/vsftpd.log

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

root@microserver:~# cat /etc/vsftpd.conf

# Конфигурация FTP сервиса микросервера - /etc/vsftpd.conf
# http://gimmor.blogspot.com/2012/09/ftp-vsftpd-hp-proliant-microserver.html
# 13 сентября 2012
# сервер: микросервер

# Особенности: анонимный доступ на чтение и запись

# Для просмотра всех опций ftp-сервера: man 5 vsftpd.conf

# Сервер будет запущен в отдельном(standalone) режиме

listen=YES
listen_ipv6=NO
# По умолчанию, ftp-сервер доступен на всех локальных интерфейсах микросервера
# Чтобы отобрать интерфейсы, на которых будет доступен ftp-сервер, задается опция:
listen_address=192.168.3.1,192.168.5.1
# в нашем случае, ftp-сервер будет работать в локальной сети

# Порт, на котором  ftp-сервер слушает подключения, 21- стандартный порт FTP.
listen_port=21
#
ftp_data_port=20
connect_from_port_20=YES

# Разрешен доступ анонимных пользователей, с известными именами ftp, anonymous
anonymous_enable=YES
# Не требуется пароль для анонимных пользователей
no_anon_password=YES
# Опция ftp_username позволяет задать имя анонимного пользователя
ftp_username=ftp

# Каталог для анонимных пользователей, /srv/ftp по-умолчанию
# каталог должен принадлежать пользователю ftp, иначе соединение закрывается
anon_root=/srv/ftp


#secure_chroot_dir=/var/run/vsftpd/empty


# Опции разрешающие анонимному пользователю, загружать файлы, создавать, удалять каталоги
write_enable=YES
anon_upload_enable=YES
anon_mkdir_write_enable=YES
anon_other_write_enable=YES

# Разрешена выгрузка файлов пользователем
download_enable=YES

ls_recurse_enable=YES

# Права на доступ к загруженным пользователем файлам на ftp сервер (вновь созданным)
anon_umask=0013
file_open_mode=0766
chown_upload_mode=0011

# Разрешить доступ локальным пользователям
local_enable=NO


# Журнал ftp-сервера
vsftpd_log_file=/var/log/vsftpd.log

# Можно перенаправить журнальный вывод в стандартный системный журнал
syslog_enable=NO

# Журналирование команд протокола

log_ftp_protocol=NO

# Регистрация активности(выгрузка/загрузка) пользователей в журнале /var/log/vsftpd.log
xferlog_enable=YES
xferlog_file=/var/log/vsftpd.log

Права на каталог /srv/ftp и его файлы

Чтобы было можно создавать,удалять,изменять каталоги в клиенте ftp, бит исполнения (x) должен быть установлен для каталога anon_root, для пользователя, группы, для всех.

$ ls -l /srv
 dr-xrwxr-x 3 ftp ftp 4096 мая   27 19:14 ftp



Также, если возникает ошибка доступа (невозможно зайти):

500 OOPS: vsftpd: refusing to run with writable root inside chroot()
Login failed.
421 Service not available, remote server has closed connection
ftp>

Это особенность сервера vsftpd, ограничивающего доступ к анонимному корню (папке /srv/ftp или /var/ftp).
Для исправления, надо убрать для всех  права на запись в каталог anon_root (/srv/ftp), а если и доступ локальных пользователей то и для local_root.

Было:
# ls - l /srv/ftp
итого 4
drwxrwxrwx. 3 ftp ftp 4096 мая 16 17:27 ftp

Станет:

# chmod a-w /srv/ftp

Стало:
# ls /srv -l
итого 4
dr-xr-xr-x. 3 ftp ftp 4096 мая 16 17:27 ftp

Чтобы можно было читать (загружать c ftp, Download) файлы, у любого файла должны быть права на чтения для пользователя, группы, для всех.
# ls -l /srv/ftp/test
-rw-r--r-- 1 ftp ftp 528881 мая   27 19:45 IMG_20140525_004452.jpg

Для задания прав на загружаемый файл есть основная опция, file_open_mode, задающая права на доступ к созданному (загруженному)файлу.
Затем к этому значению, применяются маски anon_umask и chown_upload_mode.

Пример - будут созданы файлы, загруженные на ftp (Upload), файлы с правами на чтение и запись, при этом будет сброшена возможность записи для всех остальных, но пользователь (ftp) и его группа (ftp) смогут читать и писать в файл. Также для всех будет сброшена исполняемость файла, т.е. файлы
anon_umask=0113
file_open_mode=0666
chown_upload_mode=0111

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

Например: 07 = b111 - rwx, 06 = b110 - rw-, 01 = b001 - --x

Часто используется значение 0644 - которое разрешает на запись и чтение, только пользователю, а всем остальным - только чтение.

Чтобы анонимный пользователь мог создавать папку (например, копировать целую папку на ftp-сервер), бит исполнения для вновь создаваемой папки должен быть. Т.е. маска file_open_mode = 0766
Тогда
anon_umask=0013
file_open_mode=0766
chown_upload_mode=0011


Есть некоторый баг, что невозможно загрузить в корневой каталог ftp-сервера какой-либо файл. Выручает в этом случае, предварительное создание любого каталога на сервере.

# mkdir /srv/ftp/testdir
# chown ftp:ftp /srv/ftp/testdir

Запуск сервера в standalone режиме

из под пользователя root
# /usr/sbin/vsftpd

Запуск сервера в системе с Systemd

# systemctl start vsftpd.service

# systemctl status vsftpd.service
● vsftpd.service - Vsftpd ftp daemon
     Loaded: loaded (/usr/lib/systemd/system/vsftpd.service; disabled; vendor preset: disabled)
     Active: active (running) since Sun 2012-05-17 19:22:54 MSK; 5s ago
    Process: 8710 ExecStart=/usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf (code=exited, status=0/SUCCESS)
   Main PID: 8711 (vsftpd)
      Tasks: 1 (limit: 9171)
     Memory: 540.0K
        CPU: 6ms
     CGroup: /system.slice/vsftpd.service
             └─8711 /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf

Для постоянного запуска при перезагрузке системы:

# systemctl enable --now vsftpd
Created symlink /etc/systemd/system/multi-user.target.wants/vsftpd.service → /usr/lib/systemd/system/vsftpd.service.

Проблемы доступа, вызванные подсистемой SELinux

Быстрый способ оценить, влияют ли политики безопасности на проблему доступа к ftp-серверу vsftpd - временно перевести подсистему SELinux в нестрогий (permissive) режим наблюдения и регистрации.

# setenforce 0

# sestatus

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      32

Если после этого  дело пошло, тогда возможно подкорректировать политики.

Посмотреть политики относящиеся к ftpd:

# sestatus -b | grep "ftpd"

ftpd_anon_write                             on

ftpd_connect_all_unreserved                 on

ftpd_connect_db                             off

ftpd_full_access                            on

ftpd_use_cifs                               off

ftpd_use_fusefs                             off

ftpd_use_nfs                                off

ftpd_use_passive_mode                       on

Включаются эти переменные так:

# setsebool -P ftpd_anon_write on

# setsebool -P ftpd_full_access on

# setsebool -P ftpd_use_passive_mode on

Также можно посмотреть контекст безопасности для anon_root:

# ls --context /srv -l

итого 4

dr-xr-xr-x. 3 ftp ftp unconfined_u:object_r:public_content_t:s0 4096 мая 16 17:27 ftp

public_content_t - контекст на чтение

public_content_rw_t - контекст на чтение и запись

Сменить контекст (рекурсивно на вложенные каталоги) можно так:

# semanage fcontext -a -t public_content_rw_t "/srv/ftp"

# restorecon -F -R -v /srv/ftp

Relabeled /srv/ftp from unconfined_u:object_r:public_content_t:s0 to system_u:object_r:public_content_rw_t:s0

Relabeled /srv/ftp/upload from unconfined_u:object_r:public_content_t:s0 to system_u:object_r:public_content_rw_t:s0

Проблемы доступа вызванные настройкой Firewall

На примере дистрибутива Fedora 32 Workstation.

Быстро оценить влияние настроек брэндмауэра на доступ к серверу fsvtpd - временно отключить встроенный Firewalld.

# systemctl stop firewalld.service

Если влияет. включаем для отладки:

# systemctl start firewalld.service

Основная команда управления firewall-cmd.

Зоны, сервисы, порты.

# firewall-cmd --get-default-zone
FedoraWorkstation

# firewall-cmd --info-zone=FedoraWorkstation

FedoraWorkstation (active)
  target: default
  icmp-block-inversion: no
  interfaces: wlp4s0b1
  sources:
  services: dhcpv6-client ftp mdns samba-client ssh
  ports: 1025-65535/udp 1025-65535/tcp 40000-40010/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Добавим описание сервиса FTP в зону по умолчанию:

# firewall-cmd --add-service=ftp --permanent
# firewall-cmd --service=ftp --add-port=21/tcp --permanent


Просмотрим, правильность описания FTP-сервера:
# firewall-cmd --info-service=ftp

Анонимный доступ к серверу пользователя ftp

$ ftp://ftp@microserver/
$ ftp microserver.local

ftp@ - это указывает пользователя

$ ftp
ftp> open microserver.local

Локальные (зарегистрированые) пользователи и их доступ к FTP серверу

Для локальных пользователей есть свои опции:
local_enable=YES
local_root=/home
chroot_local_user=YES
# Маска доступности файла, другим пользователям. Здесь - недоступна всем, но доступна на чтение группе зарегистрировавшегося пользователя
local_umask=0013

После этого, локальные, системные пользователи из /etc/passwd будут попадать в /home
Выхода за пределы /home у них не будет, но вот друг друга просматривать будут, что не есть хорошо.

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

Публикация ftp-сервера посредством avahi

При установленном на сервере пакете avahi-daemon, возможно публикация сервиса ftp, посредством mDNS.
Для этого создается файл, в папке /etc/avahi/services/ следующего содержания:

root@microserver:~# cat /etc/avahi/services/ftp.service 

<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<!-- Публикация FTP сервера
     8 сентября 2012 
     сервер: микросервер
-->
    <service-group>
    <name>Microserver File Transfer</name>
    <service>
    <type>_ftp._tcp</type>
    <port>21</port>
    </service>
    </service-group>

Возможно потребуется перезапуск демона Avahi:

# systemctl restart avahi-daemon

После этого, сервис доступен для просмотра с помощью Nautilus. Ссылки на ftp-сервер микросервера появляются во всех программах поддерживающих mDNS (Nautilus, Web-Epiphany)

Просмотр опубликованного сервиса FTP через Nautilus

Вход на ftp-сервер настроен для анонимного использования (для быстрого доступа).

Вход на FTP сервер через Nautilus

Настройка разрешения доменных имен в Ubuntu. ping hostname unknown host

Правильная настройка системы разрешения имен в Ubuntu

Разрешение имен - преобразование имени компьютера, воспринимаемого человеком, в цифровой адрес компьютера.
Постоянно возникающая проблема разрешения  имен в Ubuntu, из-за неполной конфигурации "из коробки", доставляет массу неудобств при взаимодействии в сетях, в частности с микросервером, с windows компьютерами.
1. Невозможность сделать "пинг" по имени хоста.
root@microserver#ping mir
ping: unknown host mir

root@mir: ping microserver
ping: unknown host microserver

2. Трудности просмотра через графические программы (Nautilus). Требуется указывать ip-адрес, что влечёт за собой его предварительное выяснение.
3. Неработающий просмотр сети в Nautilus.

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

Что можно получить при правильной настройке разрешения имен в Ubuntu 12.04 микросервера

Автоматическую конфигурацию клиентов сети, проводных и беспроводных, с корректным заданием шлюза в сеть интернет.
Корректно работающий просмотр сетей в Windows и Ubuntu.
Автоматическую доступность всех компьютеров и устройств по их именам. по NetBIOS-именам в домашней локальной сети, домашней беспроводной сети.
Работающий кэширующий DNS сервер в домашней сети
Дополнительные возможности локальных соединений (link-local) точка-точка (ad-hoc) проводных клиентов без сервера в сети.
Сервисы обмена файлами, сетевые принтеры.
Автоматически публикуемые сервисы mDNS, что на пользовательском уровне обеспечивает удобство в разных программах, таких как eKiga, Nautilus.
Например:

Навигатор Avahi -SSH. Список устройств с доступом SSH

Броузер Nautilus видит опубликованные сервисы Avahi

Имя компьютера - Hostname

Имя компьютера(hostname) задается в файле /etc/hostname


Процесс разрешения имен в Ubuntu - name resolve order

Файл /etc/nssswitch.conf конфигурирует способ, которым следуют стандартные библиотечные процедуры разрешения имен, будь то  имена компьютеров (hosts), пользователей (users), группы (groups).
Каждая база данных имен может иметь разнообразные источники - текстовые файлы (/etc/hosts), локальные базы данных, DNS, NIS, WINS, LDAP и пр.
Так сказать - исторические наслоения способов разрешения имен.


Посмотрим файл: /etc/nsswitch.conf подсистемы Name service switch
root@microserver#cat /etc/nsswitch.conf

При установленном сервере mDNS (avahi-daemon)
...
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

...

Минимальный порядок опроса:
...
hosts: files dns
...

Для разрешения windows-имен компьютеров:

...
hosts: files wins dns 
...


Первое простейшее решение - /etc/hosts

Простой текстовый файл /etc/hosts сопоставляющий имя компьютера (hostname) и ip-адрес. Аналог листка бумаги с записанными ip-адресами и именем компьютера.
Если на микросервере внести запись в /etc/hosts и на настольном компьютере проделать тоже самое, то проблема решиться. Вот выдержка из файлов:

root@microserver#cat /etc/hosts
...
192.168.3.8 mir
...

root@mir#cat /etc/hosts

...
192.168.3.1 microserver
...

После этого, пинги по имени компьютера проходят в обе стороны.

root@microserver#ping mir

PING mir (192.168.3.8) 56(84) bytes of data.
64 bytes from mir (192.168.3.8): icmp_req=1 ttl=64 time=0.158 ms

...

root@mir: ping microserver

PING microserver (192.168.3.1) 56(84) bytes of data.

64 bytes from microserver (192.168.3.1): icmp_req=1 ttl=64 time=0.299 ms

...

Главный недостаток этого способа - это ip-адрес, который может меняться при каждой загрузке, если настроено динамическое получение, посредством dhcp. Исправляется это выделением постоянного ip-адреса настольному компьютеру на сервере dhcp, с помощью директивы host (dhcp-host) в конфигурационном файле.
Второй недостаток в том, что при увеличении сети, для нормального разрешения имен, надо на каждом компьютере добавлять информацию о каждом компьютере сети, что весьма трудоемко и чревато пропусками.
Что и ограничивает применение этого способа в небольших одноранговых сетях со статической ip-адресацией и в тестовых условиях недоступности динамических сервисов.

Конфигурация без усилий. Avahi - ZeroConf - mDNS - .local

Avahi - свободная реализация разделов "DNS Service Discovery" и  "Multicast DNS" спецификации "Zeroconf Networking".
Multicast DNS (mDNS) - децентрализованная широковещательная доменная система имен. Была разработана в компании Apple, под кодовым именем Bonjour. Предназначена для автоматического конфигурирования сетевого интерфейса при соединениях без выделенного сервера, т.н. link-local. Например, соединение двух компьютеров посредством ehternet-интерфейса, простым ethernet-проводом, в результате произойдет автоконфигурация интерфейсов и компьютеры будут иметь dns имена вида host.local. Использование этой технологии позволит обойтись без ручного вмешательства в сетевые настройки.

Демон mDNS отвечает на порту 5353 на широковещательные сообщения по адресу  224.0.0.251. Если при установленном и настроенном демоне avahi-daemon, команды ping mir.local или microserver.local не работают, то возможно проблема в настройках брендмауэра.

Домен .local является доменом по умолчанию, для mDNS.

В настольной Ubuntu сервис avahi устанавливается по умолчанию и работает. Настольный компьютер отзывается по адресу: mir.local с любого компьютера оборудованного avahi.

В серверной версии Ubuntu требуется установка пакета avahi-daemon.
root@microserver# apt-get install avahi-daemon
После установки, микросервер также становиться доступным по адресу: microserver.local

Есть конфигурационный файл: /etc/default/avahi-daemon, но настроек в нём нет.
Основной конфигурационный файл: /etc/avahi/avahi-daemon.conf
Также доступны: /etc/avahi/hosts и папка для статически определимых сервисов /etc/avahi/services/

Для быстрой публикации сервисов роутеров и пр. оборудования, без поддержки avahi, надо создать xml-файл вида в папке /etc/avahi/services/.


root@microserver#cat /etc/avahi/services/bigpond.service

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">

<service-group>
  <name replace-wildcards="yes">Bigpond router</name>
  <service>
    <type>_ssh._tcp</type>
    <host-name>bigpond.local</host-name>
    <port>22</port>
  </service>
  <service>
    <type>_http._tcp</type>
    <host-name>bigpond.local</host-name>
    <port>80</port>
  </service>
</service-group>

В данном случае, определены предоставляемые сервисы роутером Bigpond, т.к. он сам не может об этом рассказать. Также для роутера определено статически имя в домене .local в файле: /etc/avahi/hosts

root@microserver# cat /etc/avahi/hosts

10.0.0.138 bigpond.local

После этого роутер доступен по адресу bigpond.local. Особенность роутера bigpond в том, что он не имеет hostname.

Публикация разнообразных сервисов, посредством avahi позволяет домашней сети приобрести удобства управления разнообразным оборудованием, потому что обычно все сетевые устройства имеют тот или иной интерфейс настройки и знать о них в одном месте (avahi-discovery и т.п.) очень удобно.

В моих условиях, демон avahi-daemon обязателен к установке, т.к. это резко упрощает взаимодействие между компьютерами.

Повышается удобство работы по протоколу ssh - ssh microserver.local, что часто избавляет от выяснения текущего ip-адреса и через какой интерфейс идёт подключение к микросерверу. А интерфейсом может быть много и на всех на них работает сервис mDNS.

Единственный недостаток - это продолжающаяся недоступность компьютеров по именам(hostname). ping mir & ping microserver - всё ещё не работают "из коробки".

И эту проблему может автоматически решить DNS-сервер в локальной домашней сети.

Централизованная система доменных имен DNS - bind9

Domain Name Service (DNS) - сервис сети Интернет, отображающий (преобразующий) ip-адреса в доменные имена (также и в полностью уточнённые доменные имена FQDN) и обратно.
Микросервер с установленным сервисом DNS выступает в роли сервера имен (name server).

Если объяснить просто, то DNS сервер, это программа ведения списка имен компьютеров, с возможностью обращения к нему через локальную (глобальную) сеть по стандартному протоколу. В частности, список имен (база данных имен), доступен по протоколу UDP на порту 53. Обращаясь с ip-адресом, можно получить  имя компьютера и наоборот.

Наиболее известный сервер DNS - BIND (Berkley Internet Naming Daemon).
Установка сервиса DNS bind9 и сопутствующих утилит.

root@microserver#apt-get install bind9

root@microserver#apt-get install dnsutils

Конфигурационные файлы BIND:
/etc/bind/named.conf

/etc/bind/named.conf.options

/etc/bind/named.conf.local

На сервере BIND существует возможность динамического обновления доменной зоны, информацией поставляемой DHCP сервером, о именах подключенных клиентов, что дает искомую возможность доступности по hostname.

Однако, конфигурацию BIND отложим на потом, т.к. есть более быстрый способ - DNSMasq.


DNSMasq - альтернатива связке BIND & DHCPd

DNSmasq - легкий DNS,DHCP,TFTP сервер, применим в небольших домашних сетях.
Возможности сервера позволяют автоматически вносить в список имен DNS, имена компьютеров обращающихся по протоколу DHCP. Это обеспечивает доступность нового компьютера всем компьютерам локальной сети по имени вида: mir, mir.home.


Один конфигурационный файл /etc/dnsmasq.conf

Установка сервера dnsmasq
root@microserver# apt-get install dnsmasq

Для того, чтобы новый сервер dnsmasq не конфликтовал с dhcpd сервером, тот надо остановить и исключить из автозагрузки, что можно сделать в файле: /etc/default/isc-dhcpd-server. Либо деинсталлировать, что менее полезно. Также, при использовании виртуализации, сервер dnsmasq используется в качестве dns-сервера для виртуальных машин и может вызывать конфликт с новой копией.


Остановка и запуск dnsmasq-сервера:
root@microserver#stop dnsmasq
root@microserver#start dnsmasq

Минимальная настройка конфигурации DNSMasq для микросервера:

root@microserver#nano /etc/dnsmasq.conf
# Конфигурация микросервера
# сервер: микросервер
# Определим интерфейсы на которых будет работать сервис DNS,DHCP 
# проводная сеть home (eth0)
interface=home
# беспроводная сеть ap (wlan0)
interface=ap

#Определим домен для локальной сети domain=home

# Определим диапазон выделяемых адресов для проводных клиентов
dhcp-range=192.168.3.11-192.168.3.111,12h
# Определим диапазон выделяемых адресов для беспроводных клиентов
dhcp-range=192.168.5.11-192.168.5.111,12h
no-hosts
# Определим конфигурацию для коммутатора cisco, заменить нули на нормальный MAC-адрес
dhcp-host=00:00:00:00:00:00, 192.168.3.2

Клиентский компьютер получивший настройки от микросервера:

Сетевые настройки проводной сети home

Видно, что маршрут по-умолчанию проходит через микросервер (192.168.3.1). DNS-сервер, разрешающий имена в адреса, также микросервер. Однако, маршрут по-умолчанию может быть скорректирован следующими настройками:

Окно "Маршруты"

Если опцию "Игнорировать автоматически полученные маршруты" отметить, то маршрут по-умолчанию не будет перенесен в таблицу маршрутов и команда ip route не покажет строку вида:
default via 192.168.3.1 dev home  proto static

После настройки имеет смысл провести ряд тестов:
С микросервера:
root@microserver# ping mir
root@microserver# ping cisco
С настольного компьютера:
i@mir$ ping microserver
i@mir$ ping cisco

NetBIOS Name server - NMBD

NMBD сервер имен для SMB/CIFS клиентов (обычно Windows компьютеры). NMBD отвечает на запросы "NetBIOS over IP", задаваемые клиентами Samba, SMB/CIFS такими как Windows Vista, Windows 7.
NetBIOS over IP - специальная адаптация раннего протокола NetBIOS к сетям TCP/IP.
Протокол является обеспечивающим участником процесса "Сетевое окружение" в Windows, со стороны микросервера.

NMBD слушает такие широковещательные запросы на порту 137 по протоколу UDP и если встречает в запросе собственное NetBIOS-имя, то возвращает IP-адрес компьютера, на котором запущен. По умолчанию, NetBIOS имя компьютера совпадает с hostname, но может быть изменено в конфигурации smb.conf.
NetBIOS микросервера = microserver
Также могут быть добавлены дополнительные имена NetBIOS к компьютеру. Для чего это может быть понадобиться?

В многосетевых компьютерах NMBD демон запускается на каждом интерфейсе и по идее возвращает IP-адрес интерфейса.

NMBD следует порядку разрешения NetBIOS имен, указанному в конфигурации smb.conf, также и с привлечением файл /etc/samba/lmhosts.

Файл /etc/samba/lmhosts - подобен файлу /etc/hosts, но только для имен NetBIOS.
Синтаксис текстового файла lmhosts можно просмотреть подробно в man lmhosts, но для понимания достаточно:
192.168.3.1 MICROSERVER

Файл lmhosts может быть использован для указание NetBIOS имени различных статических устройств, присутствие которых в сети Windows желательно, но они сами не могут конфигурировать свое NetBIOS имя (отсутствующий nmbd-демон) и разумеется для тестирования протокола Samba.

Действие  NMBD ограничивается сегментом сети, т.к. протокол широковещательный (multicast).


WINS - Windows Internet Name Service

NMBD может быть настроен как WINS сервер (Windows Internet Name Service) и как WINS proxy.

Преимущества WINS сервера в том, что этот сервер поддерживает динамическую базу данных NetBIOS-имен компьютеров, которые сами и регистрируют свои имена на WINS сервере, также поддерживает уникальность NetBIOS имен в локальной сети.

Рекомендуется использовать в сетях, состоящих из более чем одного сегмента (наш случай), что позволяет при правильно настроенной IP-маршрутизации, просматривать компьютеры другой подсети.


Функциональность WINS сервера запускается указанием директивы wins support = yes в конфигурационном файле /etc/samba/smb.conf. База имен WINS сервера хранится в файле /var/locks/wins.dat.

Присутствует опция wins hook, позволяющая организовать связь посредством внешней программы, для обновления DNS, при появлении новой записи в базе имен WINS.

Опция wins server более подходит для клиентской настройки Samba (например на компьютере mir). Указывает, сервер wins.

Указание о том, на каком сервере регистрировать свое имя, клиентский компьютер может получить при динамической конфигурации по протоколу DHCP, для этого в используются опции в /etc/dhcp/dhcpd.conf (при использовании isc-dhcp-server), на пример для микросервера:
...

option netbios-name-servers 192.168.3.1;
...
при использовании сервера DNSMasq в качестве DHCP:
...
dhcp-option=44,192.168.3.1
dhcp-option=44,192.168.5.1
dhcp-option=46,8
...
т.к. используется 2 интерфейса (home & ap). Опция dhcp-option=46,8  задает способ запроса NetBIOS имен, в данном случае - гибридный - через WINS-сервер и затем широковещательный.

Возможные значения опция 46:
1.B-node (Broadcast): Разрешение имен с помощью широковещательных запросов, WINS не используется.
2. P-node (Peer): Используется только WINS.
4. M-node (Mixed): Смешанный тип, сначала используется широковещательный запрос, затем в случае неудачи - WINS
8. H-node (Hybrid): WINS, а затем широковещательный запрос.

Вот вывод на стороне клиента, откуда видно что получен адрес wins сервера:

i@mir$ cat /var/log/syslog 

Sep  4 11:03:34 mir dhclient: DHCPACK of 192.168.3.80 from 192.168.3.1
Sep  4 11:03:34 mir dhclient: bound to 192.168.3.80 -- renewal in 20410 seconds.
Sep  4 11:03:34 mir NetworkManager[1237]: <info> (home): DHCPv4 state changed preinit -> reboot
Sep  4 11:03:34 mir NetworkManager[1237]: <info> Activation (home) Stage 4 of 5 (IP4 Configure Get) scheduled...
Sep  4 11:03:34 mir NetworkManager[1237]: <info> Activation (home) Stage 4 of 5 (IP4 Configure Get) started...
Sep  4 11:03:34 mir NetworkManager[1237]: <info>   address 192.168.3.80
Sep  4 11:03:34 mir NetworkManager[1237]: <info>   prefix 24 (255.255.255.0)
Sep  4 11:03:34 mir NetworkManager[1237]: <info>   gateway 192.168.3.1
Sep  4 11:03:34 mir NetworkManager[1237]: <info>   hostname 'mir'
Sep  4 11:03:34 mir NetworkManager[1237]: <info>   nameserver '192.168.3.1'
Sep  4 11:03:34 mir NetworkManager[1237]: <info>   domain name 'home'
Sep  4 11:03:34 mir NetworkManager[1237]: <info>   wins '192.168.5.1'
Sep  4 11:03:34 mir NetworkManager[1237]: <info> Activation (home) Stage 5 of 5 (IP Configure Commit) started...

...

А вот воспользуется ли какой-либо демон этой полученной информацией? Samba клиент по идее должен обновить опцию wins servers, но не факт. Ключевое слово по теме: dhcpcd-hook-samba. И да, в Ubuntu 12.04 эти изменения не вносятся, что и показывает содержимое клиентской конфигурации Samba:
i@mir$ cat /etc/samba/smb.conf | grep wins

Для исправления данной оплошности, надо сделать несколько изменений в клиентской конфигурации.
Существуют автоматически вызываемые скрипты, который выполняются, когда dhclient завершает работу, располагаются они в /etc/dhcp/dhclient-exit-hooks.d/. Там можно обнаружить скрипт обновления времени, например.

Достаточно создать скрипт,в этой папке, который будет автоматически редактировать файл /etc/samba/smb.conf на клиенте и вносить сведения о новом сервере wins:

Содержимое скрипта /etc/dhcp/dhclient-exit-hooks.d/smb-wins-update
i@mir$ cat /etc/dhcp/dhclient-exit-hooks.d/smb-wins-update

#!/bin/bash 
/usr/bin/sed 's/\(wins server = \)\([0-9][\.0-9]*\)/\1'$new_netbios_name_servers'/' </etc/samba/smb.conf >/tmp/smb.temp 
cp /tmp/smb.temp /etc/samba/smb.conf 


Незабываем сделать скрипт исполняемым:
i@mir$ chmod +x /etc/dhcp/dhclient-exit-hooks.d/smb-wins-update


Проверка - простым просмотром файла /etc/samba/smb.conf на клиенте, после подключения.


WINBIND

WINBIND демон (winbindd)  для разрешения имен с помощью Windows NT серверов, а также информации о пользователях и группах. Входит в пакет Samba.

Winbind используется совместно с Name Service Switch (переключатель-диспетчер служб имен).
В файле /etc/nsswitch.conf можно указать:
hosts: files dns wins
и если имя не удалось разрешить стандартными средствами linux, то будет использован wins сервер.
А вот какой WINS сервер будет использован зависит от настроек сети Windows.


Конфигурация windbind сервера выполняется в файле /etc/samba/smb.conf


Для домашней сети, использование winbind - избыточно и этот сервис можно деактивировать. В больших сетях, управляемых доменной политикой, winbind поможет подключить микросервер к Active Directory и позволит пользователям зарегистрированным в домене получать доступ к ресурсам микросервера под своими именами.

Воспользуемся командой net (man net). Видим, что в домашней сети не обнаружено доменов Windows:

root@microserver# net ads info
ads_connect: No logon servers
ads_connect: No logon servers
Didn't find the ldap server!

Проверить наличие WINS сервера в локальной сети:

i@mir$ wbinfo -p
Ping to winbindd succeeded

При запущенному сервере WINBIND, работают команды разрешения имен на микросервере:
root@microserver# wbinfo -N MICROSERVER
root@microserver# wbinfo -N MIR
При остановленном сервере WINBIND не работают:
root@microserver# wbinfo -N MICROSERVER

failed to call wbcResolveWinsByName: WBC_ERR_WINBIND_NOT_AVAILABLE
Could not lookup WINS by name MICROSERVER

Команда smbclient не зависит от работы winbind и можно просмотреть ресурсы микросервера: 


root@microserver# smbclient -N -L MICROSERVER


Anonymous login successful
Domain=[HOME] OS=[Unix] Server=[Samba 3.6.3]

Sharename       Type      Comment
---------       ----      -------
IPC$            IPC       IPC Service (hp proliant microserver)
avoska          Disk      авоська для обмена
Anonymous login successful
Domain=[HOME] OS=[Unix] Server=[Samba 3.6.3]

Server               Comment
---------            -------
MICROSERVER          hp proliant microserver

Workgroup            Master
---------            -------
HOME                 MICROSERVER

Замеченные проблемы
Редактирование файла /etc/nsswitch.conf может повлечь за собой недоступность компьютеров по имени, а также неявную неработоспособность многих программ.
Существует проблема взаимодействия домена .local системы mDNS и домена .local системы обычной DNS.
При входе через ssh (ssh microserver) выдается сообщение о подмене хоста (DNS spoofing).

Ресурсы

https://help.ubuntu.com/community/HowToZeroconf
http://0pointer.de/lennart/projects/nss-mdns/
Обзор службы WINS. http://technet.microsoft.com/ru-ru/library/cc725802(v=ws.10).aspx
DHCP options. http://www.opennet.ru/man.shtml?topic=dhcp-options&category=5&russian=0
Настройка взаимодействия Linux с Windows. Samba. http://pm4u.narod.ru/samba.htm
Порты протокола TCP/IP, используемые операционной системой Windows NT. http://support.microsoft.com/kb/150543/ru