TYK Dashboard and Gateway Environment Variables Usage - linux

i'm using licensed version of TYK Dashboard .So i need the change configuration of TYK Configs.
So at this link at the here https://tyk.io/docs/configure/dashboard-env-variables/ I've wanted to use environment variables at launch time of VM .
But these are not working on my machine (on-premis). I could not find the mistake in my approach .Please help .
My script is shown at below .
export TYK_DB_LICENSEKEY=$LICENSE_KEY
export TYK_DB_MONGOUSESSL=$MONGOUSESSL
sudo /opt/tyk-dashboard/install/setup.sh --listenport=3000 --redishost=$REDIS_HOST --redisport=6379 --tyk_api_hostname=$HOSTNAME --tyk_node_hostname=http://localhost --tyk_node_port=8080 --portal_root=/portal --domain="XXX.XXX.XXX.XXX"
At least I can handle the mongo url but LICENSE KEY parameter has no sign anywhere.
Please Help ME !

install/setup.sh simply sets up some sensible defaults inside your tyk_analytics.conf file.
You can either edit the /opt/tyk-dashboard/tyk_analytics.conf directly, and insert your license key in there. Then restart the dashboard service systemctl restart tyk-dashboard.
Alternatively, if you want to use environment variables, you need to set them globally on the machine, or in your tyk-dashboard systemd unit file.
edit /lib/systemd/system/tyk-dashboard.service
Add your environment variable inside the [Service] directive
Environment="TYK_DB_LICENSEKEY=FOOBARBAZ"
save & quit, then
systemctl daemon-reload
systemctl restart tyk-dashboard
More comprehensive answer here: https://serverfault.com/questions/413397/how-to-set-environment-variable-in-systemd-service

Related

Centos 7 environment variables for Postgres service

Recently I had the problem of starting a postgresql service with custom PGDATA path. It tried to look in the default data directory (/var/lib/pgsql/9.3/data/) which was not initialized and therefore triggered these errors. It appears the problem is that the service starter on Centos 7 strips all the environment variables, including PGDATA.
Interesting thread on the issue
Is there a way to configure
service postgresql-9.3 start
to use custom environment variables? Are there configuration files for services where these variables have to be defined?
Thank you in advance!
Thanks for the above answer, we just ran into this change today. You can also keep the default settings and only override the PGDATA variable by putting the following in /etc/systemd/system/postgresql-9.3.service:
# Include the default config:
.include /lib/systemd/system/postgresql-9.3.service
[Service]
Environment=PGDATA=<your path here>/pgsql/9.3/data
This removes the need to reintegrate changes in /usr/lib/systemd/system/postgresql-9.3.service back to your local copy.
OK, I got a solution that worked for me.
nano /etc/systemd/system/postgresql-9.3.service
with the contents copied over from /usr/lib/systemd/system/postgresql-9.3.service and PGDATA variable changed. Then
systemctl daemon-reload
And then I started the service normally and it worked fine. The trick was making changes to this service configuration file.

Need help to change postgresql port on CentOS 7

