Файловый сервер без 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

Какие есть альтернативы Samba для подключения сетевого диска вне локальной сети?

Имеется домашний сервер с белым IP на Ubuntu Server 20, на нем подняты Samba и FTP, прикручен nginx. Подключение гигабит.
Хочется сделать сетевую шару доступной клиентам на Windows через Интернет в виде сетевого диска, после некоторых раздумий пришел к следующим вариантам:
1) Пробросить порт Samba напрямую в Интернет — плохой вариант, небезопасно.
2) Поднять VPN сервер и запускать клиентов в Samba через VPN — приемлемый вариант, безопасно.
Оба варианта выше предварительно не нравятся, потому что после непродолжительного гугления было найдено несколько сообщений о том, что Samba плохо переносит соединения с задержкой, и есть предположение, что пинг у такого подключения будет не меньше 10, если не >40. Не знаю, насколько такая цифра критична, конкретики не было.

3) Поднять webdav на nginx — плохой (?) вариант, судя по тем же результатам поиска будет медленнее Samba.
4) NFS — давние эксперименты с NFS закончились провалом — нормально шара работала только в локальной сети, но не нужна при наличии Samba и отсутствии Mac. NFS вообще работает\имеет смысл не в локальной сети?

Требование одно: подключение клиенту Windows в виде сетевой шары, то есть network drive, с возможностью не только скачивать, загружать и удалять файлы (FTP), но и открывать их напрямую с диска. Мелких файлов не ожидается вообще, скорее всего они будут не меньше 10 гигабайт. Желательно, конечно, выжать из гигабита максимум. Клиенты будут доверенные, поэтому вопрос безопасности стоит только в плоскости уязвимостей (привет тухлым версиям Samba).

Вопроса два:
1) Какой из этих вариантов будет работать быстрее всего?
2) Может быть, я упускаю еще какие-то решения?

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

Какие есть альтернативы Samba для подключения сетевого диска вне локальной сети?

Имеется домашний сервер с белым IP на Ubuntu Server 20, на нем подняты Samba и FTP, прикручен nginx. Подключение гигабит.
Хочется сделать сетевую шару доступной клиентам на Windows через Интернет в виде сетевого диска, после некоторых раздумий пришел к следующим вариантам:
1) Пробросить порт Samba напрямую в Интернет — плохой вариант, небезопасно.
2) Поднять VPN сервер и запускать клиентов в Samba через VPN — приемлемый вариант, безопасно.
Оба варианта выше предварительно не нравятся, потому что после непродолжительного гугления было найдено несколько сообщений о том, что Samba плохо переносит соединения с задержкой, и есть предположение, что пинг у такого подключения будет не меньше 10, если не >40. Не знаю, насколько такая цифра критична, конкретики не было.

3) Поднять webdav на nginx — плохой (?) вариант, судя по тем же результатам поиска будет медленнее Samba.
4) NFS — давние эксперименты с NFS закончились провалом — нормально шара работала только в локальной сети, но не нужна при наличии Samba и отсутствии Mac. NFS вообще работает\имеет смысл не в локальной сети?

Требование одно: подключение клиенту Windows в виде сетевой шары, то есть network drive, с возможностью не только скачивать, загружать и удалять файлы (FTP), но и открывать их напрямую с диска. Мелких файлов не ожидается вообще, скорее всего они будут не меньше 10 гигабайт. Желательно, конечно, выжать из гигабита максимум. Клиенты будут доверенные, поэтому вопрос безопасности стоит только в плоскости уязвимостей (привет тухлым версиям Samba).

Вопроса два:
1) Какой из этих вариантов будет работать быстрее всего?
2) Может быть, я упускаю еще какие-то решения?

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

Samba Alternatives

#1 Univention Corporate Server

Univention Corporate Server is an efficient and highly advanced IT system that integrates the open-source software to make the networking work in the largest enterprises simple and easy. It is the perfect solution for those who want to get the solutions of the primary MS Windows server.

In addition to integrating the features of MS Windows Server, Univention Corporate Server has owned sets of features as well that are much time more than that of MS Windows Server.

