we are having clearcase in our organization production network. There is another separate network which is having limitted ports are opened. The users in production network will not be there in lab network.
Is it possible to open few ports and access clearcase from the lab network?
That depends on your support IT and network admins, but yes, you can open ports if you know which ones are important for ClearCase.
See "About Firewalls and ClearCase"
IBM Rational ClearCase is known to operate correctly through firewalls in internal networks if the following conditions are met:
Port 371 (UDP and TCP) is passed through to any/all ClearCase server hosts from the allowed hosts.
All ports over 1024 (UDP and TCP) are open from the allowed ClearCase client hosts to needed ClearCase server hosts.
On Windows with McAfee Antivirus (access protection), also open port 6666 (IRC). Cleartool.exe may use that port to acquire a license.
If you do not open that port, the user command will fail with error: Unable to contact albd_server on host.
Yes its possible to open the ports on your lab network and able to use the clearcase from there
The general ports which are for clearcase is port 371 UDP and TCP which is used for the Clearcase server and 1024 UDP and TCp which is used for Clearcase client
Related
I have installed SQL Server in an AWS instance (Ubuntu) and it is working perfectly but found that it is not able to connect to the database from certain IPs (from that region not working for any ISPs). My port 1433 is open and I am able to access it from my system. Here is my security group configuration:
But in my friends system which is in a different network it is not connecting though I can access port 80 from that system. I telnet that port (1433) and it is throwing "could not connect host". I tried tracetcp and after 9 hops the requests are timed out. I used VPN in that system and it got connected.
Not able to determine what could be the issue. Not a network pro and any help is highly appreciated.
I've created a new Azure VM and tried opening 1433 for a remote database connection (I understand long term this shouldn't be a public port).
I've created a rule in my NSG to open port 1433, and entirely disabled windows firewall, and I still cannot get through port 1433.
If I go in and disassociate the NSG, then I can connect just fine, so it's not the server that's blocking, it's happening at the NSG level
This is a fresh install of Windows 2012 R2 Datacenter.
Here's my NSG
Inbound security rules image
Here's my VM Networking details
Networking VM Rules
Check if SQL-Server service accept remote connections and if it's listening on 1433 port. Specify a source IP address for the rule (is absolutely not recommended to open a port to all). Do a port scan to the specific ip.
I have 4 Azure VMs which are part of the same resource group and virtual network. 3 of them are running SQL Sever and 1 of them is configured as a domain controller. The 3 SQL VMs are getting there DNS from the DC.
The VMs can log into the domain and see each other on the network. When I try to use connect to SQL instances across the virtual network, however, I receive a network path not found error.
I have renamed the instances and even tried removing and re-installing them. So I am sure it is a network issue, and not a SQL Server problem. I also can't connect via IP address, so it doesn't seem to be DNS.
The instances are all default instances and are connected on 1433, the VMs all have TCP 1433 endpoints and Windows Firewall is turned off.
I think you need to Enable the Port from Azure Services As well
The instances are all default instances and are connected on 1434, the
VMs all have TCP 1433 endpoints, and Windows Firewall is turned off.
Ensure you have both ports open in all machines. 1433, 1434
Also remember that disable windows firewall is just a temporary thing, you should re-enable it once the connection test pass.
Note that depending of your kind of connection/services you also should open:
1433: / TCP / UDP
80: For sync over HTTP / TCP
443: SQL Server default instance running over an HTTPS endpoint / TCP
4022: Service Broker / TCP
135: Transact-SQL debugger / TCP
7022: Defacto database mirroring / TCP
2383: SQL Server Analysis Services
2382: connection requests to a named instance of Analysis Services
I am trying to connect from a NoMachine client on a Windows 7 machine to an OpenSUSE machine. I can only connect via NX however I keep running into Error 138:Connection Timed out. I can connect via SSH on my Command prompt however Seem to be unable to connect via here. Does anyone know a solution - been doing this since morning with no light in sight!
Routers supporting UPnP or NAT-PMP are configured automatically to pass connections to NoMachine and all required information is displayed at initial screen (Welcome to NoMachine).
Routers not supporting UPnP or NAT-PMP and Firewalls have to be configured manually to pass traffic to port 4000 (NX protocol), 22 (SSH protocol on Linux/MacOSX) or (4022) (SSH protocol on Windows).
So, check the configuration first.
I have a similar issue setting up my ftp server.
There are a couple of possibilities why the connection was not established, but in my case, and perhaps yours, you must allow the service you're trying to execute in your firewall settings.
In my case I allowed the ftp port and some other specific port for tcp communication.
This (and the proper service, router, etc setup) allowed the communication to be established.
I am trying to use this c socket class, but it only works when I use it on my own computer.
Desktop only
Server is started like this: cSocketServer -p:2030 -i:192.168.178.22
Client connects: cSocketclient -p:2030 -s:192.168.178.22
Works fine.
Desktop server, laptop client
Server: cSocketServer -p:2030 -i:192.168.178.22
Client: cSocketclient -p:2030 -s:192.168.178.22
Exact same as above, but this fires the connect failed: 10060 error. Which essentially means it timed out.
Desktop only (external address)
Server: cSocketServer -p:2030 -i:192.168.178.22
Client: cSocketclient -p:2030 -s:xx.xx.xx.xx
Where xx.xx.xx.xx is my external ip address.
Same error: connect failed: 10060. Port 2030 is definitely open and accessible, because I tested it with a few unrelated applications that allow their users to choose their own ports (like utorrent). While those run, whatismyip.org states port 2030 is open. But when I run my application it sais it Timed-out. Those applications do not have any special privileges in the firewall.
But even if I did mess up some firewall/router settings (which I'm fairly sure I didn't) that wouldn't explain why I can't connect to the server from within my local network. Other services (such as file sharing) work fine so there is definitely a connection between the 2 computers.
Both client and server run on windows 7 64-bit.
Also; for some reason, each client that connects gets their own inbound port assigned or something? Is that normal? When clients connect the server states;
Accepted client: 192.168.178.22:55156
Accepted client: 192.168.178.22:55164
Accepted client: 192.168.178.22:55176
What's that all about?
If two TCP connections have the same source IP, destination IP, source port, and destination port, there would be no way to tell them apart. To ensure they differ somewhere, clients typically assign a unique source port to every outbound connection they make.
As for the errors, you really need to do some troubleshooting. Do the listening sockets show up in a 'netstat'? Do you get the same problem with the firewalls turned off? Are the server and client on the same LAN (for the internal address case)? Is port forwarding enabled and working in the router (for the external address case)?
My bet is that the external address case won't work because you haven't configured the port to be forwarded by your router or your router doesn't support hairpin (local access to external IP). Other programs may work because they support UPnP or don't rely on hairpin (all access to external IPs come from outside your LAN).
I have no immediate explanation for why your desktop-to-laptop won't work inside your LAN. Are you sure both computers are in the same LAN? Can they ping each other?
Get rid of the -i argument to the server, or specify 0.0.0.0 and fix the code so that isn't considered an error, which is itself an error.