enter image description here
I am still beginner with ubuntu servers and when l was trying to connect to server I got the error in image
I searched a lot about the problem to find solution but I didn't find anything help with this problem.
the way ssh works you need to make sure the target machine is running sshd demon on port 22. (service)
The given topic is discussed in detail below thread.
https://github.com/microsoft/WSL/issues/2278
As per the thread, One of the prominent reasons the above issue is showing up is due to target firewall access at port 22 as well. Please check if such a filter exists.
Related
I am recently working on a project in Google Cloud Compute Engine, and I have created an image of my current work. In this instance I can access using VNC Viewer to a GUI like of the instance by using the public IP and the port :5901 .
I gave the permissions to another person to use this image in his own proyect, but although he can start the instance created from my image, he cant access using VNC and the public IP (timeout problem).
I guess it has to do with anything related to the SSH protocol, but I dont know exactly how.
Does anyone has an idea of how to solve this issue?
I found the asnwer in a youtube video: Here, (10:52) I just had to habilitate the tcp ports on my project. Thanks!
I had to go to firewall configuration, add firewall a rule that habilitates all tcp ports from 0.0.0.0/0 for incoming connections in all instances since I'll be using more than one instance in my project.
Honestly I don't know if I did "overdo" anything, but it worked for me.
I am new to Mesos and just finished setting up mesos and along with zookeeper on my test server.
Unfortunately I keep getting this error message on my mesos console indicating i am unable to connect to mesos on port 5050 and can't seem to figure out why.
I have included the error in the screen shot below
The mesos log files doesn't point to why the error is showing either.
I resolved the problem by this:
./bin/mesos-master.sh --ip=x.x.x.x --work_dir=/var/lib/mesos --hostname=x.x.x.x
We can avoid this problem by starting mesos-master with following option:
--ip=xx.xx.xx.xx --hostname_lookup=false
I have resolved this problem. Open the web page in Chrome, and open the developer tool, you will see the chrome is accessing the web site with domain, in my case the domain name is "mesosphere", as there is no mesosphere in dns, so the accessing was failed.
I solved the problem by adding the mesosphere in the hosts file, C:/windows/system32/etc/hosts/
If you use the domain name for the Mesos cluster you must set the domain name in windows hosts.
There can be multiple issues here.
Is your mesos-master running and healthy ?
Has leader election process completed, if all is good.
Check if you are able to do
ping leader.mesos
If above ping doesn't work, that means leader has not been elected. First fix that.
I had this problem also. Luckily, I have a running mesos server also. So, I can compare the different between my demo and the running mesos server. I captured the packets between client and server in my demo. I found the explorer didn`t resend fresh request, only some keepalive packets.
but, when I catch the packets in the running mesos server, I found the explorer send get request frequently. like the image
I think, if you run some task or add some agent, maybe it will activate the explore to send request frequently. Then the "Failed to connect" will disappeared.
I was having the same issues and what fixed it for me was the zookeeper configuration. In my case I was using the EC2 public IP Address rather than the private one. Once I changed the /etc/mesos/zk file to zk://<private IP>:2181/mesos I was able to connect without the constant error messages. In other words, zookeeper was reporting to be running in one IP and mesos-master was trying to connect using a different IP.
My configuration was correct as suggested. But failed to start mesos-master service. But There is alternative way to start mesos-master node with exact same configuration. Commands to start mesos-master
$ cd /usr/sbin [or mesos_installation directory/bin]
$sudo ./mesos-master --work_dir=/var/lib/mesos --log_dir=/home/rajeev/logs/mesos/
Its start mesos-master service successfully for me.
I have a very weird problem.
We have a Hyper-V failover cluster, where some guest VMs start to show specific problems after a live migration.
In each case, the live migration mostly works, but after it has been migrated, we can't log into some software (our product WinGate) any more. The SSPI handshake succeeds, we can RDP to the image, so it's not networking.
But ADSI fails to open a search object to retrieve a user object, and gives error 8007203A.
Since networking is working, SSPI is working, obviously domain connectivity is working to some degree, but the ADSI failure is very perplexing.
Has anyone else seen this? I feel it's most likely a bug in Windows, but we have been seeing this for over 18 months now - since we set up the cluster.
P.s. all hosts and VMs are 2k12R2 fully patched.
P.p.s. all VM MACs are fixed.
OK, looks like I found the answer.
Problem is NLA reclassified the domain network adapter after a live migrate, and set it to an unidentified network. This then kicked in the firewall to block ADSI.
thanks to this blog I was able to force NLA to view the adapter as a domain adapter (by adding a domain DNS suffix to the adapter), and the problem is solved. Hope this helps someone else!
We have a Win Server 2008 box being hosted (dedicated) for us.
I need to connect to one of it's DB's from a server in our LAN.
What started out as a "sure, I'll just throw that together for you real quick" project has turned into a week-long hair-pulling pile of WTF :)
I am able to RDP into that server without fail or issue.
When I tried to connect to the DB, I got a generic "could not connect" error, so I went hunting.
Telnet attemtps and pings time out.
Since then, we have tried endless variations of firewall settings (including wide open), and still ... no go.
In addition to our firewall, the hosting provider also has a firewall layer.
We turned on all logging, and we don't even see any connection attempts at our FW.
We then had the hosting provider turn on all logging, and they don't see any connection attempts either!
Hrmmmph
I'm at a complete loss.
Any suggestions?
BTW, while I'm comfortable enough with all this to explore and make changes, my experience with firewalls and stuff is fairly limited, so don't hesitate to dumb it down ;)
It is hard to give just one answer to this question, because the interim results of the problem analysis lead to different steps that you need to do next. It will more likely be a step by step help with tracing down the problem.
Do not trust any firewall setting (esp. not any that someone else did, and again esp. not if you don't know him), unless you tested it. Firewall settings are tricky and even experienced professionals get them wrong now and then.
In the guide below, I will write <win2008server> in commands where you have to put the name or IP of the windows 2008 server to which you want to connect. On the other side, I will use the expression "office PC" when I mean your workstation PC in the office from where you are trying to connect to the win2008server.
STEP 1: Checking the Endpoints
1.) Can you telnet to the RDP port?
On your office PC, try this on a command prompt:
telnet <win2008server> 3389
This is to make sure that DNS name resulution works for telnet, as well as network hardware and routing. It should, because you can use RDP to establish this connection. However, anything can get in between, like the telnet command being in any way configured nonstandard or being replaced for whatever reason on a company pc (sysadmins have strange ideas at times...).
2.) Can you telnet locally on the win2008server to the database?
When logged in using RDP on the win2008server, open a command prompt on the server and issue the command
telnet <win2008server> <database port>
That means you are trying to connect from the server to itself. This is to make sure the database port is open on the server.
STEP 2: Checking the Firewalls of the Endpoints
If for 1.) and 2.), your answer is yes it works, you have to test if either the remote side can not be reached or your location can not connect to the internet on the port you are testing (database port). You do this by replacing the respective other side with any other host on the internet for which you know it's reachable or can reach other servers. Typically, you google for a port checker ;)
3.) Check if the win2008server can be reached from another location than yours:
3.1.) Check if the RDP port of the win2008server can be reached from a third party location:
Google for port checker and take the first result (e.g. http://www.yougetsignal.com/tools/open-ports/ ). Type in the name or IP address of the win2008server and the RDP port, usually 3389 . Click on "check" and wait for the success or the timeout.
3.2.) Check if the database port of the win2008server can be reached from a third party location:
Do the same as in 3.1.), just with the database port instead of the RDP port.
4.) Check if you can connect to an outside server on the database port:
For this to work, you need to know a server or create one, which is somewhere outside on the internet, and which listens on the database port. You typically do this by keeping your private PC at home run and accessible through RDP or SSH, and there you open a server and configure your private internet router to forward the connection correctly.
Another way to do this test is webspace with SSH access. Many webspace providers nowadays allow for an SSH login (usually any webspace at $4/month and above).
Let's assume you have SSH access to any such third party place. You can use nc (netcat) there to open a server socket on the database port with this command:
nc -l <database port>
If it's your private PC at home, you usually have to also configure your private router and set up a dynamic DNS name for your internet access for the whole story to work out. You do not have this extra work with a webspace based SSH login. However, there you can not test ports below 1024 because you do not have the privileges. Good luck with this ;)
After you got this, try connecting to the port that you opened:
4.1.) From your office PC with
telnet <third party location> <database port>
4.2.) If 4.1.) does not work, also try with the port checker, because you might have gotten something wrong with setting up the server. Look at 3.) for this, and use the <third party location> and <database port> with the port checker (fourth party check).
STEP 3: Blaming ;)
At least one of the things should have failed by now and you can start calling people and letting them know about your tests and the results. You should be able to combine the results logically, but never start with that. Think about how to convey the information. Start out with your findings and then let them have a moment for their own conclusion. It can be difficult to tell someone in another company or department that their firewall isn't configured correctly. They might deny this even in the presence of proof. Be patient. Explain your findings again. Hint at the conclusion. This can be the trickiest part of the whole problem solution.
I have to say that today I had the same problem.
My solution was just to edit secpol.msc and disable all the FW profiles; then, run services.msc and also disable Windows Firewall service.
After this server was pingable for me.
I am troubleshooting an issue with IIS6 where all sites bound to ip addresses other than the default give an error message "network location cannot be reached" when trying to start any of these sites.
The nic has all the ip addresses configured.
When I do a httpcfg query iplisten, I see only the default ip address.
When I added them with httpcfg, then all the web sites stopped working so I figured I didn something wrong so I removed them.
Two questions:
1- Why are those websites refusing to start?
2- What should be in the result of httpcfg query iplisten? All ip addresses or just one?
The websites used to work fine and something has changed. I applied a few Windows updates but I am not sure if they broke anything (I doubt it.. otherwise hundreds of web hosting companies would be screaming)
The solution was to use httpcfg without specifying the port number.
Sometimes there are bugs wehn applying windows updates. One thing you might try is running aspnet_regiis /i or /c. I'm not sure if that's your problem but it's certainly worth a shot.
That message generally comes from Windows networking (it's one of ERROR_NETWORK_UNREACHABLE, ERROR_HOST_UNREACHABLE, ERROR_PROTOCOL_UNREACHABLE - you can search for error messages in WinError.h).
Have you set up virtual directories to point at network shares on another machine? If so, check connectivity to that machine.