Setting a laravel storage directory permission by ebextentions - laravel

I'm working on elastic beanstalk exextentions. A storage-permission-denied error occurs every deployments and I a have to type command to resolve that. Does the code below(.extensions/chmod.config), prevent the error occur ?
container_commands:
01addpermission:
command: "chmod -R 755 /var/app/current/storage"
01clearcache:
command: "php /var/app/current config:cache"

The code sadly will not work. The reason is that container commands run when your app is in the staging folder, not in current folder:
The specified commands run as the root user, and are processed in alphabetical order by name. Container commands are run from the staging directory, where your source code is extracted prior to being deployed to the application server.
You can try to use relative paths:
container_commands:
01addpermission:
command: "chmod -R 755 ./storage"
02clearcache:
command: "php . config:cache"
The alternative is to use postdeploy platform hook which runs commands after you app is deployed:
Files here run after the Elastic Beanstalk platform engine deploys the application and proxy server

Related

Laravel on ElasticBeanstalk 'log file permission denied' error keeps coming up even the permission is set in the .ebextensions config file

I am deploying my Laravel application to the ElasticBeanstalk environment. But I am having issue with laravel.log file permissions.
I deployed my application using "eb deploy" command. After I deployed, I access my application. But it is throwing the following error.
The stream or file "/var/app/current/storage/logs/laravel.log" could not be opened: failed to open stream: Permission denied
To solve the issue, I ssh into the server and run the following command.
sudo -u root chmod 777 -R /var/app/current/storage/logs
The problem is solved. Now my application is working. But I deploy my application again running "be deploy" command. After the deployment, the issue popped up again. To solve the issue in a consistent way. I tried to run the command in the .ebextensions config file as follow.
container_commands:
01-migrations:
command: "php artisan migrate --force"
02-log-storage-permissions:
command: "sudo -u root chmod -R 777 /var/app/current/storage/logs/"
I could deploy my application. But the issue still persists. It seems like the command is not working. What is wrong with my configuration and how can I fix it?
I believe that this is because container_commands run when your application is in the staging folder. Thus, after you run 02-log-storage-permissions, your /var/app/current will be replaced anyway with the staging folder. So your chmod wont persist.
To rectify the issue, you can try one of the two options:
Use
02-log-storage-permissions:
command: "sudo -u chmod -R 777 ./storage/logs/"
to change the logs in staging folder.
use postdeploy hook to run your script:
after the Elastic Beanstalk platform engine deploys the application and proxy server.

Laravel - AWS Beanstalk - Storage symlink not working (403 error)

