linux - unidad - Vagabundo huevo y gallina: carpeta compartida con el usuario uid=apache

smb linux

Question

Mi caja de Vagabundo se construye desde una base de Linux (Linux científico), durante el aprovisionamiento (usando scripts de shell), se instala Apache.

Recientemente cambié el archivo de Vagrant (v2) a:

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

Lo cual funciona bien si la caja ya está aprovisionada y acaba de reiniciarse.

Ahora, después de que un vagrant destroy && vagrant up el error:

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

Lo cual está claro: como durante la ejecución inicial, apache aún no está instalado.

Una solución fea sería, por supuesto, hacer el aprovisionamiento básico con esa synced_folder comentada, comentarla y luego reiniciar.

¿Hay algún truco limpio para resolver eso? Especialmente de una manera que vagrant up siempre se ejecuta sin interrupciones, incluso si la caja es nueva.

Answer 1

Cómo resolví esto fue que primero configuro el recurso compartido en Vagrantfile sin información de usuario o grupo. Luego, en la fase de aprovisionamiento, desmonto el recurso compartido y lo vuelvo a montar con la información de usuario y de grupo adecuada. p.ej:

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''

Puede verificar el nombre compartido de virtualbox o ejecutando el aprovisionamiento con indicador de depuración y configuraciones que no funcionan (imprime el comando de montaje real). Sé que esto es una solución y podría no funcionar en todas las situaciones, pero funcionó para mí.

Answer 2

En mi caso, no necesito que la synced_folder durante la fase de provisión. Así que desactivo el synced_folder si el invitado no está aprovisionado.

Compruebe si está aprovisionado en Vagrantfile es un truco, pero funciona .

Y para mí es justo hacer

vagrant up   # To build and provision the first time
vagrant halt # An intermediate step to mount the folder
vagrant up   # To have the folder mounted

Entonces mi Vagrantfile es algo así como:

def provisioned?(vm_name=''default'', provider=''virtualbox'')
  File.exist?(".vagrant/machines/#{vm_name}/#{provider}/action_provision")
end

Vagrant.configure(2) do |config|
  [ ... ]
  config.vm.synced_folder "../geoserver_data", "/var/lib/geoserver_data",
    disabled: !provisioned?,
    owner: "tomcat7",
    group: "tomcat7"
  [ ... ] 

Answer 3

Esto es lo que hice:

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

En lugar de usar el nombre de usuario y el grupo (como texto) use el uid y el gid. Luego crea el grupo y el usuario con esos ID. Esto es porque el error de hecho es:

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

El comando id no pudo reconocer al usuario. Por lo tanto, cambiar a uid y gid el ID de comando no será utilizado por vagabundo.

La única advertencia que recibí con este enfoque es que el directorio de inicio del usuario (/ opt / MyApp) ya existe, pero puedo aceptarlo, o puede cambiar el comando useradd para ignorar el directorio de inicio si ya existe.

Antes de eso, la solución alternativa que utilicé es:

vagrant up; vagrant provision; vagrant reload

Pero, no es bueno ni limpio.

Answer 4

Si puede corregir los valores de uid / gid, puede usarlos en el comando mount, ya que no tienen que relacionarse con un usuario / grupo existente.

Hago esto con un usuario que luego es creado por un títere usando valores fijos (pareados) uid / gid

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

Answer 5

Ryan Sechrest ha tratado ampliamente este problema .

Una de las soluciones presentadas es:

Establezca permisos de directorios en 777 y archivos en 666

config.vm.synced_folder "/Users/ryansechrest/Projects/Sites", 
  "/var/www/domains", mount_options: ["dmode=777", "fmode=666"]