23.3. Построение одноранговой сети Windows/Linux

Проблема
Анонимный файловый сервер удобен, но еще удобнее одноранговая сеть, в кото рой пользователи могут обмениваться файлами друг с другом напрямую. Вы хо тите, чтобы пользователи Windows и Linux могли делать это без паролей и про чих затруднений.
Решение
На хостах Linux достаточно установить серверные и клиентские компоненты
Samba, а затем настроить общие каталоги, как описано в разделе 23.2.
На хостах Windows необходимо включить общий доступ к файлам, а затем на строить общие каталоги. Пользователи Windows NT/2000 должны активизиро вать «гостевые» учетные записи, чтобы предоставить внешним пользователям до ступ к своим каталогам. Пользователи Windows XP включают общий доступ,
запуская мастера настройки сети. Все компьютеры должны принадлежать к од ной рабочей группе (workgroup в примерах данной главы).
Далее на компьютере с системой Windows открывается окно Сетевое окру жение, в котором производится поиск всех общих ресурсов в локальной сети.
Подключение в одноранговых сетях Samba с компьютеров Linux описано в раз делах 23.17 и 23.18.
Комментарий
Не устанавливайте NetBEUI или поддержку сетей Novell (IPX/SPX), если вы не
уверены в том, что это абсолютно необходимо. Установка этих протоколов сни зит производительность системы.
При загрузке компьютеру необходимо несколько минут, чтобы разослать ин формацию о своих ресурсах. Будьте терпеливы.
См. также
Разделы 23.2, 23.4, 23.17 и 23.18.

Блог начинающего линуксоида.

советы, руководства, инструкции.

Страницы

воскресенье, 4 октября 2015 г.

Настройка локальной сети Linux — Linux и Linux — Windows

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

Общие сведения.

Для создания общих сетевых ресурсов в среде Windows, применяется протокол CIFS (ранее известный как SMB), поддержка которого в UNIX-подобных системах обеспечивается программным обеспечением Samba. Samba работает по протоколам TCP и UDP, соединение шифруется. С помощью Samba возможно обеспечить не только общий доступ к файлам и принтерам, но и, например, построить контроллер домена с поддержкой Active Directory (об этом в следующий раз). С помощью Samba можно открыть общий доступ не только между Windows и Linux, но и между Linux и Linux. Однако есть некоторые ограничения. Во первых, SMB — это «виндовый» протокол, со всеми вытекающими. Он не слишком хорошо интегрируется с UNIX-системами. Не вдаваясь в сложные технические описания, скажу лишь что скорость передачи данных по Samba медленнее, зачастую значительно, она нестабильна, как и загрузка сетевого канала, а также даёт весьма ощутимую нагрузку на процессор. Поэтому если в вашей домашней сети нет Windows-машин, то предпочтительнее использовать протокол сетевой файловой системы — NFS.

Суть работы NFS весьма проста. Удалённый ресурс встраивается в общее дерево файловой системы, и в результате каталог, который находится на файловом сервере или другом компьютере, отображается в вашей системе как локальный, будто находится на диске. NFS работает по протоколу TCP. NFS весьма полезна при создании так называемых тонких клиентов (бездисковые рабочие станции, в которых система загружается по сети). Скорость передачи данных по NFS в 2 раза выше, чем через Samba, загрузка сети равномерная, а нагрузка на центральный процессор минимальная. Однако у NFS есть два недостатка. Первый — довольно фиговая поддержка в Windows (реализуется через подсистему UNIX и отдельное приложение). Второй — отсутствие шифрования (c версии NFSv4, для шифрования может использоваться протокол Kerberos). Тем не менее, для Линуксовой сети, NFS — идеальный вариант.

Внимание: на обеих системах должны быть настроены статические IP адреса.В Windows кликнете правой кнопкой на значке сетевых подключений и выберите «Центр управления сетями и общим доступом», далее «Изменение параметров адаптера», выберите нужный адаптер (вашу сетевую карту) и зайдите в её свойства. Перейдите в пункт «Протокол Интернета версии 4» и выберите «Использовать следующий IP адрес»:

Если ваши компьютеры соединены напрямую, поле «Основной шлюз» можете оставить пустым. Если через роутер — укажите IP адрес роутера (тот, через который осуществляется доступ к его вэб-интерфейсу, обычно 192.168.0.1). В Linux аналогичную операцию можно провести в Network Manager (настройка сетевых подключений, вкладка IPv4):

Если вы используете фаерволл (брандмауэр Windows либо другое аналогичное ПО, а также iptables в Linux или фаерволл в вашем роутере), убедитесь что открыты нужные порты (Для SAMBA: 135, 139, 445/TCP; 137, 138/UDP. Для NFS: 2049/TCP).

