Коробка "Мой бродяга" построена из базового 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 всегда работает без перерывов, даже если поле нового.
Ryan Sechrest имеет широко обсуждаемые с этой проблемой.
Одно из представленных решений:
Установить разрешения каталогов на 777 и файлы на 666
config.vm.synced_folder "/Users/ryansechrest/Projects/Sites", "/var/www/domains", mount_options: ["dmode=777", "fmode=666"]
Если вы можете исправить значения uid/gid, вы можете использовать их в команде mount - им не нужно связываться с существующим пользователем/группой
Я делаю это с пользователем, который позже создается марионеткой, используя фиксированные (соответствующие) значения uid/gid
config.vm.synced_folder "foo", "/var/www/foo",
id: "foo", :mount_options => ["uid=510,gid=510"]
Это то, что я сделал:
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
Но, это не приятно ни чистым.
Как я решил это, я сначала сконфигурировал этот ресурс в 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'
Вы можете проверить имя общего ресурса из виртуального бокса или выполнить инициализацию с флагом отладки и неработоспособными настройками (он выводит фактическую команду монтирования). Я знаю, что это любопытное решение и может не работать в любой ситуации, но это сработало для меня.