Файловый сервер без SAMBA. Работа по SSH

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

Если рассматривать офис, в котором установлены только стационарные компьютеры, и работа  за пределами офиса не планируется, в таком случае действительно стоит ограничиться работой по SMB.

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

Работа большинства современных серверных приложений (1С, GroupWare и т.д.) абсолютно спокойно выполняется через веб-интерфейс. С почтой также обычно проблем не бывает. Доступ в Интернет при удаленной работе системного администратора также не вызывает никаких сомнений. Остается единственная проблема - доступ к файлам на файловом сервере.

В качестве альтернативы протоколу SMB, рассмотрим преимущества работы с файловым хранилищем по SSH:

• Только авторизованный доступ.
• Изначально жесткое разделение прав пользователей на доступ.
• Отсутствие разницы в работе пользователя вне зависимости от его местонахождения.
• Возможность авторизации пользователя как по паролю (возможна интеграция с Microsoft AD), так и по ключу.
• Отсутствие необходимости в закупке, настройке и поддержке сервера VPN.
• Отсутствие необходимости в закупке серверной лицензии Microsoft Windows.

Единственный недостаток — данное решение для большинства системных администраторов является непривычным.

Техническая часть
Вначале займемся настройкой сервера.
Создадим папку, в которой и будут размещаться папки общего доступа.
Допустим она будет находится в /home/share
#mkdir /home/share

Далее создадим в ней две подпапки - /public и /sales
#cd /home/share
#mkdir public
#mkdir sales

Соответственно необходимо создать и две группы пользователей на сервере - public и sales
#addgroup public
#addgroup sales

Создадим несколько тестовых пользователей - user1 и user2:
#adduser user1
#adduser user2

Далее создадим пользователю user1 доступ только в public, а user2 - и в public, и в sales.
Для этого введем их в соответствующие группы:
#addgroup user1 public
#addgroup user2 public
#addgroup user2 sales

Настройка пользователей на сервере закончена.
Далее необходимо правильно установить права на папки.
#chown root:public /home/share/public
#chown root:sales /home/share/sales
#chmod 770 /home/share/public
#chmod 770 /home/share/sales

Для того, чтобы был нормальный доступ к файлам в папках, на эти папки нужно еще установить бит SedGID.
#chmod g+ws,o= /home/share/public
#chmod g+ws,o= /home/share/sales

Важно контролировать, чтобы у всех файлов внутри этих каталогов были права 660, а у вложенных каталогов - 770.
Если бы у нас заведомо файлы только создавались, можно было бы обойтись использованием umask.
Однако пользователи периодически копируют из разных источников файлы, у которых уже установлены некие, отличающиеся от необходимых, права.
Для решения этой проблемы используем gamin и fileschanged:
#aptitude install gamin fileschanged

Создадим скрипт, который будет устанавливать права:
#nano /root/share.sh

И запишем в него:
#!/bin/bash
if [ -d "$2" ]; then
chmod 770 "$2"
elif [ -f "$2" ]; then
chmod 660 "$2"
fi

Теперь при помощи fileschanged необходимо данный скрипт выполнить:
#fileschanged -cCfr -x /root/share.sh /home/share &

Сервера время от времени имеют свойство перезагружаться. Для автоматической перезагрузки серверов добавим в файл /etc/rc.local строку:
/usr/bin/fileschanged -cCfr -x /root/share.sh /home/share &

Все работы на сервере закончены.
Настройка и подключение клиентских компьютеров рассмотрена в другой статье - Подключение удаленных каталогов по SSHFS с помощью AutoFS

Дополнение к статье
Как показала практика, использовать gamin слишком непродуктивно. Слишком много ресурсов использует данная программа.
На Celeron 2.6 она использует 25% процессора. Возникла необходимость искать альтернативу. И она была найдена!
Теперь на сервере крутится inotifywait.

Для начала необходимо установить пакет inotify-tools
#aptitude install inotify-tools
Далее в /etc/rc.local добавить строку:
/usr/bin/inotifywait -mr --format '%w%f' -e close_write -e moved_to -e create /home/share | while read file; do /root/share.sh "$file"; done

Важно! Переменную $file необходимо брать в кавычки.
Если этого не сделать, и в пути встретятся имена файлов или каталогов с пробелами - ничего не сработает.
Естественно и скрипт /root/share.sh необходимо изменить.
Теперь он будет выглядеть следующим образом:
#!/bin/bash
if [ -d "$1" ]; then
chmod 770 "$1"
elif [ -f "$1" ]; then
chmod 660 "$1"
fi

Вот теперь действительно все. Нагрузка на процессор сервера значительно снизилась.
inotifywait потребляет порядка 0.5%-1%. На мой взгляд, это вполне допустимо.

Автор статьи:
Якимчук Сергей,
Руководитель отдела технической поддержки IT Stream