I am trying to run gitlab ci which contains custom php image. The before_script invokes docker_install.sh
In docker_install.sh I executed whoami it gives "docker". I tried to list down groups it gives "docker sudo".
When I try to execute further instructions in docker_install.sh file, like
cp ci/php.ini /etc/php/7.4/cli/php.ini
It does not execute and gives error cp: cannot create regular file '/etc/php/7.4/cli/php.ini': Permission denied
If I do
sudo cp ci/php.ini /etc/php/7.4/cli/php.ini
it executes successfully. However there are many such instruction for which I do not want to append sudo.
What is the solution to this problem?
Docker user doesn't have root permissions.
Gitlab CI doesn't allow you modifying the user
One way is to derive FROM the original image by Dockerfile set user to USER root and after you have finished with your installation back to USER docker. Or leave it at root and just run your CI job.
Another less secure way is using su-exec (instead of sudo)
https://github.com/ncopa/su-exec
Related
What is the difference between the following two command lines?
root#superhero:~/Workspace/# sudo git push origin master
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
root#superhero:~/Workspace/# git push origin master
Everything up-to-date
Using sudo causes the command to run as the root user. The Git command uses credentials and configuration stored in the current user's home directory; when you run as sudo, this code is going to be looking at the root home directory, not your home directory and thus miss this context.
In most cases, it should not be necessary to use sudo. There are very few cases where it is required (such as installing software globally such as with apt-get) and when it comes to programming, use of sudo is often but not always an anti-pattern (in order to ensure that source code is hermetic and reproducable, most software should be installed in the repository, not globally).
When you are using sudo in your command. This is the root user that execute the command. The key used to access to your git server are store in a directory (.ssh/). When you run the command in root. The directory is the '.ssh/' of root so not the good one.
Another point, with sudo, this is a user from sudo group that execute the command. So the sudo group does not have access to your.ssh
Jenkins was running all fine on a RedHat Linux machine (a clean EC2 machine on AWS), until I decided to change the JENKINS_HOME. I simply moved the Jenkins directory from /var/lib/jenkins to /home/ec2-user/jenkins and then created a symlink. (I followed the first answer to this question: Change JENKINS_HOME on Red Hat Linux?).
However when I restart Jenkins I get the error:
Unable to create the home directory ‘/var/lib/jenkins’. This is most
likely a permission problem. To change the home directory, use
JENKINS_HOME environment variable or set the JENKINS_HOME system
property.
I tried changing JENKINS_HOME in /etc/sysconfig/jenkins, setting it to the new folder (which I suppose defeats the point of a symlink?) and I still get the same error
Unable to create the home directory ‘/home/ec2-user/jenkins’.
It is for backup purposes, so that I have all Jenkins data in a mounted external data storage (AWS Elastic File System).
I've figured it out. This error was persisting because the /jenkins/ folder needs to be accessible to user 'jenkins' to run processes, but it couldn't access this folder because it is belongs to the particular logged in user. I changed the mounting to /var/ where jenkins can access as global process, and it solved the problem.
I ran into the same problem, so sharing my solution here:
The user jenkins does not have access to the folder home/ec2-user/jenkins. You can modify the access rights of the folder home/ec2-user/home by changing or adding the user jenkins to owner
sudo chown jenkins /home/ec2-user/jenkins
sudo chmod u+w /home/ec2-user/jenkins
To verify the new ownership, you can do:
ls -ld /home/ec2-user/jenkins
The error seems pretty obvious: "This is most likely a permission problem."
I assume /home/jenkins does not exists, and the user jenkins does not have write permissions in /home. If you moved the Jenkins home, then you probably did it as root and just forgot to update owner permissions.
You would need to create the home, something like this:
sudo service jenkins stop
# make the changes in /etc/sysconfig/jenkins
sudo mkdir --parents /home/jenkins # or mv, in your case
sudo chown --recursive jenkins /home/jenkins
sudo service jenkins start
Ok I'm fairly new to UBUNTU but was just following some "simple steps", you know the sort that someone always claims will work out the box yet never ever does?
Anyway here's what I get:
# sudo docker run -i -v $PWD:/home/yyyy/work aaaa/bbbb git clone https://github.com/xxxx/yyyy.git
Cloning into 'xxxx'...
/home/yyyy/work/yyyy/.git: Permission denied
What do i do?
docker run ... aaaa/bbb git means running the aaaa/bbbb image (based probably on Ubuntu)
It depends on how that image was built (its Dockerfile): it the WORKDIR was set to /home/yyyy/work, but USER was set to another user, there would be a permission issue
I'm new to jenkins.
I got jenkins intalled with
...
sudo apt-get install jenkins
on a linux system.
I've got a project(s) with svn checkout.
Every time when jenkins checkout the svn-repo, the files ownership get root ownership ( root / root ).
But the jenkins is not an root user.
In some projects it make "mvn clean" impossible, or delete a folder.
I google about it
svn checkout as root
can do this.
I think about it, that i will run jenkins (service) as another user.
Manualy i set the workspace folder in jenkins to jenkins user / group.
But in some project after svn update is get back to "root / root" ownership.
I don't know the real reason for "svn as root".
I look for the answer, and I would appreciate help
It is very, very unlikely the checkout would create files owned by root if Jenkins was not running as root. Practically the only explanation is that Jenkins really running as root and you did not check it from a reliable source. The user which Jenkins reports under $JENKINS_URL/systemInfo might be wrong. (How did you check Jenkins is not running as root?)
Please check again by running something like
ps axu | grep java
or
top
and look for the java process and see who is the user running it.
How exactly to fix your installation depends how you installed Jenkins. Please provide more information if you need more help.
Set up a docker instance via pull ubuntu and then via base-image/docker, and then successfully installed node.js on top of this.
However, when I attempt to pull the repo of a node.js app that I'm working on, I get to an npm install action and then run into trouble because that action expects NOT to be run as root, and I have instantiated it via
docker run -name="{name}" -t -i {my custom docker container mirroring base-image) /bin/bash
which has logged me in as root. Is there a way to run docker not as root?
Yes -- you'll need to create the other user account inside the container according to whatever your container's Linux distro expects (here is an Ubuntu example).
Once you've got the user account set up, you can use the Dockerfile USER parameter to run the remaining commands in the Dockerfile as that user. Please see the PostgreSQL example for a full use case.
Where did the postgre user come from in that example? Debian packages create any users they need when they are installed. If you would like to create your own user you could add RUN useradd to your Dockerfile. For a full example, you could look at the Jira Dockerfile in this Atlassian Blog
As the operator you can also decide the user account to use at docker runtime, using the -u parameter. This would override the USER chosen in the Dockerfile.