Re: secure hosts communications

2019-02-01 Thread Ugo Vasi

Hi Rohit,
to tell the truth, from what I see in the documentation, it is said "On 
Ubuntu 16.04: just modify /etc/init/libvirt-bin.conf" so I don't touch 
the file "/etc/default/libvirt-bin"... the strange thing is that (in my 
case) libvirt does not consider the parameter libvirtd_opts set in 
"/etc/init/libvirt-bin.conf" but only if I set it to 
"/etc/default/libvirt-bin".


In any case, all hosts are now in "Up mode" and the migration works.

Thanks for the support


Il 01/02/19 10:29, Rohit Yadav ha scritto:


Cheers Ugo, yes that was the fix. It's clearly mentioned in our docs :

http://docs.cloudstack.apache.org/en/4.11.2.0/installguide/hypervisor/kvm.html#install-and-configure-libvirt


- Rohit



rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue


*From:* Ugo Vasi 
*Sent:* Friday, February 1, 2019 2:47:42 PM
*To:* Rohit Yadav; users@cloudstack.apache.org
*Subject:* Re: secure hosts communications
Hi Rohit,
I think I've found the problem: following the configuration instructions
of the agent, we are told to only modify the file
/etc/libvirt/libvirtd.conf for the ubuntu 16.04 system, and so I did.

I tried to change the parameter libvirtd_opts = "-l" in the file / etc /
default / libvirt-bin (similar to the configuration for ubuntu 14.04,
but without "-d").

Restarting the libvirt-bin service, this works regularly and listens on
port 16514.

 From the UI of cloudstak now that host has lost the status "insecure"
and has become "Up".

Now I will try with other hosts.


Thanks


Il 31/01/19 20:22, Rohit Yadav ha scritto:
>
> Hi Ugo,
>
>
> Please make sure your KVM host's libvirtd is in the listening -l mode.
> Without the libvirtd daemon in listening mode kvm agent will have
> issues using libvirtd as well.
>
>
> Once you fix it, restart libvirtd and cloudstack-agent and you should
> see some output for:  netstat -nl | grep 16514
>
>
> - Rohit
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com <http://www.shapeblue.com>
> @shapeblue
>
> ------------
> *From:* Ugo Vasi 
> *Sent:* Thursday, January 31, 2019 7:08:00 PM
> *To:* Rohit Yadav; users@cloudstack.apache.org
> *Subject:* Re: secure hosts communications
> Hi Rohit,
> the cloudstack-agent  version is 4.11.2.0:
>
> # dpkg -l cloudstack-agent
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-=-===
> ii  cloudstack-agent 4.11.2.0 all CloudStack agent
>
>
> It seems that libvirtd don't open any tcp port you say:
> # netstat -nl | grep 16509
> #
> # netstat -nl | grep 16514
> #
>
> # ls -lahi /etc/cloudstack/agent
> total 44K
> 525530 drwxr-xr-x 2 root root 4.0K Jan 31 11:17 .
> 263345 drwxr-xr-x 3 root root 4.0K Dec 21 12:34 ..
> 525534 -rw--- 1 root root  490 Jan 31 12:14 agent.properties
> 525537 -rw--- 1 root root 1.8K Jan 31 11:16 cloud.ca.crt
> 525536 -rw--- 1 root root 1.8K Jan 31 11:16 cloud.crt
> 525535 -rw--- 1 root root 1.3K Jan 31 11:16 cloud.csr
> 525538 -rw--- 1 root root 5.2K Jan 31 11:17 cloud.jks
> 525540 -rw--- 1 root root 1.7K Jan 31 11:17 cloud.key
> 525532 -rwxr-xr-x 1 root root  906 Nov 13 10:24 environment.properties
> 525533 -rwxr-xr-x 1 root root 3.6K Nov 13 10:24 log4j-cloud.xml
>
> # ls /etc/pki/libvirt -l
> total 4
> lrwxrwxrwx 1 root root   31 Jan 31 11:17 clientcert.pem ->
> /etc/cloudstack/agent/cloud.crt
> drwxr-xr-x 2 root root 4096 Jan 31 11:17 private
> lrwxrwxrwx 1 root root   31 Jan 31 11:17 servercert.pem ->
> /etc/cloudstack/agent/cloud.crt
> # ls /etc/pki/libvirt/private/ -l
> total 0
> lrwxrwxrwx 1 root root 31 Jan 31 11:17 clientkey.pem ->
> /etc/cloudstack/agent/cloud.key
> lrwxrwxrwx 1 root root 31 Jan 31 11:17 serverkey.pem ->
> /etc/cloudstack/agent/cloud.key
>
> # grep -vE '#|^$' /etc/libvirt/libvirtd.conf
> listen_tls=1
> listen_tcp=0
> tcp_port="16509"
> auth_tcp="none"
> mdns_adv = 0
> unix_sock_group = "libvirtd"
> unix_sock_ro_perms = "0777"
> unix_sock_rw_perms = "0770"
> auth_unix_ro = "none"
> auth_unix_rw = "none"
> key_file="/etc/pki/libvirt/private/serverkey.pem"
> cert_file="/etc/pki/libvirt/servercert.pem"
> ca_file="/etc/pki/CA/cacert.pem"
> tls_port="16514"
> auth_tls="none"
>
&g

Re: secure hosts communications

2019-02-01 Thread Rohit Yadav
Cheers Ugo, yes that was the fix. It's clearly mentioned in our docs :

http://docs.cloudstack.apache.org/en/4.11.2.0/installguide/hypervisor/kvm.html#install-and-configure-libvirt


- Rohit

<https://cloudstack.apache.org>




From: Ugo Vasi 
Sent: Friday, February 1, 2019 2:47:42 PM
To: Rohit Yadav; users@cloudstack.apache.org
Subject: Re: secure hosts communications

Hi Rohit,
I think I've found the problem: following the configuration instructions
of the agent, we are told to only modify the file
/etc/libvirt/libvirtd.conf for the ubuntu 16.04 system, and so I did.

I tried to change the parameter libvirtd_opts = "-l" in the file / etc /
default / libvirt-bin (similar to the configuration for ubuntu 14.04,
but without "-d").

Restarting the libvirt-bin service, this works regularly and listens on
port 16514.

 From the UI of cloudstak now that host has lost the status "insecure"
and has become "Up".

Now I will try with other hosts.


Thanks


Il 31/01/19 20:22, Rohit Yadav ha scritto:
>
> Hi Ugo,
>
>
> Please make sure your KVM host's libvirtd is in the listening -l mode.
> Without the libvirtd daemon in listening mode kvm agent will have
> issues using libvirtd as well.
>
>
> Once you fix it, restart libvirtd and cloudstack-agent and you should
> see some output for:  netstat -nl | grep 16514
>
>
> - Rohit
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> @shapeblue
>
> 
> *From:* Ugo Vasi 
> *Sent:* Thursday, January 31, 2019 7:08:00 PM
> *To:* Rohit Yadav; users@cloudstack.apache.org
> *Subject:* Re: secure hosts communications
> Hi Rohit,
> the cloudstack-agent  version is 4.11.2.0:
>
> # dpkg -l cloudstack-agent
> Desired=Unknown/Install/Remove/Purge/Hold
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-=-===
> ii  cloudstack-agent 4.11.2.0all CloudStack agent
>
>
> It seems that libvirtd don't open any tcp port you say:
> # netstat -nl | grep 16509
> #
> # netstat -nl | grep 16514
> #
>
> # ls -lahi /etc/cloudstack/agent
> total 44K
> 525530 drwxr-xr-x 2 root root 4.0K Jan 31 11:17 .
> 263345 drwxr-xr-x 3 root root 4.0K Dec 21 12:34 ..
> 525534 -rw--- 1 root root  490 Jan 31 12:14 agent.properties
> 525537 -rw--- 1 root root 1.8K Jan 31 11:16 cloud.ca.crt
> 525536 -rw--- 1 root root 1.8K Jan 31 11:16 cloud.crt
> 525535 -rw--- 1 root root 1.3K Jan 31 11:16 cloud.csr
> 525538 -rw--- 1 root root 5.2K Jan 31 11:17 cloud.jks
> 525540 -rw--- 1 root root 1.7K Jan 31 11:17 cloud.key
> 525532 -rwxr-xr-x 1 root root  906 Nov 13 10:24 environment.properties
> 525533 -rwxr-xr-x 1 root root 3.6K Nov 13 10:24 log4j-cloud.xml
>
> # ls /etc/pki/libvirt -l
> total 4
> lrwxrwxrwx 1 root root   31 Jan 31 11:17 clientcert.pem ->
> /etc/cloudstack/agent/cloud.crt
> drwxr-xr-x 2 root root 4096 Jan 31 11:17 private
> lrwxrwxrwx 1 root root   31 Jan 31 11:17 servercert.pem ->
> /etc/cloudstack/agent/cloud.crt
> # ls /etc/pki/libvirt/private/ -l
> total 0
> lrwxrwxrwx 1 root root 31 Jan 31 11:17 clientkey.pem ->
> /etc/cloudstack/agent/cloud.key
> lrwxrwxrwx 1 root root 31 Jan 31 11:17 serverkey.pem ->
> /etc/cloudstack/agent/cloud.key
>
> # grep -vE '#|^$' /etc/libvirt/libvirtd.conf
> listen_tls=1
> listen_tcp=0
> tcp_port="16509"
> auth_tcp="none"
> mdns_adv = 0
> unix_sock_group = "libvirtd"
> unix_sock_ro_perms = "0777"
> unix_sock_rw_perms = "0770"
> auth_unix_ro = "none"
> auth_unix_rw = "none"
> key_file="/etc/pki/libvirt/private/serverkey.pem"
> cert_file="/etc/pki/libvirt/servercert.pem"
> ca_file="/etc/pki/CA/cacert.pem"
> tls_port="16514"
> auth_tls="none"
>
>
>
> Il 31/01/19 13:26, Rohit Yadav ha scritto:
> >
> > Looks like some error occurred while generating the keystore. Can you
> > check if you see any .jks and crt/key files at /etc/cloudstack/agent/
> > directory?
> >
> >
> > Also share output of:
> >
> > netstat -nl | grep 16509 # if you get any listening libvirtd, then
> > your libvirtd is NOT secured
> >
> > netstat -nl | grep 16514 # if you get this, then libvirtd is secured
> >
> >
> > ls -lahi /etc/cloudstack/agent
> >
> >
> > Did you up

