We are trying to use RESTCOMM OLYMPUS by making few customizations as part of our application. The main customization is that we have deployed OLYMPUS war on our Apache TOmcat web server and the OUTBOUND PROXY is properly pointed to the same server where RESTCOMM is running.
So far all is good, but recently we got the issue that "getUserMedia()" deprecation issue because of insecure origin issue by chromium fix.
So, it means we need to use HTTPS and WSS. I can see that just around 7 days back OLYMPUS code has been updated on GITHUB to use WSS if HTTPS has been used in browser location bar.
So first we have installed self signed CERT and enabled SLL config on TOMCAT so that our customized OLYMPUS UI is accessed via https from Tomcat. And then we used WSS protocol to connect to OUTBOUND PROXY. Bt we got the below error
"WebSocket connection to 'wss:/:5082/' failed: Error in connection establishment: net::ERR_TIMED_OUT
WSMessageChannel:createWebSocket(): websocket connection has failed:[object Event]"
Then we thought that in addition to TOMCAT ( where WAR is deployed) we need to install self singed cert and SSL config on RESTCOMM as well. So we did it by following http://docs.telestax.com/restcomm-enable-https-secure-connector-on-jboss-as-7-or-eap-6/ and also we have used WSS protocol.
But this time also we got the error but with a different error code though
"WebSocket connection to 'wss:/:5083/' failed: Error in connection establishment: net::ERR_CONNECTION_CLOSED
WSMessageChannel:createWebSocket(): websocket connection has failed:[object Event]"
Can i request the forums to explain if we are missing any thin here?
Thanks in advance
I would suggest to use the mobicents RestComm docker image instead of using the zip bundle, because for docker image all settings are handled automatically and https/wss should work out of the box. Here are some quick steps to get you started:
Install docker in your Ubuntu if not already there
Download RestComm docker image:
$ docker pull mobicents/restcomm:latest
Start docker image:
$ docker run -e SECURE="true" -e SSL_MODE="allowall" -e USE_STANDARD_PORTS="true" -e VOICERSS_KEY="VOICERSS_KEY_HERE" --name=restcomm -d -p 80:80 -p 443:443 -p 9990:9990 -p 5060:5060 -p 5061:5061 -p 5062:5062 -p 5063:5063 -p 5060:5060/udp -p 65000-65535:65000-65535/udp mobicents/restcomm:latest
Now you should be able to reach your RestComm instance Admin UI at:
https://<host ip address>/
Make sure that you don't have any servers running in your host at the ports used by the docker container above, or you'll have to use different ports (please refer to the docker hub page for such options)
Best regards,
Antonis Tsakiridis
Related
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)
I want to host my fastAPI application using gunicorn and host it on a Kubernetes Service. My Kubernetes service runs a liveness probe (health check) using HTTP call on a specified endpoint.
I also want the application to be served on HTTPS because my Kubernetes service exposes it to be used by external components.
Now my HTTP endpoint can't rely on redirection as the liveness probe expects a 200 Response and redirection will hamper that.
I want to host my HTTPS endpoint on a pre-specified port as the organization has the best practices in place and the endpoint and port are specified.
Some similar problems on StackOverflow:
Running Gunicorn on both http and https
uvicorn [fastapi] python run both HTTP and HTTPS
But both of these are okay with redirection, and we are not. And we cannot use the NGINX server too, because that support is deprecated in my organization.
If we are trying this out in a Docker environment. The following will get it done:
Dockerfile:
ENTRYPOINT ./start.sh
Shell Script start.sh:
gunicorn -k uvicorn.workers.UvicornWorker -w 3 -b 0.0.0.0:30000 -t 360 --reload app:app & gunicorn -k uvicorn.workers.UvicornWorker -w 3 --ssl-certfile certfile.txt --ssl-keyfile keyfile.txt --ca-certs ca_certs.txt -b 0.0.0.0:8443 -t 360 --reload app:app
The & runs one in the background and then runs the other one. You can configure one to use HTTP and one to use HTTPS.
We are using gunicorn for fastAPI application so we are using uvicorn workers and you need to change it accordingly for your use case.
For people landing here looking for fastapi/uvicorn help:
uvicorn api:app\
--ssl-certfile=yourcert.pem\
--ssl-keyfile=yourkey.pem\
--host 0.0.0.0 --port 443 --workers 1\
&\
uvicorn api:app\
--host 0.0.0.0 --port 80 --workers 1
You should know, the background daemon will fail to close on CTRL+C. It's best to use something like tmux, and run the :80 and :443 in different windows.
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.
I have a problem with my registry docker. My "server" VM is on kali-linux. I created the registry docker in HTTP and use a centOS VM as a client. I declared the registry insecure in the client VM and it worked perfectly.
Now I try to put it in HTTPS. In order to do that, I use nginx as a proxy. I followed this tutorial : Step 5 — Setting Up SSL except for Part 8 to make it a service (I don't know why but i can't do it).
Because I don't have a domain name, I used a fake one. In order to be recognized, I added my IP (192.168.X.X) and the domain name I used (myregistryexemple) to the /etc/hosts file on both VM.
As asked by the tutorial, I generated the certificat on my "server" VM (the kali one), and send it by scp to my client VM. I make the centOS vm trust the certificate thanks to this commands :
yum install ca-certificates
update-ca-trust force-enable
cp cert.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
I restart the service docker on the client VM. And launch the docker registry and the nginx proxy with "docker-compose up" on my kali VM.
I tag and try to push an ubuntu on the registry :
docker tag ubuntu myregistryexemple/ubuntu
docker push myregistryexemple/ubuntu
But I get this error :
The push refers to a repository [docker.io/myregistryexemple/ubuntu]
56827159aa8b: Preparing
440e02c3dcde: Preparing
29660d0e5bb2: Preparing
85782553e37a: Preparing
745f5be9952c: Preparing
denied: requested access to the resource is denied
Then I try to push to localhost directly :
docker tag ubuntu localhost:5000/ubuntu & docker push localhost:5000/ubuntu
then I docker login on the domain from the client VM, it worked, but when i tried to pull from my domain registry on the client VM, docker cannot find on the registry the docker images i tried to push.
Do someone has any idea why and knows how to help me ?
Ok so i found a way to make it work.
It is quite simple : Juste follow the complete tutorial I quote on the question ( https://www.digitalocean.com/community/tutorials/how-to-set-up-a-private-docker-registry-on-ubuntu-14-04#step-5-%E2%80%94-setting-up-ssl )
After you created the repository, and before you push/pull a docker image.
You need to go, in both client and server VM, on /etc/hosts .
Add the line : domainChosen serverVmIp
Save and quit it.
Now we need the client to trust the certificate generated. In order to do that, you can use this tutorial : http://kb.kerio.com/product/kerio-connect/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html .
Then restart your registry and your docker deamon. And you normaly can use your domain name to push/pull in your registry in https.
My question is, as I understand docker-machine uses docker remote API to do whatever it does, for example to regenerate certificates. I have checked docker API but couldn't find how it's possible to send certificates to that machine using only docker api, can someone help please?
The TLS files are hosted locally on the Docker client. For this reason you should protect the files as if they were a root password.
This page will walk you through generating the files needed to negotiate a connection over TLS. Note that the remote daemon must be running TLS.
https://docs.docker.com/engine/security/https/
docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=$HOST:2376 version
Note: Docker over TLS should run on TCP port 2376.
Warning: As shown in the example above, you don’t have to run the
docker client with sudo or the docker group when you use certificate
authentication. That means anyone with the keys can give any
instructions to your Docker daemon, giving them root access to the
machine hosting the daemon. Guard these keys as you would a root
password!