Linux => Windows

Представим ситуацию: у вас есть второй компьютер (или файловый сервер), под управлением Ubuntu 14.04, на котором находится большая коллекция ваших видео, фото и так далее, расположенная на отдельном диске, который монтируется в /media/MyDATA. Этот диск нужно расшарить на компьютер под управлением Windows 8.1. Первым делом, установим необходимые пакеты:

sudo apt install samba samba-common smbclient

Теперь необходимо сконфигурировать Самбу. У вас есть два пути: консольный и графический.

Консольный.

Открываем файл /etc/samba/smb.conf:

sudo nano /etc/samba/smb.conf

Полностью удаляем всё содержимое и вписываем такие настройки:

[global]
workgroup = WORKGROUP
netbios name = Ubuntu-PC
server string = Ubuntu PC
map to guest = bad user
guest account = nobody
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192

#Следовать по симлинкам
unix extensions = no
wide links = yes
follow symlinks = yes

log level = 1

# UTF кодировка
unix charset = UTF-8
dos charset = cp1251
store dos attributes = yes

max log size = 10

[MyDATA]
path = /media/MyDATA
writeable = yes
available = yes
public = yes
guest ok = yes
force user = nobody
force group = nobody

В секции global описываются общие параметры: WORKGROUP — имя рабочей группы (должно быть одинаково для всех машин в локальной сети), Ubuntu-PC — имя компьютера, с которого расшариваются каталоги (укажите своё), вход без пароля, гостевой доступ и оптимизации для соединения. В секции MyDATA описывается доступ к диску, смонтированному в /media/MyDATA. При желании вы можете указать доступ к отдельным каталогам на этом диске, аналогичным способом. Сохраните файл и выполните команду:

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

Теперь запустите сервер Samba:

sudo service start smbd

Графический.

Для настройки параметров Samba в графическом интерфейсе, существует 2 замечательные утилиты — system-config-samba (есть только в Ubuntu и производных) и gadmin-samba (есть везде). Эти утилиты представляют собой весь конфиг Самбы, выполненный в графическом режиме. Для Ubuntu установим первую утилиту:

sudo apt install syste-config-samba

Здесь всё предельно понятно и в настройках разберётся любой 🙂

Для других дистрибутивов (например Debian), установите пакет gadmin-samba:

sudo apt install gadmin-samba

После настройки, перезапустите демон Samba. Для Ubuntu:

sudo service restart smbd

sudo systemctl restart smbd.service

Также можно открыть доступ к нужному каталогу из файлового менеджера, открыв свойства каталога:

В Windows необходимо включить сетевое обнаружение. Для этого в центре управления сетями, зайдите в «Изменить дополнительные параметры общего доступа»

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

Linux => Linux

А теперь представим, что у нас есть компьютер с Debian 8 (IP адрес 192.168.0.2), и ноутбук с Ubuntu 14.04 (IP адрес 192.168.0.3). С ноутбука нужно расшарить раздел диска, который смонтирован в /media/DATA (это раздел для торрентов и прочей файлопомойки). Для этого мы используем NFS:

sudo apt install nfs-kernel-server nfs-common rpcbind

Укажем что нужно расшаривать:

sudo nano /etc/exports

/media/DATA — то, что нужно расшарить.
192.168.0.0/255.255.255.0 — только компьютерам в этой подсети будет обеспечен доступ к общему ресурсу (можете указать конкретный IP адрес).
rw — поддержка чтения и записи.
no_root_squash — Позволяет пользователю root (на стороне клиента) иметь доверенный полный доступ к разделу.
no_subtree_check — Если монтируется только часть тома, то сервер будет выполнять проверку принадлежности файла запрошенного клиентом, именно к той части тома, которая примонтирована. Это замедляет передачу данных, по этому зачастую данная опция включена в список параметров.
crossmnt — Этот параметр похож на nohide он дает возможности видеть каталоги смонтированные на основной системе. Таким образом, когда дочерняя файловая система «B» установлена на основной «А», установив crossmnt на «А» имеет тот же эффект, что и установка «nohide» на B.
fsid=0 — NFS-сервер должен быть в состоянии идентифицировать каждую файловую систему, которую экспортирует. Для сервера NFSv4, существует выделенная файловая система, которая является корнем всей экспортируемой файловой системе. fsid = root или fsid = 0 означают одно и то же.

sudo exportfs -a

Далее нужно указать, каким хостам в сети разрешено иметь доступ к серверу:

sudo nano /etc/hosts.allow

Указываем доступ для всех машин, находящихся в подсети 192.168.0.0/255.255.255.0:

nfsd: 192.168.0.0/255.255.255.0
rpcbind: 192.168.0.0/255.255.255.0
mountd: 192.168.0.0/255.255.255.0