Re: secure hosts communications

2019-02-01 Thread Ugo Vasi

Hi Rohit,
I think I've found the problem: following the configuration instructions 
of the agent, we are told to only modify the file 
/etc/libvirt/libvirtd.conf for the ubuntu 16.04 system, and so I did.


I tried to change the parameter libvirtd_opts = "-l" in the file / etc / 
default / libvirt-bin (similar to the configuration for ubuntu 14.04, 
but without "-d").


Restarting the libvirt-bin service, this works regularly and listens on 
port 16514.


From the UI of cloudstak now that host has lost the status "insecure" 
and has become "Up".


Now I will try with other hosts.


Thanks


Il 31/01/19 20:22, Rohit Yadav ha scritto:


Hi Ugo,


Please make sure your KVM host's libvirtd is in the listening -l mode. 
Without the libvirtd daemon in listening mode kvm agent will have 
issues using libvirtd as well.



Once you fix it, restart libvirtd and cloudstack-agent and you should 
see some output for:  netstat -nl | grep 16514



- Rohit



rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue


*From:* Ugo Vasi 
*Sent:* Thursday, January 31, 2019 7:08:00 PM
*To:* Rohit Yadav; users@cloudstack.apache.org
*Subject:* Re: secure hosts communications
Hi Rohit,
the cloudstack-agent  version is 4.11.2.0:

# dpkg -l cloudstack-agent
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=-===
ii  cloudstack-agent 4.11.2.0    all CloudStack agent


It seems that libvirtd don't open any tcp port you say:
# netstat -nl | grep 16509
#
# netstat -nl | grep 16514
#

# ls -lahi /etc/cloudstack/agent
total 44K
525530 drwxr-xr-x 2 root root 4.0K Jan 31 11:17 .
263345 drwxr-xr-x 3 root root 4.0K Dec 21 12:34 ..
525534 -rw--- 1 root root  490 Jan 31 12:14 agent.properties
525537 -rw--- 1 root root 1.8K Jan 31 11:16 cloud.ca.crt
525536 -rw--- 1 root root 1.8K Jan 31 11:16 cloud.crt
525535 -rw--- 1 root root 1.3K Jan 31 11:16 cloud.csr
525538 -rw--- 1 root root 5.2K Jan 31 11:17 cloud.jks
525540 -rw--- 1 root root 1.7K Jan 31 11:17 cloud.key
525532 -rwxr-xr-x 1 root root  906 Nov 13 10:24 environment.properties
525533 -rwxr-xr-x 1 root root 3.6K Nov 13 10:24 log4j-cloud.xml

# ls /etc/pki/libvirt -l
total 4
lrwxrwxrwx 1 root root   31 Jan 31 11:17 clientcert.pem ->
/etc/cloudstack/agent/cloud.crt
drwxr-xr-x 2 root root 4096 Jan 31 11:17 private
lrwxrwxrwx 1 root root   31 Jan 31 11:17 servercert.pem ->
/etc/cloudstack/agent/cloud.crt
# ls /etc/pki/libvirt/private/ -l
total 0
lrwxrwxrwx 1 root root 31 Jan 31 11:17 clientkey.pem ->
/etc/cloudstack/agent/cloud.key
lrwxrwxrwx 1 root root 31 Jan 31 11:17 serverkey.pem ->
/etc/cloudstack/agent/cloud.key

# grep -vE '#|^$' /etc/libvirt/libvirtd.conf
listen_tls=1
listen_tcp=0
tcp_port="16509"
auth_tcp="none"
mdns_adv = 0
unix_sock_group = "libvirtd"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0770"
auth_unix_ro = "none"
auth_unix_rw = "none"
key_file="/etc/pki/libvirt/private/serverkey.pem"
cert_file="/etc/pki/libvirt/servercert.pem"
ca_file="/etc/pki/CA/cacert.pem"
tls_port="16514"
auth_tls="none"



Il 31/01/19 13:26, Rohit Yadav ha scritto:
>
> Looks like some error occurred while generating the keystore. Can you
> check if you see any .jks and crt/key files at /etc/cloudstack/agent/
> directory?
>
>
> Also share output of:
>
> netstat -nl | grep 16509 # if you get any listening libvirtd, then
> your libvirtd is NOT secured
>
> netstat -nl | grep 16514 # if you get this, then libvirtd is secured
>
>
> ls -lahi /etc/cloudstack/agent
>
>
> Did you upgrade to the latest LTS minor 4.11.2.0 release? If not
> please do that, we've some bugs around CA certificates fixed.
>
>
> - Rohit
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com <http://www.shapeblue.com>
> @shapeblue
>
> 
> *From:* Ugo Vasi 
> *Sent:* Thursday, January 31, 2019 4:56:28 PM
> *To:* users@cloudstack.apache.org; Rohit Yadav
> *Subject:* Re: secure hosts communications
> Update:
> by rebooting the host system, the libvirt is restarted and the ACS-agent
> has been reconnected to management.
>
> The host remains in "unsecure" mode
>
> If I set to false "ca.plugin.root.auth.strictness" can I migrate the VM?
>
>
>
> Il 31/01/19 11:50, Ugo Vasi ha scritto:
> > Hi Rohit,
> > I tryed renew certificate but it failed!
&

Re: secure hosts communications

2019-01-31 Thread Rohit Yadav
Hi Ugo,


Please make sure your KVM host's libvirtd is in the listening -l mode. Without 
the libvirtd daemon in listening mode kvm agent will have issues using libvirtd 
as well.


Once you fix it, restart libvirtd and cloudstack-agent and you should see some 
output for:  netstat -nl | grep 16514


- Rohit

<https://cloudstack.apache.org>




From: Ugo Vasi 
Sent: Thursday, January 31, 2019 7:08:00 PM
To: Rohit Yadav; users@cloudstack.apache.org
Subject: Re: secure hosts communications

Hi Rohit,
the cloudstack-agent  version is 4.11.2.0:

# dpkg -l cloudstack-agent
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=-===
ii  cloudstack-agent 4.11.2.0all CloudStack agent


It seems that libvirtd don't open any tcp port you say:
# netstat -nl | grep 16509
#
# netstat -nl | grep 16514
#

# ls -lahi /etc/cloudstack/agent
total 44K
525530 drwxr-xr-x 2 root root 4.0K Jan 31 11:17 .
263345 drwxr-xr-x 3 root root 4.0K Dec 21 12:34 ..
525534 -rw--- 1 root root  490 Jan 31 12:14 agent.properties
525537 -rw--- 1 root root 1.8K Jan 31 11:16 cloud.ca.crt
525536 -rw--- 1 root root 1.8K Jan 31 11:16 cloud.crt
525535 -rw--- 1 root root 1.3K Jan 31 11:16 cloud.csr
525538 -rw--- 1 root root 5.2K Jan 31 11:17 cloud.jks
525540 -rw--- 1 root root 1.7K Jan 31 11:17 cloud.key
525532 -rwxr-xr-x 1 root root  906 Nov 13 10:24 environment.properties
525533 -rwxr-xr-x 1 root root 3.6K Nov 13 10:24 log4j-cloud.xml

# ls /etc/pki/libvirt -l
total 4
lrwxrwxrwx 1 root root   31 Jan 31 11:17 clientcert.pem ->
/etc/cloudstack/agent/cloud.crt
drwxr-xr-x 2 root root 4096 Jan 31 11:17 private
lrwxrwxrwx 1 root root   31 Jan 31 11:17 servercert.pem ->
/etc/cloudstack/agent/cloud.crt
# ls /etc/pki/libvirt/private/ -l
total 0
lrwxrwxrwx 1 root root 31 Jan 31 11:17 clientkey.pem ->
/etc/cloudstack/agent/cloud.key
lrwxrwxrwx 1 root root 31 Jan 31 11:17 serverkey.pem ->
/etc/cloudstack/agent/cloud.key

# grep -vE '#|^$' /etc/libvirt/libvirtd.conf
listen_tls=1
listen_tcp=0
tcp_port="16509"
auth_tcp="none"
mdns_adv = 0
unix_sock_group = "libvirtd"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0770"
auth_unix_ro = "none"
auth_unix_rw = "none"
key_file="/etc/pki/libvirt/private/serverkey.pem"
cert_file="/etc/pki/libvirt/servercert.pem"
ca_file="/etc/pki/CA/cacert.pem"
tls_port="16514"
auth_tls="none"



