Головна

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

Ідеологічна частина

Спочатку розглянемо політично-організаційну частину такого сервера.
Робота з Samba, і взагалі по протоколу SMB в Windows-мережі стала вже стандартом. Та й створювалась вона, швидше за все, для цього ж.
Але сьогодні вже немає сенсу прив'язуватися тільки до цього протоколу. Він несе в собі занадто багато обмежень.

Якщо розглядати офіс, в якому встановлені тільки стаціонарні комп'ютери та робота з дому або взагалі з-за меж офісу не планується ніколи - то в такому випадку дійсно варто обмежитися роботою по SMB і не шукати собі проблем.
Зовсім інша справа, коли користувач працює за ноутбуком. Тут вже будувати систему потрібно так, що б у працівника були мінімальні (а краще, що б їх не було взагалі) відмінності в трудовому процесі, при роботі через інтернет.
Робота більшості сучасних серверних додатків (, GroupWare і т.д.) абсолютно спокійно робиться за допомогою веб-інтерфейсу. З поштою теж зазвичай проблем не буває. Доступ в інтернет при віддаленій роботі системного адміністратора взагалі не обходить. Залишається остання проблема - доступ до файлів на файловому сервері.

Як альтернативу протоколу SMB, розглянемо переваги роботи з файловим сховищем по SSH:
1. Тільки авторизований доступ.
2. Жорстке розділення прав користувачів на доступ.
3. Відсутність різниці в роботі користувача незалежно від його місцезнаходження.
4. Можливість авторизації користувача як по паролю (можлива інтеграція з Microsoft AD), так і по ключу.
5. Відсутність необхідності в закупівлі, налаштуванні та підтримці сервера VPN.
6. Відсутність потреби у закупівлі серверної ліцензії 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 &

Ось і все. Всі роботи на сервері закінчені.

Доповнення до статті

Як показала практика, використовувати 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%. Це цілком припустимо, як на мене.

 

Додати коментар

Захисний код
Оновити