Если вы указали в файле exports только IP адрес нужной машины, то соответственно, указывайте его.

Теперь запустите сервис:

sudo service nfs-kernel-server start

На компьютере установите следующие пакеты:

sudo apt install nfs-common rpcbind

Создайте директорию для монтирования общего ресурса:

sudo mkdir /media/Share

Монтирование вручную.

sudo mount -t nfs4 192.168.0.3:/ /media/Share

В результате всё содержимое диска /media/DATA (на ноутбуке) окажется доступным на компьютере в каталоге /media/Share, как если бы эти данные хранились на нём. Для того чтобы ресурс монтировался автоматически после загрузки системы, есть два способа.

Монтирование через fstab.

Файл /etc/fstab содержит в себе информацию о присутствующих файловых системах, точках монтирования и параметрах монтирования. Чтобы ресурс /media/DATA монтировался на ваш компьютер автоматически, добавьте в конец файла /etc/fstab следуюущую строку:

192.168.0.3:/ /media/Share nfs user,rw,noauto 0 0

Опция noauto запрещает автоматическое монтирование во время загрузки, так как сеть может быть недоступна в этот момент. Вместо этого, в файловом менеджере, в левой колонке появится пункт Share, кликнув на который, сетевой ресурс автоматически смонтируется. Однако при таком способе монтирования, есть пара существенных недостатков. Во первых, если в момент выключения компьютера, был открыт какой-либо файл, расположенный на сетевом ресурсе, компьютер откажется выключаться. Во-вторых, такая же ситуация произойдёт в случае пропажи связи между клиентом (компьютером) и сервером (ноутбуком). Для того, чтобы этих проблем не было, существует второй способ монтирования.

Монтирование с помощью AutoFS.

AutoFS — это пакет для обеспечения монтирования съёмных и сетевых накопителей, только при обращении к ним. При отсутствии обращения к сетевому ресурсу или съёмному устройству в течении определённого времени, он автоматически размонтируется, и мгновенно монтируется при первом же обращении к нему. Устанавливаем:

sudo apt install autofs

sudo nano /etc/auto.master

В конец файла добавляем строку:

/mnt /etc/auto.nfs —timeout=60

/mnt — каталог для монтирования сетевого ресурса.
/etc/auto.nfs — путь к файлу, в котором описаны параметры монтирования.
—timeout=60 — время в секундах, после которого произойдёт размонтирование ресурса (можете указать своё).

Сохраняем и переходим к следующему файлу:

sudo nano /etc/auto.nfs

Share -fstype=nfs,rw,noatime,noexec,nosuid,tcp,async,rsize=32768,wsize=32768,intr,nolock,soft,noauto 192.168.0.3:/

Создадим директорию Share в каталоге /mnt, куда будет монтироваться ресурс:

sudo mkdir /mnt/Share

Вот и всё. Теперь в каталоге /mnt/Share, при первом же обращении к нему, будет появляться содержимое удалённого ресурса /media/DATA. Кнопка подключения сетевого диска появится в файловом менеджере.

Перекрестное опыление: управляем Linux из-под Windows, и наоборот

В прошлой статье я обещал рассмотреть механизм удаленного подключения с Windows на серверы под управлением *nix, и наоборот при помощи PowerShell. Обещанного обычно ждут три года, но я успел чуть раньше. Что ж, если хочется с верного макбука управлять гетерогенной инфраструктурой, или наоборот ― с Surface Pro рулить Linux-серверами без всяких putty, ― прошу под кат.

Microsoft Loves Linux

Еще в 2015 году Microsoft торжественно объявила о запуске программы «Microsoft Linux». Сюда вошла как банальная поддержка гостевых *nix-like OS на Hyper-V, так и встроенная в Windows 10 Ubuntu и возможность запуска в Docker продуктов Microsoft, таких как SQL Server.

Компания также опубликовала исходный код PowerShell, что позволило запускать «Ракушку Мощи» не только на Windows. Из-под одноименного аккаунта на Github, помимо исходного кода, выложены и бинарники под большинство современных систем (лицензия MIT).

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

Порой удобно совмещать традиционные консольные команды со вставками PowerShell:

Для подключения к Windows-машинам при помощи PowerShell используется протокол WS-Man. Для GNU\Linux привычен SSH. Так как сегодня становятся универсальными оба протокола, разберем их подробнее.

PowerShell 6.0 под Windows и *nix, пока еще находится в бете. Поэтому не рекомендую без хорошего тестирования применять на боевых серверах описанное ниже.

Магомед не идет к горе

Когда технология удаленного доступа при помощи PowerShell только набирала обороты, единственным универсальным способом подключения к разным системам был протокол WS-Man. Для тестового стенда я взял Windows Server 2016 и Centos 7, для которых и буду настраивать возможность удаленного подключения и выполнения команд при помощи этого протокола.

