Hi I am having trouble working with the Hudson workspace. I am using fabric to manipulate source files on the Hudson CI server. By default, the source files are downloaded from subversion server to workspace folder, with "hudson" as the owner.
On the ubuntu machine that runs Hudson CI, I cannot run the "cp" command on a source file even though the OS user belows to admin and adm group and also a sudoer. The error looks like:
cp: cannot create regular file `b.t':
Permission denied
What am I missing? Thanks for the help.
Check the user that Hudson runs under. Check the destination directory, if the Hudson user really has permission to create a file. You can login as the Hudson user and try to copy the file manually.
If nothing else helps, ask a Linux expert.
Related
I have a project on my production server linux1.
I copied the project from linux1 to my Windows PC with Windows FileZilla.
Then I copied it to my test server linux2 from my Windows PC with Windows Filezilla.
On the linux2 test server I made some file permission changes on the files and also changed some of the code.
Then I copied the project from linux2 test server back to my Windows PC with Windows FileZilla.
If I now push the project from my Windows PC to my Git repository, and if I then pull the project on my production linux1 server, will the file permissions on linux1 change? Or will this just update the code?
Git only tracks one permission: the executable bit. All files are stored as 644 (owner rw-, group and other r--) or 755 (owner rwx, group and other r-x).
When you pull on your production server files' executable bits will be updated according to how they were committed. Other permissions and file ownership are not tracked. The user doing the pulling needs permission to modify the files on the local filesystem and will probably become the owner of any modified files.
If you need further control over permissions you can run a script. Alternatively, use a deployment tool that has more robust control over file permissions (that's not what Git was designed to do).
As a side note, it would probably be simpler to just use git clone / fetch / pull on your staging server instead of going through your Windows PC.
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
I am currently learning Jenkins and how to utilize continuous integration. I am having an issue where all of my data/config files are reset after rebooting my PC. Has anyone had similar issues or am I missing something?
Sincerely, I didn't have this problem it's somehow strange because Jenkins, as I know, stores all the configurations in config.xml files in the installation directory. Not sure if it'll help you, but after a restart, if your data doesn't appear to be indexed in Jenkins, go to "Configure" and there you'll find "Reload configuration from disk".
What I didn't understood from your question:
after a restart of Jenkins+ PC, you data+settings don't appear in Jenkins GUI? Or they are also missing from the config.xml file from the installation directory. For example, if you create a user and a job, after a restart this settings are missing only from the GUI or also from config.xml & jobs directory.
How do you run Jenkins? You start Jenkins from Eclipse, you have it installed on your PC.
Does Jenkins have permissions to create/edit files in the installation directory? Be aware that after install, Jenkins creates a default username "JENKINS" and will try to edit files and create directories with that username on your PC.
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.
I need to grant jenkins user permission to access some specific directories like usr/lib or usr/local/include so that he can copy some files into those directories during the execution of some Jenkins jobs. How can I do that?
The idea that something accessed from the web can overwrite system files is very scary (and insecure), but I think you would need to grant the user under which Jenkins is running the privileges need to write there.
Again, there are good reasons why ordinary user's aren't granted permissions to write to those directories. You might want to consider running the job in a chroot jail. That way, if something goes wrong, you won't destroy your system.
For specific task i would say use sudo
You mentioned usr/lib or usr/local/include directories, and if your goal is to install some tools and packages during job execution, you could install it locally into your job workspace (for example, into .local directory) and after that make your jobs work with those directories by setting environment variables like LD_LIBRARY_PATH, CFLAGS, etc.