Vagrant chicken-and-egg: общая папка с uid = apache user

Коробка "Мой бродяга" построена из базового Linux (научного Linux) во время подготовки (с использованием сценариев оболочки), установлен Apache.

Недавно я изменил файл Vagrant (v2) на:

config.vm.synced_folder "public", "/var/www/sites.d/example.com",
   :owner => "apache", :group => "apache"

Что хорошо работает, если ящик уже подготовлен и перезагружен.

Теперь, после a vagrant destroy && vagrant up, я получаю ошибку:

mount -t vboxsf -o uid=`id -u apache`,gid=`id -g apache` 
   /var/www/sites.d/example.com /var/www/sites.d/example.com
id: apache: User does not exist

Это ясно - как и во время первого запуска, apache еще не установлен.

Уродливым обходным путем было бы, конечно, сделать базовое обеспечение с тем, что synced_folder закомментировано, прокомментировать его и перезагрузить.

Есть ли какой-нибудь чистый трюк, чтобы решить это? Особенно в том, что vagrant up всегда работает без перерывов, даже если поле нового.

Ответ 1

Ryan Sechrest имеет широко обсуждаемые с этой проблемой.

Одно из представленных решений:

Установить разрешения каталогов на 777 и файлы на 666
config.vm.synced_folder "/Users/ryansechrest/Projects/Sites", 
  "/var/www/domains", mount_options: ["dmode=777", "fmode=666"]

Ответ 2

Если вы можете исправить значения uid/gid, вы можете использовать их в команде mount - им не нужно связываться с существующим пользователем/группой

Я делаю это с пользователем, который позже создается марионеткой, используя фиксированные (соответствующие) значения uid/gid

config.vm.synced_folder "foo", "/var/www/foo",
   id: "foo", :mount_options => ["uid=510,gid=510"]

Ответ 3

Это то, что я сделал:

config.vm.synced_folder "./MyApp", "/opt/MyApp", owner: 10002, group: 1007, create: true

config.vm.provision :shell do |shell|
  shell.inline = "groupadd -g 1007 myapp;
                  useradd -c 'MyApp User' -d /opt/MyApp -g myapp -m -u 10002 myapp;"
end

Вместо использования имени пользователя и группы (в виде текста) используйте uid и gid. Затем создайте группу и пользователя с этими идентификаторами. Это связано с тем, что на самом деле ошибка:

mount -t vboxsf -o uid=`id -u myapp`,gid=`getent group myapp | cut -d: -f3` opt_MyApp /opt/MyApp
...
id: myapp: No such user

Команда id не смогла распознать пользователя. Таким образом, переключение на uid и gid идентификатор команды не будет использоваться бродягой.

Единственное предупреждение, которое я получил с этим подходом, заключается в том, что пользовательский домашний каталог (/opt/MyApp) уже существует, но я могу жить с этим, или вы можете изменить команду useradd, чтобы игнорировать домашний каталог, если он уже существует.

До этого обходной путь, который я использовал, это:

vagrant up; vagrant provision; vagrant reload

Но, это не приятно ни чистым.

Ответ 4

Как я решил это, я сначала сконфигурировал этот ресурс в Vagrantfile без информации о пользователе или группе. Затем на этапе инициализации я отключу общий ресурс и перемонтирую его с соответствующей информацией о пользователе и группе. например:.

exec {
'umount /share/location':
  command => 'umount /share/location';
} -> exec {
'mount /share/location':
  command => 'mount -t vboxsf -o uid=`id -u apache`,gid=`id -g apache` /share/name /share/location'

Вы можете проверить имя общего ресурса из виртуального бокса или выполнить инициализацию с флагом отладки и неработоспособными настройками (он выводит фактическую команду монтирования). Я знаю, что это любопытное решение и может не работать в любой ситуации, но это сработало для меня.