jail и nfs

[100kg]

комуто удалось запустить nfs в клетке?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[zingel]

а зачем?

[princeps]

сервер или клиент?

[ProFTP]

а зачем?

что-то вроде бы рекомендовать для Read Only наверное

[zingel]

а chmod?

[ProFTP]

Код: Выделить всё

  Read Only файловые иерархии

   Одной из основных проблем, встречающихся при организации jail-ов,
   является экономия дискового пространства на "общие" данные.
   Действительно, зачем бессмысленно держать несколько десятков
   одинаковых файловых иерархий, которые не требуют модификации во время
   работы, но при этом требуют регулярного maintenance. Эта проблема
   должна решаться путем разделения набора данных в каждом jail-е на
   read-only и working. Первый представляет из себя не модифицируемый
   набор данных: бинари, библиотеки, общие данные. Модификацию его
   производит только администратор, следовательно для этого подходит
   sharing данных, который помогает создать jail(2). Что можно включить в
   эту часть? По опыту своего использования подобных сред я могу выделить
   следующие категории данных (файловых иерархий): /usr (целиком),
   /bin;/sbin;/dev, /kernel. Никто из них не обязан быть доступным на
   модификацию никому внутри jail-а.

   Организовать это достаточно просто, благо jail(2) предоставляет для
   этого все возможности. Итак мы хотим сделать несколько файловых
   иерархий внутри jail-а недоступными на модификацию даже суперюзеру:
    1. mount_nfs. Мы может подмонтировать подготовленную файловую
       иерархию в jail (например в /.invisible) по NFS с опцией ro с
       "мастер" хоста и сделать необходимые симлинки внутри jail-а (/bin
       -> /.invisible/bin и т.д.).
    2. Multiple mount_ufs in RO mode. Существует патч для ядра,
       http://hellbell.h1.ru/jail/files/multi_mount_ro.diff
       который использует возможность монтирования ufs разделов в RO
       режиме более одного раза. Я использовал этот патч (приведенный
       только для 4.x) с 3.x вплоть до 4.3-stable.
    3. mount_nullfs. К сожалению данная файловая система может считаться
       с натяжкой стабильной только в current. Попытки ее использования
       для данной цели на 4.x ни к чему хорошему не привели.
    4. mount_union. Здесь ситуация гораздо лучше. В RO режиме можно
       использовать union практически без ограничений, подмонтировав его
       в "master" каталог и раздав его в ro для jail-ов.

Код: Выделить всё

Попытка обслуживать NFS из ведущей среды также может вызвать
     проблемы, и эту проблему невозможно решить переконфигурацией на использование только
     определенных IP адресов, т.к. некоторые службы NFS работают непосредственно
     с ядром. Любое сетевое программное обеспечение от третьих лиц, выполняющееся в ведущей
     среде, должно быть проверено и сконфигурировано так, чтобы это не было возможности
     связаться (bind) со всеми IP адресами, которые привели бы к тем услугам, также предлагающимся
     средой jail. ???-прим. перевод.

[zingel]

Код: Выделить всё

связаться (bind)

login.conf для этого есть и вообще nfs юзается в отдельном нативном влане у нормальных людей