Il 31/01/19 13:26, Rohit Yadav ha scritto:
>
> Looks like some error occurred while generating the keystore. Can you
> check if you see any .jks and crt/key files at /etc/cloudstack/agent/
> directory?
>
>
> Also share output of:
>
> netstat -nl | grep 16509 # if you get any listening libvirtd, then
> your libvirtd is NOT secured
>
> netstat -nl | grep 16514 # if you get this, then libvirtd is secured
>
>
> ls -lahi /etc/cloudstack/agent
>
>
> Did you upgrade to the latest LTS minor 4.11.2.0 release? If not
> please do that, we've some bugs around CA certificates fixed.
>
>
> - Rohit
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> @shapeblue
>
> 
> *From:* Ugo Vasi 
> *Sent:* Thursday, January 31, 2019 4:56:28 PM
> *To:* users@cloudstack.apache.org; Rohit Yadav
> *Subject:* Re: secure hosts communications
> Update:
> by rebooting the host system, the libvirt is restarted and the ACS-agent
> has been reconnected to management.
>
> The host remains in "unsecure" mode
>
> If I set to false "ca.plugin.root.auth.strictness" can I migrate the VM?
>
>
>
> Il 31/01/19 11:50, Ugo Vasi ha scritto:
> > Hi Rohit,
> > I tryed renew certificate but it failed!
> > Now libvirt does not restart and agent is disconnected:
> >
> > agent log:
> > 2019-01-31 11:17:07,530 INFO
> > [resource.wrapper.LibvirtPostCertificateRenewalCommandWrapper]
> > (Certificate Renewal Timer:null) (logid:fe1554cc) Restarting libvirt
> > after certificate provisioning/renewal
> > 2019-01-31 11:17:07,567 INFO  [cloud.agent.Agent]
> > (AgentShutdownThread:null) (logid:) Stopping the agent: Reason =
> sig.kill
> > 2019-01-31 11:17:07,568 WARN  [cloud.agent.Agent] (Certificate Renewal
> > Timer:null) (logid:fe1554cc) Failed to execute post certificate
> > renewal command:
> > java.lang.IllegalStateException: Shutdown in progress
>

Re: secure hosts communications

2019-01-31 Thread Ugo Vasi

Hi Rohit,
the cloudstack-agent  version is 4.11.2.0:

# dpkg -l cloudstack-agent
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=-===
ii  cloudstack-agent 4.11.2.0    all CloudStack agent


It seems that libvirtd don't open any tcp port you say:
# netstat -nl | grep 16509
#
# netstat -nl | grep 16514
#

# ls -lahi /etc/cloudstack/agent
total 44K
525530 drwxr-xr-x 2 root root 4.0K Jan 31 11:17 .
263345 drwxr-xr-x 3 root root 4.0K Dec 21 12:34 ..
525534 -rw--- 1 root root  490 Jan 31 12:14 agent.properties
525537 -rw--- 1 root root 1.8K Jan 31 11:16 cloud.ca.crt
525536 -rw--- 1 root root 1.8K Jan 31 11:16 cloud.crt
525535 -rw--- 1 root root 1.3K Jan 31 11:16 cloud.csr
525538 -rw--- 1 root root 5.2K Jan 31 11:17 cloud.jks
525540 -rw--- 1 root root 1.7K Jan 31 11:17 cloud.key
525532 -rwxr-xr-x 1 root root  906 Nov 13 10:24 environment.properties
525533 -rwxr-xr-x 1 root root 3.6K Nov 13 10:24 log4j-cloud.xml

# ls /etc/pki/libvirt -l
total 4
lrwxrwxrwx 1 root root   31 Jan 31 11:17 clientcert.pem -> 
/etc/cloudstack/agent/cloud.crt

drwxr-xr-x 2 root root 4096 Jan 31 11:17 private
lrwxrwxrwx 1 root root   31 Jan 31 11:17 servercert.pem -> 
/etc/cloudstack/agent/cloud.crt

# ls /etc/pki/libvirt/private/ -l
total 0
lrwxrwxrwx 1 root root 31 Jan 31 11:17 clientkey.pem -> 
/etc/cloudstack/agent/cloud.key
lrwxrwxrwx 1 root root 31 Jan 31 11:17 serverkey.pem -> 
/etc/cloudstack/agent/cloud.key


# grep -vE '#|^$' /etc/libvirt/libvirtd.conf
listen_tls=1
listen_tcp=0
tcp_port="16509"
auth_tcp="none"
mdns_adv = 0
unix_sock_group = "libvirtd"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0770"
auth_unix_ro = "none"
auth_unix_rw = "none"
key_file="/etc/pki/libvirt/private/serverkey.pem"
cert_file="/etc/pki/libvirt/servercert.pem"
ca_file="/etc/pki/CA/cacert.pem"
tls_port="16514"
auth_tls="none"



Il 31/01/19 13:26, Rohit Yadav ha scritto:


Looks like some error occurred while generating the keystore. Can you 
check if you see any .jks and crt/key files at /etc/cloudstack/agent/ 
directory?



Also share output of:

netstat -nl | grep 16509 # if you get any listening libvirtd, then 
your libvirtd is NOT secured


netstat -nl | grep 16514 # if you get this, then libvirtd is secured


ls -lahi /etc/cloudstack/agent


Did you upgrade to the latest LTS minor 4.11.2.0 release? If not 
please do that, we've some bugs around CA certificates fixed.



- Rohit



rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue

--------
*From:* Ugo Vasi 
*Sent:* Thursday, January 31, 2019 4:56:28 PM
*To:* users@cloudstack.apache.org; Rohit Yadav
*Subject:* Re: secure hosts communications
Update:
by rebooting the host system, the libvirt is restarted and the ACS-agent
has been reconnected to management.

The host remains in "unsecure" mode

If I set to false "ca.plugin.root.auth.strictness" can I migrate the VM?



Il 31/01/19 11:50, Ugo Vasi ha scritto:
> Hi Rohit,
> I tryed renew certificate but it failed!
> Now libvirt does not restart and agent is disconnected:
>
> agent log:
> 2019-01-31 11:17:07,530 INFO
> [resource.wrapper.LibvirtPostCertificateRenewalCommandWrapper]
> (Certificate Renewal Timer:null) (logid:fe1554cc) Restarting libvirt
> after certificate provisioning/renewal
> 2019-01-31 11:17:07,567 INFO  [cloud.agent.Agent]
> (AgentShutdownThread:null) (logid:) Stopping the agent: Reason = 
sig.kill

> 2019-01-31 11:17:07,568 WARN  [cloud.agent.Agent] (Certificate Renewal
> Timer:null) (logid:fe1554cc) Failed to execute post certificate
> renewal command:
> java.lang.IllegalStateException: Shutdown in progress
>     at
> 
java.lang.ApplicationShutdownHooks.remove(ApplicationShutdownHooks.java:82)

>     at java.lang.Runtime.removeShutdownHook(Runtime.java:239)
>     at
> 
com.cloud.agent.Agent$PostCertificateRenewalTask.runInContext(Agent.java:1157)

>     at
> 
org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)

>     at
> 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)

>     at
> 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)

>     at
> 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)

>

Re: secure hosts communications

2019-01-31 Thread Rohit Yadav
Looks like some error occurred while generating the keystore. Can you check if 
you see any .jks and crt/key files at /etc/cloudstack/agent/ directory?


Also share output of:

netstat -nl | grep 16509 # if you get any listening libvirtd, then your 
libvirtd is NOT secured

netstat -nl | grep 16514 # if you get this, then libvirtd is secured


ls -lahi /etc/cloudstack/agent


Did you upgrade to the latest LTS minor 4.11.2.0 release? If not please do 
that, we've some bugs around CA certificates fixed.


- Rohit

<https://cloudstack.apache.org>




From: Ugo Vasi 
Sent: Thursday, January 31, 2019 4:56:28 PM
To: users@cloudstack.apache.org; Rohit Yadav
Subject: Re: secure hosts communications

Update:
by rebooting the host system, the libvirt is restarted and the ACS-agent
has been reconnected to management.

The host remains in "unsecure" mode

If I set to false "ca.plugin.root.auth.strictness" can I migrate the VM?



