Question 97963 in Nginx Question posted in
The official documentation can be found here.

Jenkins server –httpListenAddress=127.0.0.1 not working – Nginx

recently I installed Jenkins server, and wanted to hide it behind Nginx proxy.
My Nginx proxy works fine and I read to restrict Jenkins to 127.0.0.1:8080 therefore, I edited the config file /etc/default/jenkins and put below line of code:

JENKINS_ARGS="--webroot=/var/cache/$NAME/war --httpPort=8080 --httpListenAddress=127.0.0.1"

After restarting jenkins, I still have access to Jenkins on port 8080

Environment:

Ubuntu 20.04

OpenJDK 11

Jenkins 2.332.1

Netstat output:

    sudo netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      2313/java

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      970/nginx: master p
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      708/systemd-resolve
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      946/sshd: /usr/sbin
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      757/cupsd

tcp6       0      0 :::80                   :::*                    LISTEN      970/nginx: master p
tcp6       0      0 :::22                   :::*                    LISTEN      946/sshd: /usr/sbin
tcp6       0      0 ::1:631                 :::*                    LISTEN      757/cupsd

P.S. I tried on EC2/Amazom linux 2, same issue

Tags:

2

Answers


  1. 0

    While it won’t hurt to restrict port 8080 in an AWS environment there really isn’t a reason to worry about it. You’ll want to setup a security group to your server so everything is blocked except for maybe port 22 (ssh), port 80 (http) and port 443 (https). You can do this through the AWS console.

    To do this, go to the AWS console and select EC2 and then your instance. In the middle of the page is the "Security" tab. From there you can create a security group to determine what traffic you allow in and out.

    In this way no one can connect to any ports that you don’t allow in. You’re not currently using https it looks like and so you may want to leave out port 443 until you’re ready.

    Login or Signup to reply.
  2. 0

    As of Jenkins version 2.332.1, which you indicated you are running, Jenkins made the switch from running as a service using classic SysV init scripts over to fully integrating with systemd on Linux distributions that support it, which includes Ubuntu 20.04. I don’t see any signs that the systemd unit file for Jenkins ever parses /etc/default/jenkins, meaning those settings are only parsed by the SysV init script, which would explain why your configuration had no effect there.

    As you found, setting the environment variable in /lib/systemd/system/jenkins.service indeed works, but your instinct is absolutely correct that it is not best practice to directly edit the unit file managed by the packaging system. As with most things in Linux, the /etc directory is where administrators are meant to put their configuration files, and /lib and /usr/lib are reserved for the package manager, so luckily systemd is no exception to this and provides a mechanism for such changes.

    Systemd has the concept of "drop-in" directories where you can place ".conf" files with partial systemd unit configurations whose directives will override those in the main unit file. From the systemd.unit man page:

    Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be merged in the alphanumeric order and parsed after the main unit file itself has been parsed. This is useful to alter or add configuration settings for a unit, without having to modify unit files. Each drop-in file must contain appropriate section headers.

    Here’s how I set up Jenkins 2.332.1 on Ubuntu 20.04 using a systemd drop-in override to bind the listener to 127.0.0.1:

    Verify Jenkins is running and listening on all addresses/interfaces:

    $ sudo ss -tlnp | grep 8080
LISTEN    0         50               *:8080               *:*        users:(("java",pid=2688,fd=116))

    Create a systemd drop-in directory for Jenkins:

    $ sudo mkdir /etc/systemd/system/jenkins.service.d

    Create an override file using your favorite editor. You can name it whatever you want as long as it has a .conf extension. Personally, I prefer something descriptive and to begin with a number so that I can control the lexicographic order in which the files are parsed, should I ever end up with multiple override files. Given that, I created a file /etc/systemd/system/jenkins.service.d/50-listen-address-override.conf with the following content:

    [Service]
Environment="JENKINS_LISTEN_ADDRESS=127.0.0.1"

    Now, all we have to do is tell systemd that we made some changes we want it to reparse:

    $ sudo systemctl daemon-reload

    And we can restart Jenkins to give it its new config:

    $ sudo systemctl restart jenkins

    If we verify our work, we can now see that Jenkins is only bound to 127.0.0.1:

    $ sudo ss -tlnp | grep 8080
LISTEN   0        50          [::ffff:127.0.0.1]:8080          *:*       users:(("java",pid=31636,fd=116))

    For what it’s worth, you can also use the command systemctl edit jenkins to create the override, and systemd will create the drop-in directory and override file automatically for you and drop you into your default editor to write the file contents, however it does not give you the freedom to choose your own name for the override file, giving it instead a generic name of override.conf.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search