When I deploy with Capifony a Symfony2 project I get this error message in apache log when accessing a webpage:
PHP Fatal error: Uncaught exception 'RuntimeException' with message
'Failed to write cache file
"/var/deploys/acme/releases/20150219150638/app/cache/prod/classes.php"
In order to avoid this, each time I deploy I have to execute chmod 777 -R cache for fixing the permissions, which doesn't seem to me like a good solution.
The cache is set in the writable_dirs option, so I don't know exactly why it gives a permissions error:
set :writable_dirs, ["app/cache", "app/logs", "app/sessions"]
I have the following deploy.rb configuration:
set :stages, %w(production staging)
set :default_stage, "staging"
set :stage_dir, "app/config"
require 'capistrano/ext/multistage'
set :application, "Api"
set :domain, "<my_domain>"
set :deploy_to, "/var/deploys/acme.com"
set :app_path, "app"
set :repository, "git#bitbucket.org:acme/api.git"
set :scm, :git
set :model_manager, "doctrine"
# Or: `propel`
role :web, domain
role :app, domain, :primary => true
set :keep_releases, 3
# Be more verbose by uncommenting the following line
logger.level = Logger::MAX_LEVEL
# Other options
set :user, "root"
set :use_sudo, false
# Symfony2 specific configuration
set :shared_files, ["app/config/parameters.yml"]
set :shared_children, [app_path + "/logs", web_path + "/uploads", "vendor"]
set :use_composer, true
set :update_vendors, true
set :writable_dirs, ["app/cache", "app/logs", "app/sessions"]
set :webserver_user, "www-data"
set :permission_method, :chown
set :use_set_permissions, true
set :assets_install, true
set :dump_assetic_assets, true
task :upload_parameters do
origin_file = "app/config/parameters.yml"
destination_file = shared_path + "/app/config/parameters.yml"
try_sudo "mkdir -p #{File.dirname(destination_file)}"
top.upload(origin_file, destination_file)
end
after "deploy:setup", "upload_parameters"
UPDATE
The cache folder has the following permissions when deployed:
drwxrwxrwx 3 root root 4096 Feb 20 13:13 cache
Inside the cache folder, a prod folder is also created with these permissions:
drwxrwxr-x 7 root root 4096 Feb 20 13:13 prod
UPDATE 2
I use root as user because in the server the user root has my public ssh key. If I set another user in the config, it asks me for root password when deploying. However I have set the webserver_user variable in my config above. Also the user root it's not in the group www-data, should it be?
My capifony version it's 2.8.3. Here is an example of command it executes when setting permissions if chmod_alt is selected as settings permissions method:
getfacl --absolute-names --tabular ...
This error is also generated if I have chmod as setting permissions method.
Although the previous command gives an error, I think the command that provokes the roll back (with chmod_alt) is this one:
`echo stat /var/deploys/acme.devel/releases/20150226123037/app/sessions -c %U`
It generates the following error message (after which it makes a rollback):
cannot stat `/var/deploys/acme.devel/releases/20150226123037/app/sessions':
No such file or directory
I have set the following parameters in my deploy.rb in order to make it work:
set :use_sudo, true
default_run_options[:pty] = true
And I have removed app/sessions from writable dirs option:
set :writable_dirs, ["app/cache", "app/logs"]
If you are using linux you could try to configure ACL for these directories to not override them each time you deploy.
See "Setting up Permissions" Part in installation documentation
I prefer method like
$ sudo setfacl -R -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX app/cache app/logs
$ sudo setfacl -dR -m u:"$HTTPDUSER":rwX -m u:`whoami`:rwX app/cache app/logs
Your system probably doesn't support chmod +a. Try using:
set :permission_method, :chmod_alt
Related
I'm using gitlab on a rasberry pi model 3 B. Following some information about my setup (sudo gitlab-rake gitlab:env:info):
System information
System: Raspbian 8.0
Current User: git
Using RVM: no
Ruby Version: 2.3.6p384
Gem Version: 2.6.13
Bundler Version:1.13.7
Rake Version: 12.3.0
Redis Version: 3.2.11
Git Version: 2.14.3
Sidekiq Version:5.0.5
Go Version: go1.3.3 linux/arm
GitLab information
Version: 10.6.0-rc3
Revision: 52fa89e
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: postgresql
URL: http://gitlab.example.com
HTTP Clone URL: http://gitlab.example.com/some-group/some-project.git
SSH Clone URL: git#gitlab.example.com:some-group/some-project.git
Using LDAP: no
Using Omniauth: no
GitLab Shell
Version: 6.0.3
Repository storage paths:
- default: /mnt/SeagateExpansion/GitLab/repositories
Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks
Git: /opt/gitlab/embedded/bin/git
After the gitlab update to version 10.6.0 I need to change the url again but when I do the necessary changes in /etc/gitlab/gitlab.rb and run sudo nano gitlab-ctl reconfigure I get the following error messages:
========================================================================
Error executing action `run` on resource 'ruby_block[directory resource:
/mnt/SeagateExpansion/GitLab]'
========================================================================
and
============================================================================
Error executing action `create` on resource
'storage_directory[/mnt/SeagateExpansion/GitLab]'
============================================================================
The result message says:
There was an error running gitlab-ctl reconfigure:
storage_directory[/mnt/SeagateExpansion/GitLab] (gitlab::gitlab-rails line 42) had an error: Mixlib::ShellOut::ShellCommandFailed: ruby_block[directory resource: /mnt/SeagateExpansion/GitLab] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/storage_directory.rb line 33) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of chmod 00700 /mnt/SeagateExpansion/GitLab ----
STDOUT:
STDERR: chmod: changing permissions of ‘/mnt/SeagateExpansion/GitLab’: Operation not permitted
---- End output of chmod 00700 /mnt/SeagateExpansion/GitLab ----
Ran chmod 00700 /mnt/SeagateExpansion/GitLab returned 1
So the problem seems to be, that the execution of the run and create command on the resource storage (GitLab folder on the external HDD [HDD = SeagateExpansion]) expects the permissions to be 700, right?
According to this errors I tried to change the permission of
the external HDD folder /mnt/SeagateExpansion/GitLab see the ls -l output:
drwxrwxrwx 1 root GitLabUser 0 Jan 4 17:55 GitLab
With the help of this post I tried to change the permission with the command:
sudo find /mnt/SeagateExpansion/GitLab -type d -exec chmod 700 {} \;
to the required permission 700. But the changes don't take affect. I also tried chmod -R 700 /mnt/SeagateExpansion/GitLab and executed the commands as root but the changes don't take effect. Even after restarting the raspberry pi. What am I doing wrong?
I also tried to change the options settings/flag of the HDD in /etc/fstab to user but this doesn't help ether.
I'm thankful for every hint and answer :).
Best regards,
Bredjo
I finally figured it out. The solution is to change the mount settings in the /etc/fstab. Because if you have the wrong options settings (see: https://en.wikipedia.org/wiki/Fstab) you are not able to change the permissions because its a ntfs filesystem.
So my old fstab entry was this:
UUID=FE820568820526AD /mnt/SeagateExpansion ntfs defaults,gid=GitLabUser 0 0
And the new entry is this:
UUID=FE820568820526AD /mnt/SeagateExpansion ntfs-3g permissions 0 0
Note that you need to install ntfs-3g to use it in fstab. And the permissions options only comes with ntfs-3g. See: https://www.tuxera.com/community/ntfs-3g-advanced/ownership-and-permissions/
After this change I executed again:
sudo gitlab-ctl reconfigure
Now the error disappeared and the permission 700 of the folder /mnt/SeagateExpansion/GitLab could be set. I also noticed that the owner of the GitLab folder was also changed to user git after the reconfiguration:
drwx------ 1 git root 0 Jan 4 17:55 GitLab
That's because I don't need the option gid=GitLabUserany more.
Now everything works again :).
I'm trying to use gitlab-ci and capistrano to deploy my symfony application. But I can't deploy using SSH by injecting keys into docker, the script keeps prompting for password when connecting. I'm using a local instance of gitlab.
In gitlab's SSH_PRIVATE_KEY private variable, I added the git user's private key, and in SSH_SERVER_HOSTKEYS, the ssh-keyscan -H 192.168.0.226 command's result.
In file authorized_keys from deploy's .ssh folder, I put the git user's public key.
Here are the configurations files:
gitlab-ci.yml:
image: php:7.1
cache:
paths:
- vendor/
before_script:
# Install dependencies
- bash ci/docker_install.sh > /dev/null
- bash ci/ssh_inject.sh
stages:
- deploy
deploy:
stage: deploy
script:
- apt-get install ruby-full -yqq
- gem install capistrano -v 3.8.0
- gem install capistrano-symfony
- cap production deploy
environment:
name: production
url: http://website.com
only:
- master
ssh_inject.sh: link
#!/bin/bash
set -xe
# Install ssh-agent if not already installed, it is required by Docker.
# (change apt-get to yum if you use a CentOS-based image)
which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )
# Run ssh-agent (inside the build environment)
eval $(ssh-agent -s)
# Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store
ssh-add <(echo "$SSH_PRIVATE_KEY")
mkdir -p ~/.ssh
[[ -f /.dockerenv ]] && echo "$SSH_SERVER_HOSTKEYS" > ~/.ssh/known_hosts
deploy.rb:
# config valid only for current version of Capistrano
lock '3.8.0'
set :application, 'symfony'
set :repo_url, 'git#gitlab.local:symfony.git'
# Default deploy_to directory is /var/www/my_app_name
set :deploy_to, '/home/symfony'
set :symfony_env, "prod"
set :composer_install_flags, '--no-dev --prefer-dist --no-interaction --optimize-autoloader'
set :symfony_directory_structure, 3
set :sensio_distribution_version, 5
# symfony-standard edition directories
set :app_path, "app"
set :web_path, "web"
set :var_path, "var"
set :bin_path, "bin"
set :app_config_path, "app/config"
set :log_path, "var/logs"
set :cache_path, "var/cache"
set :symfony_console_path, "bin/console"
set :symfony_console_flags, "--no-debug"
# asset management
set :assets_install_path, "web"
set :assets_install_flags, '--symlink'
# Share files/directories between releases
set :linked_files, %w(app/config/parameters.yml)
set :linked_dirs, %w(web/uploads)
# Set correct permissions between releases, this is turned off by default
set :permission_method, false
set :file_permissions_paths, ["var/logs", "var/cache"]
set :file_permissions_users, ["apache"]
before "deploy:updated", "deploy:set_permissions:acl"
after "deploy:updated", "symfony:assetic:dump"
and production.rb:
server '192.168.0.226', user: 'deploy', roles: %w{app db web}
What could be wrong? I tried to set forward_agent to true but it's not working eather.
If I build the docker container manually and install all dependencies, the ssh connexion can be established without asking for password...
Here is the error:
EDIT:
Is there something to add in the runner configuration ? Here it is:
concurrent = 1
check_interval = 0
[[runners]]
name = "Docker runner"
url = "http://gitlab.local/ci"
token = "mytoken"
executor = "docker"
[runners.docker]
tls_verify = false
image = "php:7.1"
privileged = false
disable_cache = false
volumes = ["/cache"]
[runners.cache]
bash ci/ssh_inject.sh does not work because it is run in a different shell. use:
source ./ci/ssh_inject.sh
instead.
You need to create a ssh key on the gitlab runner with the gitlab-runner user.
Then add the pubkey of this key to your server in the authorized_keys file.
Solved by moving ssh_inject.sh content into gitlab-ci.yml.
If anyone has an idea about why it needs to be in gitlab-ci.yml, I'd like to understand.
I am deploying my Symfony2 web app onto an Apache web server, on an Ubuntu machine, hosted on AWS, using Capifony multistage deploy.
I have user set
set :user, "ubuntu"
And writable directory for cache set like so
set :writable_dirs, ["app/cache"]
set :webserver_user, "www-data"
set :use_set_permissions, true
set :permission_method, :acl
Everything is deploying fine apart from when this is run
executing "setfacl -R -m u:ubuntu:rwx -m u:www-data:rwx /var/www/releases/20140310012814/app/cache"
I get multiple Operation not permitted errors such as
setfacl: /var/www/releases/20140310012814/app/cache/prod/classes.php: Operation not permitted
It seems that the user, presumably 'www-data', cannot set permissions on files created by 'ubuntu'. However, I have run the following on the server from the /var/www/current directory, but I'm not entirely sure what they do:
sudo setfacl -R -m u:www-data:rwX -m u:`whoami`:rwX app/cache
sudo setfacl -dR -m u:www-data:rwx -m u:`whoami`:rwx app/cache
Here is some acl info
getfacl app/cache
# file: app/cache
# owner: ubuntu
# group: ubuntu
user::rwx
user:www-data:rwx
user:ubuntu:rwx
group::rwx
mask::rwx
other::rwx
default:user::rwx
default:user:www-data:rwx
default:user:ubuntu:rwx
default:group::rwx
default:mask::rwx
default:other::rwx
I have had a look at a similar issue here Should I run something similar? such as:
sudo sh -c 'setfacl -R -m u:ubuntu:rwX -m u:www-data:rwX /var/www/current/app/cache'
Thanks
Capifony has a cookbook entry explaining how to automatically set proper permissions. Basically what you need is this:
set :writable_dirs, ["app/cache", "app/logs"]
set :webserver_user, "www-data"
set :permission_method, :acl
set :use_set_permissions, true
:use_sudo doesn't need to be true as long as the :writable_dirs are owned by :user.
The problem
setfacl: /var/www/releases/20140310012814/app/cache/prod/classes.php: Operation not permitted
This message indicates that the cache directory isn't empty when the task is run (setfacl operates on prod/classes.php in that directory), which is not owned by :user (setfacl is not permitted).
The fact that the file is not owned by :user is quite normal because the webserver will create a lot of cache files, which make them owned by :webserver_user.
The strange thing here is that the cache directory isn't empty. Normally a new release should have an empty cache directory. A common cause for this is that the cache directory is shared, meaning you've added it to :shared_children. If so, please remove it. The cache directory shouldn't be shared.
If this is not the case, then try to find out why the cache directory isn't empty when the setfacl task is run. Maybe other tasks are running to soon.
Writable shared children
What if you actually want a shared directory to be writable for the webserver? This is actually very common, think of a media or uploads directory that should be shared.
The permissions should be set on the actual shared directory, not the symlink in the release directory. Capifony takes care of this for you, as long as the exact same phrase in :writable_dirs is also in :shared_children.
# this will work:
set :shared_children, ["web/uploads"]
set :writable_dirs, ["web/uploads"]
# this will also work:
set :web_path, "web" # is default
set :shared_children, [web_path + "/uploads"]
set :writable_dirs, ["web/uploads"]
# this will not:
set :web_path, "web" # is default
set :shared_children, [web_path + "/uploads"]
set :writable_dirs, ["web/uploads/"] # trailing /
Please check if the directory mentioned in the error is the actual shared directory (not the symlink).
The owner of the shared directory must be the user that will run the setfacl command. In other words, it must be :user. When you've changed the value of :user, or have had :use_sudo enabled in the past, this could cause issues. Please check if the directories (as set in :writable_dirs) are indeed owned by :user.
Capifony will perform a check if the permissions are already set. If so, it won't try to do it again. This is done with the following command:
getfacl --absolute-names --tabular #{dir} | grep #{webserver_user}.*rwx | wc -l"
Try to run this command manually (replace #{dir} and #{webserver_user} with the actual values) to see the outcome. If it yields no results, then Capifony assumes the permissions have not yet been set, and will try to do so.
In that case, manually check the permissions with getfacl. If they are indeed incorrect, manually set them (again, replace #{user}, #{webserver_user} and #{dir}) using "the power of root":
sudo setfacl -R -m u:#{user}:rwX -m u:#{webserver_user}:rwX #{dir}
sudo setfacl -dR -m u:#{user}:rwx -m u:#{webserver_user}:rwx #{dir}
Then run Capifony again. If all is well, it should succeed this time!
You have run the sudo setfacl on the current directory, but you are receiving the errors on the single releases folders. Anyway, www-data should be the right owner of the cache folder, it is the main user of that dir, in the end!
In our deploy script, we use this:
set :permission_method, :acl
set :writable_dirs, ["app/cache"]
set :webserver_user, "www-data"
set :use_set_permissions, false
set :use_sudo, false
I think this is the right solution.
This problem occurs when I try to install any themes inside my wordpress admin console.
I have tried change the owner of the /var/www directories (with chown -R <username> /var/www) I have also setup permission 755 for the directory. I realize the problem is due to the file's permission in the upgrade directory. The file has permission -rw-r--r-- (this directory and files inside are supposed to be created by the FTP user I supplied when installing the theme)
Do you have selinux installed?
You can check by going to the ssh window and type # sestatus
It should show you
SELinux status: enabled/disabled
SeLinuxfs mount: /selinux
Current mode: enforce/permissive
Mode from config file: enforce
Policy Version: XX
Policy from config file: targeted
if it's on 'enforce', you can temporarily change it to permissive to see if that's your issue but using
# setenforce 0
# getenforce // Should return permissive
Try to upload then. If it works you need to add that directory to tell selinux to allow httpd to write there.
chcon -R -t httpd_sys_rw_content_t DIRECTORY/PATH/THAT/YOU/WANT/TO/WRITE/TO/
Hope this helps
i try to deploy my symfony2 project with the help of capifony
cap deploy:setup
makes no problem and store on /var/www/htdocs/symfony-project two folders
.symfony-project
.. releases
.. shared
after that, when i try to run:
cap deploy:cold
i get
--> Updating code base with remote_cache strategy
--> Creating cache directory................................✔
--> Creating symlinks for shared directories................✔
--> Normalizing asset timestamps............................✔
--> Downloading Composer....................................✔
--> Installing Composer dependencies........................✘
*** [deploy:update_code] rolling back
failed: "sh -c 'sh -c '\\''cd /var/www/htdocs/symfony-project/releases/20130311124645 &&
php composer.phar install --no-scripts --verbose --prefer-dist --optimize-
autoloader'\\'''" on webservername.net
and there are no folders in
var/www/htdocs/symfony-project/releases/
my deploy.rb is the following one:
set :user, "user"
set :port, "12345"
set :application, "Application Name"
set :domain, "webservername.net"
set :deploy_to, "/var/www/htdocs/symfony-project"
set :app_path, "app"
set :repository, "ssh://#{user}#webservername.net:#{port}/var/repos/symfony-project.git"
set :scm, :git
set :branch, "master"
set :model_manager, "doctrine"
role :web, domain
role :app, domain
role :db, domain, :primary => true
set :use_sudo, false
set :keep_releases, 3
set :deploy_via, :remote_cache
set :use_composer, true
has anyone an Idea what could it be caused by?
It seems that you face a permission problem. Make sure you are entirely owner of your local .composer/ directory.
sudo chown -R user:user ~/.composer/ should resolve your issue.
In my case I faced the same error message. But the reason was a dependency which could not be resolved by composer.
Running cap staging deploy -d and stepping through each command, as #weyandch suggested, helped to find the command which failed.