Il 31/01/19 11:50, Ugo Vasi ha scritto:
> Hi Rohit,
> I tryed renew certificate but it failed!
> Now libvirt does not restart and agent is disconnected:
>
> agent log:
> 2019-01-31 11:17:07,530 INFO
> [resource.wrapper.LibvirtPostCertificateRenewalCommandWrapper]
> (Certificate Renewal Timer:null) (logid:fe1554cc) Restarting libvirt
> after certificate provisioning/renewal
> 2019-01-31 11:17:07,567 INFO  [cloud.agent.Agent]
> (AgentShutdownThread:null) (logid:) Stopping the agent: Reason = sig.kill
> 2019-01-31 11:17:07,568 WARN  [cloud.agent.Agent] (Certificate Renewal
> Timer:null) (logid:fe1554cc) Failed to execute post certificate
> renewal command:
> java.lang.IllegalStateException: Shutdown in progress
> at
> java.lang.ApplicationShutdownHooks.remove(ApplicationShutdownHooks.java:82)
> at java.lang.Runtime.removeShutdownHook(Runtime.java:239)
> at
> com.cloud.agent.Agent$PostCertificateRenewalTask.runInContext(Agent.java:1157)
> at
> org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:32)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> 2019-01-31 11:17:09,797 INFO  [cloud.agent.AgentShell] (main:null)
> (logid:) Agent started
> 2019-01-31 11:17:09,800 INFO  [cloud.agent.AgentShell] (main:null)
> (logid:) Implementation Version is 4.11.2.0
> 2019-01-31 11:17:09,802 INFO  [cloud.agent.AgentShell] (main:null)
> (logid:) agent.properties found at /etc/cloudstack/agent/agent.properties
> 2019-01-31 11:17:09,815 INFO  [cloud.agent.AgentShell] (main:null)
> (logid:) Defaulting to using properties file for storage
> 2019-01-31 11:17:09,816 INFO  [cloud.agent.AgentShell] (main:null)
> (logid:) Defaulting to the constant time backoff algorithm
> 2019-01-31 11:17:09,828 INFO  [cloud.utils.LogUtils] (main:null)
> (logid:) log4j configuration found at
> /etc/cloudstack/agent/log4j-cloud.xml
> 2019-01-31 11:17:09,850 INFO  [cloud.agent.AgentShell] (main:null)
> (logid:) Using default Java settings for IPv6 preference for agent
> connection
> 2019-01-31 11:17:09,998 INFO  [cloud.agent.Agent] (main:null) (logid:)
> id is 5
> 2019-01-31 11:17:10,030 INFO  [kvm.resource.LibvirtConnection]
> (main:null) (logid:) No existing libvirtd connection found. Opening a
> new one
> 2019-01-31 11:17:10,175 ERROR [cloud.agent.AgentShell] (main:null)
> (logid:) Unable to start agent:
> com.cloud.utils.exception.CloudRuntimeException: Failed to connect
> socket to '/var/run/libvirt/libvirt-sock': No such file or directory
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:914)
> at com.cloud.agent.Agent.(Agent.java:190)
> at com.cloud.agent.AgentShell.launchNewAgent(AgentShell.java:453)
> at
> com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:422)
> at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:406)
> at com.cloud.agent.AgentShell.start(AgentShell.java:512)

Re: secure hosts communications

2019-01-31 Thread Ugo Vasi
tion
Jan 31 11:17:21 cshp214 sh[25457]: INFO  [cloud.agent.Agent] (main:) 
(logid:) id is 5
Jan 31 11:17:21 cshp214 sh[25457]: INFO 
[kvm.resource.LibvirtConnection] (main:) (logid:) No existing libvirtd 
connection found. Opening a new one
Jan 31 11:17:21 cshp214 sh[25457]: libvirt: XML-RPC error : Failed to 
connect socket to '/var/run/libvirt/libvirt-sock': No such file or 
directory
Jan 31 11:17:21 cshp214 sh[25457]: ERROR [cloud.agent.AgentShell] 
(main:) (logid:) Unable to start agent:
Jan 31 11:17:21 cshp214 sh[25457]: 
com.cloud.utils.exception.CloudRuntimeException: Failed to connect 
socket to '/var/run/libvirt/libvirt-sock': No such file or directory
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:914)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.Agent.(Agent.java:190)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.AgentShell.launchNewAgent(AgentShell.java:453)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:422)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.AgentShell.launchAgent(AgentShell.java:406)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.AgentShell.start(AgentShell.java:512)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.AgentShell.main(AgentShell.java:547)
Jan 31 11:17:21 cshp214 sh[25457]: Unable to start agent: Failed to 
connect socket to '/var/run/libvirt/libvirt-sock': No such file or 
directory
Jan 31 11:17:21 cshp214 systemd[1]: cloudstack-agent.service: Main 
process exited, code=exited, status=67/n/a
Jan 31 11:17:21 cshp214 systemd[1]: cloudstack-agent.service: Unit 
entered failed state.
Jan 31 11:17:21 cshp214 systemd[1]: cloudstack-agent.service: Failed 
with result 'exit-code'.

Jan 31 11:17:21 cshp214 dnsmasq[4000]: read /etc/hosts - 13 addresses
Jan 31 11:17:21 cshp214 dnsmasq[4000]: read 
/var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
Jan 31 11:17:21 cshp214 dnsmasq-dhcp[4000]: read 
/var/lib/libvirt/dnsmasq/default.hostsfile
Jan 31 11:17:22 cshp214 snmpd[2460]: Connection from UDP: 
[127.0.0.1]:37699->[127.0.0.1]:161
Jan 31 11:17:24 cshp214 snmpd[2460]: message repeated 2 times: [ 
Connection from UDP: [127.0.0.1]:37699->[127.0.0.1]:161]
Jan 31 11:17:24 cshp214 libvirtd[25368]: libvirt version: 1.3.1, 
package: 1ubuntu10.24 (Marc Deslauriers  
Wed, 23 May 2018 13:29:29 -0400)

Jan 31 11:17:24 cshp214 libvirtd[25368]: hostname: cshp214
Jan 31 11:17:24 cshp214 libvirtd[25368]: Configured security driver 
"none" disables default policy to create confined guests
Jan 31 11:17:25 cshp214 libvirtd[25368]: unsupported configuration: 
Security driver apparmor not enabled



Can anyone help me?

Il 30/01/19 13:37, Rohit Yadav ha scritto:


Hi Ugo,


This will be a one-time procedure, and the KVM host and the VMs do 
not need a reboot but the provisionCertificate API will restart the 
libvirtd process (just check if that can have any side effects for 
your VMs/distro, on most modern distros restarting libvirtd does not 
have any side-effects on existing running VMs).



- Rohit



rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue


*From:* Ugo Vasi 
*Sent:* Wednesday, January 30, 2019 4:47:09 PM
*To:* users@cloudstack.apache.org; Rohit Yadav
*Subject:* Re: secure hosts communications
Hi Rohit,
I have a 4.11.2.0 ACS infrastructure (Ubuntu 16.04 with KVM hypervisor)
I see that all the hosts are in unsecure state from the UI and so the
live migration don't works (we had trubles with mgmt server).

I read in the documentation that launching the provisionCertificate API
(by pressing the appropriate button in the UI) the certificates will be
renewed/regenerated for already connected agents/hosts.

I do not understand if provisioning should be done manually on each host
or if the procedure should be done only once.

Do this procedure reboot the host or the instances that it contains?


Thanks



Il 27/11/18 09:49, Rohit Yadav ha scritto:
> Hi Richard,
>
>
> Please read: 
http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#security

>
>
> 4.11.2 is out, please consider using it instead of 4.11.1 as it has 
several bugfixes etc.

>
> In short, with all of your KVM hosts up and connected to mgmt 
server, first change the auth strictness global setting to true, then 
using API secure the hosts using the provisionCertificate API. In the 
UI, go to your hosts that don't show up as secure and click on the 
key button (a new button) to secure the host which calls the 
provisionCertificate API as well.

>
>
> - Rohit
>
> <https://cloudstack.apache.org>
>
>
>
> 
> From: Richard Persaud 
> Sent: Monday, November 26, 2018 8:19:56 PM
> To: users@cloudstack.apache.o

Re: secure hosts communications

2019-01-31 Thread Ugo Vasi
 : Failed to 
connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
Jan 31 11:17:21 cshp214 sh[25457]: ERROR [cloud.agent.AgentShell] 
(main:) (logid:) Unable to start agent:
Jan 31 11:17:21 cshp214 sh[25457]: 
com.cloud.utils.exception.CloudRuntimeException: Failed to connect 
socket to '/var/run/libvirt/libvirt-sock': No such file or directory
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:914)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.Agent.(Agent.java:190)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.AgentShell.launchNewAgent(AgentShell.java:453)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:422)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.AgentShell.launchAgent(AgentShell.java:406)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.AgentShell.start(AgentShell.java:512)
Jan 31 11:17:21 cshp214 sh[25457]: #011at 
com.cloud.agent.AgentShell.main(AgentShell.java:547)
Jan 31 11:17:21 cshp214 sh[25457]: Unable to start agent: Failed to 
connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory
Jan 31 11:17:21 cshp214 systemd[1]: cloudstack-agent.service: Main 
process exited, code=exited, status=67/n/a
Jan 31 11:17:21 cshp214 systemd[1]: cloudstack-agent.service: Unit 
entered failed state.
Jan 31 11:17:21 cshp214 systemd[1]: cloudstack-agent.service: Failed 
with result 'exit-code'.

Jan 31 11:17:21 cshp214 dnsmasq[4000]: read /etc/hosts - 13 addresses
Jan 31 11:17:21 cshp214 dnsmasq[4000]: read 
/var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses
Jan 31 11:17:21 cshp214 dnsmasq-dhcp[4000]: read 
/var/lib/libvirt/dnsmasq/default.hostsfile
Jan 31 11:17:22 cshp214 snmpd[2460]: Connection from UDP: 
[127.0.0.1]:37699->[127.0.0.1]:161
Jan 31 11:17:24 cshp214 snmpd[2460]: message repeated 2 times: [ 
Connection from UDP: [127.0.0.1]:37699->[127.0.0.1]:161]
Jan 31 11:17:24 cshp214 libvirtd[25368]: libvirt version: 1.3.1, 
package: 1ubuntu10.24 (Marc Deslauriers  
Wed, 23 May 2018 13:29:29 -0400)