Univention Corporate Server is mainly known for its best management and cost-efficient operating system. It delivers the best possibilities and options to the users for the administration of server applications and even the whole IT system in a more systemized way.

Univention Corporate Server primarily designed for the virtualized IT environment and those who have to manage the entire infrastructure of the IT department regardless of whether the IT administration is using Mac, Linux, Windows, or any other operating system.

The standardized integrated management system of Univention Corporate Server make the users able to administer their servers from different locations across the globe by controlling these from the easy to use the web interface of the Univention Corporate Server. The best about Univention Corporate Server is that it can be installed on any virtual machine or ISO as well and can be started even in the cloud too.

#2 389 Directory Server

389 Directory Server is an open source LDAP server that was first known by the name of Fedora Directory Server. 389 Directory Server is said to be the enterprise level of the management server that is best known for its multi-master replication system and the featured of handing the largest LDAPs at the same time. It is a free to use server system that can be used for the handling of small to largest level of the enterprises server management system. The three most important advantages of using 389 Directory Server are performance, reliability and scalability. When it comes to performance than 389 Directory Server is capable of handling the thousands of functions at the same time. In term of reliability, 389 Directory Server is the provider to a stable directory server that contains the rich feature set of backup technologies. 389 Directory Server is the one of the largest databases that depends on the size of your hard disk. Despite the fact that it provides the advanced level of functionalities to its users, 389 Directory Server provide the high throughout performance and ease of expansion at the same time. The main highlighted features and functions of 389 Directory Server are surety for high performance, multi master replication system, availability of extensive documentation, availability of active directory user, group synchronization system, support for LDAPv3 and many others.

#3 Apache Directory

Apache Directory is the independent directory of those tools and programs used in any LDAP server. However, there is only one limitation, and that is Apache Directory can be used with the ApacheDS only.

It is a kind of Eclipse RCP application that is based on the composition of several OSGI plugins and architectures that easily upgraded by using the other additional tools as well. These available plugins are run within the Eclipse by itself.

Apache Directory Studio supports the multiplatform application and is compatible with the Linux, Windows, and Mac OS X operating systems. Apache Directory contains several features in the shape of the LDAP editor and browser, an LDIF editor, a schema browser, a DSML editor, and many others.

The plugins of Apache Directory for Eclipse installed from the web-based directory. The users of Apache Directory can also get the old version of the Apache Directory Studio and Apache LDAP Studio from the official website of Apache Directory.

В Чем Отличие FTP, Samba или DLNA на WiFi Роутере — Какой Файловый Сервер Лучше?

Недавно один из подписчиков задал вопрос, касающийся файлового накопителя, подключенного к USB порту wifi роутера. В чем отличия FTP сервера от Samba и DLNA и какой из них лучше? Постараюсь без сложных терминов показать разницу между этими файловыми хранилищами.

Что такое FTP, Samba, DLNA?

• FTP (от англ. File Transfer Protocol — протокол передачи файлов) — стандартный протокол, предназначенный для передачи файлов по сетям.
• Samba, или SMB (от англ. Server Message Block) — сетевой протокол прикладного уровня для удалённого доступа к файлам, принтерам и другим сетевым ресурсам, а также для межпроцессного взаимодействия.
• DLNA — (от англ. Digital Living Network Alliance) — универсальный протокол для обмена медиаданными между устройствами различных производителей.

В чем отличие FTP, Samba (smb) и DLNA серверов?

Если подключить к USB разъему маршрутизатора флешку или внешний жесткий диск, то у нас появится возможность запустить на нем один из вышеперечисленных или одновременно несколько типов файловых серверов. В чем разница?

Больше всего отличаются Samba и FTP серверы от DLNA. Последний предназначен только для трансляции видео, музыки или фото с одного устройства на другое. Например, вы сохранили какой-то ролик на компьютер или смартфон и хотите вывести его на большой экран телевизора. Для этого необходимо установить программу для создания медиасервера и начать трансляцию по сети. А на ТВ открыть медиаплеер с поддержкой DLNA и воспроизвести.

То же самое и на роутере. После запуска DLNA сервера медиа контент с вашего внешнего накопителя появится в проигрывателе на другом устройстве, подключенном к wifi. После чего его можно воспроизвести.