Silently create perforce client from command line - jenkins

I need to create perforce clients from my jenkins build scripts, and this needs to be done unattended. This is mainly because jenkins jobs run in unique folders, Perforce insists that each client has a unique root target folder, and we create new jenkins jobs all the time based on need. Right now each time I create a unique jenkins job, I have to manually create a perforce client for that job - I can do this from the command line, but Perforce also insists on pausing the client creation to show me the specification settings file, which I need to manually close before the client is created.
To create the client I'm using
p4 -u myuser -P mypassword client -S //mydepo/mystream someclientname
and I'm using this awful hack to simultaneously kill notepad
p4 -u myuser -P mypassword client -S //mydepo/mystream someclientname | taskkill /IM notepad.exe /F
This sort of works, but it doesn't feel right. Is there an official/better way I can force p4 to silently force create a client?

Do this:
p4 -u user -P ticket client -S //depot/stream -o someclientname | p4 -u user -P ticket client -i

You can prepare client form upfront and pass the path by:
p4 client -i newClientForm.txt
I guess that you can have a script that prepare such file before calling p4 client.
Take a look on the default form that is popping up every time.
I don't know how you can deal with passing both options -S and -i though.

Related

How to export credentials from one jenkins instance to another?

I am using the credentials plugin in Jenkins to manage credentials for git and database access for my team's builds. I would like to copy the credentials from one jenkins instance to another, independent jenkins instance. How would I go about doing this?
UPDATE: TL;DR Follow the link provided below in a comment by Filip Stachowiak it is the easiest way to do it. In case it doesn't work for you go on reading.
Copying the $HUDSON_HOME/credentials.xml is not the solution because Jenkins encrypts paswords and these can't be decrypted by another instance unless both share a common key.
So, either you use the same encription keys in both Jenkins instances (Where's the encryption key stored in Jenkins? ) or what you can do is:
Create the same user/password, you need to share, in the 2nd Jenkins instance so that a valid password is generated
What is really important is that user ids in both credentials.xml are the same. For that (see the credentials.xml example below) for user: Jenkins the identifier <id>c4855f57-5107-4b69-97fd-298e56a9977d</id> must be the same in both credentials.xml
<com.cloudbees.plugins.credentials.SystemCredentialsProvider plugin="credentials#1.22">
<domainCredentialsMap class="hudson.util.CopyOnWriteMap$Hash">
<entry>
<com.cloudbees.plugins.credentials.domains.Domain>
<specifications/>
</com.cloudbees.plugins.credentials.domains.Domain>
<java.util.concurrent.CopyOnWriteArrayList>
<com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
<scope>GLOBAL</scope>
<id>c4855f57-5107-4b69-97fd-298e56a9977d</id>
<description>Para SVN</description>
<username>jenkins</username>
<password>J1ztA2vSXHbm60k5PjLl5jg70ZooSFKF+kRAo08UVts=
</password>
</com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
</java.util.concurrent.CopyOnWriteArrayList>
</entry>
</domainCredentialsMap>
</com.cloudbees.plugins.credentials.SystemCredentialsProvider>
I was also facing the same problem. What worked for me is I copied the credentials.xml, config.xml and the secrets folder from existing jenkins to the new instance. After the restart of jenkins things worked fine.
This is what worked for me.
Create a job in Jenkins that takes the credentials and writes them to output. If Jenkins replaces the password in the output with ****, just obfuscate it first (add a space between each character, reverse the characters, base64 encode it, etc.)
I used a Powershell job to base64 encode it:
[convert]::ToBase64String([text.encoding]::Default.GetBytes($mysecret))
And then used Powershell to convert the base64 string back to a regular string:
[text.encoding]::Default.GetString([convert]::FromBase64String("bXlzZWNyZXQ="))
After trying quite a few things for several days this is the best solution I found for migrating my secrets from a Jenkins 2.176 to a new clean Jenkins 2.249.1 jenkins-cli was the best approach for me.
The process is quite simple just dump the credentials from the old instance to a local machine, or Docker pod with java installed, as a XML file (unencrypted) and then uploaded to the new instance.
Before starting you should verify the following:
Access to the credentials section on both Jenkins instances
Download the jenkins-ccli.jar from one of the instances (https://www.your-jenkins-url.com/cli/)
Have User and Password/Token at hand.
Notice: In case your jenkins uses an oAuth service you will need to
create a token for your user. Once logged into jenkins at the top
right if you click your profile you can verify both username and
generate password.
Now for the special sauce, you have to execute both parts from the same machine/pod:
Notice: If your instances are using valid Certificates and you want to
secure your connection you must remove the -noCertificateCheck
flag from both commands.
# OLD JENKINS DUMP # 
export USER=madox#example.com
export TOKEN=f561banana6ead83b587a4a8799c12c307
export SERVER=https://old-jenkins-url.com/
java -jar jenkins-cli.jar -noCertificateCheck -s $SERVER -auth $USER:$TOKEN list-credentials-as-xml "system::system::jenkins" > /tmp/jenkins_credentials.xml
# NEW JENKINS IMPORT # 
export USER=admin
export TOKEN=admin
export SERVER=https://new-jenkins-url.com/
java -jar jenkins-cli.jar -noCertificateCheck -s $SERVER -auth $USER:$TOKEN import-credentials-as-xml "system::system::jenkins" < /tmp/jenkins_credentials.xml
If you have the credentials.xml available and the old Jenkins instance still running, there is a way to decrypt individual credentials so you can enter them in the new Jenkins instance via the UI.
The approach is described over at the DevOps stackexchange by kenorb.
This does not convert all the credentials for an easy, automated migration, but helps when you have only few credentials to migrate (manually).
To summarize, you visit the /script page over at the old Jenkins instance, and use the encrypted credential from the credentials.xml file in the following line:
println(hudson.util.Secret.decrypt("{EncryptedCredentialFromCredentialsXml=}"))
To migrate all credentials to a new server, from Jenkins: Migrating credentials:
Stop Jenkins on new server.
new-server # /etc/init.d/jenkins stop
Remove the identity.key.enc file on new server:
new-server # rm identity.key.enc
Copy secret* and credentials.xml to new server.
current-server # cd /var/lib/jenkins
current-server # tar czvf /tmp/credentials.tgz secret* credentials.xml
current-server # scp credentials.tgz $user#$new-server:/tmp/
new-server # cd /var/lib/jenkins
new-server # tar xzvf /tmp/credentials.tgz -C ./
Start Jenkins.
new-server # /etc/init.d/jenkins start
Migrating users from a Jenkins instance to another Jenkins on a new server -
I tried following https://stackoverflow.com/a/35603191 which lead to https://itsecureadmin.com/2018/03/26/jenkins-migrating-credentials/. However I did not succeed in following these steps.
Further, I experimented exporting /var/lib/jenkins/users (or {JENKINS_HOME}/users) directory to the new instance on new server. After restarting the Jenkins on new server - it looks like all the user credentials are available on new server.
Additionally, I cross-checked if the users can log in to the new Jenkins instance. It works for now.
PS: This code is for redhat servers
Old server:
cd /var/lib/jeknins
or cd into wherever your Jenkins home is
tar cvzf users.tgz ./users
New server:
cd /var/lib/jeknins
scp <user>#<oldserver>:/var/lib/jenkins/user.tgz ~/var/lib/jenkins/.
sudo tar xvzf users.tgz
systemctl restart jenkins
Did you try to copy the $JENKINS_HOME/users folder and the $JENKINS_HOME/credentials.xml file to the other Jenkins instance?

How to configure user and password for neo4j cluster without REST API

The version I use is neo4j-enterprise-2.2.0-M02
My question is :
How can I configure a user (like add a new user, change the password ,etc) in backend or browser, instead of REST API? Can I do it via neo4j-shell? imagine that I am a DBA, it is not very convenient to do this by REST API.
Any help will be greatly appreciated!
You can use the browser instead of the API. Just go to http://localhost:7474 (or whatever IP to which the web console is bound) and you will be prompted to change the password. Once authenticated, use the command :server change-password to change the password again.
It is not yet possible to create multiple user accounts within the system.
You can use the command :help server to see available authentication commands.
Although still utilizing the REST API, I'll throw the cURL option out there to anyone who doesn't have access to a web browser (AWS instance, for example):
$ curl -H "Content-Type: application/json" -X POST -d '{"password":"WHATEVER THE PASSWORD IS"}' -u neo4j:neo4j http://localhost:7474/user/neo4j/password
Another option is to modify the auth file directly and restart neo. Doing this, you can even change the username!
Run
find / -name dbms
For me this gave one hit:
/var/lib/neo4j/data/dbms/auth
Save this code as build_auth_string.sh:
#!/bin/bash
DEFAULT_IFS="$IFS"
SALT_LEN=32
# either read from stdin or use the argument
if [ -z "$1" ]; then
read INPUT
else
INPUT="$1"
fi
if [ -z "$INPUT" ]; then
echo "correct format <uname:pass>"
exit
fi
IFS=':'
read -a UNAME_PASS <<< "$INPUT"
UNAME="${UNAME_PASS[0]}"
PASS="${UNAME_PASS[1]}"
# representing the password in hex format like \xAB\x0C etc
# HEX_PASS=$(echo -n $PASS | xxd -p | awk '{print toupper($1);}' | sed -r 's/(.{2})/\\x\1/g')
HEX_PASS=$(echo -n $PASS | hexdump -v -e '"\\\x" 1/1 "%02X"')
# echo $HEX_PASS
# create the salt and store it in hex format
SALT=$(cat /dev/urandom | tr -dc 'a-f0-9' | fold -w $SALT_LEN | head -n 1)
# SALT="28FD26AD92D6D2D8820E969F3F3732B4"
HEX_SALT=$(echo -n $SALT | sed -r 's/(.{2})/\\x\1/g')
# calculate the sha256 sum of the salt and password value
# need to split the output because the output ends with a hyphen
IFS=' '
read -a PASSWORD_HASH_ARRAY <<< $(printf $HEX_SALT$HEX_PASS | sha256sum)
PASSWORD_HASH="${PASSWORD_HASH_ARRAY[0]}"
# echo "$UNAME;$PASS;$SALT"
# echo "$PASSWORD_HASH"
# and print out the auth string
COMBINED=$(echo -n "$PASSWORD_HASH,$SALT" | awk '{print toupper($1);}')
echo "$UNAME:SHA-256,$COMBINED:"
IFS="$DEFAULT_IFS"
The code for the above came from https://github.com/artsince/docker-neo4j-auth/blob/master/build_auth_string.sh - im posting it here just encase..
And then just run the above script like
build_auth_string.sh myUsername:myP#ssw0rd
Copy/paste that into your auth file replacing whatever was there before, and restart neo4j :)
A fresh install of Neo4j 2.2.x has a user 'neo4j', with an initial password 'neo4j'. You are required to change the password before you can do anything.
It's easy to do this from the command line, by calling httpie to interact with the REST API. For example, to set a new password of 'foobar', run this command:
http -a neo4j:neo4j POST http://localhost:7474/user/neo4j/password password=foobar
If you want to reset the password and you dont know the old password :
then for Windows user
go to this path:
C:\Users\xyz\Documents\Neo4j\default.graphdb\dbms
and delete that auth file.
Restart the neo4j they will again ask to set the username and password!!
by default
username:neo4j
password:neo4j
Currently it's not possible to configure authorization using neo4j-shell. As you've mentioned the REST API is the way to go. Using a convenient REST client this is very easy.
My tools of choice is either postman (a plugin for chrome browser) or httpie for the command line. E.g. with httpie changing the password for a user is as simple as:
http localhost:7474/user/neo4j/password password=neo4j new_password=mypass
Be aware that password (and other authorization settings) are not automatically distributed in a cluster, see the manual how to copy over settings between instances.
For Mac users, version 2.3.1 of Neo4J, best way to reset credentials is to remove the file with credential information and start the service again.
Steps to follow
Find where the file that contains credentials is located from the browser console (localhost:7474). Go to Star (Favourites)->System->Server configuration
Search for dbms.security.auth_store.location property to see where it points to. In my case it was /Users/felipe/Documents/Neo4j/default.graphdb/./dbms/auth
Delete that file.
Start the service again and go to the console again (localhost:7474).
By default you will be asked to set the password for the user neo4j.
I hope it helps.
To elaborate on felipe's response (since I do not have enough rep points to comment):
I stopped the server, I deleted the auth files in BOTH:
DBROOT\data\auth
DBROOT\dbms\auth
Restarted the server, and connected to it via the localhost:7474, used the default username/password (neo4j/neo4j) and then it prompted me for a new password.
On Neo4j 4.0+, you can run:
$ cypher-shell
If it's the first time you connect, you can enter neo4j as user and password and you will be prompted to set a new password.
If you want to change the password afterwards, you can write in the Cypher shell:
:server change-password

How to add accounts to Jenkins without the web interface?

I want to automate the entire installation of Jenkins, given a list of user names I want to be able to create user accounts for each. The only method I've read to set up user accounts is here:
https://wiki.jenkins-ci.org/display/JENKINS/Standard+Security+Setup
Tried seeing if there was an option to configure with command line at:
https://localhost:8080/cli/
But does not seem to the be case.
Is it possible to add user accounts without using the web interface? More specifically a method that is scriptable.
My last resort is to do raw post requests but hoping there is a nicer way.
Yes of course, it is possible to script provisioning for jenkins. But not with the cli tool alone.
I guess you want to use "Jenkins own user database" with Project Matrix Authorization Strategy.
Steps to prepare provisioning:
Configure your Jenkins manually (enable security, add rolls and at least one user)
Shutdown your jenkins (to let him write all in-memory changes to disk)
Copy $JENKINS_HOME/config.xml to your provisioning script (as as seed data)
Copy $JENKINS_HOME/users/ (as seed data)
Get the cli tool: cd /tmp; wget -nv http://localhost:8080/jnlpJars/jenkins-cli.jar
If you do not want to have static seed data (one config.xml for each user) you can generate a (users/username/)config.xml using a bash script or a more advanced tool. But for simplicity sake you can take users/username1/config.xml as a template. Replace relevant data with a placeholder e.g. "PLACEHOLDER_FULLNAME" for full user name.
e.g.:
change
"<fullName>sample full username</fullName>"
to
"<fullName>PLACEHOLDER_FULLNAME</fullName>"
In your provisioning script, iterate over all users. For each user, replace each placeholder with the correct value.
e.g.
cp $SEED_DATA/templates/user/config.xml /tmp/config.xml
sed -e "s/\${PLACEHOLDER_USERNAME}/1/" -e "s/\${ChuckNorris}/dog/" /tmp/config.xml
sed -e "s/\${PLACEHOLDER_EMAIL}/1/" -e "s/\${he#findsyou.com}/dog/" /tmp/config.xml
...
mkdir -p $SEED_DATA/users/$USERNAME/
cp /tmp/config.xml $SEED_DATA/users/$USERNAME/config.xml
When you want to use generated users config.xml please generate for each user some permission settings in $JENKINS_HOME/config.xml:
<authorizationStrategy class="hudson.security.ProjectMatrixAuthorizationStrategy">
...
<permission>hudson.model.View.Create:username1</permission>
<permission>hudson.model.View.Delete:username1</permission>
<permission>hudson.model.View.Read:username1</permission>
...
<permission>hudson.model.View.Create:username2</permission>
<permission>hudson.model.View.Delete:username2</permission>
<permission>hudson.model.View.Read:username2</permission>
...
</authorizationStrategy>
Provisioning steps:
Install jenkins as you did before & maybe dynamic config generator (see above)
cp $SEED_DATA/config.xml $JENKINS_HOME/
cp -R $SEED_DATA/users/ $JENKINS_HOME/
chown -R "jenkins:jenkins" $JENKINS_HOME/users/ (maybe optional)
cd /tmp; java -jar jenkins-cli.jar -s http://localhost:8080/ reload-configuration

Jenkins Host key verification failed

I have a problem with jenkins, setting "git", shows the following error:
Failed to connect to repository : Command "git ls-remote -h https://person#bitbucket.org/person/projectmarket.git HEAD" returned status code 128:
stdout:
stderr: fatal: Authentication failed
I have tested with ssh:
git#bitbucket.org:person/projectmarket.git
This is error:
Failed to connect to repository : Command "git ls-remote -h git#bitbucket.org:person/projectmarket.git HEAD" returned status code 128:
stdout:
stderr: Host key verification failed.
fatal: The remote end hung up unexpectedly
I've also done these steps with "SSH key".
Login under Jenkins
sudo su jenkins
Copy your github key to Jenkins .ssh folder
cp ~/.ssh/id_rsa_github* /var/lib/jenkins/.ssh/
Rename the keys
mv id_rsa_github id_rsa
mv id_rsa_github.pub id_rsa.pub
but still not working git repository in jenkins.
thanks by help!.
Change to the jenkins user and run the command manually:
git ls-remote -h git#bitbucket.org:person/projectmarket.git HEAD
You will get the standard SSH warning when first connecting to a new host via SSH:
The authenticity of host 'bitbucket.org (207.223.240.181)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?
Type yes and press Enter. The host key for bitbucket.org will now be added to the ~/.ssh/known_hosts file and you won't get this error in Jenkins anymore.
Jenkins is a service account, it doesn't have a shell by design. It is generally accepted that service accounts. shouldn't be able to log in interactively.
To resolve "Jenkins Host key verification failed", do the following steps. I have used mercurial with jenkins.
1)Execute following commands on terminal
$ sudo su -s /bin/bash jenkins
provide password
2)Generate public private key using the following command:
ssh-keygen
you can see output as ::
Generating public/private rsa key pair.
Enter file in which to save the key (/var/lib/jenkins/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
3)Press Enter --> Do not give any passphrase--> press enter
Key has been generated
4) go to --> cat /var/lib/jenkins/.ssh/id_rsa.pub
5) Copy key from id_rsa.pub
6)Exit from bash
7) ssh#yourrepository
8) vi .ssh/authorized_keys
9) Paste the key
10) exit
11)Manually login to mercurial server
Note: Pls do manually login otherwise jenkins will again give error "host verification failed"
12)once manually done, Now go to Jenkins and give build
Enjoy!!!
Good Luck
Or you can use:
ssh -oStrictHostKeyChecking=no host
This will be insecure (man in the middle attacks) but easiest solution.
The better way to do that is to generate correct mappings between host and ip address, so ssh will not complain:
#!/bin/bash
for domain in "github.com" "bitbucket.org"; do
sed -i "/$domain/d" ~/.ssh/known_hosts
line=$(ssh-keyscan $domain,`nslookup $domain | awk '/^Address: / { print $2 ; exit }'`)
echo $line >> ~/.ssh/known_hosts
done
Excerpt from gist.
I think, that many people didnt recognize, at least available since jenkins 2.361:
btw. No Verification is for sure not the best option.
Had same problem, i fix it like that :
reset permission on id_rsa* only for current user no group no other
chmod o-rwx ~/.ssh/id*
chmod G-rwx ~/.ssh/id*
ls -lart ~/.ssh/
-rw------- 1 jenkins nogroup 398 avril 3 09:34 id_rsa.pub
-rw------- 1 jenkins nogroup 1675 avril 3 09:34 id_rsa
And clear ~/.ssh/know_hosts
Now Connect as jenkins
sudo su jenkins
Try the jenkins commands
git ls-remote -h git#bitbucket.org:user/project.git HEAD
If no problem appears, now jenkins will be able to connect the repo (for me ^^ at least)
As for the workaround (e.g. Windows slave), define the following environment variable in global properties:
GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no"
Note: If you don't see the option, you probably need EnvInject plugin for it.
login as jenkins using: "sudo su -s /bin/bash jenkins"
git clone the desired repo which causes the key error
it will ask you to add the key by showing Yes/No (enter yes or y)
that's it!
you can now re-run the jenkins job.
I hope you this will fix your issue.
using https://bitbucket.org/YYYY/XX.git
you shoud delete username#
Make sure we are not editing any of the default sshd_config properties to skip the error
Host Verification Failed - Definitely a missing entry of hostname in known_hosts file
Login to the server where the process is failing and do the following:
Sudo to the user running the process
ssh-copy-id destinationuser#destinationhostname
It will prompt like this for the first time, say yes and it will also ask password for the first time:
The authenticity of host 'sample.org (205.214.640.91)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? *yes*
Password prompt ? give password
Now from the server where process is running, do ssh destinationuser#destinationhostname. It should login without a password.
Note: Do not change the default permissions of files in the user's .ssh directory, you will end up with different issues
I ran into this issue and it turned out the problem was that the jenkins service wasn't being run as the jenkins user. So running the commands as the jenkins user worked just fine.
Copy host keys from both bitbucket and github:
ssh root#deployserver 'echo "$(ssh-keyscan -t rsa,dsa bitbucket.org)" >> /root/.ssh/known_hosts'
ssh root#deployserver 'echo "$(ssh-keyscan -t rsa,dsa github.com)" >> /root/.ssh/known_hosts'
Best way you can just use your "git url" in 'https" URL format in the Jenkinsfile or wherever you want.
git url: 'https://github.com/jglick/simple-maven-project-with-tests.git'
SSH
If you are trying it with SSH, then the Host key Verification error can come due to several reasons.Follow these steps to overcome all the reasons.
Set the Environment variable as HOME and provide the address as the root directory of .ssh folder. e.g:- If your .ssh is kept inside Name folder.
C:/Users/Name.
Now make sure that the public SSH key is being provided in the repository link also. Either it is github or bitbucket or any other.
Open git bash. And try cloning the project from the repository. This will help in adding your repository URL in the known_host file, which is being auto created in the .ssh folder.
Now open jenkins and create a new job. Then click on configure.
provide the cloning URL in Source code management under Git. The URL should be start with git#github.com/......... or ssh://proje........
Under the Credential you need to add the username and password of your repository form which you are cloning the project. Select that credential.
And now apply and save the configuration.
Bingo! Start building the project. I hope now you will not get any Host Key verification error!
Try
ssh-keygen -R hostname
-R hostname Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts
Use ssh-keyscan should be much more easier:
ssh-keyscan bitbucket.org >> ~/.ssh/known_hosts
This command will put all required hosts to ~/.ssh/known_hosts. You will need to run this command inside your Jenkins machine. You can also create a job and put that command into the "Execute shell" section of the Configure of that job and then execute the job.
issue is with the /var/lib/jenkins/.ssh/known_hosts. It exists in the first case, but not in the second one. This means you are running either on different system or the second case is somehow jailed in chroot or by other means separated from the rest of the filesystem (this is a good idea for running random code from jenkins).
Next steps are finding out how are the chroots for this user created and modify the known hosts inside this chroot. Or just go other ways of ignoring known hosts, such as ssh-keyscan, StrictHostKeyChecking=no or so.
After ssh-keygen probably one only needs to copy the public key to remote host with:
ssh-copy-id -i ~/.ssh/mykey user#host
There is a safe and (relative easy) way to accomplish this, which should also work if you have separate worker nodes/clouds (like docker/kubernetes).
Adding host keys to Jenkins configuration
First go to a console and execute ssh-keyscan your_git_server.url
Copy the output of that command
Then navigate to https://YOUR_JENKINS_URL/manage/configureSecurity/
Scroll down to Git Host Key Verification Configuration
Paste the output of the command into the window. it should look like this:
Both bitbucket and github have pages about their keys and servers. Read them and ensure that you are adding the proper keys and not some random keys
Getting the ssh-keyscan via your Jenkins installation
If you for some reason do not have ssh-keyscan, you can go to the script console ( https://YOUR_JENKINS_URL/manage/script ) and paste in the following script:
def sout = new StringBuilder(), serr = new StringBuilder()
def proc = 'ssh-keyscan bitbucket.org'.execute()
proc.consumeProcessOutput(sout, serr)
proc.waitForOrKill(1000)
println "copy this to jenkins>\n$sout"
//println "err> $serr"

Jenkins, possible to set Jenkins to job to require password?

Some of our Jenkins jobs are such that they deploy e.g. to a client acceptance test environment. It is very important that this type of jobs are not triggered by accident. Is it therefore possible to configure Jenkins to somehow require a password when triggering a specific build?
Set up Project based security, then you can restrict build access on a per-job basis.
From the help on the Jenkins configuration page:
[Project based security] is an extension to "Matrix-based security"
that allows additional ACL matrix to be defined for each project
separately (which is done on the job configuration screen.)
This allows you to say things like "Joe can access project A, B, and C
but he can't see D." See the help of "Matrix-based security" for the
concept of matrix-based security in general.
ACLs are additive, so the access rights granted below will be
effective for all the projects.*
ok.
my 5cents about this question.
Our Jenkins uses Redmine's mysql db as auth input.
in Jenkins you'll need next plugins:
Parameterized Build
Build User Vars Plugin
and after activating Password parameter, you'll be asked for it before build.
So, i figured out 2 options.
It is applicable, if your slaves has direct connection with mysql (or any DB engine).
then pre-build check:
SALT=$(mysql --defaults-extra-file="~/redmcheck.my" -B -se "select salt from redmine.users where login='${BUILD_USER}';")
HASH=$(mysql --defaults-extra-file="~/redmcheck.my" -B -se "select hashed_password from redmine.users where login='${BUILD_USER}';")
CHECK=$(sha1 -qs $SALT$(sha1 -qs $Password))
if [ $HASH != $CHECK ]
then
exit 1;
fi
It will broke build, if your entered password doesn't equal.
Second solution, is to use Rest API in Redmine.
And it allows to recheck user on remote slaves.
CODE=$(curl -X GET -u ${BUILD_USER}:${Password} --write-out "%{http_code}" -o /dev/null -s https://redmine/users/current.json);
if [ $CODE != "200" ]
then
exit 1;
fi
If it gets 200 code, so it goes build.

Resources