In my project we have a docker folder that we use to run the container. The issue is that when we run prettier i got this error:
[error] Unable to expand directory: .
[error] EACCES: permission denied, scandir '/home/nanez/my-project/docker/data/postgres'
This folder need root permissions to access and delete it (using sudo ofc). I already added the whole docker folder to .prettierignore and also the specific postgres folder and i still throwing the error. Here my .prettierignore:
## Deps
node_modules
cache
generated
docker
./docker
/docker/**/*
/docker/*
/docker/data/postgres
As you can see, I added the docker folder with all the posibilities that I thought.
If I run prettier with the negative pattern work good, for ex: npx prettier . '!./docker' --check. This run all without problem, but I'm wonder why I can't ignore directly with npx prettier . --check if already I have the docker folder in the .prettierignore.
I'm using WSL2 with Ubuntu 20.04LTS.
Thanks :)
Related
I have a file that I can't edit but needs to run on in a docker container. Because the file doesn't have an extension, I have to use chmod for setting the file executable. But after I build the docker image from the docker file I always get a "permission denied" error
My docker file:
FROM alpine
COPY . /home/guestuser/bin/gateway
RUN apk add libressl-dev
RUN apk add libffi-dev
RUN pwd
WORKDIR /home/guestuser/bin/.
RUN ["chmod", "+x", "gateway"]
RUN pwd
CMD ["/home/guestuser/bin/gateway"]
EXPOSE 11878
I alwas get this error:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"/home/guestuser/bin/gateway\": permission denied": unknown.
As I already mentioned, I am not able to edit the file I want to execute. What am I doing wrong?
You may try this simple one.
FROM alpine
COPY . /home/guestuser/bin/gateway
RUN apk add libressl-dev
RUN apk add libffi-dev
WORKDIR /home/guestuser/bin/
RUN chmod -R 755 /home/guestuser
CMD ["/bin/bash", "/home/guestuser/bin/gateway"]
Otherwise, run sleep command login to container and see your commands works manually
It looks like you are using the exec form of CMD, as shown here
There are two ways to use CMD. The first is the way you are already doing it, in exec form:
CMD ["/home/guestuser/bin/gateway"]
Or you could use shell form:
CMD /home/guestuser/bin/gateway
If you need a shell you could also explicitly call one in exec form, which is what Ganesh was trying to suggest.
CMD ["sh", "/home/guestuser/bin/gateway"]
But if that syntax is correct, why didn't it work?
Well, because this is assuming that gateway is a file. The issue is... it probably isn't.
When you run this command:
COPY . /home/guestuser/bin/gateway
From the reference:
Multiple resources may be specified but the paths of files and directories will be interpreted as relative to the source of the context of the build.
You are copying the entire contents of the build context into the directory /home/guestuser/bin/gateway. If you want to copy a specific file, you should name it explicitly rather than using . The COPY command's syntax is source first, then destination, as shown here.
So when you are trying to execute gateway, you are probably "executing" a directory named gateway. So long as there is more than one file in the build context, gateway will be a directory. That can include the Dockerfile itself, so even if the build context is a folder with just the Dockerfile and the script you want to run, you'll still pull in both files, which turns gateway itself into a directory.
Tests you can try
As proof that your Dockerfile CMD syntax is correct, try changing that CMD to something like this:
CMD ["top"]
Similarly, you can remove the CMD and just run the container in interactive mode. It will drop you in your WORKDIR, which is empty except for the gateway directory, complete with the contents of whatever directory structure was pulled in during the build process.
So, to make this work, change your COPY line to name the script you want:
COPY somescript /home/guestuser/bin/gateway
Other notes:
your default user here is root, so you don't need to chmod gateway
RUN pwd will only show the first time you build the container
I'm trying to build c++ project.
When I run the make command in terminal it works,
but when I do it through Jenkins, it shows me a message that files are missing.
What can be the problem, and how can I solve it?
The Error:
+ make
make -f enclave_lib.mk SGX_DEBUG=1
make[1]: Entering directory '/home/yoni/Documents/private_ledger-tp/CryptoLib'
mt19937ar.c:44:19: fatal error: stdio.h: No such file or directory
From your comments, the problem is that Jenkins is executed as root user, and can not find the lib stdio.h.
To fix this you can have several options:
locate stdio.h
You run this command from your user. It will give you the path to stdio.h. That you can feed in your make
sudo apt-get install build-essential
As a root user, you install build-essential. That should install this missing dependency
execute Jenkins with your privilege, not with root privilege
in your build process, connect to your account (su youruser)
It turned out that in our case it was an issue of environment variables.
What I did to solve it is
Getting the data on environment variables both from Terminal and Jenkins, and write them sorted into 2 files.
Comparing the 2 files with meld
Any variables that seemed relevant that the Terminal environment and the Jenkins didn't I placed into /etc/environment file (Jenkins takes additional environment vars from there)
env | sort > envInTerminal.txt
env | sort > envInJenkins.txt
meld envInTerminal.txt envInJenkins.txt
sudo gedit /etc/environment
I am migrating a Django application from Openshift v2 to v3 (In case you don't know, RedHat is shutting down v2 on September 30th, see: https://blog.openshift.com/migrate-to-v3-v2-eol/)
So, I am following this blog post to help me: https://blog.openshift.com/migrating-django-applications-openshift-3/ . I am new to all these Docker / Kubernetes concepts the new version is build upon.
I was able to make some progress : I managed to get a successful build of my app. Yet it crashes at deployment time:
---> Running application from script (app.sh) ...
/usr/libexec/s2i/run: line 42: /opt/app-root/src/app.sh: Permission denied
Indeed, app.sh has lost its x permission. I log into the failing container as debug and see it:
> oc debug dc/<my app>
> (app-root)sh-4.2$ ls -l /opt/app-root/src/app.sh
-rw-rw-r--. 1 default root 127 Sep 6 21:20 /opt/app-root/src/app.sh
The blog posts states "Ensure that the app.sh file is executable by running chmod +x app.sh.", which I did on my local repo. Whatever, I want to do it again directly in the pod, but it doesn't work:
(app-root)sh-4.2$ chmod +x /opt/app-root/src/app.sh
chmod: changing permissions of ‘/opt/app-root/src/app.sh’: Operation not permitted
So, how can I set the x permission to app.sh ? Thank you
Without looking into more details, any S2I builder image will gladly use your custom supplied run script to start the application in an alternative way.
Create .s2i/bin/ (mind the dot) in your source code directory, place the run script into it and rebuild the app in OpenShift - it will automatically use your custom run script upon deployment.
This is the preferred way of starting applications using custom commands in OpenShift.
Regarding your immediate problem, there is a very simple reason why you can not change the permissions of the script: you were trying to modify the permissions in the deployed pod, and not the builder pod. Deployed pods run using different UIDs, usually somewhere in the range of 100000000, and definitely do not match the file ownership as generated by the build. Hence permission denied.
The root cause of your problem (app.sh losing executable permissions) must be in the way the build process installs those files, and indeed looking at the /usr/libexec/s2i/assemble script in the base image does seem to reveal the culprit. The last two lines are:
# set permissions for any installed artifacts
fix-permissions /opt/app-root
If you wanted to change this part of the build instead of using a custom run script, I suggest you then create .s2i/bin/assemble in your project's source code and make it look sort of like this:
#!/bin/bash
echo "Running stock build:"
${STI_SCRIPTS_PATH}/assemble
echo "Fixing the mess:"
chmod 755 /opt/app-root/src/app.sh
This will fix whatever the stock build process does to file permissions, and will do it using the same UID as the rest of the build, so file ownership shouldn't be an issue.
as I stumbled upon this issue myself I've found a way to resolve it.
You have to make your file app.sh executable and push it in your repo as such.
If git does not track this modification as it did for me, you have to use: git update-index --chmod=+x app.sh for it to work.
I am deploying to Elastic Beanstalk with Deploybot. I need to change directory permissions for /app/tmp after deployment. The tmp directory in my cake 2 installation becomes unwritable and so forces an error.
Can anyone tell me how to do this (bearing in mind im using Deplybot and not the EB CLI)?
Thanks
You should be able to use a Container Command to chmod the directory appropriately. Something like this should work:
.ebextensions/01-chmod.config
container_commands:
chmod-tmp:
command: "chmod 777 /app/tmp"
Right.... couldn't get the container commands to do what I wanted so came at it from the other direction.
Put .gitignore files in all the tmp folders and set the content to:
*
!.gitignore
This ignored all the files but kept the folders.
I've linked a git branch to my Elastic Beanstalk environment and using git aws.push it deploys correctly.
I've now added a .extensions directory which contains a config script which should be creating a couple of directories. However, nothing appears to be happening.
I understand that the .extensions directory should be copied across to the ec2 instance as well but I'm not seeing it.
I've checked eb-tools.log and it's not mentioned in the upload.
Is there something additional that's required?
The script contains:
commands:
cache:
command: mkdir /tmp/cache
items:
command: mkdir /tmp/cache/items
chmod:
command: chmod -R 644 /tmp
You can find the run logs for this at /var/log/cfn-init.log.
In here I could see that the mkdir commands had worked initially but subsequently failed as the directory already existed.
Turns out that eb extensions run commands in alphabetical order so I had to change the commands to:
01command1:
02command2:
etc.
From this point on it worked fine.
Something else that was confusing me is that the .ebextensions directory in my local git repo was not appearing on the target instance directory. this is because once it's been run it will delete the directory.
Double check that your local script file has a .config extension. I was having a similar problem because my local file was called .ebextensions/01_stuff.yaml and it was fixed once I renamed it to .ebextensions/01_stuff.config.