Сетевое хранилище - необходимые (и не очень) сервисы.
Попробую накидать себе план-список того, что нужно будет реализовать…
Какая у нас самая популярная десктопная OS в мире? Правильно, GNU/Linux^W Microsoft Шindoшs различных версий и модификаций, как бы не кипятились по этому поводу воинствующие линуксоиды. То есть, её поддержку нужно заложить обязательно (ну, я сам пользуюсь Windows, что, я себя буду ограничивать, что ли?), а это Samba, оно же «общие папки» или «сетевые папки» (у продвинутых юзеров — диски, те, которые в «Их компьютере» отображаются). Внезапно, Samba может не только папки по сети расшаривать, но мы к этому нюансу вернёмся позднее.
Что уметь WeDro ещё должно наше? Йода-мастер впечатления моём мозге неизгладимые оставил на…
Ну, раз больше своих идей нет, то тупо срисую нужную мне функциональность с оригинальной прошивки ведра: NFS, FTP, поддержку Apple TimeMachine вычёркиваем нафиг (кому надо — те доустановят и донастроют), DLNA — «ненуачо?», удобно же (но, совсем не обязательно).
Маловато будет! Маловато!
Докинем в список WebDAV — удобно же. А это значит — web-сервер. Причём, не Apache ни в коем случае. Ибо нефиг. Этот жЫрдяй способен сожрать ВСЕ ресурсы любой железки. Про модули, конечно помним, да? Php, Python, Perl и иже с ними. Что-то из этого всё равно понадобится, так как рулить самим сетевым хранилищем по SSH — это, конечно, труЪ и олдскульно, но, тупо, неудобно. Php я, местами, знаю, в отличие от, так что без вариантов. Что у нас выходит?! Легких web-серверов с поддержкой webdav и php я знаю ровно два — это Lighttpd (говорящее название, да?!) и Nginx. Может, есть и ещё, может, можно выбрать другой ЯП, но, это уже не ко мне. Оба обозначенных web-сервера работают с php через FastCGI, что тащит за собой либо php-fcgi, либо php-fpm. Опять же, lighttpd обладает весьма зубодробильным конфигом, поэтому я предпочитаю nginx, что делает ненужным php-fcgi (или как оно там? не важно). Web-сервер будет 100%, так что можно дать пользователям возможность использовать http userdir, для выкладывания всякой считающейся ими нужной всему человечеству (паблик же) ерунды. Нам не трудно, а им приятно. +1 сервис, в итоге 🙂 В отличие от lighttpd, nginx не имеет модуля непосредственной поддержки http_userdir, но понимает регекспы, которыми и нужно воспользоваться.
Едем дальше: авторизация. Сервисов-то кучка накопилась уже: Samba, NFS, FTP, WebDAV — все они требуют авторизации, все (не все программы-серверы), так или иначе (кто-то из коробки, а за кого-то постарался maintainer соответствующего пакета) работают с PAM. Но, тут вылезают первые грабли — Samba хранит свои пароли в своей базе и синхронизирует их и системными только в одностороннем порядке: меняешь в самбе — меняются в системе (при соответствующей настройке самбы, естественно). Двухсторонней синхронизации (PAM <-> Samba) нет. Шучу, есть, но ломает совместимость и безопасность протокола, так что нет 🙂 Запомнили, что односторонняя синхронизация работает?! Забудьте. Я, конечно, написал на колене свою обёртку над passwd, которую просто нужно было положить в /usr/local/bin, чтобы она подменяла системное приложение, но это всё костыли и полумеры. Ибо.
Когда я уже смирился и решил раскостыливаться по-полной, из-за горизонта вышел (точнее, из соседнего кабинета зашёл) Денис, с вопросом, «а как ему юзера, который авторизуется на pppoe-сервере через WINBIND (не просто так выделяю), завернуть на проксю с фильтрами». Получив намек на /etc/ppp/ip-{up,down}.d, Денис обрадовался, так как проблему он почти решил, и я, получив напоминание про Winbind, пришёл в то же настроение с тем же мнением.
Итак, авторизация пользователей будет через pam_winbind через локально работающую Samba, логины/пароли которой, в этом случае НЕ синхронизируются с локальными логинами/паролями unix. На данной радостной ноте я узнал о существовании модуля php-pam и обрадовался свыше принципиально возможного, «поймал сегфолт» и решил свой бред записывать. Дабы самому не забыть и другим пригодиться…