Для начала установим на Centos свежий PowerShell:

После установки появилась возможность запускать привычные Windows-администратору командлеты. Например, посмотрим версию PS и получим список запущенных процессов командлетами $PSVersionTable и Get-Process:

Работаем в консоли PowerShell на CentOS.

Чтобы подключаться к Linux-машине с консоли Windows, нам понадобится установить и настроить:

• OMI (Open Management Infrastructure) ― адаптация WMI, которую также можно использовать для управления компьютерами с ОС, отличными от Windows;
• PSRP (PowerShell Remoting Protocol) ― библиотека, необходимая для удаленного подключения PowerShell.

Подробно с работой и эволюцией OMI и PSRP можно ознакомиться в отличном материале от Matt Wrock, я же просто установлю OMI командой:

Далее нужно настроить порты и аутентификацию в конфигурационном файле /etc/opt/omi/conf/omiserver.conf, после чего перезапустить сервер командой:

Для упрощения эксперимента я не буду настраивать ни NTLM-аутентификацию, ни Kerberos. Еще и шифрование отключу ― разумеется, в боевой среде делать этого не стоит. Для включения текстовой аутентификации и шифрования на стороне Windows в работе winrm достаточно выполнить следующие команды:

После настройки можно проверить работу OMI из консоли Windows:

Подключаемся к CentOS из cmd.

Теперь проверим работу обратным подключением ― из Linux к Windows:

… а затем с CentOS подключаемся к Windows.

После того, как WMI\OMI заработал, нужно установить и настроить PSRP. К сожалению и вопреки инструкции, бинарник отсутствует. Библиотеку пришлось компилировать, долго и нудно исправляя возникающие ошибки зависимостей:

Теперь мы сможем подключаться с Windows на Linux и наоборот при помощи PowerShell. Начнем с Windows на Linux:

С Windows на Linux.

Аналогичным образом можно провести и обратное подключение.

Invoke-Command можно «натравить» на список компьютеров, и с рабочей станции Windows создать пользователя на всех серверах Linux командой вида:

Надо сказать, что способ не самый удобный и эффективный. Минусов добавляет компиляция библиотек, разнообразные баги ― например, на момент написания статьи PSRP не позволял нормально подключиться из Linux в Windows.

Да и сами разработчики рекомендуют не плясать вокруг WS-Man, а обратиться к проверенному способу ― SSH. Что ж, попробуем и его.

Гора идет к Магомету

На этот раз машина с Windows получит чуть больше специфической подготовки ― нужно установить свежий PowerShell и OpenSSH.

После можно проверить синтаксис командлета New-PSSession. Если все произошло как надо, то командлет, помимо привычного параметра ComputerName, будет поддерживать и HostName.

PowerShell 6.0.0-beta.9 и обновленный синтаксис командлета.

Качаем последний релиз или используем пакет из репозитория Chocolatey. Все это разархивируем в \Program Files\OpenSSH.

В консоли с правами администратора переходим в папку с разархивированным содержимым и запускаем установку командой:

Теперь генерируем ключи:

В тестовой среде мы будем использовать парольную аутентификацию, поэтому стоит убедиться что она включена в файле sshd_config:

Если вы также хотите автоматически запускать PowerShell при подключении по SSH, то в параметре subsystem нужно прописать путь к желаемой версии PS:

Для работы клиента SSH нужно добавить директорию в %PATH% любым удобным способом. Например, таким:

Остается только настроить и запустить службы:

После установки уже можно наслаждаться подключением к серверу Windows по ssh.

C Windows через Putty на Linux, с Linux обратно на Windows по SSH.

На достигнутом останавливаться не будем и перейдем к настройке Linux. При настройке сервера SSH по умолчанию достаточно прописать PowerShell в Subsystem:

Теперь проверим подключение через командлет New-PSSession и Invoke-Command.

Работаем из PowerShell с Linux-сервером.

Теперь подключимся из Linux к Windows:

Работаем из PowerShell с Windows-сервером.

В отличие от WS-Man, SSH настраивается намного проще и работает стабильнее. Да и беспарольное подключение по ключам настраивать привычнее.

В хозяйстве пригодится

С однозначным «советом потребителю» все опять сложно: SSH проще в настройке и стабильнее, но WS-Man использует API и позволяет применять инструменты вроде JEA. На боевых серверах использовать WS-Man я бы не стал однозначно, а вот реализация OpenSSH в Windows как сервера, так и клиента мне понравилась. Для самопальной автоматизации вполне подойдет даже без PowerShell.

В любом случае, границы между Linux и Windows хоть и медленно, но начинают стираться, что безусловно радует.