Jan 31 11:17:24 cshp214 libvirtd[25368]: hostname: cshp214
Jan 31 11:17:24 cshp214 libvirtd[25368]: Configured security driver 
"none" disables default policy to create confined guests
Jan 31 11:17:25 cshp214 libvirtd[25368]: unsupported configuration: 
Security driver apparmor not enabled



Can anyone help me?

Il 30/01/19 13:37, Rohit Yadav ha scritto:


Hi Ugo,


This will be a one-time procedure, and the KVM host and the VMs do not 
need a reboot but the provisionCertificate API will restart the 
libvirtd process (just check if that can have any side effects for 
your VMs/distro, on most modern distros restarting libvirtd does not 
have any side-effects on existing running VMs).



- Rohit



rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue


*From:* Ugo Vasi 
*Sent:* Wednesday, January 30, 2019 4:47:09 PM
*To:* users@cloudstack.apache.org; Rohit Yadav
*Subject:* Re: secure hosts communications
Hi Rohit,
I have a 4.11.2.0 ACS infrastructure (Ubuntu 16.04 with KVM hypervisor)
I see that all the hosts are in unsecure state from the UI and so the
live migration don't works (we had trubles with mgmt server).

I read in the documentation that launching the provisionCertificate API
(by pressing the appropriate button in the UI) the certificates will be
renewed/regenerated for already connected agents/hosts.

I do not understand if provisioning should be done manually on each host
or if the procedure should be done only once.

Do this procedure reboot the host or the instances that it contains?


Thanks



Il 27/11/18 09:49, Rohit Yadav ha scritto:
> Hi Richard,
>
>
> Please read: 
http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#security

>
>
> 4.11.2 is out, please consider using it instead of 4.11.1 as it has 
several bugfixes etc.

>
> In short, with all of your KVM hosts up and connected to mgmt 
server, first change the auth strictness global setting to true, then 
using API secure the hosts using the provisionCertificate API. In the 
UI, go to your hosts that don't show up as secure and click on the key 
button (a new button) to secure the host which calls the 
provisionCertificate API as well.

>
>
> - Rohit
>
> <https://cloudstack.apache.org>
>
>
>
> 
> From: Richard Persaud 
> Sent: Monday, November 26, 2018 8:19:56 PM
> To: users@cloudstack.apache.org
> Subject: RE: secure hosts communications
>
> Thank you, Rohit.
>
> I am using 4.11.1 with a full KVM environment. They are showing 
unsecure with strictness set to true.

>
> What configuration needs to be adjusted to have the KVM hosts show 
secure?

>
> Regards,
>
>

Re: secure hosts communications

2019-01-31 Thread Rohit Yadav
Old keystore if any on the KVM hosts (at /etc/cloudstack/agent/cloud.jks) will 
be removed.


- Rohit

<https://cloudstack.apache.org>




From: Ugo Vasi 
Sent: Thursday, January 31, 2019 2:24:06 PM
To: Rohit Yadav; users@cloudstack.apache.org
Subject: Re: secure hosts communications

Hi Rohit,
sorry if I insist with the questions... by launching the procedure, does
the framework rebuild and "overwrite" the configuration of the certificates?

Il 31/01/19 09:28, Ugo Vasi ha scritto:
> Hi Rohit,
> this is a fresh installed infrastructure, but we had some hardware
> problems (a mgms server restart) and now the hosts are in "unsecure"
> state.
>
> Do you have any idea how it could have happened to go to this state?
> I'm analyzing the logs but I do not find much about it.
>
> Il 31/01/19 08:38, Rohit Yadav ha scritto:
>>
>> Hi Ugo,
>>
>>
>> If it's a fresh 4.11.2.0 installation you don't need to do anything
>> you'll get your KVM hosts secured after you add them.
>>
>>
>> TL;DR - If you're upgrading, you simply need to run the
>> provisionCertificate API against each of your KVM hosts after
>> installation and upgrade. Refer:
>> http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#securing-process
>>
>>
>>
>> - Rohit
>>
>>
>>
>> rohit.ya...@shapeblue.com
>> www.shapeblue.com<http://www.shapeblue.com>
>> @shapeblue
>>
>> ------------
>> *From:* Ugo Vasi 
>> *Sent:* Wednesday, January 30, 2019 6:43:00 PM
>> *To:* Rohit Yadav; users@cloudstack.apache.org
>> *Subject:* Re: secure hosts communications
>> Hi Rohit,
>> what I do not understand is if in this ACS version (4.11.2.0) you have
>> to start the procedure manually or it is done during the installation.
>> Did I skip some steps during the installation?
>>
>> Thanks
>>
>> Il 30/01/19 13:37, Rohit Yadav ha scritto:
>> >
>> > Hi Ugo,
>> >
>> >
>> > This will be a one-time procedure, and the KVM host and the VMs do not
>> > need a reboot but the provisionCertificate API will restart the
>> > libvirtd process (just check if that can have any side effects for
>> > your VMs/distro, on most modern distros restarting libvirtd does not
>> > have any side-effects on existing running VMs).
>> >
>> >
>> > - Rohit
>> >
>> >
>> >
>> > rohit.ya...@shapeblue.com
>> > www.shapeblue.com<http://www.shapeblue.com> <http://www.shapeblue.com>
>> > @shapeblue
>> >
>> >
>> 
>> > *From:* Ugo Vasi 
>> > *Sent:* Wednesday, January 30, 2019 4:47:09 PM
>> > *To:* users@cloudstack.apache.org; Rohit Yadav
>> > *Subject:* Re: secure hosts communications
>> > Hi Rohit,
>> > I have a 4.11.2.0 ACS infrastructure (Ubuntu 16.04 with KVM
>> hypervisor)
>> > I see that all the hosts are in unsecure state from the UI and so the
>> > live migration don't works (we had trubles with mgmt server).
>> >
>> > I read in the documentation that launching the provisionCertificate
>> API
>> > (by pressing the appropriate button in the UI) the certificates
>> will be
>> > renewed/regenerated for already connected agents/hosts.
>> >
>> > I do not understand if provisioning should be done manually on each
>> host
>> > or if the procedure should be done only once.
>> >
>> > Do this procedure reboot the host or the instances that it contains?
>> >
>> >
>> > Thanks
>> >
>> >
>> >
>> > Il 27/11/18 09:49, Rohit Yadav ha scritto:
>> > > Hi Richard,
>> > >
>> > >
>> > > Please read:
>> >
>> http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#security
>> > >
>> > >
>> > > 4.11.2 is out, please consider using it instead of 4.11.1 as it has
>> > several bugfixes etc.
>> > >
>> > > In short, with all of your KVM hosts up and connected to mgmt
>> > server, first change the auth strictness global setting to true, then
>> > using API secure the hosts using the provisionCertificate API. In the
>> > UI, go to your hosts that don't show up as secure and click on the key
>> > button (a new button) to secure the host which calls the
>> > provisionCertificate API as 

Re: secure hosts communications

2019-01-31 Thread Ugo Vasi

Hi Rohit,
sorry if I insist with the questions... by launching the procedure, does 
the framework rebuild and "overwrite" the configuration of the certificates?


Il 31/01/19 09:28, Ugo Vasi ha scritto:

Hi Rohit,
this is a fresh installed infrastructure, but we had some hardware 
problems (a mgms server restart) and now the hosts are in "unsecure" 
state.


Do you have any idea how it could have happened to go to this state? 
I'm analyzing the logs but I do not find much about it.


Il 31/01/19 08:38, Rohit Yadav ha scritto:


Hi Ugo,


If it's a fresh 4.11.2.0 installation you don't need to do anything 
you'll get your KVM hosts secured after you add them.



TL;DR - If you're upgrading, you simply need to run the 
provisionCertificate API against each of your KVM hosts after 
installation and upgrade. Refer: 
http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#securing-process




- Rohit



rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue


*From:* Ugo Vasi 
*Sent:* Wednesday, January 30, 2019 6:43:00 PM
*To:* Rohit Yadav; users@cloudstack.apache.org
*Subject:* Re: secure hosts communications
Hi Rohit,
what I do not understand is if in this ACS version (4.11.2.0) you have
to start the procedure manually or it is done during the installation.
Did I skip some steps during the installation?

Thanks

Il 30/01/19 13:37, Rohit Yadav ha scritto:
>
> Hi Ugo,
>
>
> This will be a one-time procedure, and the KVM host and the VMs do not
> need a reboot but the provisionCertificate API will restart the
> libvirtd process (just check if that can have any side effects for
> your VMs/distro, on most modern distros restarting libvirtd does not
> have any side-effects on existing running VMs).
>
>
> - Rohit
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com <http://www.shapeblue.com>
> @shapeblue
>
> 


> *From:* Ugo Vasi 
> *Sent:* Wednesday, January 30, 2019 4:47:09 PM
> *To:* users@cloudstack.apache.org; Rohit Yadav
> *Subject:* Re: secure hosts communications
> Hi Rohit,
> I have a 4.11.2.0 ACS infrastructure (Ubuntu 16.04 with KVM 
hypervisor)

> I see that all the hosts are in unsecure state from the UI and so the
> live migration don't works (we had trubles with mgmt server).
>
> I read in the documentation that launching the provisionCertificate 
API
> (by pressing the appropriate button in the UI) the certificates 
will be

> renewed/regenerated for already connected agents/hosts.
>
> I do not understand if provisioning should be done manually on each 
host