I just installed the postgresql (as it says on postgresql), server is running like charm, no problem at all.
I just tried(want) to change the default port (5432) to (9898).
First I just tried to do it by postgresql.conf file under /var/lib/pgsql/data/postgresql.conf.
I just remove the comment for port related line, and change it as port=9898, but there is a comment saying overriding port here doesn't change anything for RHEL and deriven guys, it also says try to override the port config by service config file(cannot find it, where is it?).
I also change the postmaster.opts too (doesn't work the same).
Finally! how may I change the Postgresql 9.2.7 port number on CentOS 7?
Finally I found it, the service file is /lib/systemd/system/postgresql.service, I just change the following line.
Environment=PGPORT=9898
stop the service as
service postgresql stop
then reload the daemon services using this
systemctl daemon-reload
Finally start the postgresql using
service postgresql start
Now it's working like charm :D
Login to psql. Try
show config_file ;
That is the file you should change. Did you restart the server after changing the port?
You can also try the file under /etc/rc.d/init.d for PostgreSQL if it is running as a service.
From /lib/systemd/system/postgresql.service
# It's not recommended to modify this file in-place, because it will be
# overwritten during package upgrades. If you want to customize, the
# best way is to create a file "/etc/systemd/system/postgresql.service",
# containing
# .include /lib/systemd/system/postgresql.service
# ...make your changes here...
# For more info about custom unit files, see
# http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F
# For example, if you want to change the server's port number to 5433,
# create a file named "/etc/systemd/system/postgresql.service" containing:
# .include /lib/systemd/system/postgresql.service
# [Service]
# Environment=PGPORT=5433
# This will override the setting appearing below.
I think it is better to follow the steps above.
I am using Amazon EC2 instance with Amazon Linux AMI release ( A kind of CentOS it seems). I needed to change PGPORT variable in /etc/init.d/postgresql file and restart the postgresql service using 'service postgresql restart'. And it works!!
PGPORT=some_new_port # /etc/init.d/postgresql

How to run php-fpm as root

I know the risks about running php-fpm as root.
However there are situations where one would need to do it, like appliances,
accessing operating system resources or even for testing purposes.
I have tried to change the user and group of php-fpm.d/www.conf to root
when I restart the php-fpm process it raise an error:
Starting php-fpm: [26-Jun-2014 00:39:07] ERROR: [pool www] please specify user and group other than root
[26-Jun-2014 00:39:07] ERROR: FPM initialization failed
[FAILED]
What should I do. Anyone help?
See:
# php-fpm --help
...
-R, --allow-to-run-as-root
Allow pool to run as root (disabled by default)
Just adding -R (like this ans. suggests) to your command may not work. It depends how your running the command to start php-fpm.
If you're using service php-fpm restart and it's using /etc/init.d instead of systemctl (see here), then you'll have to add -R to the DAEMON_ARGS variable located in the /etc/php/<phpversion>/fpm/php-fpm.conf script. (This variable is used in the do_start() function. See here).
If it's using systemctl then you'll have to edit the script used by systemctl which should be located in /lib/systemd/system/<phpversion>-fpm.service. Append -R to the ExcecStart variable. Then run systemctl daemon-reload and systemctl start php<version>-fpm (See here)
I used the following questions/answers/resources to help me compile this solution.
https://serverfault.com/a/189961
https://serverfault.com/q/788669
https://stackoverflow.com/a/52919706/9530790
https://serverfault.com/a/867334
https://www.geeksforgeeks.org/what-is-init-d-in-linux-service-management/
These 3 steps will fix the error.
Locate php-fpm.service. For me it's /usr/lib/systemd/system/php-fpm.service. If you're not sure where it is, type find / -name php-fpm.service.
Append -R to the ExecStart variable. Eg ExecStart=/usr/sbin/php-fpm --nodaemonize -R.
Restart php-fpm. If systemctl restart php-fpm throws an error, run systemctl daemon-reload.
To anyone else wondering how to make php run as root, you also need to modify /etc/php-fpm.d/www.conf or modify a copy of it. Both user and group need to be changed to root. If you've made a copy of www.conf, you'll also need to modify this line listen = /run/php-fpm/www.sock.
By default, php-fpm is shipped with a "www.conf" that contains, among others, the default www-data user configuration:
[www]
user = www-data
group = www-data
So, you need to create another file, loaded after www.conf, that will overwrite that default config. For example, create a file docker.conf in the same path as your php-fpm's Dockerfile and containing the following:
[www]
user = root
group = root
Then, in your Dockerfile, inject that file in your container with a name that will be loaded after the default www.conf:
COPY ./docker.conf /usr/local/etc/php-fpm.d/zzz-docker.conf
Update 2018
Running it within a container is a possible valid reason to run php-fpm as root. It can be done by passing the -R command line argument to it
Original answer:
However there are situations where one would need to do it, like appliances, accessing operating system resources
You never need to do it. That's it. If you are managing system resources, grant permissions for the php-fpm user to that resources rather than running the whole process as root. If your question would be more specific I could show how to do that in a certain situation.

How can I run Jboss as a daemon on a virtual machine?

What I've done so far according to these instructions is unziped and moved jboss into my /usr/local/ directory. Then I put the jboss_init_redhat.sh script in /etc/init.d/ as jboss and edited the script to meet my configurations. I then run /etc/init.d/jboss start and all it says is
JBOSS_CMD_START = cd /usr/local/jboss-4.2.3.GA//bin; /usr/local/jboss-4.2.3.GA//bin/run.sh -c default -b 0.0.0.0
and then nothing happens. Also if I go into /usr/local/jboss-4.2.3.GA/bin and run run.sh it starts the server but when I go to the vm's IP:8080 in my browser I still get nothing. Any help would be appreciated also I don't know much about doing this so excuse my inexperience.
Init scripts should be owned and started by root.
The init script you use uses su (better would be to runuser) to change to the jboss user.
The jboss user itself does not have permission to do that.
The jboss user also does not have permission to write to /var/run etc.
So run sudo /etc/init.d/jboss start (you need to set up sudo first to allow this) or change to the root account and execute /etc/init.d/jboss start.
If it still fails check the logs at /usr/local/jboss-4.2.3.GA/server/default/log.
Hope this helps.

How to reset Jenkins security settings from the command line?

Is there a way to reset all (or just disable the security settings) from the command line without a user/password as I have managed to completely lock myself out of Jenkins?
The simplest solution is to completely disable security - change true to false in /var/lib/jenkins/config.xml file.
<useSecurity>true</useSecurity>
A one-liner to achieve the same:
sed -i 's/<useSecurity>true<\/useSecurity>/<useSecurity>false<\/useSecurity>/g' /var/lib/jenkins/config.xml
Then just restart Jenkins:
sudo service jenkins restart
And then go to admin panel and set everything once again.
If you in case are running your Jenkins inside a Kubernetes pod and can not run service command, then you can just restart Jenkins by deleting the pod:
kubectl delete pod <jenkins-pod-name>
Once the command was issued, Kubernetes will terminate the old pod and start a new one.
One other way would be to manually edit the configuration file for your user (e.g. /var/lib/jenkins/users/username/config.xml) and update the contents of passwordHash:
<passwordHash>#jbcrypt:$2a$10$razd3L1aXndFfBNHO95aj.IVrFydsxkcQCcLmujmFQzll3hcUrY7S</passwordHash>
Once you have done this, just restart Jenkins and log in using this password:
test
The <passwordHash> element in users/<username>/config.xml will accept data of the format
salt:sha256("password{salt}")
So, if your salt is bar and your password is foo then you can produce the SHA256 like this:
echo -n 'foo{bar}' | sha256sum
You should get 7f128793bc057556756f4195fb72cdc5bd8c5a74dee655a6bfb59b4a4c4f4349 as the result. Take the hash and put it with the salt into <passwordHash>:
<passwordHash>bar:7f128793bc057556756f4195fb72cdc5bd8c5a74dee655a6bfb59b4a4c4f4349</passwordHash>
Restart Jenkins, then try logging in with password foo. Then reset your password to something else. (Jenkins uses bcrypt by default, and one round of SHA256 is not a secure way to store passwords. You'll get a bcrypt hash stored when you reset your password.)
I found the file in question located in /var/lib/jenkins called config.xml, modifying that fixed the issue.
In El-Capitan config.xml can not be found at
/var/lib/jenkins/
Its available in
~/.jenkins
then after that as other mentioned open the config.xml file and make the following changes
In this replace <useSecurity>true</useSecurity> with <useSecurity>false</useSecurity>
Remove <authorizationStrategy> and <securityRealm>
Save it and restart the jenkins(sudo service jenkins restart)
The answer on modifying was correct. Yet, I think it should be mentioned that /var/lib/jenkins/config.xml looks something like this if you have activated "Project-based Matrix Authorization Strategy". Deleting /var/lib/jenkins/config.xml and restarting jenkins also does the trick. I also deleted the users in /var/lib/jenkins/users to start from scratch.
<authorizationStrategy class="hudson.security.ProjectMatrixAuthorizationStrategy">
<permission>hudson.model.Computer.Configure:jenkins-admin</permission>
<permission>hudson.model.Computer.Connect:jenkins-admin</permission>
<permission>hudson.model.Computer.Create:jenkins-admin</permission>
<permission>hudson.model.Computer.Delete:jenkins-admin</permission>
<permission>hudson.model.Computer.Disconnect:jenkins-admin</permission>
<!-- if this is missing for your user and it is the only one, bad luck -->
<permission>hudson.model.Hudson.Administer:jenkins-admin</permission>
<permission>hudson.model.Hudson.Read:jenkins-admin</permission>
<permission>hudson.model.Hudson.RunScripts:jenkins-admin</permission>
<permission>hudson.model.Item.Build:jenkins-admin</permission>
<permission>hudson.model.Item.Cancel:jenkins-admin</permission>
<permission>hudson.model.Item.Configure:jenkins-admin</permission>
<permission>hudson.model.Item.Create:jenkins-admin</permission>
<permission>hudson.model.Item.Delete:jenkins-admin</permission>
<permission>hudson.model.Item.Discover:jenkins-admin</permission>
<permission>hudson.model.Item.Read:jenkins-admin</permission>
<permission>hudson.model.Item.Workspace:jenkins-admin</permission>
<permission>hudson.model.View.Configure:jenkins-admin</permission>
<permission>hudson.model.View.Create:jenkins-admin</permission>
<permission>hudson.model.View.Delete:jenkins-admin</permission>
<permission>hudson.model.View.Read:jenkins-admin</permission>
</authorizationStrategy>
We can reset the password while leaving security on.
The config.xml file in /var/lib/Jenkins/users/admin/ acts sort of like the /etc/shadow file Linux or UNIX-like systems or the SAM file in Windows, in the sense that it stores the hash of the account's password.
If you need to reset the password without logging in, you can edit this file and replace the old hash with a new one generated from bcrypt:
$ pip install bcrypt
$ python
>>> import bcrypt
>>> bcrypt.hashpw("yourpassword", bcrypt.gensalt(rounds=10, prefix=b"2a"))
'YOUR_HASH'
This will output your hash, with prefix 2a, the correct prefix for Jenkins hashes.
Now, edit the config.xml file:
...
<passwordHash>#jbcrypt:REPLACE_THIS</passwordHash>
...
Once you insert the new hash, reset Jenkins:
(if you are on a system with systemd):
sudo systemctl restart Jenkins
You can now log in, and you didn't leave your system open for a second.
To disable Jenkins security in simple steps in Linux, run these commands:
sudo ex +g/useSecurity/d +g/authorizationStrategy/d -scwq /var/lib/jenkins/config.xml
sudo /etc/init.d/jenkins restart
It will remove useSecurity and authorizationStrategy lines from your config.xml root config file and restart your Jenkins.
See also: Disable security at Jenkins website
After gaining the access to Jenkins, you can re-enable security in your Configure Global Security page by choosing the Access Control/Security Realm. After than don't forget to create the admin user.
To reset it without disabling security if you're using matrix permissions (probably easily adaptable to other login methods):
In config.xml, set disableSignup to false.
Restart Jenkins.
Go to the Jenkins web page and sign up with a new user.
In config.xml, duplicate one of the <permission>hudson.model.Hudson.Administer:username</permission> lines and replace username with the new user.
If it's a private server, set disableSignup back to true in config.xml.
Restart Jenkins.
Go to the Jenkins web page and log in as the new user.
Reset the password of the original user.
Log in as the original user.
Optional cleanup:
Delete the new user.
Delete the temporary <permission> line in config.xml.
No securities were harmed during this answer.
On the offchance you accidentally lock yourself out of Jenkins due to a permission mistake, and you dont have server-side access to switch to the jenkins user or root... You can make a job in Jenkins and add this to the Shell Script:
sed -i 's/<useSecurity>true/<useSecurity>false/' ~/config.xml
Then click Build Now and restart Jenkins (or the server if you need to!)
\.jenkins\secrets\initialAdminPassword
Copy the password from the initialAdminPassword file and paste it into the Jenkins.
1 first check location if you install war or Linux or windows based on that
for example if war under Linux and for admin user
/home/"User_NAME"/.jenkins/users/admin/config.xml
go to this tag after #jbcrypt:
<passwordHash>#jbcrypt:$2a$10$3DzCGLQr2oYXtcot4o0rB.wYi5kth6e45tcPpRFsuYqzLZfn1pcWK</passwordHash>
change this password using use any website for bcrypt hash generator
https://www.dailycred.com/article/bcrypt-calculator
make sure it start with $2a cause this one jenkens uses
In order to remove the by default security for jenkins in Windows OS,
You can traverse through the file Config.xml created inside /users/{UserName}/.jenkins.
Inside this file you can change the code from
<useSecurity>true</useSecurity>
To,
<useSecurity>false</useSecurity>
step-1 : go to the directory cd .jenkins/secrets then you will get a 'initialAdminPassword'.
step-2 : nano initialAdminPassword
you will get a password
changing the <useSecurity>true</useSecurity> to <useSecurity>false</useSecurity> will not be enough, you should remove <authorizationStrategy> and <securityRealm> elements too and restart your jenkins server by doing sudo service jenkins restart .
remember this, set <usesecurity> to false only may cause a problem for you, since these instructions are mentioned in thier official documentation here.
Jenkins over KUBENETES and Docker
In case of Jenkins over a container managed by a Kubernetes POD is a bit more complex since: kubectl exec PODID --namespace=jenkins -it -- /bin/bash will you allow to access directly to the container running Jenkins, but you will not have root access, sudo, vi and many commands are not available and therefore a workaround is needed.
Use kubectl describe pod [...] to find the node running your Pod and the container ID (docker://...)
SSH into the node
run docker exec -ti -u root -- /bin/bash to access the container with Root privileges
apt-get update
sudo apt-get install vim
The second difference is that the Jenkins configuration file are placed in a different path that corresponds to the mounting point of the persistent volume, i.e. /var/jenkins_home, this location might change in the future, check it running df.
Then disable security - change true to false in /var/jenkins_home/jenkins/config.xml file.
<useSecurity>false</useSecurity>
Now it is enough to restart the Jenkins, action that will cause the container and the Pod to die, it will created again in some seconds with the configuration updated (and all the chance like vi, update erased) thanks to the persistent volume.
The whole solution has been tested on Google Kubernetes Engine.
UPDATE
Notice that you can as well run ps -aux the password in plain text is shown even without root access.
jenkins#jenkins-87c47bbb8-g87nw:/$ps -aux
[...]
jenkins [..] -jar /usr/share/jenkins/jenkins.war --argumentsRealm.passwd.jenkins=password --argumentsRealm.roles.jenkins=admin
[...]
Easy way out of this is to use the admin psw to login with your admin user:
Change to root user: sudo su -
Copy the password: xclip -sel clip < /var/lib/jenkins/secrets/initialAdminPassword
Login with admin and press ctrl + v on password input box.
Install xclip if you don't have it:
$ sudo apt-get install xclip
Using bcrypt you can solve this issue. Extending the #Reem answer for someone who is trying to automate the process using bash and python.
#!/bin/bash
pip install bcrypt
yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install xmlstarlet
cat > /tmp/jenkinsHash.py <<EOF
import bcrypt
import sys
if not sys.argv[1]:
sys.exit(10)
plaintext_pwd=sys.argv[1]
encrypted_pwd=bcrypt.hashpw(sys.argv[1], bcrypt.gensalt(rounds=10, prefix=b"2a"))
isCorrect=bcrypt.checkpw(plaintext_pwd, encrypted_pwd)
if not isCorrect:
sys.exit(20);
print "{}".format(encrypted_pwd)
EOF
chmod +x /tmp/jenkinsHash.py
cd /var/lib/jenkins/users/admin*
pwd
while (( 1 )); do
echo "Waiting for Jenkins to generate admin user's config file ..."
if [[ -f "./config.xml" ]]; then
break
fi
sleep 10
done
echo "Admin config file created"
admin_password=$(python /tmp/jenkinsHash.py password 2>&1)
# Repalcing the new passowrd
xmlstarlet -q ed --inplace -u "/user/properties/hudson.security.HudsonPrivateSecurityRealm_-Details/passwordHash" -v '#jbcrypt:'"$admin_password" config.xml
# Restart
systemctl restart jenkins
sleep 10
I have kept password hardcoded here but it can be a user input depending upon the requirement. Also make sure to add that sleep otherwise any other command revolving around Jenkins will fail.
To very simply disable both security and the startup wizard, use the JAVA property:
-Djenkins.install.runSetupWizard=false
The nice thing about this is that you can use it in a Docker image such that your container will always start up immediately with no login screen:
# Dockerfile
FROM jenkins/jenkins:lts
ENV JAVA_OPTS -Djenkins.install.runSetupWizard=false
Note that, as mentioned by others, the Jenkins config.xml is in /var/jenkins_home in the image, but using sed to modify it from the Dockerfile fails, because (presumably) the config.xml doesn't exist until the server starts.
I will add some improvements based on the solution:
https://stackoverflow.com/a/51255443/5322871
On my scenario it was deployed with Swarm cluster with nfs volume, in order to perform the password reset I did the following:
Attach to the pod:
$ docker exec -it <pod-name> bash
Generate the hash password with python (do not forget to specify the letter b outside of your quoted password, the method hashpw requires a parameter in bytes):
$ pip install bcrypt
$ python
>>> import bcrypt
>>> bcrypt.hashpw(b"yourpassword", bcrypt.gensalt(rounds=10, prefix=b"2a"))
'YOUR_HASH'
Once inside the container find all the config.xml files:
$ find /var/ -type f -iname "config.xml"
Once identified, modify value of the field ( on my case the config.xml was in another location):
$ vim /var/jenkins_home/users/admin_9482805162890262115/config.xml
...
<passwordHash>#jbcrypt:YOUR_HASH</passwordHash>
...
Restart the service:
docker service scale <service-name>=0
docker service scale <service-name>=1
Hope this can be helpful for anybody.
I had a similar issue, and following reply from ArtB,
I found that my user didn't have the proper configurations. so what I did:
Note: manually modifying such XML files is risky. Do it at your own risk. Since I was already locked out, I didn't have much to lose. AFAIK Worst case I would have deleted the ~/.jenkins/config.xml file as prev post mentioned.
**> 1. ssh to the jenkins machine
cd ~/.jenkins (I guess that some installations put it under /var/lib/jenkins/config.xml, but not in my case )
vi config.xml, and under authorizationStrategy xml tag, add the below section (just used my username instead of "put-your-username")
restart jenkins. in my case as root service tomcat7 stop; ; service tomcat7 start
Try to login again. (worked for me)**
under
add:
<permission>hudson.model.Computer.Build:put-your-username</permission>
<permission>hudson.model.Computer.Configure:put-your-username</permission>
<permission>hudson.model.Computer.Connect:put-your-username</permission>
<permission>hudson.model.Computer.Create:put-your-username</permission>
<permission>hudson.model.Computer.Delete:put-your-username</permission>
<permission>hudson.model.Computer.Disconnect:put-your-username</permission>
<permission>hudson.model.Hudson.Administer:put-your-username</permission>
<permission>hudson.model.Hudson.ConfigureUpdateCenter:put-your-username</permission>
<permission>hudson.model.Hudson.Read:put-your-username</permission>
<permission>hudson.model.Hudson.RunScripts:put-your-username</permission>
<permission>hudson.model.Hudson.UploadPlugins:put-your-username</permission>
<permission>hudson.model.Item.Build:put-your-username</permission>
<permission>hudson.model.Item.Cancel:put-your-username</permission>
<permission>hudson.model.Item.Configure:put-your-username</permission>
<permission>hudson.model.Item.Create:put-your-username</permission>
<permission>hudson.model.Item.Delete:put-your-username</permission>
<permission>hudson.model.Item.Discover:put-your-username</permission>
<permission>hudson.model.Item.Read:put-your-username</permission>
<permission>hudson.model.Item.Workspace:put-your-username</permission>
<permission>hudson.model.Run.Delete:put-your-username</permission>
<permission>hudson.model.Run.Update:put-your-username</permission>
<permission>hudson.model.View.Configure:put-your-username</permission>
<permission>hudson.model.View.Create:put-your-username</permission>
<permission>hudson.model.View.Delete:put-your-username</permission>
<permission>hudson.model.View.Read:put-your-username</permission>
<permission>hudson.scm.SCM.Tag:put-your-username</permission>
Now, you can go to different directions. For example I had github oauth integration, so I could have tried to replace the authorizationStrategy with something like below:
Note:, It worked in my case because I had a specific github oauth plugin that was already configured. So it is more risky than the previous solution.
<authorizationStrategy class="org.jenkinsci.plugins.GithubAuthorizationStrategy" plugin="github-oauth#0.14">
<rootACL>
<organizationNameList class="linked-list">
<string></string>
</organizationNameList>
<adminUserNameList class="linked-list">
<string>put-your-username</string>
<string>username2</string>
<string>username3</string>
<string>username_4_etc_put_username_that_will_become_administrator</string>
</adminUserNameList>
<authenticatedUserReadPermission>true</authenticatedUserReadPermission>
<allowGithubWebHookPermission>false</allowGithubWebHookPermission>
<allowCcTrayPermission>false</allowCcTrayPermission>
<allowAnonymousReadPermission>false</allowAnonymousReadPermission>
</rootACL>
</authorizationStrategy>
Edit the file $JENKINS_HOME/config.xml and change de security configuration with this:
<authorizationStrategy class="hudson.security.AuthorizationStrategy$Unsecured"/>
After that restart Jenkins.
A lot of times you wont be having permissions to edit the config.xml file.
The simplest thing would be to take a back of config.xml and delete using sudo command.
Restart the jenkins using the command sudo /etc/init.d/jenkins restart
This will disable all the security in the Jenkins and the login option would disappear
For one who is using macOS, the new version just can be installed by homebrew. so for resting, this command line must be using:
brew services restart jenkins-lts
The directory where the file is located config.xml in windows
C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins\.jenkins

Resources