Connect a Jaeger agent to a collector running in Openshift - jaeger

I am having problems pointing a jaeger agent to a collector running in openshift.
I am able to browse my OCP collector endpoint doing this:
https://mycollectoropenshift.com:443
My jaeger agent Dockerfile currently looks like this
FROM centos:latest
EXPOSE 5775/udp 6831/udp 6832/udp 5778
COPY agent-linux /go/bin/
#CMD ["--collector.host-port=localhost:14267"]
#CMD ["--collector.host-port=https://mycollectoropenshift.com:443"]
CMD ["--collector.host-port=mycollectoropenshift.com:443"]
ENTRYPOINT ["/go/bin/agent-linux"]
I get the expected result when i point my agent to a collector running locally per the first commented line.
I get the following error using the second uncommented CMD flag.
error":"dial tcp: address https://mycollectoropenshift.com:443: too many colons in address"
When i attempt the agent to the collector running on openshift, i get the error below
Failed to run the agent: listen tcp 10.100.120.221:443: bind: cannot assign requested address
I am able to successfully curl the collector endpoint by doing this
curl https://mycollectoropenshift.com:443
I get the following error when i attempt to curl the endpoint this way:
curl mycollectoropenshift.com:443
curl: (52) Empty reply from server
I need help setting up a proper --collector.host-port flag that will connect to a collector running remotely behind an HTTPS protocol.

I don't think it's possible at the moment and you should definitely ask for this feature in the mailing list, Gitter or GitHub issue. The current assumption is that a clear TChannel connection can be made between the agent and collector(s), all being part of the same trusted network.
If you are using the Java, Node or C# client, my recommendation in your situation is to have your Jaeger Client to talk directly to the collector. Look for the env var JAEGER_ENDPOINT in the Client Features documentation page.

Related

In Cloud Foundry, how do I create a service to run my Apache web server?

I'm on Ubuntu 18, running the following version of Cloud Foundry ...
$ cf -v
cf version 7.4.0+e55633fed.2021-11-15
I would to set up several containers, running off Docker image. First is an Apache web server. I have the following Dockerfile
FROM httpd:2.4
COPY ./my-httpd.conf /usr/local/apache2/conf/httpd.conf
COPY ./my-vhosts.conf /usr/local/apache2/conf/extra/httpd-vhosts.conf
COPY ./directory /usr/local/apache2/htdocs/directory
How do I set this up in Cloud foundry? I tried creating a service but got these errors
$ cf cups apache-service -p "localhost, 80"
FAILED
No API endpoint set. Use 'cf login' or 'cf api' to target an endpoint.
When I tried to create this API endpoint I got
$ cf api "http://my_ip_address"
Setting API endpoint to http://my_ip_address...
Request error: Get "http://my_ip_address": dial tcp my_ip_address:80: connect: connection refused
TIP: If you are behind a firewall and require an HTTP proxy, verify the https_proxy environment variable is correctly set. Else, check your network connection.
I'm thinking I'm missing something rather substantial but don't know what the right questions to ask are.
The error message you are providing (dial tcp my_ip_address:80: connect: connection refused ) is related to the cf api $address not responding.
Ensure that your Cloud Foundry API Endpoint is still active and you don't have any firewall preventing you from accessing the API. (port is open, the process is running, and the firewall is allowing traffic from your IP if applicable)

How to CURL an instance of OpenStack from another Instance

I have running devstack on my machine and created an instance of Alpine Linux which runs a Rails API (IP 10.0.0.6) on port 3000 (also tried 80, 8080). Then I created a simple CirrOS client instance (IP 10.0.0.4) to access the /test endpoint of the API. However, i find that I can Å•un:
ping 10.0.0.6
from the CirrOS instance and receive response of packets. However, when I try:
curl -XGET http://10.0.0.6:3000/test
I receive the error:
curl: (7) couldn't connect to host
The two instances belong to the private network and the security group policy allows any Ingress and Egress of any kind of protocol.
The /test endpoint works locally on the API instance.
I also tested that I'm able to make an ssh connection from one instance to another.
What configuration could I be missing? Thanks!
Found the solution.
It wasn't a wrong configuration on openstack side.
I needed to run rails with the flag -b 0.0.0.0 to allow any IP. Rails on default only serves the localhost IP.
rails s -b 0.0.0.0
You could always try telneting on the particular port which server is running on to locate the issue whether it's networking issue or it is any other configuration issue.

TURN server broken - Coturn

