My deployment is putting the files on the server but all of the files have a modified time of 0 so Apache isn't hosting the updated files.
I added an AfterInstall script that is supposed to touch every file in the directory but it's not working for some reason. There is no error and if I run the script manually it works fine, just not during the deploy process.
Has anyone else run into this issue? Is there something simple I'm overlooking to make this work?
Touch script
#!/bin/bash
find /var/www/html/docs -type f -exec touch {} +
YML file
version: 0.0
os: linux
files:
- source: /source/
destination: /var/www/html/site/
file_exists_behavior: OVERWRITE
permissions:
- object: /var/www/html/site
pattern: "**"
owner: [redacted]
group: [redacted]
hooks:
AfterInstall:
- location: scripts/after_install
timeout: 10
runas: [redacted]
appspe.yml script:
version: 0.0
os: linux
files:
- source: /
destination: /home/ubuntu/
permissions:
- object: /home/ubuntu/
owner: root
group: root
mode: 777
hooks:
BeforeInstall:
- location: scripts/install_dependencies.sh
timeout: 300
runas: root
- location: scripts/start_server.sh
timeout: 300
runas: root
ApplicationStop:
- location: scripts/stop_server.sh
timeout: 300
runas: root
Unfortunately, it didn't copy the files to /home/ubuntu/ directory. With this, I am getting the following error while deploying through codedeploy
LifecycleEvent - BeforeInstall Script -
scripts/install_dependencies.sh Script - scripts/start_server.sh
[stderr]cp: cannot stat 'scripts/gunicorn.service': No such file or
directory [stderr]Failed to start gunicorn.service: Unit
gunicorn.service not found. [stderr]Failed to execute operation: No
such file or directory [stderr]Failed to restart gunicorn.service:
Unit gunicorn.service not found. [stderr]cp: cannot stat
'scripts/LIMA': No such file or directory [stderr]ln: failed to create
symbolic link '/etc/nginx/sites-enabled/LIMA': File exists
[stderr]ERROR: Bad port
What went wrong here?
I faced the same issue.
When I moved the commands in the "BeforeInstall" hook to the "AfterInstall" hook it worked for me.
Your errors seem to be of the following categories:
Missing files. ([stderr]cp: cannot stat 'scripts/gunicorn.service': No such file or directory).
Debug: Check if the file actually exists in your deployment bundle. Check the bundle itself and the logs here: less /opt/codedeploy-agent/deployment-root/deployment-group-ID/deployment-ID/. See here
Failure to create symlink because it already exists. ([stderr]ln: failed to create symbolic link '/etc/nginx/sites-enabled/LIMA': File exists). This is not related to file overwrite. Probably there is a 'ln' command somewhere in your script to create the symlink.
Debug: Modify the script to test the symlink for existence and then create it.
I hope this helps.
I'm using AWS Code Deploy in order to deploy my ASP.NET application into an auto-scaling group.
When deploying i've this error: Script at specified location: application-start.bat failed with exit code 66.
From what i've seen the error code 66 is "The network resource type is not correct", which is very bizzare in this case...
My bundle contains an appspec.yml file like this:
version: 0.0
os: windows
files:
- source: ./
destination: c:\inetpub\wwwroot
hooks:
ApplicationStop:
- location: application-stop.bat
timeout: 900
ApplicationStart :
- location: application-start.bat
timeout: 900
And the bat 2 files (application-stop / application-start) only contains one line each
iisreset /stop
iisreset /start
When i go to the EC2 instance to look at the aws code deploy logs, it's not more clear to me
2016-04-04 08:58:42 ERROR [codedeploy-agent(2848)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Error during perform: InstanceAgent::Plugins::CodeDeployPlugin::ScriptError - Script at specified location: application-start.bat failed with exit code 66
C:/Windows/TEMP/ocr512.tmp/src/lib/instance_agent/plugins/codedeploy/hook_executor.rb:150:in 'execute_script'
C:/Windows/TEMP/ocr512.tmp/src/lib/instance_agent/plugins/codedeploy/hook_executor.rb:107:in 'block (2 levels) in execute'
Does anyone run into the same issues and find a way to fix it ?
I am attempting to run a few scripts while deploying using AWS Code Deploy, but they never run due to not having permissions to run the scripts.
Here is my appspec.yml file:
version: 0.0
os: linux
files:
- source: /
destination: /var/www/html
permissions:
- object: /var/www/html/codedeploy-scripts
owner: root
mode: 777
type:
- directory
hooks:
ApplicationStop:
- location: codedeploy-scripts/application-stop
timeout: 300
runas: root
BeforeInstall:
- location: codedeploy-scripts/before-install
timeout: 300
runas: root
AfterInstall:
- location: codedeploy-scripts/after-install
timeout: 600
runas: root
ApplicationStart:
- location: codedeploy-scripts/application-start
timeout: 300
runas: root
ValidateService:
- location: codedeploy-scripts/validate-service
timeout: 300
runas: root
The codedeploy-scripts folder get deployed with the app and the permissions I set on the folder does not get set. The permissions on the folder always get reset to:
[ec2-user#ip-10-0-8-181 html]$ ls -al
total 156
drwxrwsr-x 7 ec2-user www 4096 Oct 13 16:36 .
drwxrwsr-x 3 ec2-user www 4096 Oct 13 15:01 ..
-rw-rw-r-- 1 ec2-user www 740 Oct 13 16:28 appspec.yml
drwxr-sr-x 2 ec2-user www 4096 Oct 13 16:36 codedeploy-scripts
...
The files in the folder seem to have executable rights:
[ec2-user#ip-10-0-8-181 alio]$ ls -al codedeploy-scripts
total 28
drwxr-sr-x 2 ec2-user www 4096 Oct 13 16:36 .
drwxrwsr-x 7 ec2-user www 4096 Oct 13 16:36 ..
-rwxr-xr-x 1 ec2-user www 343 Oct 13 16:28 after-install
-rwxr-xr-x 1 ec2-user www 12 Oct 13 16:28 application-start
-rwxr-xr-x 1 ec2-user www 12 Oct 13 16:28 application-stop
-rwxr-xr-x 1 ec2-user www 889 Oct 13 16:28 before-install
-rwxr-xr-x 1 ec2-user www 12 Oct 13 16:28 validate-service
Why doesn't the code get deployed with the permissions i set in the appspec file. The codedeploy-scripts folder should have 777 permissions but it never does.
This is the error i get in /var/log/aws/codedeploy-agent/codedeploy-agent.log for each of those scripts:
2015-10-13 16:36:23 WARN [codedeploy-agent(9918)]: InstanceAgent::Plugins::CodeDeployPlugin::HookExecutor: Script at specified location: codedeploy-scripts/validate-service is not executable. Trying to make it executable.
Any help would be appreciated.
The agent is executing the scripts directly from the extracted archive bundle not from any arbitrary places you might have copied them using the files section. You'll need to set the execute bit in your archive in S3 or Git repository.
What you have as is does this:
Copy all the files to /var/www/html.
Set permissions on the directory on the contents of /var/www/html/codedeploy-scripts to 777 but not the directory itself (See the appspec.yml reference). This will also be affected by umask, which you might be setting /etc/profile.
Execute each of the scripts for the lifecycle events (as they occur) from the archive root. So your ValidateSerivce script is running from <deployment-archive-root>/codedeploy-scripts/validate-service not from /var/www/html/codedeploy-scripts/validate-service
Note: ApplicationStop is special because it runs before new new archive bundle is downloaded.
Without more details, I won't be able to speak to why setting your scripts to be executable fixed your issue, but the accepted answer shouldn't have resolved anything other than the log statement you were seeing.
Take a closer look at the log:
2015-10-13 16:36:23 WARN [codedeploy-agent(9918)]: InstanceAgent::Plugins::CodeDeployPlugin::HookExecutor: Script at specified location: codedeploy-scripts/validate-service is not executable. Trying to make it executable.
It's only a warning, not an error. The Code Deploy agent noticed that your validate_service.sh script wasn't executable and it was "Trying to make it executable". If we look at the relevant Code Deploy agent code, you'll see that the agent will chmod +x the script itself.
When you set your scripts to be executable, you only silenced this warning, and it shouldn't have affected anything else. Looking back at the Code Deploy agent code, in L106, if the agent wasn't able to make your scripts executable you would have seen an error in your logs.
To answer your question on the permissions, you have a misconfigured appspec.yml. When you say:
permissions:
- object: /var/www/html/codedeploy-scripts
owner: root
mode: 777
type:
- directory
You are telling Code Deploy to set all files of type "directory" within /var/www/html/codedeploy-scripts to have permissions 777.
All of your scripts under codedeploy-scripts are "file" types (not "directory"), which is why their permissions weren't set, and the permissions only apply to files under the directory you specify, which is why the permissions on the codedeploy-scripts directory weren't set.
Here's the description of the appspec.yml permission's type option from the AWS docs:
type – Optional. The types of objects to apply the specified permissions to. This can be set to file or directory. If file is specified, the permissions will be applied only to files that are immediately contained within object after the copy operation (and not to object itself). If directory is specified, the permissions will be recursively applied to all directories/folders that are anywhere within object after the copy operation (but not to object itself).
I'd like to expand on an issue mentioned by Jonathan Turpie which can create a very weird situation.
From the docs on ApplicationStop:
This deployment lifecycle event occurs even before the application revision is downloaded. ... The AppSpec file and scripts used for this deployment lifecycle event are from the previous successfully deployed application revision.
Now imagine this situation:
A revision was deployed with botched ApplicationStop script permissions. The deployment still went fine because a previous version was used.
A new revision is pushed and fails the ApplicationStop step (because now it tried to execute the botched script from step 1).
You notice your mistake, fix the code, publish a new revision, but it still fails with the same error!
At this point it's not possible to fix the error by deploying new code. You only have two options:
In the deployment settings enable "Ignore Stop failures" (e.g. with the --ignore-application-stop-failures CLI flag [1])
Manually fix the file permissions in the previous successful deployment's root.
This concerns any stop script failures, not just permissions of course.
[1] https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html
Solving permission issues:
Hoping you are in the root directory where all your scripts .sh files reside:
chmod +x ./*.sh
This makes all .sh files executable
Add some script change_permissions.sh and add the following in the file:
#!/bin/bash
chmod -R 777 /var/www/html/
This will give your destination folder - /var/www/html/ executable permissions.
Finally asspec.yml file add somehow following:
BeforeInstall:
- location: change_permissions.sh
timeout: 6
runas: root
This will at run time in your ec2 instance apply the executable permission to the files.
I am having an issue with my Django Logger and after checking the Apache logs I can see that it is a permission error.
[Mon Dec 15 22:15:22 2014] [error] [client 134.226.38.233] ValueError:
Unable to configure handler 'file': [Errno 13] Permission denied:
'/var/www/bias_experiment/src/survey.log', referer:
http://phaedrus.scss.tcd.ie/bias_experiment/surveyone/
I changed the owner and group of the file (from me) to www-data with sudo chown www-data:www-data survey.log but this had no effect. Setting the write permissions to 777 gets rid of the error but I understand this is bad practice.
This answer to this question "Permission Denied when writing log file" has been very usefull but I do not understand one thing.
"You must make sure that the owner of the file is the service that's
trying to write something to it or that the file belongs to group of
the service or you'll get a permission denied error."
What is the name of the service or group that writes the Django Log file?
Setup:
Server: Ubuntu 12.04
Apache 2.2.22
mod_wsgi Version: 3.3-4ubuntu0.1
Python 2.7.3
Django 1.6
is the same user that run apache. it depends by the OS, common values are
www-data
httpd
you must grant write and execute privileges to the directory that 'contains' the file.