How can I get Jenkins to run on a different port? - amazon-web-services

I'm having some trouble in trying to change my jenkins port as I was hoping to use port 8080 for a different service. I've tried this so far:
Currently running on amazon linux:
Jenkins version: Jenkins 2.332.1
I've tried to edit the config file: /etc/sysconfig/jenkins to:
JENKINS_PORT="7777"
After I restart jenkins however, the port does not change:
● jenkins.service - Jenkins Continuous Integration Server
Loaded: loaded (/usr/lib/systemd/system/jenkins.service; disabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/jenkins.service.d
└─override.conf
Active: active (running) since Tue 2022-04-05 15:52:24 UTC; 1min 33s ago
Main PID: 1017 (java)
Tasks: 36
Memory: 500.6M
CGroup: /system.slice/jenkins.service
└─1017 /usr/bin/java -Djava.awt.headless=true -jar /usr/share/java/jenkins.war --webroot=%C/jenkins/war --httpPort=8080
Apr 05 15:53:38 ip-172-0-2-240.eu-west-1.compute.internal jenkins[1017]: at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
Apr 05 15:53:38 ip-172-0-2-240.eu-west-1.compute.internal jenkins[1017]: at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
What am i missing here?

Check the service starting command
/usr/bin/java -Djava.awt.headless=true -jar /usr/share/java/jenkins.war --webroot=%C/jenkins/war --httpPort=8080
Edit the service by changing --httpPort=8080 to desired port then call daemon-reload and restart the service
Also, ensure the Security Group is configured for that port
There is a different fix in this link https://cdmana.com/2022/03/202203242138366513.html which suggest editing JENKINS_PORT in /usr/lib/systemd/system/jenkins.service the calling service jenkins start

Related

Cannot connect my AWS EC2 Instance to my GitHub Webhook

How I should be able to add two port numbers to my new Inbound Rule for the GitHub webhook I created with the Type being Custom TCP, the Protocol being TCP, the Port Range being 8080, and most importantly, the Source being Anywhere with two custom source ports of 0.0.0.0/0 and ::/0 which is seen below in a screenshot of the specific reference from the course itself:
Then when I try and do the same for my EC2 Instance's Inbound Rules, I can only add one source for the port range of 8080 as seen below...
As a result, I cannot have both 0.0.0.0/0 and ::/0 connected to port range 8080 simultaneously as seen again below for clarification
When I try and do so, I am forced into creating two separate Inbound Rules, both being Custom TCP, Port Range 8080, and the Source of each directing to 0.0.0.0/0 and ::/0 independent of each other, not under one unified Inbound Rule
As a result, I believe this is why I am not capable of creating an established webhook from my GitHub repo to my AWS EC2 instance.
For more clarification, the course itself is walking me through how to properly setup a webhook from GitHub to my newly created AWS EC2 in conjunction with the directions here in the very detailed and well-written Strapi documentation, however, after I have followed these directions and have properly created a webhook.js file within my NodeWebHooks file of my root SSH, this is the error I get when I try to establish the connection which is most probably because of the inability to setup my Inbound Rule properly per the additional directive of the course.
As I still try and attempt to follow the documentation with two separate Inbound Rules from Port 8080 with a source of 0.0.0.0/0 and ::/0 respectively, in accordance with the guide, in my root SSH I enter:
echo $PATH
and copy and paste the path within the file of:
sudo nano /etc/systemd/system/webhook.service
in the proper script as below:
or as code, it is:
[Unit]
Description=Github webhook
After=network.target
[Service]
Environment=PATH=/home/ubuntu/.npm-global/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
Type=simple
User=ubuntu
ExecStart=/usr/bin/nodejs /home/ubuntu/NodeWebHooks/webhook.sj
Restart=on-failure
[Install]
WantedBy=multi-user.target
Then when I save and exit from that file, in order to enable it, I do:
sudo systemctl enable webhook.service
and receive the appropriate desired response of "Created symlink ... etc..." where it clarifies that a webhook.service has been created.
However, then when I run the following:
sudo systemctl start webhook
sudo systemctl status webhook
I get an error which states the following:
or alternatively, as code it is the following response:
ubuntu#ip-172-31-3-74:~$ sudo systemctl start webhook
ubuntu#ip-172-31-3-74:~$ sudo systemctl status webhook
● webhook.service - Github webhook
Loaded: loaded (/etc/systemd/system/webhook.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2021-10-02 22:45:47 UTC; 7s ago
Process: 27129 ExecStart=/usr/bin/nodejs /home/ubuntu/NodeWebHooks/webhook.sj (code=exited, status=1/FAILURE)
Main PID: 27129 (code=exited, status=1/FAILURE)
Oct 02 22:45:47 ip-172-31-3-74 systemd[1]: webhook.service: Main process exited, code=exited, status=1/FAILURE
Oct 02 22:45:47 ip-172-31-3-74 systemd[1]: webhook.service: Failed with result 'exit-code'.
Oct 02 22:45:47 ip-172-31-3-74 systemd[1]: webhook.service: Service hold-off time over, scheduling restart.
Oct 02 22:45:47 ip-172-31-3-74 systemd[1]: webhook.service: Scheduled restart job, restart counter is at 5.
Oct 02 22:45:47 ip-172-31-3-74 systemd[1]: Stopped Github webhook.
Oct 02 22:45:47 ip-172-31-3-74 systemd[1]: webhook.service: Start request repeated too quickly.
Oct 02 22:45:47 ip-172-31-3-74 systemd[1]: webhook.service: Failed with result 'exit-code'.
Oct 02 22:45:47 ip-172-31-3-74 systemd[1]: Failed to start Github webhook.
The issue is most likely that the webhook.service file references under [Service]: home/ubuntu/NodeWebHooks/webhook.sj, when it is probably named /home/ubuntu/NodeWebHooks/webhook.js. It's the little things that get you!

Unable to restart Hue in AWS EMR cluster

I have an EMR Cluster in AWS, configured in a Cloudformation template. In my template, I have a step that executes a script on the master node. The purpose of this script is to make changes to the hue.ini file.
The final step in the script is to restart Hue, for the changes to take effect. I'm following this documentation for the correct command. This documentation is explicit with Do Not run restart.
Running sudo systemctl stop hue followed by sudo systemctl start hue leaves Hue in the following state (per sudo systemctl status hue):
[root#ip-10-x-xxx-xxx ~]# sudo systemctl status hue
● hue.service - Hue web server
Loaded: loaded (/etc/systemd/system/hue.service; enabled; vendor preset: disabled)
Active: activating (auto-restart) (Result: exit-code) since Wed 2021-05-19 18:44:27 UTC; 2s ago
Process: 22743 ExecStart=/etc/init.d/hue start (code=exited, status=1/FAILURE)
Main PID: 17508 (code=exited, status=1/FAILURE)
Tasks: 0
Memory: 0B
CGroup: /system.slice/hue.service
May 19 18:44:27 ip-10-x-xxx-xxx systemd[1]: Failed to start Hue web server.
May 19 18:44:27 ip-10-x-xxx-xxx systemd[1]: Unit hue.service entered failed state.
May 19 18:44:27 ip-10-x-xxx-xxx systemd[1]: hue.service failed.
Running start again manually on the instance returns this:
Job for hue.service failed because the control process exited with error code. See "systemctl status hue.service" and "journalctl -xe" for details.
Those logs just show the same as above. I have also checked this similar question but the answer does not work for me.
EMR: emr-6.2.0
Hue: 4.8.0
After a little more research, it seems this is not the best approach. The best approach is to include a hue-ini Classification lock in my Cloudformation template. This applies the changes and performs the required restart for you.

No welcome page after openCPU install in fresh Ubuntu 18.04 instance

I am trying to install OpenCPU 2.1 on a fresh free tier AWS server. I followed
[https://aws.amazon.com/getting-started/tutorials/?awsf.getting-started-content=use-case-tmt%23websites-apps], and launched a
Ubuntu Server 18.04 LTS (HVM), x86, free tier server, and obtained
public and private IP's. Then I follow [https://opencpu.github.io/server-manual/opencpu-server.pdf], section 2.2
sudo apt-get update
sudo apt-get upgrade
I respond to grub prompt to keep local version installed
sudo add-apt-repository ppa:opencpu/opencpu-2.1 -y
sudo apt-get update
sudo apt-get install opencpu-server
and OK to defaults on pop-up on mailname and smarthost prompts.
The results all look OK. The last section reads:
To activate the new configuration, you need to run:
systemctl restart apache2
Enabling opencpu in apache...
Reloading apparmor...
Restarting apache...
Installation done!
Setting up libxml-twig-perl (1:3.50-1) ...
Setting up libnet-dbus-perl (1.1.0-4build2) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Processing triggers for systemd (237-3ubuntu10.13) ...
Processing triggers for ureadahead (0.100.0-20) ...
Processing triggers for ufw (0.35-5) ...
When I then try to point my browser to http(s)://your.server.com/ocpu (of course with the the IP replaced by public IP I got from AWS, and using either http:// or https://), then I get a time-out in the browser window after a minute or so.
Checking sudo systemctl status apache2.service provides
● apache2.service - The Apache HTTP Server
Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/apache2.service.d
└─apache2-systemd.conf
Active: active (running) since Thu 2019-02-28 09:41:19 UTC; 1min 14s ago
Process: 30750 ExecStop=/usr/sbin/apachectl stop (code=exited, status=0/SUCCESS)
Process: 30755 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
Main PID: 30771 (apache2)
Tasks: 6 (limit: 1152)
CGroup: /system.slice/apache2.service
├─30771 /usr/sbin/apache2 -k start
├─30773 /usr/sbin/apache2 -k start
├─30774 /usr/sbin/apache2 -k start
├─30775 /usr/sbin/apache2 -k start
├─30776 /usr/sbin/apache2 -k start
└─30777 /usr/sbin/apache2 -k start
Feb 28 09:41:19 ip-zzz-zz-zz-zz systemd[1]: Stopped The Apache HTTP Server.
Feb 28 09:41:19 ip-zzz-zzz-zz-zz systemd[1]: Starting The Apache HTTP Server...
Feb 28 09:41:19 ip-zzz-zzz-zz-zz systemd[1]: Started The Apache HTTP Server.
which seems OK. Also, trying a restart:
sudo a2ensite opencpu
Site opencpu already enabled
does not activate the welcome page. Is there something else that needs to be activated or set?
First try to connect to the server locally to test if it running. On the server run:
curl --insecure http://localhost/ocpu/info
If you get a response with some info about the server, opencpu is running and the issue is likely the amazon security group is blocking HTTP traffic. See the section below on how to enable this.
On the other hand if the curl command above did not work (it gave a timeout erorr), there is a problem with the server and you need to check /var/log/apache2/error.log.
Enable HTTP(S) in the amazon security group (firewall)
If you still not connect from your browser, the issue is likely that your have not opened the http ports in your EC2 firewall (security group). To check this, open the EC2 management console in your browser and lookup the security group is associated with your EC2 instance. Then add inbound rules to this secruity group to allow port 80 and 443 from any host.
First lookup the security group that is associated with your instance:
And then add an inbound rule to allow port 80 (HTTP) and 443 (HTTPS):

Failed to start Redis In-Memory Data Store. Ubuntu 18.04

I am trying to install redis on my AWS server. I have Ubuntu 18.04 installed on it. I am following steps to install redis from digitalocean article.
When i run sudo systemctl status redis command i am getting below error.
screenshot
I tried to edit /etc/systemd/system/redis.service file and added Type=forking under [Service] section but still getting the same error.
Can anyone suggest me how i can get it fixed?
Thanks in advance.
Based on same digitalocean tutorial, actually it's running fine.
Run this command sudo systemctl restart redis.service, we get (showing "failed" on last line):
● redis.service - Redis In-Memory Data Store
Loaded: loaded (/etc/systemd/system/redis.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2021-06-28 12:03:11 +03; 1min 0s ago
Process: 20428 ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf (code=exited, status=
Main PID: 20428 (code=exited, status=203/EXEC)
Jun 28 12:03:11 XYZ systemd[1]: redis.service: Service hold-off time over, scheduling restar
Jun 28 12:03:11 XYZ systemd[1]: redis.service: Scheduled restart job, restart counter is at
Jun 28 12:03:11 XYZ systemd[1]: Stopped Redis In-Memory Data Store.
Jun 28 12:03:11 XYZ systemd[1]: redis.service: Start request repeated too quickly.
Jun 28 12:03:11 XYZ systemd[1]: redis.service: Failed with result 'exit-code'.
Jun 28 12:03:11 XYZ systemd[1]: Failed to start Redis In-Memory Data Store.
But if you run sudo service redis-server status, we get (showing "running" on 3rd line):
● redis-server.service - Advanced key-value store
Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-06-28 11:50:13 +03; 19min ago
Docs: http://redis.io/documentation,
man:redis-server(1)
Process: 19278 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=0/SUCCESS)
Process: 19371 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCC
Main PID: 19382 (redis-server)
Tasks: 4 (limit: 4915)
CGroup: /system.slice/redis-server.service
└─19382 /usr/bin/redis-server 127.0.0.1:6379
Jun 28 11:50:13 XYZ systemd[1]: Starting Advanced key-value store...
Jun 28 11:50:13 XYZ systemd[1]: redis-server.service: Can't open PID file /var/run/redis/red
Jun 28 11:50:13 XYZ systemd[1]: Started Advanced key-value store.
After searching for hours, it seems like it's some difference between systemctl & service and nothing more, but the actual redis server is running fine. Corrects me if that's not the case. Here's the link: https://askubuntu.com/questions/903354/difference-between-systemctl-and-service-commands
You can even check if redis is working fine, by redis-cli ping, should print PONG
I also encountered this problem, then I tried to check it again.
Finally, I found that when I authorized /var/lib/redis, I entered the wrong command, causing the redis account to have no access to /var/lib/redis.
sudo chown redis:redis /var/lib/redis
sudo systemctl restart redis
succeeded.

docker-machine create with digitalocean driver: ssh command error

I´m using docker tools on windows.
create command was working perfectly last week and I managed to create a number of machines on Digital Ocean. Then I tried today with no success. I repeated the same command with different regions and I always get the same result:
λ docker-machine create -d digitalocean --digitalocean-access-token=MYTOKEN --digitalocean-region=ams2 vmname
Running pre-create checks...
Creating machine...
(fernu) Creating SSH key...
(fernu) Creating Digital Ocean droplet...
(fernu) Waiting for IP address to be assigned to the Droplet...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with ubuntu(systemd)...
Installing Docker...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Error creating machine: Error running provisioning: ssh command error:
command : sudo systemctl -f start docker
err : exit status 1
output : Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details.
If I execute the suggested command:
root#fernu:~# systemctl status docker.service
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/docker.service.d
└─10-machine.conf
Active: inactive (dead) (Result: exit-code) since Fri 2017-06-30 20:56:13 UTC; 8min ago
Docs: https://docs.docker.com
Process: 4943 ExecStart=/usr/bin/docker daemon -H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --storage-driver aufs --tlsverify --tlscacert /etc/docker/ca.pem --tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label provider=digitalocean (code=exited, status=1/FAILURE)
Main PID: 4943 (code=exited, status=1/FAILURE)
Jun 30 20:56:13 fernu systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Jun 30 20:56:13 fernu systemd[1]: Failed to start Docker Application Container Engine.
Jun 30 20:56:13 fernu systemd[1]: docker.service: Unit entered failed state.
Jun 30 20:56:13 fernu systemd[1]: docker.service: Failed with result 'exit-code'.
Jun 30 20:56:13 fernu systemd[1]: docker.service: Service hold-off time over, scheduling restart.
Jun 30 20:56:13 fernu systemd[1]: Stopped Docker Application Container Engine.
Jun 30 20:56:13 fernu systemd[1]: docker.service: Start request repeated too quickly.
Jun 30 20:56:13 fernu systemd[1]: Failed to start Docker Application Container Engine.
Any help would be appreciated
Update
It´s working with ubuntu 14:
--digitalocean-image=ubuntu-14-04-x64 so it seams like a problem with the default image (ubuntu-16-04-x64)
This seems to be hitting a lot of people. TL;DR: There is a bug in docker-machine v0.12.0 and this issue can be resolved by upgrading.
Logging in to the DigitalOcean instance and running journalctl -xe provides more information:
-- Unit docker.service has begun starting up.
Jul 07 20:03:52 docker-sandbox docker[4930]: `docker daemon` is not supported on Linux. Please run `do
Jul 07 20:03:52 docker-sandbox systemd[1]: docker.service: Main process exited, code=exited, status=1/
Jul 07 20:03:52 docker-sandbox systemd[1]: Failed to start Docker Application Container Engine.
-- Subject: Unit docker.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
The key here is docker daemon is not supported on Linux. A bug in docker-machine's version comparison code caused an incorrect systemd unit file to be produced (located at /etc/systemd/system/docker.service.d/10-machine.conf) on certain versions of Ubuntu.
A fix has been committed and a new release (v0.12.1) was made.
You can grab the latest release at: https://github.com/docker/machine/releases/tag/v0.12.1