I have a MAC slave connected to my Jenkins master via Java WebStart (SSH not working).
I have an administrator user called 'qalab' who has logged into the m/c (it never sleeps).
Node system information is shown as the given image.
Now, I need to launch Safari browser via Selenium.
Whenever i run the test with Safari i get the below exception
java.lang.IllegalStateException: The expected Safari data directory does not exist: /Users/null/Library/Safari
(Chrome and Firefox works fine)
Selenium looks for Safari in /Users/ user.name /Library/Safari
I tried like this.
System.setProperty("webdriver.safari.driver", "/Users/qalab/Library/Safari");
But still, it does not seem to take this path and fails with above exception.
Is there any way to fix this?
Also why does it show the user.name as root. How to change it to my user - 'qalab'?
You really don't want to run your slave as Root (which the above information indicates you are doing). Jenkins slaves have no inherent need to have escalated privileges (we run our Master and Slave with non-administrator accounts) as long as your Jenkins home directory is in someplace they can access. In your case, your Jenkins home directory above appears to be /, which is probably not what you want to do, since you will run into permission problems if you aren't root.
Any directory under your qalab user's home should work, as should any other directory that you create as long as the qalab user has privileges to read/write/execute on it (we tend to use a /Development/Jenkins directory, but that's an historical preference for us).
From one of our slaves:
user.dir /Development/Jenkins
user.home /Users/buildbot
user.name buildbot
Our master is similarly configured, and both work fine for us.
Related
I'm running into permissions issues renewing my certs with certbot-auto, because whenever it runs it displays this message:
Requesting to rerun certbot-auto with root privileges...
There is no need for it to run as root, because the user running the command has permissions on all directories used by certbot. I couldn't find any command-line options to disable this, but looking at the script itself I discovered that when it re-runs itself it checks for the argument
--cb-auto-has-root and if it's there it doesn't try to obtain root (again). I found that if I run certbot-auto with this command it runs just fine as non-root!
But I'm not sure if this workaround should be used - since it's undocumented - or will break in the future. What's the recommended way to run as a non-root user?
After updating macOS to Mojave (10.14.4), my Mac was restarted and upon opening Jenkins (at localhost:8080) it appeared that I've lost all my jobs and the entire system configurations.
There was only 1 user (admin) defined in my installation and my usual password was deemed invalid, when I tried to log back in. So, I tried entering another password I normally used and it was accepted. I then found that all my jobs and configs have disappeared. It looked as if I've just started Jenkins for the first time.
Looking through here on StackOverFlow, there were suggestions to check the JENKINS_HOME variable to find out where the jobs are saved on the disk, but when I typed export $JENKINS_HOME I just get an empty response. So, it looks like I've never configured it during set up.
I then dig through the hard drive and found the folders matching the names of the jobs I created under ~/.jenkins/workspace. However, the contents of all the folders are empty. I was expecting to see the usual files, e.g. build.xml, config.xml, etc.
I then did a global search for build.xml and config.xml on Mac Finder it turned up nothing.
Any idea where my jobs went and what could have caused all the contents of the folders of the jobs to be empty?
You can find your Jenkins installation directory in "Manage Jenkins" -> "configure System" --> "Home directory". Find what was the Jenkins home before you restart MAC. It looks like your home directory is either deleted by you or you are pointing to new folder now. Set it to earlier folder.
If can help,
I'm having a similar problem.
The curious part is about the new directory after the service restart ".jenkins" directory inside :
'/var/root/'.
And now, the password that Jenkins request me is not from
'/Users/username/.jenkins/secrets/initialAdministratorPassword' but from the newst one with same path pattern.
Simon
I've been having an issue trying to add github materials from a private repo on a Windows server.
I've seen lots of people suggesting how to add the ssh keys and where but on unix based systems. Haven't found anything related to Windows Servers.
I'm using Go latest release and have installed Go Server & Agent on a Windows Server 2008 with git installed.
I can connect to the private repo using Git Bash.
Whenever I try to add the materials it keeps saying Checking Connection and looks like it stays there forever.
If I use basic auth it works but I would like to make it work without exposing my password in the URL.
Is there a way to do that?
If you run Go under the default local system account, you can follow the suggestions from http://opensourcetester.co.uk/2013/06/28/jenkins-windows-ssh/ to setup the ssh keys for local system account.
If you run Go Server under a domain account (and not the default Local System account), check if you have uploaded your ssh keys to %USERPROFILE%/.ssh/ folder on the server machine, %USERPROFILE% being HOME folder for the domain user. Once you set that up, Go server would be able to pick the required keys. The same holds good for the agent machines. Just so you know, Go would not invoke Git-bash internally to run the git commands, so any setup on bash will not take effect when running git from within Go.
If you are using a windows machine to host GoCD server and agents , it does not run under a normal user account, it runs under the “Local System Account”
So even you can access your git repo from git bash (logged in as the current user),GOCD cannot access the same.
So you need to add the SSH keys for the Local System Account from your your current user.
1.First find the home directory for the Local System Account(It will not reside under C:/Users )
2.Use any remote administration tool to find the home directory- If you go with http://download.sysinternals.com/files/PSTools.zip
a)unzip and run command-line as administrator
b)PsExec.exe -i -s cmd.exe -start the tool )
c)run echo %userprofile% to get the home directory (eg:C:\Windows\system32\config\systemprofile)
3.Now you can either copy the SSH key files from current user or create a new one using ssh commands.
Try checking Connection after creating/copying the SSH keys, it will show Connection OK!
Jenkins puts the jenkins user's home to /Users/Shared/Jenkins by default. After we are setting up the Jenkins user correctly (making it admin, putting it into the Developer group: _xcs, changing password, allow it to login automatically, run as a LauchAgent, etc.).
Because it is in the Shared folder everyone has writing and reading permissions to this directory, not just Jenkins. (Correct me if I'm wrong: if we leave things by default and one day we enable File Sharing every user on the network will have Read & Write permissions to Jenkins's home.)
I don't believe it would be a great thing (everyone has access for the .ssh/ folder, so the private keys won't be private for long...), what are the recommendations for solving this possible issue?
Currently I set everyone to no access (750). Is it a good solution?
drwxr-x---+ 21 jenkins _xcs 714B Jun 15 11:20 Jenkins
Before anybody shoots me down for this - I have already checked every appropriate thread and still not found a solution to my problem.
I have Hudson with git plugin installed on windows server (not my choice) and Hudson runs as a service. Git/bin is on the path. However I cannot clone the repository. Here is a shortened display of the console output:
Started by user anonymous
Checkout:workspace / C:\.hudson\jobs\sdf\workspace - hudson.remoting.LocalChannel#65394b
Last Built Revision: Revision 74200b32314231a5efdadd87bf36b42ec145c720 (origin/master)
Checkout:workspace / C:\.hudson\jobs\sdf\workspace - hudson.remoting.LocalChannel#65394b
Fetching changes from the remote Git repository
Fetching upstream changes from ssh://git.mccannlondon.co.uk/git/mccann_admin
[workspace] $ "C:\Program Files\Git\bin\git.exe" fetch -t ssh://git.mccannlondon.co.uk/git/mccann_admin +refs/heads/*:refs/remotes/origin/*
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 f1:48:2a:0a:d9:18:cf:2e:f2:8c:b3:25:7f:34:d5:34
Connection abandoned.
fatal: The remote end hung up unexpectedly
ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway
So it seems I need to authenticate the host however I'm not sure why hudson is starting the job as user anonymous when I have set the Administrator as owner of the hudson service.
Does anyone know:
a) how to change hudson's run user? or
b) connect to the remove computer with the same user account as hudson uses as to allow hudson to fetch?
If this has been posted before apologies but I spent a good few hours searching around and couldn't find anything.
Thanks
Lewis
This may be related to the question Git, Can’t clone repo on windows
The problem is that MSysGit starts PLink in the background, i.e. the terminal is not actually connected to the input of PLink. That means that you simply can't type anything into PLink.
You simply have to connect to the server once using PLink or PuTTY, answer Yes and from then on, you won't be asked again.
The tutorial from cletus can be helpful as well.
A good description of the issue can be found in this blog entry
the problem is that Hudson is a service and runs under the user "Local Service Account".
The next step is to add the trace manually the cache (a file) because I know you can do in Linux.
Wrong again, Windows does not have this cache as a file but uses the registry.
Searching in the register found an entry for my user (who had previously accessed the repository and added to the cache footprint) where the trace was stored and copied to HKEY_USERS so that users can access it.
The entry goes like this:
Key Name: HKEY_USERS\.DEFAULT\Software\SimonTatham\PuTTY\SshHostKeys
Class Name: NO CLASS
Last Write Time: 23.01.2009 - 18:35
Value 0
Name: dss#22:bla_bla.com
Type: REG_SZ
Data: 0xb477b...
From the command line, you can easily add the key as follows:
reg add HKEY_USERS\.DEFAULT\Software\SimonTatham\PuTTY\SshHostKeys /v dss#22:bla_bla.com /d 0xb477b...
Now Hudson, run as a service, go happily and smoothly to the repository where the code.
The 'started by anonymous' is telling you which Hudson user started the job. If you haven't created any Hudson users, then everything is started by 'anonymous'
It is not related to which OS user is executing the process.
You asked how to change the user that Hudson runs as: you need to edit the service (Control Panel->Administrative Tools->Services, double click the Hudson service and change the "Log On" to "This account").
Once the account is setup I make sure that the git server is in MINGW's (Git Bash's) ~hudson/.ssh/known_hosts, and that there's a ~hudson/.ssh/identity file in place. The only warning I have is that if you have cygwin installed on the box you need to make sure that %CYGWIN% is empty, otherwise you'll see key permission errors in the Hudson logs. My recommendation is that you simply set the CYGWIN environment variable to empty in Hudson.
I meet the same problem and after check git plugin, http://wiki.hudson-ci.org/display/HUDSON/Git+Plugin
It is stated to change the git path to /usr/bin/git in Global setting and config the git username
And it fixes my problem
Hope it works for you as well, by the way, I use ubuntu, but it should be the same