I am encountering below error. I am able to set the property using System.setProperty("hudson.plugins.git.GitSCM.ALLOW_LOCAL_CHECKOUT", "true")
However, the issue still persists. Any pointers?
ERROR: Checkout of Git remote '<path to project folder>' aborted
because it references a local directory, which may be insecure.
You can allow local checkouts anyway by setting the system property
'hudson.plugins.git.GitSCM.ALLOW_LOCAL_CHECKOUT' to true.
I found the info I needed and propably helps you too in
https://issues.jenkins.io/browse/JENKINS-68571:
So, follow these steps:
$ sudo systemctl stop jenkins
$ sudo systemctl edit jenkins
[Service]
Environment="JAVA_OPTS=-Dhudson.model.DirectoryBrowserSupport.CSP= -Dhudson.plugins.git.GitSCM.ALLOW_LOCAL_CHECKOUT=true"
$ sudo systemctl restart jenkins
As per https://issues.jenkins.io/browse/JENKINS-68571:
it seems the System Property is read during initialization, thus changing it in Script Console does not change it.
In Script console use property on class directly:
hudson.plugins.git.GitSCM.ALLOW_LOCAL_CHECKOUT = true
Note that neither the System Property nor the class property persist across restarts.
A persistent solution depends on how you installed / start Jenkins.
If you are running via java -jar ..., add the system property there (java -Dhudson.plugins.git.GitSCM.ALLOW_LOCAL_CHECKOUT=true -jar ...).
Or, if you installed it using your systems package manager and your system is using systemd:
$ sudo systemctl edit jenkins
[Service]
Environment="JAVA_OPTS=-Dhudson.plugins.git.GitSCM.ALLOW_LOCAL_CHECKOUT=true"
$ sudo systemctl restart jenkins
running a container-job in an azure pipeline, I use a docker image ( conan ) which expects the build commands to be run under conan.
While I'm able to bootstrap the container in azure with --user root without issues using options
resources:
containers:
- container: builder
image: conanio/clang8
options: --user root
When I run a job
jobs:
- job: do_that
container: builder
steps:
- task: Bash#3
inputs:
targetType: inline
script: whoami
noProfile: false
noRc: false
I see that the user is 1001 which has been craeted by the azure bootstrap. I cannot use sudo / su since the user is not allowed to use sudo. I ask myself how would I ever run as a different user? The user has a specific ENV setup due to python shims for conan, special setups in ~/.conan, and all those kind of things.
This exact steps in azp runs automatically during the "container initialization" (right after docker create) in az using docker exec are:
# Grant user 'conan' SUDO privilege and allow it run any command without authentication.
groupadd azure_pipelines_sudo
usermod -a -G azure_pipelines_sudo conan
su -c "echo '%azure_pipelines_sudo ALL=(ALL:ALL) NOPASSWD:ALL' >> /etc/sudoers"
# Allow user 'conan' run any docker command without SUDO.
stat -c %g /var/run/docker.sock
bash -c "cat /etc/group"
groupadd -g 117 azure_pipelines_docker
usermod -a -G azure_pipelines_docker conan
The semantic idea is:
extract which user the image is designed to run on by default ( in our case conan / 1000
create a group azure_pipelines_sudo
grant this user sudo permissions without password requirements
grant this user conan permissions to access the docker socket aka run docker in docker commands
Seeing this setup I really wonder, why effectively then the docker exec statement is run using something along the lines as
docker exec -u 1001 ..
So effectively when the actual job is run, it is not using the user conan (1000) - so the one being configured to have all the capabilities like sudo / docker access - if that is by design, why doing the setup 2-4 at all?
Somewhat this looks like either a design flaw, a bug, or just a huge misunderstanding on my side.
I have seen this question but even though the title assumes, it is a very different question
Right now, this is not possible. I'am not sure what this whole concept is about, but for me that is not only an issue, it is an showstopper because one cannot workaround this issue.
Even though it is a simple answer - at least it is one.
Update:
This is not available at present.
For your concern:
So effectively when the actual job is run, it is not using the user conan (1000) - so the one being configured to have all the capabilities like sudo / docker access - if that is by design, why doing the setup 2-4 at all?
There is some related info in our official doc may related to this: since Azure Pipelines will docker create an awaiting container and docker exec a series of commands which expect the container is always up and running. https://learn.microsoft.com/en-us/azure/devops/pipelines/process/container-phases?view=azure-devops&tabs=yaml#linux-based-containers
There are three different authentication tokens used by an agent:
Agent registration token: used only when registering the agent in the agent pool
Listener OAuth token: used by the agent when listening for new jobs
Job-specific OAuth token: used by the agent when running an individual job
Even though that link question is not related to yours. But there is a comment is correct:
The agent itself is setup to run as a user. When the build runs it
runs in a container as user "containeradministrator"(root) which is a
docker user.
What you would like seems to be running a Docker container as a non-root user. This is actually not related to Azure DevOps Service side, more related to Docker.
Kindly check if this helps Connect to docker container as user other than root & this blog.
I have just installed docker toolbox on windows environnement (Windows 7 Pro) and I have got a network time out due to the entreprise proxy. How can I set the proxy in docker toolbox ?
Thanks for your help.
I encountered the same problem. Here is my solution.
Env:
Win7, Docker Toolbox 17.03, cmder terminal, behind enterprise proxy setting.
Solution:
in C:\Program Files\Docker Toolbox, find start.sh file. add following two proxy settings:
export http_proxy="http://hostname:port/"
export https_proxy="http://hostname:port/"
At least, it works for me.
I have a similar problem for Windows 7 but it was resolved by these steps :
Step 1. Create a batch script C:\Program Files\Docker Toolbox\kitematic_proxy.cmd with below configuration
set proxy=YOUR_PROXY
SET HTTP_PROXY=%proxy%
SET HTTPS_PROXY=%proxy%
for /f %%i in ('docker-machine.exe ip default') do set DOCKER_HOST=%%i
SET NO_PROXY=%DOCKER_HOST%
set DOCKER_HOST=tcp://%DOCKER_HOST%:2376
cd Kitematic
Kitematic.exe
Step 2. Open Oracle Virtual machine from the start menu , go to command prompt by clicking Show (Make sure your Oracle Vm is up and running)
enter
sudo vi /var/lib/boot2docker/profile
add this lines
export HTTP_PROXY=http://your.proxy.name:8080
export HTTPS_PROXY=http://your.proxy.name:8080
use your proxy address & port
this link help me a lot
https://github.com/docker/kitematic/wiki/Common-Proxy-Issues-&-Fixes
Note:
Don't forget to add 192.168.99.100 ip to your proxy setting's exception list (use inetcpl.cpl )
Don't forget to add HTTP_PROXY and HTTPS_PROXY to your user variable (Advance settings->Environment variables)
Don't forget to restart your pc
Installing docker on windows 7 (docker 18.09.0) behind an enterprise proxy was quite complicated for me. Here are the steps I followed:
set HTTP_PROXY variable in your windows environment (HTTP_PROXY=http://your_proxy:port)
install docker toolbox with installer or run in powershell as admin: choco install docker-toolbox (Warning! Don't use Docker for windows, as it targets Windows 10)
ensure you don't have any previous VM created by your previous attempts ( docker-machine ls should be empty. If not run: docker-machine rm default)
run in powershell as user: docker-machine --native-ssh create -d virtualbox --engine-env HTTP_PROXY=$HTTP_PROXY --engine-env HTTPS_PROXY=$HTTPS_PROXY default.
run C:\Program Files\Docker Toolbox\start.sh
Now run docker pull busybox. This should work.
I had an issue on my Windows 7 Docker toolbox installation
$ docker --version
Docker version 18.09.3, build 774a1f4eee
$ docker-compose --version
docker-compose version 1.23.2, build 1110ad01
When I tried
docker run hello-world
I received
Unable to find image 'hello-world:latest' locally
C:\Program Files\Docker Toolbox\docker.exe: Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while waiting headers).
See 'C:\Program Files\Docker Toolbox\docker.exe run --help'.
According to https://docs.docker.com/toolbox/faqs/troubleshoot/ I've registered my enterprise proxy in /var/lib/boot2docker/profile inside the docker machine:
Use ssh to log in to the virtual machine. This example logs in to the default machine.
$ docker-machine ssh default
docker#default:~$ sudo vi /var/lib/boot2docker/profile
Then I added my enterprise proxy in the end of the profile
export "HTTP_PROXY=http://host:port"
export "HTTPS_PROXY=http://host:port"
after that I continued the instructions
Add a NO_PROXY setting to the end of the file similar to the example below.
export "NO_PROXY=192.168.*.*"
Restart Docker.
After you modify the profile on your VM, restart Docker and log out of the machine.
docker#default:~$ sudo /etc/init.d/docker restart
docker#default:~$ exit
After that docker run hello-world command works well
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(amd64)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID:
https://hub.docker.com/
For more examples and ideas, visit:
https://docs.docker.com/get-started/
Configuration lost after PC restart
As #rsb2097 mentioned after every PC reboot Docker Machine lose the settings in /var/lib/boot2docker/profile. I face the same problem too and I don't know how to avoid this, but I made a script to write these settings simpler.
I thought that happens because I shut down the PC without stopping the docker machine (VirtualBox says that there are active connections on shut down): supposed that it damages.
I tried docker-machine stop but it doesn't help.
As a result I wrote AddDockerMachineProxy.cmd script that writes the proxy settings using plink.exe from Putty (https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html).
Usage
Restart the PC.
Run Docker Quickstart Terminal, I have following output:
Starting "default"...
(default) Check network to re-create if needed...
(default) Windows might ask for the permission to configure a dhcp server.
Sometimes, such confirmation window is minimized in the taskbar.
(default) Waiting for an IP...
Machine "default" was started.
Waiting for SSH to be available...
Detecting the provisioner...
Started machines may have new IP addresses.
You may need to re-run the `docker-machine env` command.
Regenerate TLS machine certs?
Warning: this is irreversible. (y/n): Regenerating TLS certificates
Waiting for SSH to be available...
Detecting the provisioner...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Run AddDockerMachineProxy.cmd script (plink.exe must be in %PATH%):
#echo off
echo Was "Docker Quickstart Terminal" run after the reboot to init the machine?
echo If not this script fails.
pause
set "exePlink=plink.exe"
set "connectionString=-pw tcuser docker#192.168.99.100"
echo Profile BEFORE:
call "%exePlink%" %connectionString% cat /var/lib/boot2docker/profile
if errorlevel 1 ( echo ERROR: PSCP failed !!! & goto BadExit )
echo APPENDING PROXY
call "%exePlink%" %connectionString% sudo bash -c "'echo export \"HTTP_PROXY=http://host:port\">> /var/lib/boot2docker/profile'"
if errorlevel 1 ( echo ERROR: PSCP failed !!! & goto BadExit )
call "%exePlink%" %connectionString% sudo bash -c "'echo export \"HTTPS_PROXY=http://host:port\">> /var/lib/boot2docker/profile'"
if errorlevel 1 ( echo ERROR: PSCP failed !!! & goto BadExit )
call "%exePlink%" %connectionString% sudo bash -c "'echo export \"NO_PROXY=192.168.*.*\">> /var/lib/boot2docker/profile'"
if errorlevel 1 ( echo ERROR: PSCP failed !!! & goto BadExit )
echo Profile AFTER:
call "%exePlink%" %connectionString% cat /var/lib/boot2docker/profile
if errorlevel 1 ( echo ERROR: PSCP failed !!! & goto BadExit )
echo Restart docker service:
call "%exePlink%" %connectionString% sudo /etc/init.d/docker restart
if errorlevel 1 ( echo ERROR: PSCP failed !!! & goto BadExit )
echo Testing connection
call docker image pull hello-world || ( echo ERROR: docker image pull is failed !!! & goto BadExit )
echo Done!
exit /b 0
:BadExit
echo ERROR !!!
exit /b 1
Ah! Actually with Docker Toolbox windows part is just very thin layer over created virtual machine, so my method is to configure virtual machine itself to make everything work. So.
0) Set global environment variables on Windows host machine
HTTP_PROXY = "http://login:password#yourproxy:8080"
HTTPS_PROXY = "http://login:password#yourproxy:8080"
Note caps letters! (also you can set FTP_PROXY and NO_PROXY)
1) Run Docker Quickstart Terminal, it will create virtual machine named default under you VirtualBox or whatever. Also it will display address of your newly created VM like
docker is configured to use the default machine with IP 192.168.99.104
2) SSH to this address (i.e. with PuTTY). Login:docker Password:tcuser
3) Run
echo '
{
"proxies":
{
"default":
{
"httpProxy": "http://login:password#yourproxy:8080",
"httpsProxy": "http://login:password#yourproxy:8080"
}
}
}' > /home/docker/.docker/config.json
This will force docker client (on VM!) to run containers with correct envs inside.
4) So now you can use docker client inside VM. To force Windows docker client (as well as docker-compose) also to set correct envs inside running containers, put the same config.json as in p.3 on Windows host machine to C:\User\<yourhomedir>\.docker directory.
Now check the environment inside running container
docker run -ti ubuntu env
HTTPS_PROXY=http://login:password#yourproxy:8080
https_proxy=http://login:password#yourproxy:8080
HTTP_PROXY=http://login:password#yourproxy:8080
http_proxy=http://login:password#yourproxy:8080
Note both CAPS and lower letter variables are set properly!
Final check for everything is ok:
docker run -ti ubuntu apt-get update
5) One issue you may face, is that address of your proxy is from network, which docker use when creating own networks, so it will spoil route to your proxy right after you will do docker network create. So make sure the proxy address is not like 172.18.x.x . If so force docker to use another address space for created networks by making another config on VM
sudo -i
echo '
{
"default-address-pools": [
{"base":"172.80.0.0/16","size":24}
]
}' > /etc/docker/daemon.json
Then restart dockerd /etc/init.d/docker restart
6) Do not restart your virtual machine, pause it when needed.
I'm working on a bash script for automatic MongoDB server installation and user creation.
#!/bin/bash
apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10
echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | tee /etc/apt/sources.list.d/mongodb.list
apt-get update
apt-get install -y mongodb-org
update-rc.d mongod defaults
sed -i 's/^auth = true/#auth = true/g' /etc/mongod.conf
sed -i 's/^#noauth = true/noauth = true/g' /etc/mongod.conf
service mongod restart
mongo user_creation.js
The script is run on a clean precise64 Vagrant VM. Add the Debian/Ubuntu repo to install the latest version (we're on Ubuntu 12.04 LTS, the maintained version is 2.0.X), add server to startup, set some variables in the MongoDB config file. Simple stuff really, however, the last line fails each and every time.
MongoDB shell version: 2.6.4 connecting to: test 2014-10-03T12:34.:56.000+0000
warning: Failed to connect to 127.0.0.1:27017, reason: errno:111 Connection refused
2014-10-03T12:34.:56.000+0000 Error: couldn't connect to server 127.0.0.1:27017
(127.0.0.1), connection attempt failed at src/mongo/shell/mongo.js:146
exception: connect failed
I thought maybe the server needed some time to load data or some other kind of initialization between its restart and the client connection so I tried putting a sleep 30 between the last two instructions : didn't work. However, removing the mongo execution from the script and starting it manually works like a charm every time! The .js is not the problem here, I've tested it and it's working alright.
Does anyone have any idea why the mongo cannot connect on its first try and how I could fix this? For now, I'll settle with this terrible (working) hack, but I'd rather have a cleaner, hackless script:
while :
do
RESULT=`mongo --eval "1;"`
echo $RESULT
if [[ "${RESULT:-null}" == *Failed\ to\ connect* ]]
then
sleep 1
else
mongo root_creation.js
break;
fi
done
It's ugly but after 1 to 10 tries, it ends up connecting and working perfectly.
I'm using a EC2 server instance. Used the following to install Jenkins:
wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins
but I need to install software on the Jenkins server so in my EC2 instance I did
sudo –s –H –u jenkins
to get into the jenkins server.
Then I tried to do
sudo cabal install quickcheck
but it prompted me for jenkins password.
I've been searching around the internet for 4hrs now and nothing is helping me get administrative privilege in the jenkins server.
So I'm building my project using the following command in shell:
sudo cabal clean
sudo cabal configure
sudo cabal build
sudo cabal install
This is the error I'm getting:
Started by timer
Building in workspace /var/lib/jenkins/jobs/Finance/workspace
Checkout:workspace / /var/lib/jenkins/jobs/Finance/workspace - hudson.remoting.LocalChannel#eea6dc
Using strategy: Default
Last Built Revision: Revision b638e2182dece0ef1a40232b1d75fa3ae5c01a5d (origin/master)
Fetching changes from 1 remote Git repository
Fetching upstream changes from origin
Commencing build of Revision b638e2182dece0ef1a40232b1d75fa3ae5c01a5d (origin/master)
Checking out Revision b638e2182dece0ef1a40232b1d75fa3ae5c01a5d (origin/master)
[workspace] $ /bin/sh -xe /tmp/hudson3500373817395137440.sh
+ sudo cabal clean
sudo: no tty present and no askpass program specified
Sorry, try again.
sudo: no tty present and no askpass program specified
Sorry, try again.
sudo: no tty present and no askpass program specified
Sorry, try again.
sudo: 3 incorrect password attempts
Build step 'Execute shell' marked build as failure
Sending e-mails to: ***#gmail.com
ERROR: Could not connect to SMTP host: localhost, port: 25
javax.mail.MessagingException: Could not connect to SMTP host: localhost, port: 25;
nested exception is:
java.net.ConnectException: Connection refused
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1934)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:638)
at javax.mail.Service.connect(Service.java:295)
at javax.mail.Service.connect(Service.java:176)
at javax.mail.Service.connect(Service.java:125)
at javax.mail.Transport.send0(Transport.java:194)
at javax.mail.Transport.send(Transport.java:124)
at hudson.tasks.MailSender.execute(MailSender.java:116)
at hudson.tasks.Mailer.perform(Mailer.java:117)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:786)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:733)
at hudson.model.Run.execute(Run.java:1592)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
at java.net.Socket.connect(Socket.java:579)
at com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:286)
at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:231)
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:1900)
... 17 more
Finished: FAILURE
Here is how you can fix it:
Stop Jenkins
Go go edit /var/lib/jenkins/config.xml
Change <useSecurity>true</useSecurity> to false
Restart Jenkins: sudo service jenkins restart
Navigate to the Jenkins dashboard to the "Configure Security" option you likely used before. This time, setup security the same as before, BUT set it to allow anyone to do anything, and allow user signup.
Go to www.yoursite.com/securityRealm/addUser and create a user
Then go change allow anyone to do anything to whatever you actually want users to be able to do. In my case, it is allow logged in users to do anything.
If you installed using apt-get in ubuntu 14.04, you will found the default password in /var/lib/jenkins/secrets/initialAdminPassword location.
Before installing jenkins, create a user named jenkins and set password there. Then after installing jenkins you can use the password you created.
With the default Jenkins installation using Homebrew on macOS this will output the initial password for the admin user:
sudo cat /Users/Shared/Jenkins/Home/secrets/initialAdminPassword
jenkins default administrator password is logged in log file in ubuntu
log file is situated in /var/log/jenkins/jenkins.log folder
password will be placed after this,
Jenkins initial setup is required. An admin user has been created and a password generated.
Please use the following password to proceed to installation:
After Jenkins is installed just run sudo cat /var/lib/jenkins/secrets/initialAdminPassword.
In the Jenkins login page:
User: admin
Password: the output from the above command
On ubuntu 19.04, the default password are stored in the home directory:
cat ~/.jenkins/secrets/initialAdminPassword
The password is present in the log generated by docker run image as shown in the example below.
Jenkins Docker run log
Additionally you can check the directory /var/jenkins_home/secrets/
Its in the file name initialAdminPassword
You can use
cat /var/jenkins_home/secrets/initialAdminPassword
In my case I was using Jenkins Docker Image and I found the initial admin password using this command:
cat ~/secrets/initialAdminPassword
You can always disable security, then go in and re-enable it with the settings you want.
By default, Jenkins account is created without password and with the login shell as /bin/false.
jenkins:x:496:493:Jenkins Continuous Integration Server:/var/lib/jenkins:/bin/false
Change the shell to /bin/bash and you should be able to login without password by sudo su - jenkins.
Command to change the shell is:
chsh -s /bin/bash jenkin
When you install jenkins on your local machine, the default username is admin and password it gets automatically filled.
I was running Jenkins executing java -jar jenkins.war.
In my case Jenkins wrote webroot in an stdout: webroot: $user.home/.jenkins. So admin secret key was placed in a ~/.jenkins/secrets/initialAdminPassword.
I don't believe that the Jenkins user that is installed via apt has a password. If it does, I have never seen documentation. Based on the commands you entered, I am guessing you are using a Debian distro?
Is there any particular reason you must use the jenkins user to do the install instead of the user which was set up when you created your instance?
When installing Jenkins from AWS Marketplace . . .
"A default user "admin"with the instance-id as password is created to secure the Jenkins instance."
On the AWS Console for EC2, with the instance selected, choose the "Usage Instructions" tab:
"AWS Marketplace Usage Instructions
Latest Versions: 2.19.4.2
A default user "admin"with the instance-id as password is created to secure the Jenkins instance. Once the instance is started, copy the public DNS hostname of the server in the AWS Management Console and enter it in your web browser. The welcome screen allows you to request a trial license, start and evaluation, enter a license key, or connect to your instance to Operations Center. Once the license step is done, your instance is fully functional. We recommend enabling security and backups. You can connect with SSH to the server using the "ubuntu"linux user. The JENKINS_HOME is located under "/var/lib/jenkins". Jenkins listens on the following ports: * HTTP 80: through HAProxy, can be configured to use HTTPS:443 instead * Jenkins SSH 2222: primarily for the CloudBees Git Validated Merge Plugin * Jenkins JNLP 10000: communication from Jenkins agents or Jenkins CLI configured to use JNLP protocol. Not exposed by default on security groups."
Similar to the Ubuntu answer above, the Windows admin default password is stored in {jenkins install dir}\secrets\initialAdminPassword file (default install location would it in C:\Program Files (x86)\Jenkins\secrets\initialAdminPassword )
If you don't create a new user when you installed jenkins, then:
user: admin
pass: go to C:\Program Files (x86)\Jenkins\secrets and open the file initialAdminPassword
I am a Mac OS user & following credential pair worked for me:
Username: admin
Password: admin
For me the best method of retrieving admin pass is by executing cat command inside the running container.
docker exec YOUR_JENKINS_CONTAINER cat /var/jenkins_home/secrets/initialAdminPassword
On Windows it can be found in the file "C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins\.jenkins\secrets\initialAdminPassword"
(I know OP specified EC2 server, but this is now the first result on google when searching Jenkins Password)
Jenkins Default username and password
username: admin
And
password available in the root directory .jenkins\secrets\initialAdminPassword just open the file and copy text and paste into password textbox.
Well,
Even I tried to log in with the admin/password which was failed.
So I created my own user like this.
Go to Jenkins home folder (C:\User.jenkins or you can find this in Jenkins server startup logs)
Go to Config file config.xml
set disableSignup to false false
if at all you want to disable login security
4.set ser security to false. true
For mac users: Just run this command
cat ~/.jenkins/secrets/initialAdminPassword
Initial Password of Jenkins is stored in the following directory
cat /var/lib/jenkins/secrets/initialAdminPassword
There are few steps to follow:
Go to the folder: C:\Users\Manjeet\.jenkins .(here in your case, there can be your system name or your name instead of mine)
Open config.xml file using any text editor.(recommended Notepad++)
Go to Line number seven which is like <useSecurity>true</useSecurity>.
So make it change this from true to false.
Save this file and close the window.
Open Command Prompt and start your Jenkins .
(java -jar jenkins.war --httpPort=8085).
Open browser and search for your localhost at your given port number.
(localhost:8085)
You will see it doesn't ask for username and password anymore. Now you have to delete
that existed user and Add new user for setting new username and password.
Steps to make new Admin:
1.Go to people option which present at second number at left hand side below Dashboard
Click on admin option present in a row and than click on delete.
Go to Dashboard, Click on Manage Jenkins, Click on Configure Global Security.
Check the box of Enable security option.
Check the box of Jenkins own user database option and Uncheck Allow user to sign up present just below of it.
6 . Check Logged-in user can do anything option and Uncheck Allow anonymous read access present just below of it.
Make it Save and it will give you a new form for creating new first user. Fill the details correctly and click on Create First Admin User .(it will automatically made a change on that config.xml file just save it. )