I am using elastic beanstalk to deploy my laravel application. Everything is working fine except for my images as I need to create a symbolic link with storage to access it publicly.
P.S. Works fine on my local
My .ebextensions file is as follows -
commands:
composer_update:
command: export COMPOSER_HOME=/root && /usr/bin/composer.phar self-update
option_settings:
- namespace: aws:elasticbeanstalk:application:environment
option_name: COMPOSER_HOME
value: /root
container_commands:
01-install_dependencies:
command: "php /usr/bin/composer.phar install"
cwd: "/var/app/ondeck"
02_storage_sym_link:
command: "php artisan storage:link"
cwd: "/var/app/ondeck"
leader_only: true
Below is the log from my ec2 instance to confirm that the command worked just fine and the link was created successfully.
[2019-04-21T15:47:16.899Z] INFO [21538] - [Application update symlink alt2#208/AppDeployStage0/EbExtensionPostBuild/Infra-EmbeddedPostBuild/postbuild_0_Synchro/Test for Command 02_storage_sym_link] : Starting activity...
[2019-04-21T15:47:16.903Z] INFO [21538] - [Application update symlink alt2#208/AppDeployStage0/EbExtensionPostBuild/Infra-EmbeddedPostBuild/postbuild_0_Synchro/Test for Command 02_storage_sym_link] : Completed activity. Result:
Completed successfully.
[2019-04-21T15:47:16.903Z] INFO [21538] - [Application update symlink alt2#208/AppDeployStage0/EbExtensionPostBuild/Infra-EmbeddedPostBuild/postbuild_0_Synchro/Command 02_storage_sym_link] : Starting activity...
[2019-04-21T15:47:17.014Z] INFO [21538] - [Application update symlink alt2#208/AppDeployStage0/EbExtensionPostBuild/Infra-EmbeddedPostBuild/postbuild_0_Synchro/Command 02_storage_sym_link] : Completed activity. Result:
The [public/storage] directory has been linked.
The error I am getting is as follows which makes the images unavailable for public access.
Forbidden
You don't have permission to access /storage/blog/images/8Yhb4OZJQIKwlMGaGE803niTxyjfzNSVTj2BiPaP.gif on this server.
Any help guiding me to the right path is appreciated. Cheers!
EDIT 1 :
container_commands:
01-install_dependencies:
command: "php /usr/bin/composer.phar install"
cwd: "/var/app/ondeck"
02_storage_sym_link:
command: "ln -s storage/app/public public/storage"
cwd: "/var/app/ondeck"
03_give_ec2_user_perm_1:
command: "sudo chown -R ec2-user /var/app/current"
03_give_ec2_user_perm_2:
command: "sudo chmod -R 777 /var/app/current"
Tried creating the symlink manually plus gave permission to the ec2-user. But still no luck :(
Putting down an alternate option which does the job for people who are/might have a similar issue -
Use S3 for file storage in your Laravel application.
To make it happen -
Create a public S3 bucket.
Create an IAM user which has full access to
S3 bucket. (With the access key, the application will have
permissions to read and write in the S3 bucket.)
Update the config file filesystems.php to use the S3 bucket. (This config handles the storage config of the application.)
Refer the Laravel Doc for more info.
Thanks to #PranavanSp for his suggestion.
Container commands are run as root, that is why when you tried to run it as the ec2-user you couldn't. The ec2-user is not in the root user group.
Then when you create symlinks, try to do it in the actual app directory(current):
container_commands:
01-install_dependencies:
command: "php /usr/bin/composer.phar install"
cwd: "/var/app/ondeck"
02_storage_sym_link:
command: "ln -s storage/app/public public/storage"
cwd: "/var/app/current"
Or try to link directly as so:
container_commands:
01-install_dependencies:
command: "php /usr/bin/composer.phar install"
cwd: "/var/app/ondeck"
02_storage_sym_link:
command: "ln -s /var/app/ondeck/storage/app/public /var/app/current/public/storage"
EBS Files can be annoying to get right at first but worth it in the end. If this still doesn't work, maybe the user(appache I assume) that runs the server does not have access to that folder. To just quickly verify this just do a:
sudo chmod -R 755 /var/app/ondeck/storage/app/public

Docker permissions are different when running on CodeBuild

I am using ruby:2.5.1-alpine for my application's container image. When I run make release locally, which runs the following commands:
docker-compose build --pull release
docker-compose up --abort-on-container-exit test
The test stage runs the migrations, linter and specs. It runs without an issues. When I run the same exact command on CodeBuild which is using a aws/codebuild/ruby:2.5.1 as the host environment I get the following error:
Running RuboCop...
Inspecting 82 files
.................................................................................W
Offenses:
bin/console:1:1: W: Lint/ScriptPermission: Script file console doesn't have execute permission.
I checked the git permissions and everything looks kosher:
edit [...master ] git ls-tree HEAD bin/
100755 blob ad9a02fe6ed489beb105295de771cab5fa87a6af bin/console
100755 blob 9d87e9579b9c16c42d65301e8540888e044ba25d bin/run
100755 blob cf5febb7c6dd34aebdb862792fa147d06a9c5764 bin/setup
edit [...master ]
I added a debug statement to see what the permissions are at the time of the tests running and here is where it diverges.
Locally I get:
test_1_4d039799a73c | File permissions for bin/console are
#<File::Stat ino=10432530, **mode=0100755**, nlink=1, uid=1000, gid=1000,...>
And On the CodeBuild server I get:
File permissions for bin/console are
#<File::Stat ino=525319, **mode=0100666**, nlink=1, uid=0, gid=0, ...>
As I pasted the above I also noticed that the UID and the GID are different. So it looks like the permissions are not being set correctly:
RUN addgroup -g 1000 app && adduser -u 1000 -G app -D app
RUN chown -R app:app $APP_ROOT
WORKDIR $APP_ROOT
This was part of the issue:
https://forums.docker.com/t/not-able-to-change-permissions-for-files-and-folders-created-on-mounted-volumes/45769
After removing the volume for the stage that runs on CodeBuild the mid and gig are correct but the permissions themselves are still off.
·[36mcodebuild_1 |·[0m File permissions for bin/console are
#<File::Stat ino=2755035, mode=0100666, nlink=1, uid=1000, gid=1000...>
Not sure how to go about debugging this.

how to delete created server WebSphere Application Server Liberty Profile

I am working on docker images
setting up in docker file ...
# - Liberty installation of required features
RUN /opt/wlp/bin/featureManager install adminCenter-1.0 localConnector-1.0 jaxrs-1.1 jsp-2.2 jdbc-4.0 jndi-1.0 cdi-1.0 servlet-3.0 beanValidation-1.0 --when-file-exists=ignore --acceptLicense
RUN /opt/wlp/bin/server create my-server
...
but getting error
CWWKE0005E: The runtime environment could not be launched.
CWWKE0045E: It was not possible to create the server called cca-dist-d because the server directory /srv/www/servers/my-server already exists.
ERROR: Service 'appserver' failed to build: The command '/bin/sh -c /opt/wlp/bin/server create my-server' returned a non-zero code: 1
Is there way to remove such server before creation or any suggestions?
just for notice that rm -R does not work :-(
RUN /bin/bash -c 'rm -R /opt/wlp/bin/server/my-server'
---> Running in 83f*****bd
rm: cannot remove '/opt/wlp/bin/server/my-server': Not a directory
Regarding Liberty profile server deletion, it is as simple as to delete the entire directory. For example
rm -R WLP_HOME/usr/servers/my-server
Now about your error message, you should check why the server exist. Sounds like you have a problem in your setup.
And if you want to delete the my-server anyway, then you should remove the right directory. In your case:
rm -R /srv/www/servers/my-server
The servers are created into servers directory from WLP_USER_DIR environment. And the variable can be used to specify an alternate location for ${wlp.user.dir}. If this is specified, the runtime will look for shared resources and server definitions in the specified directory. Check server start script or README file for more information about the different environment variables.
In your case it seems that the WLP_USER_DIR is /srv/www/

Laravel and AWS Elastic Beanstalk - File Permissions

I've created a Laravel app and deployed it to an EC2 instance using Elastic Beanstalk. Everything seems to work except that PHP can't write to the storage directory so I get this error:
Error in exception handler: The stream or file "/var/app/current/site/app/storage/logs/laravel.log"
could not be opened: failed to open stream:
No such file or directory in /var/app/current/site/vendor/monolog/monolog/src/Monolog/Handler/StreamHandler.php:84
This looks like a permissions problem to me, so I've tried using the instructions at http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers-ec2.html to set the permissions.
I have one file 01permissions.config in the .ebextensions directory:
commands:
storage_permissions:
command: chmod -R 755 $EB_CONFIG_APP_ONDECK/site/app/storage
I get the following errors in server logs:
[ERROR] Command storage_permissions (chmod -R 755 $EB_CONFIG_APP_ONDECK/site/app/storage) failed
[DEBUG] Command storage_permissions output: chmod: cannot access ‘/site/app/storage’: No such file or directory
Any ideas what's going on here?
The issue was that I had ignored the logs directory so it wasn't on the server at all. It's not that the server couldn't write to it, it's that it didn't exist.
The default permissions for an instance created by Elastic Beanstalk are:
File 664
Dir 775
They are deployed and owned by the Apache user.
For anyone else with this problem... this would have worked:
container_commands:
01storage_permissions:
command: "chmod -fR 755 /var/app/ondeck/app/storage"

Resources