New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apache should run as "vagrant" user #138

Closed
fain182 opened this Issue Aug 10, 2013 · 21 comments

Comments

Projects
None yet
@fain182

fain182 commented Aug 10, 2013

Actually all the files mounted are owned by the user vagrant, so if I need to upload some files in a directory or manage a cache of files Apache can't do it.

I think the best workaround to this problem is to run apache as user "vagrant".

@frastel

This comment has been minimized.

Show comment
Hide comment
@frastel

frastel Aug 10, 2013

Contributor

No, this is not the best solution. You have to define this with ACL so that the vagrant user and the www-data user have both the correct permissions.

Take Symfony installation for example: http://symfony.com/doc/current/book/installation.html and have a look at the "Setting up Permissions" chapter.

Contributor

frastel commented Aug 10, 2013

No, this is not the best solution. You have to define this with ACL so that the vagrant user and the www-data user have both the correct permissions.

Take Symfony installation for example: http://symfony.com/doc/current/book/installation.html and have a look at the "Setting up Permissions" chapter.

@jtreminio jtreminio closed this Aug 13, 2013

@psren

This comment has been minimized.

Show comment
Hide comment
@psren

psren Sep 19, 2013

Could you post a possibility to accomplish that? I'd like to run as "vagrant" although its not best. But it will work for me.
Or could you provide an example how to use acl in puphpet, please?

psren commented Sep 19, 2013

Could you post a possibility to accomplish that? I'd like to run as "vagrant" although its not best. But it will work for me.
Or could you provide an example how to use acl in puphpet, please?

@jeremykendall

This comment has been minimized.

Show comment
Hide comment
@jeremykendall

jeremykendall Sep 27, 2013

Bump. I'm having a related issue. After installing acl, updating /etc/fstab, and remounting, I get an "Operation not supported" error when calling setfacl. I'm following the directions @frastel linked to above, and I've successfully used those directions on other Ubuntu servers (not VMs configured with Vagrant).

Any help? The Google is not helping. Thanks!

Bump. I'm having a related issue. After installing acl, updating /etc/fstab, and remounting, I get an "Operation not supported" error when calling setfacl. I'm following the directions @frastel linked to above, and I've successfully used those directions on other Ubuntu servers (not VMs configured with Vagrant).

Any help? The Google is not helping. Thanks!

@kunalp

This comment has been minimized.

Show comment
Hide comment
@kunalp

kunalp Sep 27, 2013

Contributor

@jeremykendall I ran into the same problem. Instead of setting the permissions on the guest box, I ended up sharing the cache/logs directories by including the following to my Vagrantfile:

config.vm.synced_folder "app/cache", "/vagrant/app/cache", :extra => "dmode=777,fmode=777"
config.vm.synced_folder "app/logs", "/vagrant/app/logs", :extra => "dmode=777,fmode=777"
Contributor

kunalp commented Sep 27, 2013

@jeremykendall I ran into the same problem. Instead of setting the permissions on the guest box, I ended up sharing the cache/logs directories by including the following to my Vagrantfile:

config.vm.synced_folder "app/cache", "/vagrant/app/cache", :extra => "dmode=777,fmode=777"
config.vm.synced_folder "app/logs", "/vagrant/app/logs", :extra => "dmode=777,fmode=777"
@jeremykendall

This comment has been minimized.

Show comment
Hide comment
@jeremykendall

jeremykendall Sep 27, 2013

@kunalp and @frastel: I'm going to go with @dragonmantank's solution here: https://gist.github.com/dragonmantank/6723460, using sed to set the apache user to vagrant. It doesn't seem like setfacl works with VirtualBox shared directories, and my VM is an Ubuntu box that doesn't support chmod +a.

@kunalp and @frastel: I'm going to go with @dragonmantank's solution here: https://gist.github.com/dragonmantank/6723460, using sed to set the apache user to vagrant. It doesn't seem like setfacl works with VirtualBox shared directories, and my VM is an Ubuntu box that doesn't support chmod +a.

@jaytaph

This comment has been minimized.

Show comment
Hide comment
@jaytaph

jaytaph Sep 27, 2013