> or if the procedure should be done only once.
>
> Do this procedure reboot the host or the instances that it contains?
>
>
> Thanks
>
>
>
> Il 27/11/18 09:49, Rohit Yadav ha scritto:
> > Hi Richard,
> >
> >
> > Please read:
> 
http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#security

> >
> >
> > 4.11.2 is out, please consider using it instead of 4.11.1 as it has
> several bugfixes etc.
> >
> > In short, with all of your KVM hosts up and connected to mgmt
> server, first change the auth strictness global setting to true, then
> using API secure the hosts using the provisionCertificate API. In the
> UI, go to your hosts that don't show up as secure and click on the key
> button (a new button) to secure the host which calls the
> provisionCertificate API as well.
> >
> >
> > - Rohit
> >
> > <https://cloudstack.apache.org>
> >
> >
> >
> > 
> > From: Richard Persaud 
> > Sent: Monday, November 26, 2018 8:19:56 PM
> > To: users@cloudstack.apache.org
> > Subject: RE: secure hosts communications
> >
> > Thank you, Rohit.
> >
> > I am using 4.11.1 with a full KVM environment. They are showing
> unsecure with strictness set to true.
> >
> > What configuration needs to be adjusted to have the KVM hosts show
> secure?
> >
> > Regards,
> >
> > Richard Persaud
> >
> > From: Rohit Yadav 
> > Sent: Saturday, November 24, 2018 2:02 PM
> > To: users@cloudstack.apache.org
> > Subject: Re: secure hosts communications
> >
> > ⚠ EXT MSG:
> >
> > Richard,
> >
> >
> > Starting 4.11, agent and management servers will use an in-built CA
> framework to secured hosts. Only in case of KVM hosts you may see an
> insecure state, otherwise all KVM hosts (agents) and SSVM/CPVM agents
> will by default in Up state will be secured. There is an auth
> strictness setting that should be true.
> >
> >
&

Re: secure hosts communications

2019-01-31 Thread Ugo Vasi

Hi Rohit,
this is a fresh installed infrastructure, but we had some hardware 
problems (a mgms server restart) and now the hosts are in "unsecure" state.


Do you have any idea how it could have happened to go to this state? I'm 
analyzing the logs but I do not find much about it.


Il 31/01/19 08:38, Rohit Yadav ha scritto:


Hi Ugo,


If it's a fresh 4.11.2.0 installation you don't need to do anything 
you'll get your KVM hosts secured after you add them.



TL;DR - If you're upgrading, you simply need to run the 
provisionCertificate API against each of your KVM hosts after 
installation and upgrade. Refer: 
http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#securing-process




- Rohit



rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue


*From:* Ugo Vasi 
*Sent:* Wednesday, January 30, 2019 6:43:00 PM
*To:* Rohit Yadav; users@cloudstack.apache.org
*Subject:* Re: secure hosts communications
Hi Rohit,
what I do not understand is if in this ACS version (4.11.2.0) you have
to start the procedure manually or it is done during the installation.
Did I skip some steps during the installation?

Thanks

Il 30/01/19 13:37, Rohit Yadav ha scritto:
>
> Hi Ugo,
>
>
> This will be a one-time procedure, and the KVM host and the VMs do not
> need a reboot but the provisionCertificate API will restart the
> libvirtd process (just check if that can have any side effects for
> your VMs/distro, on most modern distros restarting libvirtd does not
> have any side-effects on existing running VMs).
>
>
> - Rohit
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com <http://www.shapeblue.com>
> @shapeblue
>
> 
> *From:* Ugo Vasi 
> *Sent:* Wednesday, January 30, 2019 4:47:09 PM
> *To:* users@cloudstack.apache.org; Rohit Yadav
> *Subject:* Re: secure hosts communications
> Hi Rohit,
> I have a 4.11.2.0 ACS infrastructure (Ubuntu 16.04 with KVM hypervisor)
> I see that all the hosts are in unsecure state from the UI and so the
> live migration don't works (we had trubles with mgmt server).
>
> I read in the documentation that launching the provisionCertificate API
> (by pressing the appropriate button in the UI) the certificates will be
> renewed/regenerated for already connected agents/hosts.
>
> I do not understand if provisioning should be done manually on each host
> or if the procedure should be done only once.
>
> Do this procedure reboot the host or the instances that it contains?
>
>
> Thanks
>
>
>
> Il 27/11/18 09:49, Rohit Yadav ha scritto:
> > Hi Richard,
> >
> >
> > Please read:
> 
http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#security

> >
> >
> > 4.11.2 is out, please consider using it instead of 4.11.1 as it has
> several bugfixes etc.
> >
> > In short, with all of your KVM hosts up and connected to mgmt
> server, first change the auth strictness global setting to true, then
> using API secure the hosts using the provisionCertificate API. In the
> UI, go to your hosts that don't show up as secure and click on the key
> button (a new button) to secure the host which calls the
> provisionCertificate API as well.
> >
> >
> > - Rohit
> >
> > <https://cloudstack.apache.org>
> >
> >
> >
> > 
> > From: Richard Persaud 
> > Sent: Monday, November 26, 2018 8:19:56 PM
> > To: users@cloudstack.apache.org
> > Subject: RE: secure hosts communications
> >
> > Thank you, Rohit.
> >
> > I am using 4.11.1 with a full KVM environment. They are showing
> unsecure with strictness set to true.
> >
> > What configuration needs to be adjusted to have the KVM hosts show
> secure?
> >
> > Regards,
> >
> > Richard Persaud
> >
> > From: Rohit Yadav 
> > Sent: Saturday, November 24, 2018 2:02 PM
> > To: users@cloudstack.apache.org
> > Subject: Re: secure hosts communications
> >
> > ⚠ EXT MSG:
> >
> > Richard,
> >
> >
> > Starting 4.11, agent and management servers will use an in-built CA
> framework to secured hosts. Only in case of KVM hosts you may see an
> insecure state, otherwise all KVM hosts (agents) and SSVM/CPVM agents
> will by default in Up state will be secured. There is an auth
> strictness setting that should be true.
> >
> >
> >
> > - Rohit
> >
> > <https://cloudstack.apache.org>
> >
> >
> >
> > 
> > From: Richard Persaud
> mailto:

Re: secure hosts communications

2019-01-30 Thread Rohit Yadav
Hi Ugo,


If it's a fresh 4.11.2.0 installation you don't need to do anything you'll get 
your KVM hosts secured after you add them.


TL;DR - If you're upgrading, you simply need to run the provisionCertificate 
API against each of your KVM hosts after installation and upgrade. Refer: 
http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#securing-process



- Rohit

<https://cloudstack.apache.org>




From: Ugo Vasi 
Sent: Wednesday, January 30, 2019 6:43:00 PM
To: Rohit Yadav; users@cloudstack.apache.org
Subject: Re: secure hosts communications

Hi Rohit,
what I do not understand is if in this ACS version (4.11.2.0) you have
to start the procedure manually or it is done during the installation.
Did I skip some steps during the installation?

Thanks

Il 30/01/19 13:37, Rohit Yadav ha scritto:
>
> Hi Ugo,
>
>
> This will be a one-time procedure, and the KVM host and the VMs do not
> need a reboot but the provisionCertificate API will restart the
> libvirtd process (just check if that can have any side effects for
> your VMs/distro, on most modern distros restarting libvirtd does not
> have any side-effects on existing running VMs).
>
>
> - Rohit
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> @shapeblue
>
> 
> *From:* Ugo Vasi 
> *Sent:* Wednesday, January 30, 2019 4:47:09 PM
> *To:* users@cloudstack.apache.org; Rohit Yadav
> *Subject:* Re: secure hosts communications
> Hi Rohit,
> I have a 4.11.2.0 ACS infrastructure (Ubuntu 16.04 with KVM hypervisor)
> I see that all the hosts are in unsecure state from the UI and so the
> live migration don't works (we had trubles with mgmt server).
>
> I read in the documentation that launching the provisionCertificate API
> (by pressing the appropriate button in the UI) the certificates will be
> renewed/regenerated for already connected agents/hosts.
>
> I do not understand if provisioning should be done manually on each host
> or if the procedure should be done only once.
>
> Do this procedure reboot the host or the instances that it contains?
>
>
> Thanks
>
>
>
> Il 27/11/18 09:49, Rohit Yadav ha scritto:
> > Hi Richard,
> >
> >
> > Please read:
> http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#security
> >
> >
> > 4.11.2 is out, please consider using it instead of 4.11.1 as it has
> several bugfixes etc.
> >
> > In short, with all of your KVM hosts up and connected to mgmt
> server, first change the auth strictness global setting to true, then
> using API secure the hosts using the provisionCertificate API. In the
> UI, go to your hosts that don't show up as secure and click on the key
> button (a new button) to secure the host which calls the
> provisionCertificate API as well.
> >
> >
> > - Rohit
> >
> > <https://cloudstack.apache.org>
> >
> >
> >
> > 
> > From: Richard Persaud 
> > Sent: Monday, November 26, 2018 8:19:56 PM
> > To: users@cloudstack.apache.org
> > Subject: RE: secure hosts communications
> >
> > Thank you, Rohit.
> >
> > I am using 4.11.1 with a full KVM environment. They are showing
> unsecure with strictness set to true.
> >
> > What configuration needs to be adjusted to have the KVM hosts show
> secure?
> >
> > Regards,
> >
> > Richard Persaud
> >
> > From: Rohit Yadav 
> > Sent: Saturday, November 24, 2018 2:02 PM
> > To: users@cloudstack.apache.org
> > Subject: Re: secure hosts communications
> >
> > ⚠ EXT MSG:
> >
> > Richard,
> >
> >
> > Starting 4.11, agent and management servers will use an in-built CA
> framework to secured hosts. Only in case of KVM hosts you may see an
> insecure state, otherwise all KVM hosts (agents) and SSVM/CPVM agents
> will by default in Up state will be secured. There is an auth
> strictness setting that should be true.
> >
> >
> >
> > - Rohit
> >
> > <https://cloudstack.apache.org>
> >
> >
> >
> > 
> > From: Richard Persaud
> mailto:richard.pers...@macys.com>>
> > Sent: Saturday, November 24, 2018 4:21:24 AM
> > To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
> > Subject: secure hosts communications
> >
> > Hello,
> >
> > Is there straight-forward to enable secure communications between
> the management and the hosts?
> >
> > I have looked at many docume

