I've recently set up a Debian 8 Jessie VM on Google Cloud. I've installed Jenkins and have the service up and running(verified by "sudo service jenkins status"), yet I can't connect to the VM's external IP from another machine. I used to run Jenkins from my personal computer until I decided I needed a dedicated server to run it continuously. When I was running it on my personal machine I would just access localhost:8080 and the Jenkins dashboard would load fairly quickly. However, upon trying to access the external IP address of the VM running Jenkins, I'm usually greeted with "Connection refused" in my web browser.
At the suggestion of most posts I've seen regarding such issues, I've lifted all firewalls on the VM and have tried to ensure that the VM is listening at the correct IP address, but nothing seems to be able to change the outcome presented by my browser. Where does the issue most likely reside: the VM, Google Cloud, or Jenkins? I'm at a loss.
My first guess is a connection/firewall issue. To test this, you could try a port forward using SSH: SSH into your server with a local port forward: ssh -L 8080:localhost:8080 yourserver. You should then be able to direct your web browser at http://localhost:8080/ and your packets flow through the SSH connection. If that makes it work, have a good look at
How to open a specific port such as 9090 in Google Compute Engine . Or better yet, if you are the only one to use that Jenkins server, just keep using the SSH tunnel. It's much more secure than opening jenkins to the public world.
Have you tried installing tcpdump on the VM and doing a packet capture? That way you can determine where the traffic is being dropped. If you don't see any traffic, then it is being dropped somewhere in the cloud before it gets to your VM. If you are seeing traffic, then you need to determine is it Jenkins or some agent on the host (perhaps a firewall but you mentioned you cleared all the rules) ... I would suggest stopping the Jenkins service and then trying to access it again. Do you get the same "Connection Refused" message? If so, then it is something on the VM. If not, then it something at the application layer, i.e. Jenkins.
Happy hunting!!!
Related
Intro:
I have an app, when I run it, it connects to a server and shares its bandwidth, (basically gives out the public IP for the server to use),
Development:
Now I wanted that app to use transparent socks5 proxy for sending and receiving requests. This was possible when I downloaded the app (non containerized version) on ubuntu and configured red-socks and iptables in it, the server the app connected to assumed the app's public IP was the one I mentioned (socks5://user:pass#ip:port) (i own these proxy IPs too)
Requirement:
Next, I wanted to scale it out, so I looked for a docker image of this app, it was available so I downloaded and ran it, it worked fine, but the IP the server received was the non proxy IP (obviously as I have not configured any proxy).
My proposed idea was to run multiple docker containers,
but I still don't know how will I configure a different socks5 proxy for each of these containers.
Can someone advise me on how to go forward with this.
Thank you in advance :D
Edits: I had mentioned I was trying to do what I did with the ubuntu system on a ubuntu docker container, removed that and organized the whole situation.
I have a Azure VM and Im experiencing a slow connection to VM via SSH.
I can connect using ssh or putty, but after some time VM drop the connection. Sometimes I get a connection timeout when I'm trying to connect to VM.
To try to identify the problem I created a new VM and tried to connect through the private interface, but I'm still having the same problem.
To illustrate the problema see the scp command:
escola#othervm:~$ scp escola#10.0.0.4:backup/backup.dmp.gz .
backup.dmp.gz 1% 1520KB 144.7KB/s 12:45 ETA
the command is executed and after a while download stops.
Any Help ?
Based on my experience, you may increase the VM size to provide more memory for your VM. If it does not make sense. You could try the following solutions and refer to this.
Edit /etc/ssh/sshd_config to set the a large value of ClientAliveCountMax. The value is per minute. Then restart ssh service with service sshd reload.
On the user .ssh directory, add ServerAliveInterval 60 in the config file in /user/.ssh/config
For more information, you could read detailed SSH troubleshooting steps for issues connecting to a Linux VM in Azure.
I have looked around for answers but didn't not able to find solution related to my query.
I was able to ssh the server earlier but after a reboot I was not able to. I checked Azure portal for the instance it was showing status as Running. I tried rebooting it a couple of times but I was not able to ssh. I checked further and found out that the public IP shown was different this time. I tried with that IP but still not able to login.
Any suggestion what I should I do next. Also, how can I make the IP static in Azure.
Please start from the official SSH connection troubleshooting guide - most of the SSH issues i had (and yours situation is the same i had a few times) were solved by reset-ssh way. Helpful would be to see the serial console output (VM dashboard => Settings).
The fact that your IP changed is normal if you did not reserve that, it will change.
I am currently trying to setup a Linux service with IBM Tivoli Identity Manager (IBM Security Identity Manager) a.k.a. ITIM, to a Linux development server where I work and have had some issues. All our Linux servers use ssh to connect. Our eventual goal is to implement single sign on across our networks using Identity Manager.
In the ITIM web interface, I chose the option MANAGE SERVICES and was displayed a page like the following, where I click the CREATE button to create a new service:
Then I am next shown a page where I choose the kind of service I want to make, in this page I choose the POSIX LINUX option because I want to connect to a Linux Server.
Then on the next page, I am entering the information for my Linux server that I want to connect to, the domain name for the server is phongdev.fit.edu, a server for development work.
Note on this page there is a field titled TIVOLI DIRECTORY INTEGRATOR (TDI) where there is default information for the TDI installation, in my case, TDI is installed on the same server as ITIM is installed, so the localhost domain name should be fine. However when I check the server using netstat command there is nothing running on that port, 16231, so I looked up the instructions for starting the TDIDispatcher on google and was told to run the following command, /etc/init.d/ITIMAd restart at the command line and that appeared to run successfully, however still nothing running on port 16231 on the server.
Since our servers use SSH I was required by ITIM to setup key based authentication, I did setup a key and passphrase on this Linux server using ssh, and entered the data on the next screen of ITIM which looks like the following, but as you can see an error is generated when I choose the TEST CONNECTION button:
I checked the logs and there is no info in the logs for these errors, I am not sure where to move next in trying to solve this issue, i suspect it may be related to the fact that the TDI Dispatcher does not appear to be running on port 16231.
Apart from what Matt said (the link especially is useful), the var/ibm/tivoli/common/TDI logs should tell you what the problem with TDI is when you start it up - if there's a problem.
The port number where it's listening ought to be mentioned somewhere in those logs.
Unless there was an upgrade or multiple attempts to configure the RMI dispatcher I don't see why the port shouldn't be 16231 or 1099.
TDI is probably running on a different port. You didn't specify if TDI is running on Windows or Linux, so my answer is assumes Linux since that is what I am most familiar with.
You can find your port # by looking in the solution.properties file in your TDI/timsol directory. It should be listed as api.remote.naming.port.
TDI runs on the default port 1099. Once you start TDI (service ITIMAd start, or however you start it on your system) use ps auxw | grep -i rmi (or something similar) to find the process. Then use netstat -anp | grep PID where PID is the process ID of the TDI RMI process. You should see immediately what port it is listening on. I am not where I have access to a TDI server right now to get you exact commands, but you should get the idea.
Here is a good article for ISIM 6 (should be the same for ITIM 5.1 on TDI 7) on changing the port # for the RMI:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=%2Fcom.ibm.itim_pim.doc%2Fdispatcher%2Finstall_config%2Ft_changeportnum.htm
If you are experiencing error CTGIMT600E and you have multiple network interfaces on TDI 6 or lower, you may need to specify your server IP (or hostname) as a java property so the TDI RMI binds on the correct interface. Edit <tdi_home>/ibmdisrv and insert -Djava.rmi.server.hostname=<yourhost>. For more infomration refer to this article:
http://www-01.ibm.com/support/docview.wss?uid=swg21381101
If you are still having issues, watch your ITIM msg.log and trace.log when you test the connection and look for clues. Also look at the TDI ibmdi.log which will be located under your TDI directory. That may also help you out.
I followed this
http://blogs.technet.com/b/keithmayer/archive/2013/04/17/step-by-step-build-a-free-sharepoint-2013-lab-in-the-cloud-with-windows-azure-31-days-of-servers-in-the-cloud-part-7-of-31.aspx#.UX_iF7XvvQI
I created a VM using the datacentre Image it created successfully and the status shows Its running. I am trying to RDP It says
Remote Desktop cant connect to the remote computer for one of these reasons:
1) Remote access to the server is not enabled
2) The remote computer is turned off
3) The remote computer is not available on the network
make sure the remote computer is turned on and conencted to the network and that remote access is enabled.
I did check the endpoints the public port is open and also 3389 private port is open too. I did try with different release one with latest patch and the other with the second latest OS patch but I am still not able to RDP.
Thanks
Yeah I already figured out firewall in my organization is blocking it. I did update the answer but it did not show up I am trying again :)
Make sure your VM has reached the "Running" status. If it's still in one of its pre-running statuses (such as Provisioning), you won't be able to RDP.
Also: Be sure you don't try logging in with 'Administrator' (the default in the rdp login box). Choose localhost\yourusername.
I had a similar problem the other day. It was solved by going to the Azure Portal, selecting the VM Dashboard, then clicking "Connect" in the grey toolbar at the bottom. This will download an RDP file that contains the correct connection settings. You can then send that rdp file to others who you would like to give access to.
I just opened one of the files used to connect, and it looks like the only real difference is the port used.
full address:s:[vm name].cloudapp.net:62808
username:s:Administrator
prompt for credentials:i:1
I am not sure if all Azure VM's use 62808, but the default RDP port is 3389 so just copying the DNS from the Dashboard into the RDP address will NOT work without adding the correct port.
One more thing folks should check when having trouble connecting is password length.
I thought I would be all secure by using a guid for a password. RDP worked fine from home (on older XP RDP client), but not from office. At first I thought it was a firewall issue. After verifying with the IT guys that I had full outbound access, I looked a little closer at the RDP error message.
It was saying my credentials were rejected. Finally, I created a second account on the VM and gave it RDP access. I was able to log in fine. The only difference between the two users was this time I didn't bother with a long password.
So I shortened the password on my main account and got in with no problem. I'm not sure what the limit is, but it seems to be less than 32.