This is an issue that i'm struggling with for a long time, and still haven't come up with a "decent" solution. The problem is as said that not all filesystems support setfacl or chmod +a, which can cause conflicts with the vagrant and apache user (especially with symfony2's console app)

Too be honest, i think it's symfony2 here to blame. Caching and logs should NOT be part of ANY project directly, and there are better paths to place them like /var/cache/, /var/log/ for instance. Since these are not shared through vagrant, changing to the correct permissions/users should not cause any problems. This is also very easily changed inside the symfony2 kernel.php as well (getCacheDir() and getLogDir()).

But because this doesn't solve all cases (like uploads done to directories inside the docroot), changing the webserver user to vagrant is probably the easiest way. Make sure though that you change some other directories as well depending on your OS, like "/var/lock/apache2" and "/var/lib/php/session"

jaytaph commented Sep 27, 2013

This is an issue that i'm struggling with for a long time, and still haven't come up with a "decent" solution. The problem is as said that not all filesystems support setfacl or chmod +a, which can cause conflicts with the vagrant and apache user (especially with symfony2's console app)

Too be honest, i think it's symfony2 here to blame. Caching and logs should NOT be part of ANY project directly, and there are better paths to place them like /var/cache/, /var/log/ for instance. Since these are not shared through vagrant, changing to the correct permissions/users should not cause any problems. This is also very easily changed inside the symfony2 kernel.php as well (getCacheDir() and getLogDir()).

But because this doesn't solve all cases (like uploads done to directories inside the docroot), changing the webserver user to vagrant is probably the easiest way. Make sure though that you change some other directories as well depending on your OS, like "/var/lock/apache2" and "/var/lib/php/session"

@psren

This comment has been minimized.

Show comment
Hide comment
@psren

psren Sep 27, 2013

I'm doing like this for now...
config.vm.synced_folder "./../", "/var/www", id: "vagrant-root" , :owner => "www-data", :group => "www-data"

psren commented Sep 27, 2013

I'm doing like this for now...
config.vm.synced_folder "./../", "/var/www", id: "vagrant-root" , :owner => "www-data", :group => "www-data"

@awildeep

This comment has been minimized.

Show comment
Hide comment
@awildeep

awildeep Sep 27, 2013

It is rather easy to move your cache and log directories:
http://symfony.com/doc/current/cookbook/configuration/override_dir_structure.html

You just really need to be sure you have a cache and log directory per application and environment running on your vm. (Having a shared cache or log directory will lead you to some very confusing bugs).

Once that is done, you should not need to deal with these permissions issues the same way, as the files in your project only need to be readable by Apache or Nginx, and writable on your local machine.

It is rather easy to move your cache and log directories:
http://symfony.com/doc/current/cookbook/configuration/override_dir_structure.html

You just really need to be sure you have a cache and log directory per application and environment running on your vm. (Having a shared cache or log directory will lead you to some very confusing bugs).

Once that is done, you should not need to deal with these permissions issues the same way, as the files in your project only need to be readable by Apache or Nginx, and writable on your local machine.

@dragonmantank

This comment has been minimized.

Show comment
Hide comment
@dragonmantank

dragonmantank Sep 27, 2013

Since @jeremykendall dragged me into this, I'll give my reasoning. :P

Running httpd as the vagrant user is, to me, the simplest way to fix permissions issues across the board. Ideally you'd actually want to set your vagrant instance up like production, which for me is running mod_itk and switching the user per vhost, or running php-fpm chrooted as a specific user, it allows us to skirt permissions issues like they would be properly set up in production.

Also, depending on the application, you might not be able to move cache or log files out of the mounted folder system. Yes, in symfony2 you can, but is everyone doing symfony work? Is puphpet soley designed to be used for a specific application workflow, or is it meant to be a way for us to work better when we're developing PHP projects, legacy or not? That's also ignoring the issues with applications that upload files into the docroot for serving, because in those cases you need those files in the docroot, and you need the webserver to have the correct permissions.

I'll agree that just switching the running user/group to vagrant is a bit of a configuration smell, but it's one that works for me across the board whether I'm developing on Windows, Mac, or Linux. Since it's a devbox, I'm kind of OK with that config smell, because I know in my production instances httpd is switching to the correct user or php-fpm has pools set up for the user.

I'd rather see an option for setting up mod_itk to run the vhosts as a specific user or setting up php-fpm to create a pool instance that runs as vagrant. Those I think are the proper solution, but I'm OK with the quick-and-dirty solution of changing envvars since puphpet only supports Debian-based OSes. More config options for itk/php-fpm would allow puphpet to support non-Debian OSes though.

Since @jeremykendall dragged me into this, I'll give my reasoning. :P

Running httpd as the vagrant user is, to me, the simplest way to fix permissions issues across the board. Ideally you'd actually want to set your vagrant instance up like production, which for me is running mod_itk and switching the user per vhost, or running php-fpm chrooted as a specific user, it allows us to skirt permissions issues like they would be properly set up in production.

Also, depending on the application, you might not be able to move cache or log files out of the mounted folder system. Yes, in symfony2 you can, but is everyone doing symfony work? Is puphpet soley designed to be used for a specific application workflow, or is it meant to be a way for us to work better when we're developing PHP projects, legacy or not? That's also ignoring the issues with applications that upload files into the docroot for serving, because in those cases you need those files in the docroot, and you need the webserver to have the correct permissions.

I'll agree that just switching the running user/group to vagrant is a bit of a configuration smell, but it's one that works for me across the board whether I'm developing on Windows, Mac, or Linux. Since it's a devbox, I'm kind of OK with that config smell, because I know in my production instances httpd is switching to the correct user or php-fpm has pools set up for the user.

I'd rather see an option for setting up mod_itk to run the vhosts as a specific user or setting up php-fpm to create a pool instance that runs as vagrant. Those I think are the proper solution, but I'm OK with the quick-and-dirty solution of changing envvars since puphpet only supports Debian-based OSes. More config options for itk/php-fpm would allow puphpet to support non-Debian OSes though.

@jeremykendall

This comment has been minimized.

Show comment
Hide comment
@jeremykendall

jeremykendall Sep 27, 2013

👍 @dragonmantank

Sorry for dragging you into this 😄

👍 @dragonmantank

Sorry for dragging you into this 😄

@awildeep

This comment has been minimized.

Show comment
Hide comment
@awildeep

awildeep Sep 27, 2013

@dragonmantank I agree /w you that not everyone is running symfony2, or a very configurable system. That being said something more robust should probably be done.

Running the webserver as vagrant definitely smells bad, mainly because I can see people using a similar script to deploy to Rackspace or some such. If this is in fact implemented by Puphpet directly, it should be an option for local only builds, and provide warnings and be adequately documented so users can't use this strategy for an external deployment method.

Ultimately I won't be running httpd threads as vagrant, even if it means I have to manually hack my Puphpet build scripts to make that happen for the short term.

@dragonmantank I agree /w you that not everyone is running symfony2, or a very configurable system. That being said something more robust should probably be done.

Running the webserver as vagrant definitely smells bad, mainly because I can see people using a similar script to deploy to Rackspace or some such. If this is in fact implemented by Puphpet directly, it should be an option for local only builds, and provide warnings and be adequately documented so users can't use this strategy for an external deployment method.

Ultimately I won't be running httpd threads as vagrant, even if it means I have to manually hack my Puphpet build scripts to make that happen for the short term.

@jaytaph

This comment has been minimized.

Show comment
Hide comment
@jaytaph

jaytaph Sep 27, 2013

It's fairly easy to add "vagrant" only declarations in puppet. You can add facts through the vagrant configuration like this:

puppet.facter = { "vagrant" => "yes" }

This way, you can actually only apply vagrant-only stuff whenever you run vagrant.

so in your webserver classes you could add something like:

if ($vagrant == "yes") {

declarations for setting up vagrant webuser

class { "webserver::vagrant" : }
}

In the end, you want to abstract much of this away in separate classes, just like your OS stuff. Either through configuration, params classes (hiera is builtin from 3.0 onwards), or through external classes (like: class { "apache::$operating_system" : } ).

This keeps things neat and easily extendable to other operating systems and features (think about support for aws, vmware fusion providers)

jaytaph commented Sep 27, 2013

It's fairly easy to add "vagrant" only declarations in puppet. You can add facts through the vagrant configuration like this:

puppet.facter = { "vagrant" => "yes" }

This way, you can actually only apply vagrant-only stuff whenever you run vagrant.

so in your webserver classes you could add something like:

if ($vagrant == "yes") {

declarations for setting up vagrant webuser

class { "webserver::vagrant" : }
}

In the end, you want to abstract much of this away in separate classes, just like your OS stuff. Either through configuration, params classes (hiera is builtin from 3.0 onwards), or through external classes (like: class { "apache::$operating_system" : } ).

This keeps things neat and easily extendable to other operating systems and features (think about support for aws, vmware fusion providers)

@jaytaph

This comment has been minimized.

Show comment
Hide comment
@jaytaph

jaytaph Sep 27, 2013

plus.. depending on the needs for different frameworks, you could have specific defines like:

class { "framework::zend2" : }
class { "framework::codeigniter" : }
class { "framework::symfony2" : }

etc.. which could share optional classes and modules like composer (which should/could be a separate module).

jaytaph commented Sep 27, 2013

plus.. depending on the needs for different frameworks, you could have specific defines like:

class { "framework::zend2" : }
class { "framework::codeigniter" : }
class { "framework::symfony2" : }

etc.. which could share optional classes and modules like composer (which should/could be a separate module).

@jtreminio

This comment has been minimized.

Show comment
Hide comment
@jtreminio

jtreminio Sep 28, 2013

Member

Hi all, been keeping tabs on this thread.

plus.. depending on the needs for different frameworks, you could have specific defines like:

This is actually one of the main reasons I'm rewriting puphpet! Should have a beta version within a few days. I'm hoping to make it much easier to add in new things, like support for a wide range of frameworks, libraries, etc.

Will keep you all posted.

Member

jtreminio commented Sep 28, 2013

Hi all, been keeping tabs on this thread.

plus.. depending on the needs for different frameworks, you could have specific defines like:

This is actually one of the main reasons I'm rewriting puphpet! Should have a beta version within a few days. I'm hoping to make it much easier to add in new things, like support for a wide range of frameworks, libraries, etc.

Will keep you all posted.

@jeremykendall

This comment has been minimized.

Show comment
Hide comment
@frastel

This comment has been minimized.

Show comment
Hide comment
@frastel

frastel Oct 1, 2013

Contributor

Sorry for delayed answer but I was on vacation.
I am ignoring the discussion about the framework specific stuff because this should be discussed in another seperate topic.
But talking about permissions:
My current approach working in vagrant boxes is:

  • project work is not done in the shared folder because of its permissions problems between host and guest system
  • I have a custom puppet module for installing acl, modifiying /etc/fstab automatically and remounting the main partition with acl. I have uploaded its content to Gist.
  • after installing the project setfacl is called on cache and logs folders with vagrant and www-data user

That's it. So setfacl is only possible when project is not running in the shared folder and setfacl is only usefuly when partition is mounted and installed correctly.

This issue was closed. I donnu why because a common solution does not exist, so I would have no problem with continuing this discussion about how vagrant and www-data permissions could be fixed. However I am still against the possibility to let the webserver be run with the vagrant user.

Contributor

frastel commented Oct 1, 2013

Sorry for delayed answer but I was on vacation.
I am ignoring the discussion about the framework specific stuff because this should be discussed in another seperate topic.
But talking about permissions:
My current approach working in vagrant boxes is:

  • project work is not done in the shared folder because of its permissions problems between host and guest system
  • I have a custom puppet module for installing acl, modifiying /etc/fstab automatically and remounting the main partition with acl. I have uploaded its content to Gist.
  • after installing the project setfacl is called on cache and logs folders with vagrant and www-data user

That's it. So setfacl is only possible when project is not running in the shared folder and setfacl is only usefuly when partition is mounted and installed correctly.

This issue was closed. I donnu why because a common solution does not exist, so I would have no problem with continuing this discussion about how vagrant and www-data permissions could be fixed. However I am still against the possibility to let the webserver be run with the vagrant user.

@aramonc

This comment has been minimized.

Show comment
Hide comment
@aramonc

aramonc Oct 9, 2013

Another solution is to mount the synced folder as NFS which will then allow you to change file permissions (either through puppet or a shell script). This option has improved a lot in the latest version of vagrant.

Unfortunately it does little for running Symfony on a 256MB VM >.<

aramonc commented Oct 9, 2013

Another solution is to mount the synced folder as NFS which will then allow you to change file permissions (either through puppet or a shell script). This option has improved a lot in the latest version of vagrant.

Unfortunately it does little for running Symfony on a 256MB VM >.<

@dragonmantank

This comment has been minimized.

Show comment
Hide comment
@dragonmantank

dragonmantank Oct 9, 2013

The only issue with NFS for me is that it doesn't work on Windows (and some of us do a fair amount of our work on Windows). I actually add a check to my Vagrantfile to see if we're running on Windows and to mount NFS or shared folder.

The only issue with NFS for me is that it doesn't work on Windows (and some of us do a fair amount of our work on Windows). I actually add a check to my Vagrantfile to see if we're running on Windows and to mount NFS or shared folder.

@crankeye

This comment has been minimized.

Show comment
Hide comment
@crankeye

crankeye Feb 7, 2014

We're using Symfony2 with Ubuntu 12.04 as the guest and Windows 7 as the host.

For now our solution has been to mount the shared folder as www-data:www-data in the Vagrant configuration:
development_config.vm.synced_folder "./", "/var/www", {:mount_options => ['dmode=777','fmode=777'], :owner => "www-data", :group => "www-data"}

Then when running commands with symfony 2 we execute them as www-data
sudo -u www-data php /var/www/project/app/console cache:clear

To speed up the environment we've moved the cache to the /tmp/ folder within the guest machine by adding these two functions to the AppKernel.php:

public function getCacheDir()
{
    return '/tmp/symfony/cache/'. $this->environment;
}

public function getLogDir()
{
    return '/tmp/symfony/log/'. $this->environment;
}

crankeye commented Feb 7, 2014

We're using Symfony2 with Ubuntu 12.04 as the guest and Windows 7 as the host.

For now our solution has been to mount the shared folder as www-data:www-data in the Vagrant configuration:
development_config.vm.synced_folder "./", "/var/www", {:mount_options => ['dmode=777','fmode=777'], :owner => "www-data", :group => "www-data"}

Then when running commands with symfony 2 we execute them as www-data
sudo -u www-data php /var/www/project/app/console cache:clear

To speed up the environment we've moved the cache to the /tmp/ folder within the guest machine by adding these two functions to the AppKernel.php:

public function getCacheDir()
{
    return '/tmp/symfony/cache/'. $this->environment;
}

public function getLogDir()
{
    return '/tmp/symfony/log/'. $this->environment;
}
@scribblet

This comment has been minimized.

Show comment
Hide comment
@scribblet

scribblet Feb 19, 2014

I have followed an approach similar to @crankeye but actually edited the puphpet generated manifest.pp file to setfacl permissions on vhost document roots and their parent directories for group www-data. I moved the SF2 cache and log directories to /tmp by editing AppKernel.php just because my personal philosophy is these directories should not be considered part of the project and as such followed a similar procedure to configure this directory.

I use CentOS for development and production and by default it has no problem with setfacl so I decided that was the best approach to manage permissions.

Firstly, I don't like the performance hit on Windows hosts associated with a synced folder being the directory the webserver guest executes PHP from (80 ms -> 3000 ms response time). So I sync just to /vagrant/my_sf2_project_source and use my IDE (IntelliJ) or rsync to move the files into the vhost document root. For example, my IDE will redeploy a file when saved to a path relative to the vhost document root.

Alternatively, use rsync e.g. rsync -r /vagrant/my_sf2_project_source /var/vhosts/php.dev/

Assuming a vhost php.dev with a document root /var/vhosts/php.dev/web for the examples below:

Firstly I ensure the vagrant user is a member of www-data and that my /tmp/symfony2 directory exists with correct ACL permissions.

user { $::ssh_username:
  shell  => '/bin/bash',
  home   => "/home/${::ssh_username}",
  groups => 'www-data',
  ensure => present,
  require => Group['www-data']
}

file { "/tmp/symfony2":
    ensure => directory,
    owner  => 'www-data',
    group  => 'www-data',
    mode   => 0775
}

exec { 'set_symfony2_permissions':  
  command => "setfacl -R -m g:www-data:rwX /tmp/symfony2 \
              && setfacl -dR -m g:www-data:rwX /tmp/symfony2",
  onlyif  => "test -d /tmp/symfony2",              
  logoutput => "on_failure",
  require => File['/tmp/symfony2']
}

and later on I ensure the document root parent directory is created with correct permissions and then the vhost directory and then I run setfacl on both

if count($apache_values['vhosts']) > 0 {
  each( $apache_values['vhosts'] ) |$key, $vhost| {
    # work out parent directory of vhost docroot
    $docroot_parent = join(delete_at(split($vhost['docroot'], '/'), size(split($vhost['docroot'], '/'))-1), '/')    

    # ensure parent directory exists
    exec { "exec mkdir -p ${docroot_parent} @ key ${key}":
      command => "mkdir -p ${docroot_parent}",
      creates => $docroot_parent,
    }

    exec { "exec mkdir -p ${vhost['docroot']} @ key ${key}":
      command => "mkdir -p ${vhost['docroot']}",
      creates => $vhost['docroot'],
      require => Exec["exec mkdir -p ${docroot_parent} @ key ${key}"]
    }

    if ! defined(File[$docroot_parent]) {
      file { $docroot_parent:
        ensure  => directory,        
        group   => 'www-data',
        mode    => 0755,
        require => Exec["exec mkdir -p ${docroot_parent} @ key ${key}"]
      }
    }

    if ! defined(File[$vhost['docroot']]) {
      file { $vhost['docroot']:
        ensure  => directory,        
        group   => 'www-data',
        mode    => 0755,
        require => Exec["exec mkdir -p ${vhost['docroot']} @ key ${key}"]
      }
    }

    #setfacl permissions
    exec { 'set_vhost_dir_permissions':      
      command => "setfacl -R -m g:www-data:rwX ${docroot_parent} ${vhost['docroot']} \
                  && setfacl -dR -m g:www-data:rwX ${docroot_parent} ${vhost['docroot']}",
      logoutput => "on_failure",
      onlyif  => "test -d ${vhost['docroot']}",              
      require => [File[$vhost['docroot']], File[$docroot_parent]]
    }
  }
}

This enables the vagrant user to run commands in SSH and upload files over SFTP while still allowing the www-data user access to the files owned by the vagrant user when they are in /tmp/symfony2 or /var/vhosts/php.dev.

Files owned by the vagrant user happen as a consequence of running the 'php app/console' commands while SSH'ing in as the vagrant user. Valid permissions arise as a consequence of both vagrant and www-data users being members of the www-data group. The www-data group has write permissions to both /var/vhosts/php.dev and /var/vhosts/php.dev/web (where Symfony2 public assets go, i.e. the document root).

A similar setup was done for the /tmp/symfony2 directory where Symfony2 writes its cache and log files.

I have followed an approach similar to @crankeye but actually edited the puphpet generated manifest.pp file to setfacl permissions on vhost document roots and their parent directories for group www-data. I moved the SF2 cache and log directories to /tmp by editing AppKernel.php just because my personal philosophy is these directories should not be considered part of the project and as such followed a similar procedure to configure this directory.

I use CentOS for development and production and by default it has no problem with setfacl so I decided that was the best approach to manage permissions.

Firstly, I don't like the performance hit on Windows hosts associated with a synced folder being the directory the webserver guest executes PHP from (80 ms -> 3000 ms response time). So I sync just to /vagrant/my_sf2_project_source and use my IDE (IntelliJ) or rsync to move the files into the vhost document root. For example, my IDE will redeploy a file when saved to a path relative to the vhost document root.

Alternatively, use rsync e.g. rsync -r /vagrant/my_sf2_project_source /var/vhosts/php.dev/

Assuming a vhost php.dev with a document root /var/vhosts/php.dev/web for the examples below:

Firstly I ensure the vagrant user is a member of www-data and that my /tmp/symfony2 directory exists with correct ACL permissions.

user { $::ssh_username:
  shell  => '/bin/bash',
  home   => "/home/${::ssh_username}",
  groups => 'www-data',
  ensure => present,
  require => Group['www-data']
}

file { "/tmp/symfony2":
    ensure => directory,
    owner  => 'www-data',
    group  => 'www-data',
    mode   => 0775
}

exec { 'set_symfony2_permissions':  
  command => "setfacl -R -m g:www-data:rwX /tmp/symfony2 \
              && setfacl -dR -m g:www-data:rwX /tmp/symfony2",
  onlyif  => "test -d /tmp/symfony2",              
  logoutput => "on_failure",
  require => File['/tmp/symfony2']
}

and later on I ensure the document root parent directory is created with correct permissions and then the vhost directory and then I run setfacl on both

if count($apache_values['vhosts']) > 0 {
  each( $apache_values['vhosts'] ) |$key, $vhost| {
    # work out parent directory of vhost docroot
    $docroot_parent = join(delete_at(split($vhost['docroot'], '/'), size(split($vhost['docroot'], '/'))-1), '/')    

    # ensure parent directory exists
    exec { "exec mkdir -p ${docroot_parent} @ key ${key}":
      command => "mkdir -p ${docroot_parent}",
      creates => $docroot_parent,
    }

    exec { "exec mkdir -p ${vhost['docroot']} @ key ${key}":
      command => "mkdir -p ${vhost['docroot']}",
      creates => $vhost['docroot'],
      require => Exec["exec mkdir -p ${docroot_parent} @ key ${key}"]
    }

    if ! defined(File[$docroot_parent]) {
      file { $docroot_parent:
        ensure  => directory,        
        group   => 'www-data',
        mode    => 0755,
        require => Exec["exec mkdir -p ${docroot_parent} @ key ${key}"]
      }
    }

    if ! defined(File[$vhost['docroot']]) {
      file { $vhost['docroot']:
        ensure  => directory,        
        group   => 'www-data',
        mode    => 0755,
        require => Exec["exec mkdir -p ${vhost['docroot']} @ key ${key}"]
      }
    }

    #setfacl permissions
    exec { 'set_vhost_dir_permissions':      
      command => "setfacl -R -m g:www-data:rwX ${docroot_parent} ${vhost['docroot']} \
                  && setfacl -dR -m g:www-data:rwX ${docroot_parent} ${vhost['docroot']}",
      logoutput => "on_failure",
      onlyif  => "test -d ${vhost['docroot']}",              
      require => [File[$vhost['docroot']], File[$docroot_parent]]
    }
  }
}

This enables the vagrant user to run commands in SSH and upload files over SFTP while still allowing the www-data user access to the files owned by the vagrant user when they are in /tmp/symfony2 or /var/vhosts/php.dev.

Files owned by the vagrant user happen as a consequence of running the 'php app/console' commands while SSH'ing in as the vagrant user. Valid permissions arise as a consequence of both vagrant and www-data users being members of the www-data group. The www-data group has write permissions to both /var/vhosts/php.dev and /var/vhosts/php.dev/web (where Symfony2 public assets go, i.e. the document root).

A similar setup was done for the /tmp/symfony2 directory where Symfony2 writes its cache and log files.

@pboethig

This comment has been minimized.

Show comment
Hide comment
@pboethig

pboethig Feb 6, 2016

In Case, that you dont see any cookie named "frontend" or "adminhtml", wenn you reload the page, the magento cookie wasnt set. In my case I have a wrong cookie_domain. I used "null" instead of "NULL".

As I set my cookie_domain to NULL in core_config_data, the problem was solved

pboethig commented Feb 6, 2016

In Case, that you dont see any cookie named "frontend" or "adminhtml", wenn you reload the page, the magento cookie wasnt set. In my case I have a wrong cookie_domain. I used "null" instead of "NULL".

As I set my cookie_domain to NULL in core_config_data, the problem was solved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment