I have a TeamCity Server(9.0.3 (build 32334)) on Amazon EC2 Windows Instance.
And i have another EC2 instance(Windows) for my Build Agents. I Installed a Build Agent on this new Instance on Port 9090 and it shows perfectly on the teamCity UI, however when i installed a second Agent on the same machine this time with port 9091, the new agent does not show up on the TeamCity UI(under connected/disconnected/unauthorized).
However both the Agent services are running ( verified it under Windows Services).
I followed this link for installing multiple agents :
https://confluence.jetbrains.com/display/TCD9/Setting+up+and+Running+Additional+Build+Agents#SettingupandRunningAdditionalBuildAgents-UsingLaunchDaemonsStartupFilesonMacOSx
And this is what i got from the TeamCity Agent log
buildServer.AGENT.registration - Call http://1.2.3.4/RPC2 buildServer.registerAgent3: org.apache.xmlrpc.XmlRpcException: jetbrains.buildServer.CannotPingAgentException: Unable to ping agent BuildAgent_QANEW. Check firewall and/or try to specify 'ownAddress' in the agent configuration. Details: Agent 'BuildAgent_QANEW' cannot be accessed by any of the addresses: [1.2.3.4, 2001:0:9d38:90d7:1ca5:281b:f575:9901, 1.2.3.4], (port 9091)
It turned out to be an Firewall issue, i added a Custom TCP rule for Port 9091 for the Security group on EC2 and now the agent on port 9091 is also connecting. So whenever there is a CannotPingAgentException its most probably due to Firewall or Incorrect Agent properties.
Related
When working behind a corporate proxy (automatically activated in Windows) by Cisco AnyConnect(v4.7.03052) VPN, I'm unable to pull any docker image either from our docker nexus registry or the official registry.
Funny enough, if I set the proxy settings in the config.json and pass the proxy as build-arg my containers are able to build(from previously pulled images) and talk to the exterior.
Only the docker engine is unable to access the internet through the proxy.
I've already tried the following:
Set the HTTP_PROXY/HTTPS_PROXY as environments variables
Set the proxy settings in the Docker Desktop proxy section - Docker doc
Set the resources network IP to the non-secured Cisco AnyConnect routes IPv4
No firewall rules seems to block the outbound request from the docker engine service.
Edit the deamon.json used by the docker service to register the mirror registries.
Stackoverflow answers not working in this case: docker-win10; docker on windows; docker image proxy
Platform info:
Win 10 - Build 19401
Docker Desktop 4.4.4(73704)
Docker Engine 20.12.12 (Linux container on Hyper-V)
Cisco AnyConnect v4.7.03052
Error message on docker pull:
λ docker pull traefik:2.0
Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Based on the similar stackoverflow issue briefly executing the command below had it working for a short time:
cd "C:\Program Files\Docker\Docker"
./DockerCli.exe -SwitchDaemon
This was a regression that slipped in the 4.4.4 see github issue.
It seems to have been resolved in the v4.5.0
I have a Linux VM running with a Jenkins, Nexus and SonarQube server on it. The IP for the VM is 192.168.56.2 and I have no trouble accessing both Jenkins and Nexus on ports 8080 and 8081 respectively. However, when I try to access 192.168.56.2:9000 for SonarQube it just says 192.168.56.2 refused to connect.
When I run systemctl status sonar in the terminal it shows that SonarQube is active and running. I have opened the firewall to port 9000 and I have not changed any of the default settings. Does anyone have any idea what might be the issue?
SonarQube will only be listening on 'loopback' rather than on all inbound IP addresses. In your server's sonar.properties file, you'll need to set the Web information in order to access the server remotely, specifically the following values:
sonar.web.host: 192.168.56.2
sonar.web.port: 80 # if you want to use a port other than 9000
Also, in the web UI's Settings, under the "General" section, set the "Server base URL" value so that links and redirects issued by SonarQube target the correct location.
I am running IBM Cloud Private using 5 VMs on my laptop. My home network subnet is 192.168.100 whereas the subnet used by all 5 VMs is 192.168.142. I am port forwarding 8443 from the VMware Workstation from host to the master node which is 192.168.142.103. My laptop IP is 192.168.100.201.
I was hoping that I should be able to access this Web UI from any other machine in my home network and I tried this URL from other machine:
https://192.168.100.201:8443
And, it directs properly to the guest VM as I see the url changes to :
https://192.168.100.201:8443/console/
But, after few seconds, I get the message that the site cannot be reached. I noticed that the url has changed from original host laptop address of 192.168.100.201 address to the Guest VM address 192.168.142.103 as shown:
https://192.168.142.103:8443/idauth/oidc/endpoint/OP/authorize?client_id=617a0480d5e506a5e797f852bea1df38&response_type=code&scope=openid%20email%20profile&redirect_uri=https://192.168.100.201:8443/auth/liberty/callback
This seems like that the redirection in the Web UI is not handled properly.
However, I installed kubectl for Windows on another machine and I did the port 8001 forward from 192.168.100.201 to the VM's master Guest 192.168.142.103 and added kubectl set config commands (from web UI Client Configure option) on my other laptop (192.168.100.202).
kubectl config set-cluster pot_icp_cluster.icp --server=https://192.168.100.201:8001 --insecure-skip-tls-verify=true
kubectl config set-context pot_icp_cluster.icp-context --cluster=pot_icp_cluster.icp
kubectl config set-credentials admin --token=<token>
kubectl config set-context pot_icp_cluster.icp-context --user=admin --namespace=default
kubectl config use-context pot_icp_cluster.icp-context
And, this works perfect as I am able to run kubectl commands from the other laptop (192.168.100.202) to the VMs running on another laptop (192.168.100.201) using port forwarding same way I did for the Web UI.
My question is: Is there something that I can do to get this redirection problem fixed in the Web UI?
I received a reply from an expert that liberty server that authenticates and verifies a login has only the master node's IP address registered with it as a callback URL during the installation. In the version of IBM Cloud Private 2.1.0.1, there is no direct way to register the new clients. However, this limitation is being fixed and starting next upgrade, we should be able to register new clients dynamically post install also.
I am trying to connect teamcity server running in Ubuntu, from windows but its not working.
I changed firewall settings and opened up port 9090 and 8111.
I got these logs from windows agent
Call http://my.domain.com:8111/RPC2 buildServer.registerAgent3:
org.apache.xmlrpc.XmlRpcException:
jetbrains.buildServer.CannotPingAgentException: Unable to ping agent .
Check firewall and/or try to specify 'ownAddress' in the agent
configuration. Details: Agent '' cannot be accessed by any of the
addresses: [183.83.50.68, 192.168.1.146], (port 9090)
It means that TeamCity server can't access TeamCity agent by the specified addresses and port.
Ensure that your agent IP address is 183.83.50.68 and that incoming connections to the 9090 port are not blocked by not only firewall, but also by antivirus or similar software.
Or you can update to the TeamCity 9.1 or later - in these versions server doesn't have to be able to connect to the agent, only agent-to-server connection is necessary.
I'm setting up Hudson as an integration server that I expect other developers and stackholders to access. Rather than have to pass around urls with a specific port, I'd like to configure Hudson to listen on port 80.
The default port from installing Hudson as a service is 8080. I'd like to change this to 80, on a Server 2008 R2 or windows 7 machine that isn't running IIS or Apache.
Do the following to reconfigure the port :
Edit hudson.xml (found in your hudson installation directory)
change the parameter string on line 44 to reference port 80 (--httpPort=8080 to --httpPort 80)
Depending on what plugins you may have set up, there may be other references to the hudson url. Find these by doing a text search in the hudson directory on ':8080' and removing the port number.
Disable the 'World Wide Web Publishing Service' service. By default, this service consumes port 80, which is the port we want to use.
Verify that your machine is configured to accept an external connection on port 80 (ie, open a firewall port)
Restart the Hudson service.