>>Доброго времени суток! >> >> Я работаю в одном из интернет-кафе ,где имеется 20 машин. >>И передо мной стала проблема создания файлового сервера, была выбрана ОС >>FreeBSD + Samba . После нескольких суток детального изучения ресурсов сети >>и всемогущего и всезнающего Гугля :) и прочтения тонны разных статей >>на данную тему, осталась одна очень существенная проблема, которую я не >>могу никак решить: >> У меня, как я уже говорил, есть сетка из >>20 машин 192.168.0.0-192.168.0.20 (WinXP) И необходимо сделать так так, чтобы при >>входе (фильмы или скажем музыка к примеру /usr/data) >>на файл-сервер пользователь без лишних вопросов (запрос пароля и имени) мог >>просматривать и слушать\смотреть\копировать данные, но не имел прав на запись либо >>удаление файлов. А Компьютер оператора 192.168.0.10 мог вносить какие бы то >>ни было изменения в содержимое, записывать, удалять информацию (можно >>по паролю), также чтобы Директора данного заведения имели свои собственные каталоги >>на сервере, в которые они могли бы иметь также полный доступ >>, но клиенты данных каталогов не видели вообще, и было бы >>неплохо поставить ограничение на размер каждой из Аудиторий , дабы не >>заполнить весь объем памяти на сервере >>Сеть моя не имеет домена. >> Я ни нашел ни одной внятной доки, которая бы в >>полной мере осетила данную проблему, я уверен что с ней сталкивались >>очень многие. и Возможно ли вообще развернуть Самбу на обслуживание моей >>сети таким образом, заранее благодарен. Если не трудно выложите плз инструкцию >>пошаговую как это сделать , с последующей ее распечаткой и наклейкой >>на стену :) мозг уже закипает ....... заранее благодарю > >Вообще возможно, но кроме как создания домена и использования самбы в качестве >контроллера домена, я другого пути не вижу. Я сам использую в >качестве контроллера домена Windows 2003, но хочу перевести всё под Unix. >По этой теме есть документация на официальном сайте самбы (но на >английском языке). ну почему же только домен? все прямо помешались на доменах... все намного проще в данном случае, а домен скорее навредит чем поможет. 1е - security=share если есть необходимость заходить не вводя чего-либо. на шары c public=yes будет доступ всем и вся без лишних запросов. writeable=no для этих само собой необходимость. 2е - на одну юникс-папку можно наложить две шары (две секции в конфиге самбы с одним и тем же path=) - одну public=yes writeable=no - для клиентов, другую puublic=no writeable=yes - для себя, любимого. browseable=no поможет спрятать от глаз клиента то, чего ему видеть необязательно (это косметическая мера, знание того, что оно на самом деле есть ему не поможет - пароль у него всеравно спросят) 3е - и самое серьезное, возможно исключает необходимость двух первых - это директива include и "стандартные подстановки" - наиболее интересны в данном контексте %M (NetBIOS Name клиента) и %I (его IP). можно прописать что-то вроде: [global] netbios name = ... security = share . . . include smb_conf_global_%I[music] path = ... include smb_conf_music_%I include smb_conf_add_shares_%I ну итп. и создать наборы "дополнительных конф. файликов". для групп одинаковых (клиенты) - использовать линки (символические или жесткие - без разницы, насоздавать можно хоть сотни простейшим скриптом) стсно в клиентских smb_conf_music должно быть writeable=no public=yes, а в твоем хоть бы и writeable=yes public=yes, т.к. эффективен он будет только при подключении с твоего IP (однако надо быть осторожным тут. ты уверен, что твой IP аутентичен?) в smb_conf_add_shares для начальников (опять же динки можно использовать) можно прописать секцию [homes], и там сделать их "личное пространство" дисковые квоты (средствами ОС) на юзера nobody и юзеров для боссов помогут решить последню проблему
|