Creating docker repo in Artifactory with dedicated port, it says "SocketException: Permission denied" - artifactory

I am running Artifactory Pro (5.3.1), and was trying to use the docker registry functionality.
I created a docker repository, and gave it a port 5001 in the "Registry Port" config.
However, there's nothing running on port 5001 ("telnet localhost 5001" refuses to connect), and the logs show this:
[http-nio-8081-exec-7] [ERROR] (o.a.s.s.SshAuthServiceImpl:210) - Failed to start SSH server
java.net.SocketException: Permission denied
at sun.nio.ch.Net.bind0(Native Method) ~[na:1.8.0_72-internal]
at sun.nio.ch.Net.bind(Net.java:433) ~[na:1.8.0_72-internal]
at sun.nio.ch.Net.bind(Net.java:425) ~[na:1.8.0_72-internal]
at sun.nio.ch.AsynchronousServerSocketChannelImpl.bind(AsynchronousServerSocketChannelImpl.java:162) ~[na:1.8.0_72-internal]
at org.apache.sshd.common.io.nio2.Nio2Acceptor.bind(Nio2Acceptor.java:66) ~[sshd-core-0.14.0.jar:0.14.0]
Any idea what could cause a "permission denied"? There's nothing running on that port (same error for any other port). It's on Ubuntu 14.04.

I had a misunderstanding how the docker registry worked with Artifactory.
The Artifactory service doesn't actually open the port assigned to the repo (5001 in this case), but the reverse proxy will listen on it and forward it (with the right X-forwarded-port) to the "normal" Artifactory service port (e.g. 8081).
After setting up the reverse proxy for it, it worked fine.

Related

Node js Application running on EC2 but not accessible in browser using Nginx

I'm a newbie to Nginx. I cannot access my Node.js application that I deploy on AWS EC2 using Nginx reverse proxy. If I do curl http://localhost:3000 I can see the application is running successfully on the server(I'm using pm2 for running node server). But when I try to access it in my browser or postman using public DNS I get the error This site can't be reached and the request gets timeout. Here's my Nginx configuration (I have followed a number of tutorials for this)
The configuration file is named nginx.conf and is in /etc/nginx/sites-enabled directory. If I do sudo nginx -t it says syntax is ok and the test is successful. Also I can see the Nginx is running using command sudo systemctl status nginx What could be the possible reason for this behaviour?
I figured it out the problem wasn't with the Nginx configuration actually I needed to allow public access for port 80 on my ec2 instance which is blocked by default. I allowed port 80 and everything is working fine. This blog helped me. Visit it for me details on how to enable port 80 for your ec2 instance.

Set GITLAB to be accessible on LAN

After many research i have not found anything...
I install GITLAB on a CentOS VM. The CentOS ip address is 192.168.100.1.
In the file /etc/gitlab/gitlab.rb, I modified the line:
external_url 'http:192.168.100.1:1234'
I executed the command 'gitlab-ctl reconfigure' and no errors appeared.
When I use Firefox, and I can access to my Gitlab with all the Centos' interfaces:
192.168.100.1:1234
127.0.0.1:1234
It is normal because when i execute 'netstat -ntlp', I can see:
tcp 0 0.0.0.0:1234 LISTEN 22222/nginx:master
What is the problem?
I cannot access to GitLAB outside from the same Network 192.168.100.1/24.
From an other VM on the same network (192.168.100.2), i can ping '192.168.100.2'. I also make an ssh connection but if I made a:
curl 192.168.100.1:1234
The result is "Time out"
Thank,
Vincent

Connection timeout while connecting to EC2 instance(SSH) after enabling nginx

Everything was working fine. I could connect to my EC2 instance through SSH. Then I wanted to install let-encrypt. I was following this tutorial to install https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04. During the process of installing lets-encrypt, I install nginx and while trying to enable nginx, I got a message that I might not be able to connect to my instance through SSH anymore. I ignored the message. Now when I try to connect to my instance though SSH, I get error
connection timed out

Artifactory Docker repo not listening on designated port

I'm trying to setup a Docker registry with Artifactory 5.2.1. It's a virtual repo that includes a docker-remote and docker-local (previously defined in Artifactory). I'd like to use the Port method of mapping and I"m running HAProxy 1.5 as a reverse proxy.
HAProxy has a SSL cert with a long list of SANs.
artifactrepo.company.com points to the main artifactory instance and works fine.
docker.company.com points to same server but HAProxy routes this to a Nexus served registry.
www.docker.company.com we intend to route to this Artifactory registry and
Per the HAProxy docs, I've set the reqirep ^([^\ :]*)\ /v2(.*$) \1\ /artifactory/api/docker/docker/v2\2 to get me to the intended port and path.
I have the "Registry Port" set to the default 6555 yet there is no process listening on that port. Artifactory and HAProxy have been restarted.
netstat -tulpn | grep 6555
gives no results.
Shouldn't Artifactory be listening on the Registry Port?
I figured this out. Turns out it was imagination poisoning from running Nexus repos.
Unlike Nexus, Artifactory doesn't actually listen on any port but the default (8081). The reference to a mapped port for a docker repo is simply to seed the generated reverse-proxy configs they give you. Those configs will have apache listen on 6555 (their default for docker) and then do the path rewrite and port map to 8081. I had intended to do this reverse-proxying using the hostname and had not scrolled all the way through their example to see that they had apache listening on 6555.

why i am getting this error "Installation failed. Failed to receive heartbeat from agent." in cloudera installtion

I am installing cloudera manager on local machine.
When trying to add new host getting following error
Installation failed. Failed to receive heartbeat from agent.
Ensure that the host's hostname is configured properly.
Ensure that port 7182 is accessible on the Cloudera Manager server
(check firewall rules).
Ensure that ports 9000 and 9001 are free on the host being added.
Check agent logs in /var/log/cloudera-scm-agent/ on the host being
added
(some of the logs can be found in the installation details).
i checked the logs,it shows like hostname differs from canonical name
So I also changed the hostname from /etc/resolv.conf
But still getting sam error
I had the same error for a simple mistake in the file /etc/hosts :
Have you checked you have DNS and reverse DNS ?
Then to check if your port is open 7182, you should do a telnet IP 7182 (replace IP by the host of Cloudera Manager Server).
If there are still some problems, maybe you have forgotten to deactivate the firewall (iptables).
Regards, K.
To resolve this issue you need to check first all port opened on your server service listing to the port no, use command: sudo netstat -lpten
Check if any thing is running on 9000 or 90001, mostly java services required for set up is running on port 9000, and cloudera-scm-agent listner also runs on port 9000. to over come this issue you can re-configure theports as well in /etc/cloudera-scm-agent/config.ini by changing as below:
--------------------------------------------------
## It should not normally be necessary to modify these.
# Port that the CM agent should listen on.
listening_port=9001
-------------------------------------------------
and then restart the cloudera-scm-agent service by command:
service cloudera-scm-agent restart
To verify this port is not activated for other sshd service check Ports opened in /etc/ssh/sshd_config.
I hope this resolution will work for others too.
Cheers,
Ankit Gupta

Resources