Re: secure hosts communications

2019-01-30 Thread Ugo Vasi

Hi Rohit,
what I do not understand is if in this ACS version (4.11.2.0) you have 
to start the procedure manually or it is done during the installation. 
Did I skip some steps during the installation?


Thanks

Il 30/01/19 13:37, Rohit Yadav ha scritto:


Hi Ugo,


This will be a one-time procedure, and the KVM host and the VMs do not 
need a reboot but the provisionCertificate API will restart the 
libvirtd process (just check if that can have any side effects for 
your VMs/distro, on most modern distros restarting libvirtd does not 
have any side-effects on existing running VMs).



- Rohit



rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue


*From:* Ugo Vasi 
*Sent:* Wednesday, January 30, 2019 4:47:09 PM
*To:* users@cloudstack.apache.org; Rohit Yadav
*Subject:* Re: secure hosts communications
Hi Rohit,
I have a 4.11.2.0 ACS infrastructure (Ubuntu 16.04 with KVM hypervisor)
I see that all the hosts are in unsecure state from the UI and so the
live migration don't works (we had trubles with mgmt server).

I read in the documentation that launching the provisionCertificate API
(by pressing the appropriate button in the UI) the certificates will be
renewed/regenerated for already connected agents/hosts.

I do not understand if provisioning should be done manually on each host
or if the procedure should be done only once.

Do this procedure reboot the host or the instances that it contains?


Thanks



Il 27/11/18 09:49, Rohit Yadav ha scritto:
> Hi Richard,
>
>
> Please read: 
http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#security

>
>
> 4.11.2 is out, please consider using it instead of 4.11.1 as it has 
several bugfixes etc.

>
> In short, with all of your KVM hosts up and connected to mgmt 
server, first change the auth strictness global setting to true, then 
using API secure the hosts using the provisionCertificate API. In the 
UI, go to your hosts that don't show up as secure and click on the key 
button (a new button) to secure the host which calls the 
provisionCertificate API as well.

>
>
> - Rohit
>
> <https://cloudstack.apache.org>
>
>
>
> 
> From: Richard Persaud 
> Sent: Monday, November 26, 2018 8:19:56 PM
> To: users@cloudstack.apache.org
> Subject: RE: secure hosts communications
>
> Thank you, Rohit.
>
> I am using 4.11.1 with a full KVM environment. They are showing 
unsecure with strictness set to true.

>
> What configuration needs to be adjusted to have the KVM hosts show 
secure?

>
> Regards,
>
> Richard Persaud
>
> From: Rohit Yadav 
> Sent: Saturday, November 24, 2018 2:02 PM
> To: users@cloudstack.apache.org
> Subject: Re: secure hosts communications
>
> ⚠ EXT MSG:
>
> Richard,
>
>
> Starting 4.11, agent and management servers will use an in-built CA 
framework to secured hosts. Only in case of KVM hosts you may see an 
insecure state, otherwise all KVM hosts (agents) and SSVM/CPVM agents 
will by default in Up state will be secured. There is an auth 
strictness setting that should be true.

>
>
>
> - Rohit
>
> <https://cloudstack.apache.org>
>
>
>
> 
> From: Richard Persaud 
mailto:richard.pers...@macys.com>>

> Sent: Saturday, November 24, 2018 4:21:24 AM
> To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
> Subject: secure hosts communications
>
> Hello,
>
> Is there straight-forward to enable secure communications between 
the management and the hosts?

>
> I have looked at many documentations but am still unable to get the 
hosts to show a "secure" state.

>
> Regards,
>
> Richard Persaud
>
>
> rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
> 
www.shapeblue.com<https://isolate.menlosecurity.com/0/eJyrViotylGyUsooKSmw0tcvLy_XK85ILEhNyilN1UvOz1XSUSrKV7Iy1FEqyUwBqjM0MFaqBQDf4BCe>

> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>
> * This is an EXTERNAL EMAIL. Stop and think before clicking a link 
or opening attachments.

>
> rohit.ya...@shapeblue.com
> www.shapeblue.com <http://www.shapeblue.com>
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>
>
>


--

*Ugo Vasi* / System Administrator
ugo.v...@procne.it <mailto:ugo.v...@procne.it>




*Procne S.r.l.*
+39 0432 486 523
via Cotonificio, 45
33010 Tavagnacco (UD)
www.procne.it <http://www.procne.it> <http://www.procne.it/>


Le informazioni contenute nella presente comunicazione ed i relativi
allegati possono essere riservate e sono, comunque, destinate
esclusivamente alle persone od alla Società sopraindicati. La
diffusione, distribuzione e/o copiatura

Re: secure hosts communications

2019-01-30 Thread Rohit Yadav
Hi Ugo,


This will be a one-time procedure, and the KVM host and the VMs do not need a 
reboot but the provisionCertificate API will restart the libvirtd process (just 
check if that can have any side effects for your VMs/distro, on most modern 
distros restarting libvirtd does not have any side-effects on existing running 
VMs).


- Rohit

<https://cloudstack.apache.org>




From: Ugo Vasi 
Sent: Wednesday, January 30, 2019 4:47:09 PM
To: users@cloudstack.apache.org; Rohit Yadav
Subject: Re: secure hosts communications

Hi Rohit,
I have a 4.11.2.0 ACS infrastructure (Ubuntu 16.04 with KVM hypervisor)
I see that all the hosts are in unsecure state from the UI and so the
live migration don't works (we had trubles with mgmt server).

I read in the documentation that launching the provisionCertificate API
(by pressing the appropriate button in the UI) the certificates will be
renewed/regenerated for already connected agents/hosts.

I do not understand if provisioning should be done manually on each host
or if the procedure should be done only once.

Do this procedure reboot the host or the instances that it contains?


Thanks



Il 27/11/18 09:49, Rohit Yadav ha scritto:
> Hi Richard,
>
>
> Please read: 
> http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#security
>
>
> 4.11.2 is out, please consider using it instead of 4.11.1 as it has several 
> bugfixes etc.
>
> In short, with all of your KVM hosts up and connected to mgmt server, first 
> change the auth strictness global setting to true, then using API secure the 
> hosts using the provisionCertificate API. In the UI, go to your hosts that 
> don't show up as secure and click on the key button (a new button) to secure 
> the host which calls the provisionCertificate API as well.
>
>
> - Rohit
>
> <https://cloudstack.apache.org>
>
>
>
> 
> From: Richard Persaud 
> Sent: Monday, November 26, 2018 8:19:56 PM
> To: users@cloudstack.apache.org
> Subject: RE: secure hosts communications
>
> Thank you, Rohit.
>
> I am using 4.11.1 with a full KVM environment. They are showing unsecure with 
> strictness set to true.
>
> What configuration needs to be adjusted to have the KVM hosts show secure?
>
> Regards,
>
> Richard Persaud
>
> From: Rohit Yadav 
> Sent: Saturday, November 24, 2018 2:02 PM
> To: users@cloudstack.apache.org
> Subject: Re: secure hosts communications
>
> ⚠ EXT MSG:
>
> Richard,
>
>
> Starting 4.11, agent and management servers will use an in-built CA framework 
> to secured hosts. Only in case of KVM hosts you may see an insecure state, 
> otherwise all KVM hosts (agents) and SSVM/CPVM agents will by default in Up 
> state will be secured. There is an auth strictness setting that should be 
> true.
>
>
>
> - Rohit
>
> <https://cloudstack.apache.org>
>
>
>
> 
> From: Richard Persaud 
> mailto:richard.pers...@macys.com>>
> Sent: Saturday, November 24, 2018 4:21:24 AM
> To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
> Subject: secure hosts communications
>
> Hello,
>
> Is there straight-forward to enable secure communications between the 
> management and the hosts?
>
> I have looked at many documentations but am still unable to get the hosts to 
> show a "secure" state.
>
> Regards,
>
> Richard Persaud
>
>
> rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
> www.shapeblue.com<https://isolate.menlosecurity.com/0/eJyrViotylGyUsooKSmw0tcvLy_XK85ILEhNyilN1UvOz1XSUSrKV7Iy1FEqyUwBqjM0MFaqBQDf4BCe>
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>
> * This is an EXTERNAL EMAIL. Stop and think before clicking a link or opening 
> attachments.
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>
>
>


--

*Ugo Vasi* / System Administrator
ugo.v...@procne.it <mailto:ugo.v...@procne.it>




