information:
hostnames:
cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
172.16.49.41 ceph-gw-one
172.16.49.42 ceph-gw-two
shell: ceph orch host add 172.16.49.42
Error EINVAL: New host 172.16.49.42 (172.16.49.42) failed check: ['INFO:cephadm:podman|docker (/bin/docker) is present', 'INFO:cephadm:systemctl is present', 'INFO:cephadm:lvcreate is present', 'INFO:cephadm:Unit chronyd.service is enabled and running', 'INFO:cephadm:Hostname "172.16.49.42" matches what is expected.', 'ERROR: hostname "ceph-gw-two" does not match expected hostname "172.16.49.42"']
shell: orch host add ceph-gw-two
Error EINVAL: Failed to connect to ceph-gw-two (ceph-gw-two).
Check that the host is reachable and accepts connections using the cephadm SSH key
you may want to run:
ceph cephadm get-ssh-config > ssh_config
ceph config-key get mgr/cephadm/ssh_identity_key > key
ssh -F ssh_config -i key root#ceph-gw-two
i have checked that wether by ip or hostname, ssh login success;
i read the adm source scripts：
out, err, code = self._run_cephadm(spec.hostname, cephadmNoImage, 'check-host',
['--expect-hostname', spec.hostname],
addr=spec.addr,
error_ok=True, no_fsid=True)
if code:
raise OrchestratorError('New host %s (%s) failed check: %s' % (
spec.hostname, spec.addr, err))
so ,i change the cmd to:
ceph orch host add ceph-gw-two 172.16.49.42;
done, it works well;
I'm trying to start a postgres instance as described in docker hub.
To do that, I ran the following command:
sudo docker run --name database -e POSTGRES_PASSWORD=supersecret -p 5432:5432 -d postgres
When I run docker ps it shows nothing, and when I run docker ps -a it shows:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
967ebe7efb74 postgres "docker-entrypoint.s…" 2 minutes ago Exited (1) 2 minutes ago database
Trying to docker start database also leads to STATUS Exited (1) as displayed above.
Here are the logs displayed by docker logs -f database:
PostgreSQL init process complete; ready for start up.
2019-09-10 14:08:26.941 UTC [1] LOG: could not create IPv6 socket for address "::": Permission denied
2019-09-10 14:08:26.941 UTC [1] LOG: could not create IPv4 socket for address "0.0.0.0": Permission denied
2019-09-10 14:08:26.941 UTC [1] WARNING: could not create listen socket for "*"
2019-09-10 14:08:26.941 UTC [1] FATAL: could not create any TCP/IP sockets
2019-09-10 14:08:26.941 UTC [1] LOG: database system is shut down
In my research on the internet to solve this problem, some people said that it could be something with my hosts file, but it seems fine as shown below.
127.0.0.1 localhost
127.0.1.1 user-PC
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
I tried to reinstall docker following the docker docs step-by-step tutorial, and I also did the post installation steps without success.
OS: Deepin GNU/Linux 15.11
Docker: Docker version 18.09.6, build 481bc77
Because you confirmed it, I write the comment as answer.
Problem is due to apparmor.
Try disabling it or, better, to configure the security profile
I've installed, Docker, Kubectl and kubeAdm.
I want to create my device model and device CRDs (I'm following this guide.
So, when I run the command :
kubectl create -f devices_v1alpha1_devicemodel.yaml
as a user I get the following out:
The connection to the server 10.0.0.68:6443 was refused - did you
specify the right host or port?
(I have added the permission for the user to access the .kube folder)
With netstat, I get :
> ubuntu#kubernetesmaster:~/src/github.com/kubeedge/kubeedge/build/crds/devices$
> sudo netstat -atunp Active Internet connections (servers and
> established) Proto
> Recv-Q Send-Q Local Address Foreign Address State
> PID/Program name tcp 0 0 0.0.0.0:22
> 0.0.0.0:* LISTEN 1298/sshd tcp 0 224 10.0.0.68:22 160.98.31.160:52503 ESTABLISHED
> 2061/sshd: ubuntu [ tcp6 0 0 :::22 :::*
> LISTEN 1298/sshd udp 0 0 0.0.0.0:68
> 0.0.0.0:* 910/dhclient udp 0 0 10.0.0.68:123 0.0.0.0:*
> 1241/ntpd udp 0 0 127.0.0.1:123
> 0.0.0.0:* 1241/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:*
> 1241/ntpd udp6 0 0 fe80::f816:3eff:fe0:123 :::*
> 1241/ntpd udp6 0 0 2001:620:5ca1:2f0:f:123 :::*
> 1241/ntpd udp6 0 0 ::1:123 :::*
> 1241/ntpd udp6 0 0 :::123 :::*
> 1241/ntpd
With lsof -i :
ubuntu#kubernetesmaster:~/src/github.com/kubeedge/kubeedge/build/crds/devices$ sudo lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
dhclient 910 root 6u IPv4 12765 0t0 UDP *:bootpc
ntpd 1241 ntp 16u IPv6 15340 0t0 UDP *:ntp
ntpd 1241 ntp 17u IPv4 15343 0t0 UDP *:ntp
ntpd 1241 ntp 18u IPv4 15347 0t0 UDP localhost:ntp
ntpd 1241 ntp 19u IPv4 15349 0t0 UDP 10.0.0.68:ntp
ntpd 1241 ntp 20u IPv6 15351 0t0 UDP ip6-localhost:ntp
ntpd 1241 ntp 21u IPv6 15353 0t0 UDP [2001:620:5ca1:2f0:f816:3eff:fe0a:874a]:ntp
ntpd 1241 ntp 22u IPv6 15355 0t0 UDP [fe80::f816:3eff:fe0a:874a]:ntp
sshd 1298 root 3u IPv4 18821 0t0 TCP *:ssh (LISTEN)
sshd 1298 root 4u IPv6 18830 0t0 TCP *:ssh (LISTEN)
sshd 2061 root 3u IPv4 18936 0t0 TCP 10.0.0.68:ssh->160.98.31.160:52503 (ESTABLISHED)
sshd 2124 ubuntu 3u IPv4 18936 0t0 TCP 10.0.0.68:ssh->160.98.31.160:52503 (ESTABLISHED)
I've already tried this
and:sudo swapoff -a
Please perform below steps on the master node. It works like charm.
1. sudo -i
2. swapoff -a
3. exit
4. strace -eopenat kubectl version
I am facing similar problem with following error while deploying the pod network into a cluster using flannel:
$ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
The connection to the server 192.168.1.101:6443 was refused - did you specify the right host or port?
I performed below steps to solved the issue:
$ sudo systemctl stop kubelet
$ sudo systemctl start kubelet
$ strace -eopenat kubectl version
then apply the yml file
$ kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
podsecuritypolicy.policy/psp.flannel.unprivileged created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds created
kubelet must be down. you need to check kubelet logs on the master and ensure api server is running and online. then only you should be able to deploy
I'll add another reason for this error that was the issue in my case.
I exported the wrong Kubeconfig file to shell and the error message was very accurate in that case - The endpoint for the API server was wrong (and of course other fields like the cluster name and the certificates - but the server endpoint is the first step in the chain).
I've encountered this problem and swapoff -a works for me though.
sudo -i
swapoff -a
exit
strace -eopenat kubectl version
This is because docker is down. Start docker on your machine.
I have tried many ways but couldn't get it work, then accidentally found the solution to my own situation:
In ~/.kube/ I have
drwxr-x--- 4 staff 128 25 Jul 22:31 cache
-rw------- 1 staff 8781 25 Jul 22:46 config
drwxr-xr-x 8 staff 256 25 Jul 22:46 configs
-rw-r--r-- 1 staff 14 25 Jul 22:31 kubectx
drwxr-xr-x 4 staff 128 29 Jun 16:59 kubens
My assumption is that there is something messed up in the .kube configuration, however I couldn't figure out which files, so I removed most of the directories/files, including cache, config. (If you don't want to keep all the configs, maybe you should remove all of them)
Then from docker dashboard to re-enable kubernetes, to get all the files installed back.
Re-config the docker-desktop by kubectl config use-context docker-desktop.
Finally, my 6443 responded.
Another suggestion is to restart your container sudo systemctl restart containerd In my situation I'm working with containerd and not a typical docker container
After doing this I think it should fix the issue for you but if doesn't work then try sudo swapoff -a
Assuming that's all the output from your netstat command and that you ran it on the master node (the one you installed Kubernetes via kubadm on), it looks to me like the installation did not complete correctly as none of the usual ports you would expect to see on a Kubernetes master node are present.
Usually on a kubernetes master node you'd expect to see kube-apiserver, kube-scheduler, kube-controller, kubelet and possibly etcd all listening on the network.
What was the output of your kubeadm init command?
I ran into this issue as well, I tried the solutions noted above and it did not work for me. Here is what worked for me:
FIX:
kubeadm init --apiserver-advertise-address=10.139.0.42 --ignore-preflight-errors all --pod-network-cidr=172.17.0.1/16 --token-ttl 0
source:
https://www.c-sharpcorner.com/article/kubernetes-installation-in-redhat-and-centos/
I faced this issue recently due to expired certificates for my K8S cluster.
I followed this blog link to renew the certificates and also replace the kube config file that I was using.
Note, it is important to replace the kube config post renewal of the certificates or else you would end up getting following error message for kubectl CLIs:
error: You must be logged in to the server (Unauthorized)
I faced same issue with the same error, You need to check that your container run time (docker/containerd) is active and running:
systemctl status containerd
systemctl restart containerd
systemctl restart kubelet
then if you check its status, it supposed to be up and running and you are able to create k8s objects right now.
In my case KUBECONFIG was the problem causing the same error.
This solved it:
export KUBECONFIG=/home/$(whoami)/.kube/config
I solved this exact problem by making sure that in the /etc/hosts file the IP address and host name was set correctly:
192.168.10.11 kube-01.testing
instead of:
127.0.1.1 kube-01.testing
(or 127.0.0.1).
This happens on Ubuntu and Debian as far as I know-
I solved this exact problem by making sure that in the /etc/hosts file the IP address and host name was set correctly:
192.168.10.11 kube-01.testing kube-01
instead of:
127.0.1.1 kube-01.testing kube-01
(or 127.0.0.1).
This happens on Ubuntu and Debian as far as I know-
If you did all the above steps (sudo swapoff -a, kubeconfig file permissions, kubelet and containerd status, etc) and nothing works for you, It is a good idea to take a look at the kubelet logs:
journalctl -xeu kubelet
In my case, I realize that the kubelet wants to download the images, but it fails.
So I turned on the VPN on the node, and after a couple of seconds, everything worked!
I have faced the same issue "The connection to the server {IP}:6443 was refused - did you specify the right host or port?"
The reason was that since Kubernetes 1.24+, kubenet has been removed.
So, when installing the Kubernetes cluster with kubeadm and using Docker as a Container Runtime, the cri-dockerd must be installed as well (otherwise I got the above error).
As it is mention in the kubernetes documentation:
On each of your nodes, install Docker for your Linux distribution as
per Install Docker Engine.
Install cri-dockerd, following the
instructions in that source code repository.
As per the error message, it is clearly says port number 6443 connection is refused.
Means
port number is blocked by firewall
if there is no firewall, then
Blockquote
the port number is not running on the specified host 6443. you can
cross verify using the below command
#netstat -tulpn | grep -i 6443.
Solution:
6443 it is kube-apiserver port number in k8s. if it is not running make sure kube-apiserver is running properly. I have faced the same problem. After that I have fix properly set the correct argument in that specific port.
/usr/local/bin/kube-apiserver \\
--advertise-address=${INTERNAL_IP} \\
--allow-privileged=true \\
--apiserver-count=3 \\
--audit-log-maxage=30 \\
--audit-log-maxbackup=3 \\
--audit-log-maxsize=100 \\
--audit-log-path=/var/log/audit.log \\
--authorization-mode=Node,RBAC \\
--bind-address=0.0.0.0 \\
--client-ca-file=/var/lib/kubernetes/ca.crt \\
--enable-admission-plugins=NodeRestriction,ServiceAccount \\
--enable-swagger-ui=true \\
--enable-bootstrap-token-auth=true \\
--etcd-cafile=/var/lib/kubernetes/ca.crt \\
--etcd-certfile=/var/lib/kubernetes/etcd-server.crt \\
--etcd-keyfile=/var/lib/kubernetes/etcd-server.key \\
--etcd-servers=https://192.168.5.11:2379,https://192.168.5.12:2379 \\
--event-ttl=1h \\
--encryption-provider-config=/var/lib/kubernetes/encryption-config.yaml \\
--kubelet-certificate-authority=/var/lib/kubernetes/ca.crt \\
--kubelet-client-certificate=/var/lib/kubernetes/kube-apiserver.crt \\
--kubelet-client-key=/var/lib/kubernetes/kube-apiserver.key \\
--kubelet-https=true \\
--runtime-config=api/all \\
--service-account-key-file=/var/lib/kubernetes/service-account.crt \\
--service-cluster-ip-range=10.96.0.0/24 \\
--service-node-port-range=30000-32767 \\
--tls-cert-file=/var/lib/kubernetes/kube-apiserver.crt \\
--tls-private-key-file=/var/lib/kubernetes/kube-apiserver.key \\
--v=2
sudo -i
swapoff -a
exit
strace -eopenat kubectl version
I am trying to set up a new instance of PostgreSQL 9.6 on a machine. I have tested it on another machine and its working fine on that machine. But the same process is not working on new machine. Below are the steps I am using
created a new data directory with below command
/opt/rh/rh-postgresql96/root/bin/initdb -D /var/lib/pgsql/9.6/data/
created a service file /etc/systemd/system/rh-postgresql96-inst2.service with below content
.include /lib/systemd/system/rh-postgresql96-postgresql.service
[Service]
Environment=PGDATA=/var/lib/pgsql/9.6/data/
Environment=PGPORT=5433
User=postgres
Group=root
registered service using command systemctl enable rh-postgresql96-inst2
now using command systemctl start rh-postgresql96-inst2 to start service.
All these steps are working fine on one machine but not on the 2nd one.
I am getting below error while starting service on the 2nd machine
rh-postgresql96-inst2.service - PostgreSQL database server
Loaded: loaded (/etc/systemd/system/rh-postgresql96-inst2.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2018-06-18 09:59:01 UTC; 10s ago
Process: 7552 ExecStart=/opt/rh/rh-postgresql96/root/usr/libexec/postgresql-ctl start -D ${PGDATA} -s -w -t ${PGSTARTTIMEOUT} (code=exited, status=1/FAILURE)
Process: 7550 ExecStartPre=/opt/rh/rh-postgresql96/root/usr/libexec/postgresql-check-db-dir %N (code=exited, status=0/SUCCESS)
HINT: Is another postmaster already running on port 5433? If not, wait a few seconds and retry.
LOG: could not bind IPv4 socket: Permission denied
HINT: Is another postmaster already running on port 5433? If not, wait a few seconds and retry.
WARNING: could not create listen socket for "localhost"
FATAL: could not create any TCP/IP sockets
LOG: database system is shut down
systemd[1]: rh-postgresql96-inst2.service: control process exited, code=exited status=1
systemd[1]: Failed to start PostgreSQL database server.
systemd[1]: Unit rh-postgresql96-inst2.service entered failed state.
systemd[1]: rh-postgresql96-inst2.service failed.
However, I am able to start service using pg_ctl.
Also, I have checked with netstat, lsof command to check if any other postgresql instance is running on port 5433 but its not the case.
Infact i tried 5431, 5434 ports also but server is not starting up
Instead of turning of SELinux you should allow postgres to bind to port 5433 in SELinux.
There is a port parameter postgresql_port_t which by default has port 5432 and 9898.
semanage port -l | grep post
postgresql_port_t tcp 5433, 9898
What you could do is simply add port 5433 to this list.
semanage port -a -t postgresql_port_t 5433 -p tcp
semanage port -l | grep post
postgresql_port_t tcp 5433, 5432, 9898
After that you can start your postgres server listening on port 5433
systemctl enable rh-postgresql96-postgresql
systemctl start rh-postgresql96-postgresql
netstat -tulpn
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 2847/postgres
tcp 0 0 127.0.0.1:5433 0.0.0.0:* LISTEN 2775/postgres
There is also a handy tool called audit2allow to help debug selinux problems.
audit2allow -m whatiswrong < /var/log/audit/audit.log > /root/showme.te
The file showme.te show you why SELinux is not allowing the service to do what you need.
You should not turn off SELinux just because it's hard to understand or if you don't know how it works. Instead you should study it :)
I reccomend this lecture from the Red Hat Summit https://www.redhat.com/en/about/videos/summit-2018-security-enhanced-linux-mere-mortals
This issue was related to SELinux.
When I run command sestatus on both machines, output was a little bit different.
One server had Current mode: permissive and 2nd one had Current mode: enforcing.
So I changed the current mode to permissive on the 2nd machine using command setenforce 0.
and it resolved the permission related issue. Now I am able to start 2nd instance.
Here is my testcase :
[root#192.168.121.130 ~$]slapd -d 1 -h ldaps://127.0.0.1:636
#(#) $OpenLDAP: slapd 2.4.23 (Apr 29 2013 07:47:08) $
mockbuild#c6b7.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd
ldap_pvt_gethostbyname_a: host=centos-6.3, r=0
daemon_init: listen on ldaps://127.0.0.1:636
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldaps://127.0.0.1:636)
daemon: bind(7) failed errno=98 (Address already in use)
slap_open_listener: failed on ldaps://127.0.0.1:636
slapd stopped.
connections_destroy: nothing to destroy.
But if I change another port , such as 6361, it works.
My environment:
OS: centos 6.4 x86_64
OpenLDAP: 2.4.23 installed by yum
Any suggestion?
it seems that another service is already running on port 636:
daemon: bind(7) failed errno=98 (Address already in use)
you can try the following command to identify this service:
netstat -tulpn | grep ':636 ' | grep 'LISTEN'
Old post, but still ...
This error is also displayed when SELinux prevents slapd from starting. Personally I experienced this after manually copying data (/var/lib/ldap/) from another server, to this one. I had to restore the imported files to default SELinux security contexts:
restorecon -R /var/lib/ldap
And I see this doesn't apply to you, but this might also happen if you're attempting to bind slapd to a port out of the ordinary. Default on CentOS7, these are the allowed ports:
#semanage port -l | grep ldap
ldap_port_t tcp 389, 636, 3268, 7389
ldap_port_t udp 389, 636
Adding another one to the legal port range, could be done with semanage. (You might need to install the package policycoreutils-python.):
semanage port -a -t ldap_port_t -p tcp 10389
... if you wish to allow slapd to bind on TCP port 10389 in addition to the four listed above. After this, the previous result would look like:
# semanage port -l | grep ldap
ldap_port_t tcp 10389, 389, 636, 3268, 7389
ldap_port_t udp 389, 636