Just a bit of background first.
I have installed coturn server in my local machine (Behind a firewall and with local IP).
I have created a port forwarding for cotrun server lets say my local ip is: 192.168.0.11:3478 is mapped with my public ip 10.1.10.212:3478.
When I use some online utility to check my public IP has this port open it? that utility shows that it is open.
I am trying to test this server using this fiddle: Code to test TURN server
I removed the stun configuration from it, and added my live ip and port. And when I try to test it, it says your TURN server is broken in console on web browser. And I see failed as output.
I have also used following commands to create a user from this link.
Wiki to Coturn Configuration
// created test user
sudo turnadmin -a -u test -r test -p test
// enabling admin support in web (not sure how to access it in browser)
sudo turnadmin -A -u test -p test
I start the turn server using following command:
turnserver -L 192.168.0.11 -a -f -v -X -r test
I have enabled the "TURNSERVER_ENABLED"
/etc/default/coturn
TURNSERVER_ENABLED=1
Screenshot of my about:webrtc:
Please find the below attached Screen shot for my about:webrtc. I am not sure what is missing.
EDIT-1
I can also see the incoming packet message processed, error 401: Unauthorized in the console of TURN server
EDIT-2
I resolved the TURN server related issue, added the turn server in client code as well, still facing issue, call is not going through,
Update
Here is what I found, the reason why it wasn't working earlier was due to a defective router in the network. This thing has harassed me for almost a month (however the internet used to work fine). But I found that there is a loss of packets and I switch to LAN cable I even avoided the firewall of the organization and there it was working just fine. Then I configured the rules in firewall and it started working as well.
A few issues that might be causing this:
The -X option requires an argument - the external IP if the TURN server is behind a NAT.
If you are setting all your parameters on the command line, you should include -n to ensure that it does not load an unrelated configuration file.
TURNSERVER_ENABLED=1 is to start turnserver with default configuration at system boot. You do not want this if you are starting turnserver manually from the command line.
https://github.com/coturn/coturn/blob/master/README.turnserver
" I have created a port forwarding for CoTurn server lets say my local ip is: 192.168.0.11:3478 is mapped with my public ip 10.1.10.212:3478."
Now surely you are aware that the private address-spaces in IPV4 are (private IP ranges):
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
So, your first IP is in the last private IP range, and your so-called "public IP" is in the first private IP-range. Now you need to find your TRUE REAL public-IP address to try to connect to it from outside. I would say that it looks like your ISP has you behind a NAT. So your TURN server might be behind two NATs. Which is kind of ironic situation for a server designed to help penetrate NATs of webRTC-clients. You might want to try to put CoTurn somewhere where it is possible for it to work like AWS (special case of CoTurn friendly NAT).
Just recently got (well with lots of help -- that even did the most of the work) CoTurn to work in cloud and on local Ubuntu ;-) (never stopped me from bragging though). Though there is troubling few srflx-call-successes yet (mostly local network or relay(TURN) calls). :-D

The system cannot infer the transport information from xxxx url

I have been trying to configure a simple pass through proxy using wso2 esb, which points to a REST service in https port.
I had tried doing the same using my development machine (Windows 7) and it is successful.
But when I try repeating the same in production server, in RHEL, I get The system cannot infer the transport information error in system log.
Things Tried
Created passthrough proxy service pointing to https://some.domain.in/something/something.
Tried CURL to https://some.domain.in/something/something and its shows the response properly
Imported certificate from the site to client-truststore.jks. Same was done locally and it worked.
in axis2.xml, edited <parameter name="HostnameVerifier">AllowAll</parameter>under https transporter
Error Message
When clicked in test in configuration console, I got the following message, Invalid address
CURL the proxy service URL, and got Empty response
Checked system logs and saw below logs
Am I missing out something?
I could see in the wso2-error-logs following messages
ERROR {org.apache.synapse.transport.passthru.TargetHandler} - I/O
error: handshake alert: unrecognized_name
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
Then I realised that I was using java 1.6 locally but 1.7 in production.
And in Java 1.7 there are some changes in SSL handling
The JDK 7 release supports
the Server Name Indication (SNI) extension in the JSSE client. SNI,
described in RFC 4366 enables TLS clients to connect to virtual
servers.
In order to bypass this, I added JAVA_OPTS="-Djsse.enableSNIExtension=false" in wso2server.sh and restarted.
This solved my problem.
Not sure if this is the correct way though
This url helped me finally

cURL : (52) Empty reply from server

I am writing a remote API to handle some backend processes and my API typically takes about 30 seconds to complete the operation (I am fine with the wait time, it is an internal process). When I make a cURL call to the API, I get the following message curl: (52) Empty reply from server.
I need the cURL to wait for the response, -m and connect-timeout do not seem to help.
Additional information : I am using Sinatra for the backend API
I try It with get "/"; sleep(30); "response"; end an just use curl without any additional parameter and it work fine.
This mean normally it's not sinata or curl. It's something between like a proxy with timeout, a application server or anything else.
I was getting the same error and traced it to be an issue with my proxy settings. Specifically I'm using TSOCKS to send everything to a socks proxy. Disabling TSOCKS allowed curl to work. Specifying the socks proxy with the curl command resolved the issue.
eg. curl --proxy socks5h://192.168.0.5:8111 http://webserver.com/file.ext