i'm trying to create restcomm cluster: sip-balancer + a few restcomm instances. But i can't connect restcomm node and sip-loadbalancer.
i used this tutorial - http://docs.telestax.com/sip-servlets-clustering-high-availability/ however haven't got any result.
Seems it should be 2 steps
change path-name attribute in
standalone/configuration/standalone-sip.xml
add org.mobicents.ha.javax.sip.BALANCERS to
standalone/configuration/mss-sip-stack.properties
as i understand node and loadbalancer use rmi as channel. i see(i used netstat) that server listens port 2000 and node establishes connection to it.
but when i try to use loadbalancer from sip client it returns "error 500 - no available nodes".
also i used remote debugged - nodes list is empty.
have i missed something?
p.s. i used docker restromm instance and sip-loadbalancer on the same machine.
thanks,
so i have found my issue.
According to the log file on restcomm node - it can't connect to balancer by RMI.
Connection error is very strange - Connection refused to host: 127.0.0.1 and sometimes Connection refused to host: 127.0.1.1
yesterday i tired to specify java.rmi.server.hostname but it did not help me
today i created small RMI client to balancer and it worked from my local machine(balancer is hosted on it too). however this app did work from virtual machine. so i added more logs to code and found:
app can lookup remote been
remote endpoint of this been is 127.0.0.1, but should be ip address of remote machine
After that i specified externalHost and public-ip for my sip-balancer and got bean endpoint address with 127.0.1.1
so issue was found - ubuntu uses this "local" ip address for your "machine name".
you can find it in /etc/hosts.
sip-balancer(java application) gets it as ip address of endpoint for services
My fix is - change 127.0.1.1 to 127.0.0.1 in /etc/hosts. after that sip-balancer provides real ip address of your machine for remote objects.
Conclusion: my issue - wrong operation system :)
Common solution: developer should check address type and don't use loopback addresses.
Related
I'm trying to setup a cluster of one machine for now. I know that I can get the API server running and listening to some ports.
I am looking to issue commands against the master machine from my laptop.
KUBECONFIG=/home/slackware/kubeconfig_of_master kubectl get nodes should send a request to the master machine, hit the API server, and get a response of the running nodes.
However, I am hitting issues with permissions. One is similar to x509: certificate is valid for 10.61.164.153, not 10.0.0.1. Another is a 403 if I hit the kubectl proxy --port=8080 that is running on the master machine.
I think two solutions are possible, with a preferable one (B):
A. Add my laptop's ip address to the list of accepted ip addresses that API server or certificates or certificate agents holds. How would I do that? Is that something I can set in kubeadm init?
B. Add 127.0.0.1 to the list of accepted ip addresses that API server or certificates or certificate agents holds. How would I do that? Is that something I can set in kubeadm init?
I think B would be better, because I could create an ssh tunnel from my laptop to the remote machine and allow my teammates (if I ever have any) to do similarly.
Thank you,
Slackware
You shoud add --apiserver-cert-extra-sans 10.0.0.1 to your kubeadm init command.
Refer to https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/#options
You should also use a config file:
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
kubernetesVersion: v1.16.2
apiServer:
certSANs:
- 10.0.0.1
You can find all relevant info here: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2
When executing into a pod I get following message
Error from server: error dialing backend: dial tcp: lookup k8s-worker-node-a on 192.168.1.1:53: no such host
Is it possible to tell kubectl to use /etc/hosts to lookup machines as I have saved them inside there.
Can the API server resolve that hostname? It's insufficient for just your workstation to know the hostname, since the API server must be able to contact kubelet on the Node to construct the URL used to view the logs
Turning up the verbosity of kubectl will show the actual handshaking that goes on between your machine, the API server, and the kubelet on the Node, which is how we discovered a similar misconfiguration in our cluster.
I have a project at http://github.com/KPB-US/dispatch-display and in it I determine what [fire] station a display [client] belongs to based on it's ip address when the socket connects.
I have a docker composition set up so it can be up and running easily using docker-compose build and docker-compose up. This builds an nginx server that points to the upstream node application running on a node server.
Everything runs fine when I specify network_mode: "host" in both services in the docker-compose.yml. I'd rather have it run more securely using dockers default network mode-- but when I do that, I get NATed [I guess, see example message below] ip addresses from the clients instead of their actual ip addresses, so I don't know which stations [clients] they are coming from.
A connection attempt was made but that remote address is not
registered in the STATIONS list - 172.18.0.1
I am determining the incoming IP address based on the x-forwarded-for header and if missing, then the socket.conn.remoteAddress.
Any ideas on how I can resolve this? I'd like to keep the containers isolated from the network (as mentioned above) but yet still be able to know where the incoming connection is really coming from.
I cannot connect to redis server (ubuntu server 16.04 LTS 64 bits on separate PC) from windows 8.1 64-bits. Redis is well documented, however I found very little information how to connect redis server from separate machine.
I have installed latest version of redis into linux and locally everything works fine. I start server via redis-server and also I start redis-cli and after that I am able to add information into server and retrieve it. The same situation is in windows - everything works locally.
In order to connect from windows into linux redis server I did these changes.
In linux I set the static local IP via sudo nano /etc/network/interfaces
address 192.186.xxx.xxx
netmask 255.255.255.0
network 192.168.xxx.xxx
broadcast 192.168.xxx.xxx
gateway 192.168.xxx.xxx
dns-nameservers 8.8.8.8
In redis.conf file I bind my windows PC IP which is given by my internet service provider. I also opened TCP 6379 port in my router GUI. In windows I modify redis.windows-service.conf and redis.windows.conf files. In both of them I bind my IP address given by my internet service provider. After this I cannot start redis-cli properly (empty black cmd window is visible)
What I am doing wrong? I would be very grateful for any help.
You should modify the redis conf, my redis conf is located at /etc/redis/6379.conf.
And you should comment the line "bind 127.0.0.1" Or change to bind 0.0.0.0.
The bind specify which network interface the redis server should listen to. The default is localhost.
And also Change the protected-mode to no :
Protected mode is a layer of security protection, in order to avoid that
Redis instances left open on the internet are accessed and exploited.
When protected mode is on and if:
1) The server is not binding explicitly to a set of addresses using the
"bind" directive.
2) No password is configured.
The server only accepts connections from clients connecting from the
IPv4 and IPv6 loopback addresses 127.0.0.1 and ::1, and from Unix domain
sockets.
By default protected mode is enabled. You should disable it only if
you are sure you want clients from other hosts to connect to Redis
even if no authentication is configured, nor a specific set of interfaces
are explicitly listed using the "bind" directive.
protected-mode yes
If you don't disable the protected-mode, your redis server will not listen public ip interface. more detail see above.
If you can access the remote server from your machine, your problem is most probably with redis security config, read the Securing Redis section in this document
I found that most of the time people don't change the "bind" directive value in redis config, you can test that by setting bind 0.0.0.0 and restarting redis server, if that's the issue, you can then allow whatever subnets you need to access the server.
I have also experience the same issue trying to connect to Redis (MSOpenTech 3.0.5 and 3.2.1) By default if no binding is stated then redis(according to the comments in the conf file) will listen to all available interfaces. That said, v 3.2.1 does have 'bind 127.0.0.1' already set... in 3.0.5 Setting the binding to 'bind 127.0.0.1' still allows the redis-cli to be used. Binding to 192.168.1.2 renders the redis-cli unusable with both versions - there is no IP and Port prompt, simply a carat and the cli does not accept keyboard input. Binging to an external IP the MSOpenTech fork service will not restart and throws an error(nice). Clearing all bindings and reverting back to original state, the redis-cli becomes usable again. Also, on the MS OpenTech fork there is no 'ProtectedMode' setting in either config file. Not sure whether this can actually be set.
Have raised this as an issue on the MSOpenTech fork via github but expecting silence to be the only reply...
I'm not sure this helps you in any way other than knowing that you are not alone. I am trying to pub from PHP to AS3 subscribers - it works great in the Flash IDE but from the localhost browser, redis appears to go decididly deaf.
Say .. I have a scenario where my workstation is in my local network and my chef server is in AWS . In knife.rb ,i gave the AWS Public IP in the chef server url. Will this work or not for open source chef .??
i tried doing that.i am getting the following error:-
ERROR: Network Error: Error connecting to https://xx.xx.xx.xx/cookbooks?num_versions=all - Connection timed out - connect(2)
Check your knife configuration and network settings
can some one help me out in this.
Sure, as long as your workstation (usually your PC/Mac) has IP connectivity to the Chef server that's how it works. Given your output, it looks like access to port 443 is not allowed (or you entered the wrong IP of your chef server).