*Procne S.r.l.*
+39 0432 486 523
via Cotonificio, 45
33010 Tavagnacco (UD)
www.procne.it<http://www.procne.it> <http://www.procne.it/>


Le informazioni contenute nella presente comunicazione ed i relativi
allegati possono essere riservate e sono, comunque, destinate
esclusivamente alle persone od alla Società sopraindicati. La
diffusione, distribuzione e/o copiatura del documento trasmesso da parte
di qualsiasi soggetto diverso dal destinatario è proibita sia ai sensi
dell'art. 616 c.p., che ai sensi del Decreto Legislativo n. 196/2003
"Codice in materia di protezione dei dati personali". Se avete ricevuto
questo messaggio per errore, vi preghiamo di distruggerlo e di informare
immediatamente Procne S.r.l. scrivendo all' indirizzo e-mail
i...@procne.it <mailto:i...@procne.it>.


rohit.ya...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 



Re: secure hosts communications

2019-01-30 Thread Ugo Vasi

Hi Rohit,
I have a 4.11.2.0 ACS infrastructure (Ubuntu 16.04 with KVM hypervisor) 
I see that all the hosts are in unsecure state from the UI and so the 
live migration don't works (we had trubles with mgmt server).


I read in the documentation that launching the provisionCertificate API 
(by pressing the appropriate button in the UI) the certificates will be 
renewed/regenerated for already connected agents/hosts.


I do not understand if provisioning should be done manually on each host 
or if the procedure should be done only once.


Do this procedure reboot the host or the instances that it contains?


Thanks



Il 27/11/18 09:49, Rohit Yadav ha scritto:

Hi Richard,


Please read: 
http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#security


4.11.2 is out, please consider using it instead of 4.11.1 as it has several 
bugfixes etc.

In short, with all of your KVM hosts up and connected to mgmt server, first 
change the auth strictness global setting to true, then using API secure the 
hosts using the provisionCertificate API. In the UI, go to your hosts that 
don't show up as secure and click on the key button (a new button) to secure 
the host which calls the provisionCertificate API as well.


- Rohit

<https://cloudstack.apache.org>




From: Richard Persaud 
Sent: Monday, November 26, 2018 8:19:56 PM
To: users@cloudstack.apache.org
Subject: RE: secure hosts communications

Thank you, Rohit.

I am using 4.11.1 with a full KVM environment. They are showing unsecure with 
strictness set to true.

What configuration needs to be adjusted to have the KVM hosts show secure?

Regards,

Richard Persaud

From: Rohit Yadav 
Sent: Saturday, November 24, 2018 2:02 PM
To: users@cloudstack.apache.org
Subject: Re: secure hosts communications

⚠ EXT MSG:

Richard,


Starting 4.11, agent and management servers will use an in-built CA framework 
to secured hosts. Only in case of KVM hosts you may see an insecure state, 
otherwise all KVM hosts (agents) and SSVM/CPVM agents will by default in Up 
state will be secured. There is an auth strictness setting that should be true.



- Rohit

<https://cloudstack.apache.org>




From: Richard Persaud 
mailto:richard.pers...@macys.com>>
Sent: Saturday, November 24, 2018 4:21:24 AM
To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
Subject: secure hosts communications

Hello,

Is there straight-forward to enable secure communications between the 
management and the hosts?

I have looked at many documentations but am still unable to get the hosts to show a 
"secure" state.

Regards,

Richard Persaud


rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com<https://isolate.menlosecurity.com/0/eJyrViotylGyUsooKSmw0tcvLy_XK85ILEhNyilN1UvOz1XSUSrKV7Iy1FEqyUwBqjM0MFaqBQDf4BCe>
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue




* This is an EXTERNAL EMAIL. Stop and think before clicking a link or opening 
attachments.

rohit.ya...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
   
  








--

*Ugo Vasi* / System Administrator
ugo.v...@procne.it <mailto:ugo.v...@procne.it>




*Procne S.r.l.*
+39 0432 486 523
via Cotonificio, 45
33010 Tavagnacco (UD)
www.procne.it <http://www.procne.it/>


Le informazioni contenute nella presente comunicazione ed i relativi 
allegati possono essere riservate e sono, comunque, destinate 
esclusivamente alle persone od alla Società sopraindicati. La 
diffusione, distribuzione e/o copiatura del documento trasmesso da parte 
di qualsiasi soggetto diverso dal destinatario è proibita sia ai sensi 
dell'art. 616 c.p., che ai sensi del Decreto Legislativo n. 196/2003 
"Codice in materia di protezione dei dati personali". Se avete ricevuto 
questo messaggio per errore, vi preghiamo di distruggerlo e di informare 
immediatamente Procne S.r.l. scrivendo all' indirizzo e-mail 
i...@procne.it <mailto:i...@procne.it>.




Re: secure hosts communications

2018-11-27 Thread Rohit Yadav
Hi Richard,


Please read: 
http://docs.cloudstack.apache.org/en/4.11.2.0/adminguide/hosts.html#security


4.11.2 is out, please consider using it instead of 4.11.1 as it has several 
bugfixes etc.

In short, with all of your KVM hosts up and connected to mgmt server, first 
change the auth strictness global setting to true, then using API secure the 
hosts using the provisionCertificate API. In the UI, go to your hosts that 
don't show up as secure and click on the key button (a new button) to secure 
the host which calls the provisionCertificate API as well.


- Rohit

<https://cloudstack.apache.org>




From: Richard Persaud 
Sent: Monday, November 26, 2018 8:19:56 PM
To: users@cloudstack.apache.org
Subject: RE: secure hosts communications

Thank you, Rohit.

I am using 4.11.1 with a full KVM environment. They are showing unsecure with 
strictness set to true.

What configuration needs to be adjusted to have the KVM hosts show secure?

Regards,

Richard Persaud

From: Rohit Yadav 
Sent: Saturday, November 24, 2018 2:02 PM
To: users@cloudstack.apache.org
Subject: Re: secure hosts communications

⚠ EXT MSG:

Richard,


Starting 4.11, agent and management servers will use an in-built CA framework 
to secured hosts. Only in case of KVM hosts you may see an insecure state, 
otherwise all KVM hosts (agents) and SSVM/CPVM agents will by default in Up 
state will be secured. There is an auth strictness setting that should be true.



- Rohit

<https://cloudstack.apache.org>




From: Richard Persaud 
mailto:richard.pers...@macys.com>>
Sent: Saturday, November 24, 2018 4:21:24 AM
To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
Subject: secure hosts communications

Hello,

Is there straight-forward to enable secure communications between the 
management and the hosts?

I have looked at many documentations but am still unable to get the hosts to 
show a "secure" state.

Regards,

Richard Persaud


rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com<https://isolate.menlosecurity.com/0/eJyrViotylGyUsooKSmw0tcvLy_XK85ILEhNyilN1UvOz1XSUSrKV7Iy1FEqyUwBqjM0MFaqBQDf4BCe>
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue




* This is an EXTERNAL EMAIL. Stop and think before clicking a link or opening 
attachments.

rohit.ya...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 



RE: secure hosts communications

2018-11-26 Thread Richard Persaud
Thank you, Rohit.

I am using 4.11.1 with a full KVM environment. They are showing unsecure with 
strictness set to true.

What configuration needs to be adjusted to have the KVM hosts show secure?

Regards,

Richard Persaud

From: Rohit Yadav 
Sent: Saturday, November 24, 2018 2:02 PM
To: users@cloudstack.apache.org
Subject: Re: secure hosts communications

⚠ EXT MSG:

Richard,


Starting 4.11, agent and management servers will use an in-built CA framework 
to secured hosts. Only in case of KVM hosts you may see an insecure state, 
otherwise all KVM hosts (agents) and SSVM/CPVM agents will by default in Up 
state will be secured. There is an auth strictness setting that should be true.



- Rohit

<https://cloudstack.apache.org>




From: Richard Persaud 
mailto:richard.pers...@macys.com>>
Sent: Saturday, November 24, 2018 4:21:24 AM
To: users@cloudstack.apache.org<mailto:users@cloudstack.apache.org>
Subject: secure hosts communications

Hello,

Is there straight-forward to enable secure communications between the 
management and the hosts?

I have looked at many documentations but am still unable to get the hosts to 
show a "secure" state.

Regards,

Richard Persaud


rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com<https://isolate.menlosecurity.com/0/eJyrViotylGyUsooKSmw0tcvLy_XK85ILEhNyilN1UvOz1XSUSrKV7Iy1FEqyUwBqjM0MFaqBQDf4BCe>
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue




* This is an EXTERNAL EMAIL. Stop and think before clicking a link or opening 
attachments.


Re: secure hosts communications

2018-11-24 Thread Rohit Yadav
Richard,


Starting 4.11, agent and management servers will use an in-built CA framework 
to secured hosts. Only in case of KVM hosts you may see an insecure state, 
otherwise all KVM hosts (agents) and SSVM/CPVM agents will by default in Up 
state will be secured. There is an auth strictness setting that should be true.



- Rohit






From: Richard Persaud 
Sent: Saturday, November 24, 2018 4:21:24 AM
To: users@cloudstack.apache.org
Subject: secure hosts communications

Hello,

Is there straight-forward to enable secure communications between the 
management and the hosts?

I have looked at many documentations but am still unable to get the hosts to 
show a "secure" state.

Regards,

Richard Persaud


rohit.ya...@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue