From nobody Sat Apr 20 01:15:02 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 205.139.110.120 as permitted sender) client-ip=205.139.110.120; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.120 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1574434042; cv=none; d=zohomail.com; s=zohoarc; b=HiBQ8yeGNMhkbY6JGm7dnoxmXhxhRZF7zpFwEY1v/AIbM+2HPrTpwpqmwJqtPjksmiHO7liHHnKEtLM5WR4TtJ+ffHU0bE7wwP1RDaxQHzQq8lkGMevQjaBF6jyPDbrmjLdNygz9Xkfqj1Kg4c4htTgz+8kRlBlQ35m3awgg6eE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1574434042; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=6j+N/gCTGR5JzsYZJiqrUw2KSV4OQE+UilCzJvX8wI4=; b=JfsHGZK1euAz5vJmddzY2IFYW2gAvdCKv9Tz4AD8YUCUeKIt65IRKBDHtXyGF7DRyru5F6O2EA/3e5wFigTCB14o3FmFrRS04TvLvofOMhcS4RoFcFUFJpzWKaJqF4LCb3G4mIOOZX1J6HL0CnSrcS/JYFNqI9+Tm7jVtZefmLg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.120 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by mx.zohomail.com with SMTPS id 1574434042625349.67702932489544; Fri, 22 Nov 2019 06:47:22 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-172-IJkFkkZ0OB641OrpAeQ_Gw-1; Fri, 22 Nov 2019 09:47:17 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4D41ADB65; Fri, 22 Nov 2019 14:47:12 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 072B976FFF; Fri, 22 Nov 2019 14:47:12 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 5A17F4BB65; Fri, 22 Nov 2019 14:47:11 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id xAMElABk017843 for ; Fri, 22 Nov 2019 09:47:10 -0500 Received: by smtp.corp.redhat.com (Postfix) id 4DEC81036C83; Fri, 22 Nov 2019 14:47:10 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-112-49.ams2.redhat.com [10.36.112.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1F9751036C7E; Fri, 22 Nov 2019 14:47:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574434040; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=6j+N/gCTGR5JzsYZJiqrUw2KSV4OQE+UilCzJvX8wI4=; b=foIkEZD11YvfSw/VdHicZJ8XpV6NtWEUcg1U7BsGvj33Wo3IrSxl3G5KUtjuPS5fbiAlcv eWkWU9C86xATLyp0KyCfrYABn3Ye6vblBwkkdxur5qTHISQ8rEi1xHbKDpuZdwu0dS89nz rNES6/n9GcGcYk49aehXtZVhOClwKzM= From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: libvir-list@redhat.com Date: Fri, 22 Nov 2019 14:46:48 +0000 Message-Id: <20191122144702.3780548-2-berrange@redhat.com> In-Reply-To: <20191122144702.3780548-1-berrange@redhat.com> References: <20191122144702.3780548-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 01/15] docs: split TLS certificate setup into its own file X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: IJkFkkZ0OB641OrpAeQ_Gw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) The generation and deployment of x509 certificates for TLS is complex and verbose and thus deserves its own standalone page. Signed-off-by: Daniel P. Berrang=C3=A9 Reviewed-by: Michal Privoznik --- docs/docs.html.in | 3 + docs/remote.html.in | 408 +---------------------------------------- docs/tlscerts.html.in | 413 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 417 insertions(+), 407 deletions(-) create mode 100644 docs/tlscerts.html.in diff --git a/docs/docs.html.in b/docs/docs.html.in index 268c16f3b3..f2721964b5 100644 --- a/docs/docs.html.in +++ b/docs/docs.html.in @@ -18,6 +18,9 @@
Remote access
Enable remote access over TCP
=20 +
TLS certs
+
Generate and deploy x509 certificates for TLS
+
Authentication
Configure authentication for the libvirt daemon
=20 diff --git a/docs/remote.html.in b/docs/remote.html.in index 78e071a898..5a0ebe4790 100644 --- a/docs/remote.html.in +++ b/docs/remote.html.in @@ -61,7 +61,7 @@ Remote libvirt supports a range of transports:
TLS 1.0 (SSL 3.1) authenticated and encrypted TCP/IP socket, usually listening on a public port number. To use this you will need to - ge= nerate client and + generate = client and server certificates. The standard port is 16514.
@@ -382,412 +382,6 @@ Note that parameter values must be Example: sshauth=3Dprivkey,agent -

- Generating TLS certificates -

-

- Public Key Infrastructure set up -

-

-If you are unsure how to create TLS certificates, skip to the -next section. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Location Machine Description Required fields
- /etc/pki/CA/cacert.pem - Installed on the client and server CA's certificate (more info) - n/a
- $HOME/.pki/cacert.pem - Installed on the client CA's certificate (more info) - n/a
- /etc/pki/libvirt/private/serverkey.pem - Installed on the server Server's private key (more info) n/a
- /etc/pki/libvirt/servercert.pem - Installed on the server Server's certificate signed by the CA. - (more info) CommonName (CN) must be the hostname of the server as it - is seen by clients. All hostname and IP address variants that mi= ght - be used to reach the server should be listed in Subject Alt Name - fields.
- /etc/pki/libvirt/private/clientkey.pem - Installed on the client Client's private key. (more info) n/a
- /etc/pki/libvirt/clientcert.pem - Installed on the client Client's certificate signed by the CA - (more info) Distinguished Name (DN) can be checked against an access - control list (tls_allowed_dn_list). -
- $HOME/.pki/libvirt/clientkey.pem - Installed on the client Client's private key. (more info) n/a
- $HOME/.pki/libvirt/clientcert.pem - Installed on the client Client's certificate signed by the CA - (more info) Distinguished Name (DN) can be checked against an access - control list (tls_allowed_dn_list). -
-

- If 'pkipath' is specified in URI, then all the client - certificates must be found in the path specified, otherwise the - connection will fail with a fatal error. If 'pkipath' is not - specified: -

-
    -
  • For a non-root user, libvirt tries to find the certificates - in $HOME/.pki/libvirt first. If the required CA certificate cannot - be found, then the global default location - (/etc/pki/CA/cacert.pem) will be used. - Likewise, if either the client certificate - or the client key cannot be found, then the global default - locations (/etc/pki/libvirt/clientcert.pem, - /etc/pki/libvirt/private/clientkey.pem) will be used. -
    • -
  • For the root user, the global default locations will always be = used.
    • -
-

- Background to TLS certificates -

-

-Libvirt supports TLS certificates for verifying the identity -of the server and clients. There are two distinct checks involved: -

-
    -
  • The client should know that it is connecting to the right -server. Checking done by client by matching the certificate that -the server sends to the server's hostname. May be disabled by adding -?no_verify=3D1 to the -remote URI. -
    • -
  • The server should know that only permitted clients are -connecting. This can be done based on client's IP address, or on -client's IP address and client's certificate. Checking done by the -server. May be enabled and disabled in the libvirtd.conf file. -
    • -
-

-For full certificate checking you will need to have certificates -issued by a recognised Certificate -Authority (CA) for your server(s) and all clients. To avoid the -expense of getting certificates from a commercial CA, you can set up -your own CA and tell your server(s) and clients to trust certificates -issues by your own CA. Follow the instructions in the next section. -

-

-Be aware that the default -configuration for libvirtd allows any client to connect provided -they have a valid certificate issued by the CA for their own IP -address. You may want to change this to make it less (or more) -permissive, depending on your needs. -

-

- Setting up a Certificate Authority (CA) -

-

-You will need the GnuTLS -certtool program documented here. In Fedora, it is in the -gnutls-utils package. -

-

-Create a private key for your CA: -

- 
-certtool --generate-privkey > cakey.pem
-
-

-and self-sign it by creating a file with the -signature details called -ca.info containing: -

- 
-cn =3D Name of your organization
-ca
-cert_signing_key
-
- 
-certtool --generate-self-signed --load-privkey cakey.pem \
-  --template ca.info --outfile cacert.pem
-
-

-(You can delete ca.info file now if you -want). -

-

-Now you have two files which matter: -

-
    -
  • cakey.pem - Your CA's private key (keep this very s= ecret!) -
    • -
  • cacert.pem - Your CA's certificate (this is public). -
    • -
-

cacert.pem has to be installed on clients and -server(s) to let them know that they can trust certificates issued by -your CA. -

-

-The normal installation directory for cacert.pem -is /etc/pki/CA/cacert.pem on all clients and servers. -

-

-To see the contents of this file, do: -

- 
certtool -i --infile cacert.pem
-
-X.509 certificate info:
-
-Version: 3
-Serial Number (hex): 00
-Subject: CN=3DLibvirt Project
-Issuer: CN=3DLibvirt Project
-Signature Algorithm: RSA-SHA
-Validity:
-        Not Before: Mon Jun 18 16:22:18 2007
-        Not After: Tue Jun 17 16:22:18 2008
-[etc]
-
-

-This is all that is required to set up your CA. Keep the CA's private -key carefully as you will need it when you come to issue certificates -for your clients and servers. -

-

- Issuing server certificates= -

-

-For each server (libvirtd) you need to issue a certificate -containing one or more hostnames and/or IP addresses. -Historically the CommonName (CN) field would contain the -hostname of the server and would match the hostname used -in the URI that clients pass to libvirt. In most TLS implementations -the CN field is considered legacy data. The preferential mechanism -is to use Subject Alt Name (SAN) extension fields to validate -against. In the future use of the CN field for validation may be -discontinued entirely, so it is strongly recommended to -include the SAN fields. -

-

-In the example below, clients will be connecting to the -server using a URI of -qemu://compute1.libvirt.org/system, so the CN -must be "compute1.libvirt.org". -

-

-Make a private key for the server: -

- 
-certtool --generate-privkey > serverkey.pem
-
-

-and sign that key with the CA's private key by first -creating a template file called server.info. -The template file will contain a number of fields to define -the server as follows: -

- 
-organization =3D Name of your organization
-cn =3D compute1.libvirt.org
-dns_name =3D compute1
-dns_name =3D compute1.libvirt.org
-ip_address =3D 10.0.0.74
-ip_address =3D 192.168.1.24
-ip_address =3D 2001:cafe::74
-ip_address =3D fe20::24
-tls_www_server
-encryption_key
-signing_key
-
-

-The 'cn' field should refer to the fully qualified public -hostname of the server. For the SAN extension data, there -must also be one or more 'dns_name' fields that contain all -possible hostnames that can be reasonably used by clients -to reach the server, both with and without domain name -qualifiers. If clients are likely to connect to the server -by IP address, then one or more 'ip_address' fields should -also be added. -

-

-Use the template file as input to a certtool -command to sign the server certificate: -

- 
-certtool --generate-certificate --load-privkey serverkey.pem \
-  --load-ca-certificate cacert.pem --load-ca-privkey cakey.pem \
-  --template server.info --outfile servercert.pem
-
-

-This gives two files: -

-
    -
  • serverkey.pem - The server's private key. -
    • -
  • servercert.pem - The server's public key. -
    • -
-

-We can examine this certificate and its signature: -

- 
certtool -i --infile servercert.pem
-X.509 certificate info:
-
-Version: 3
-Serial Number (hex): 00
-Subject: O=3DLibvirt Project,CN=3Dcompute1.libvirt.org
-Issuer: CN=3DLibvirt Project
-Signature Algorithm: RSA-SHA
-Validity:
-        Not Before: Wed Oct 04 09:09:44 UTC 2017
-        Not After: Thu Oct 04 09:09:44 UTC 2018
-Extensions:
-        Basic Constraints (critical):
-                Certificate Authority (CA): FALSE
-        Subject Alternative Name (not critical):
-                DNSname: compute1
-                DNSname: compute1.libvirt.org
-                IPAddress: 10.0.0.74
-                IPAddress: 192.168.1.24
-                IPAddress: 2001:cafe::74
-                IPAddress: fe20::24
-
-

-Note the "Issuer" CN is "Libvirt Project" (the CA) and -the "Subject" CN is "compute1.libvirt.org" (the server). -Notice that the hostname listed in the CN must also -be duplicated as a DNSname entry -

-

-Finally we have two files to install: -

-
    -
  • serverkey.pem is -the server's private key which should be copied to the -server only as -/etc/pki/libvirt/private/serverkey.pem. -
    • -
  • servercert.pem is the server's certificate -which can be installed on the server as -/etc/pki/libvirt/servercert.pem. -
    • -
-

- Issuing client certificates= -

-

-For each client (ie. any program linked with libvirt, such as -virt-manager) -you need to issue a certificate with the X.509 Distinguished Name (DN) -set to a suitable name. You can decide this on a company / organisation -policy. For example: -

- 
-C=3DGB,ST=3DLondon,L=3DLondon,O=3DLibvirt Project,CN=3Dname_of_client
-
-

-The process is the same as for -setting up the -server certificate so here we just briefly cover the -steps. -

-
    -
  1. -Make a private key: -
    -certtool --generate-privkey > clientkey.pem
-
    -
    2. -
  2. -Act as CA and sign the certificate. Create client.info containing: -
    -country =3D GB
-state =3D London
-locality =3D London
-organization =3D Libvirt Project
-cn =3D client1
-tls_www_client
-encryption_key
-signing_key
-
    -and sign by doing: -
    -certtool --generate-certificate --load-privkey clientkey.pem \
-  --load-ca-certificate cacert.pem --load-ca-privkey cakey.pem \
-  --template client.info --outfile clientcert.pem
-
    -
    3. -
  3. -Install the certificates on the client machine: -
    -cp clientkey.pem /etc/pki/libvirt/private/clientkey.pem
-cp clientcert.pem /etc/pki/libvirt/clientcert.pem
-
    -
    4. -
-

- Troubleshooting TLS certificate= problems -

-
-
failed to verify client's certificate
-
-

-On the server side, run the libvirtd server with -the '--listen' and '--verbose' options while the -client is connecting. The verbose log messages should -tell you enough to diagnose the problem. -

-
-
-

You can use the virt-pki-validate shell script -to analyze the setup on the client or server machines, preferably as root. -It will try to point out the possible problems and provide solutions to -fix the set up up to a point where you have secure remote access.

libvirtd configuration file<= /a>

diff --git a/docs/tlscerts.html.in b/docs/tlscerts.html.in new file mode 100644 index 0000000000..3eea686daa --- /dev/null +++ b/docs/tlscerts.html.in @@ -0,0 +1,413 @@ + + + + +

TLS x509 certificate setup

+ +
    + +

    + Public Key Infrastructure set up +

    +

    +If you are unsure how to create TLS certificates, skip to the +next section. +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Location Machine Description Required fields
    + /etc/pki/CA/cacert.pem + Installed on the client and server CA's certificate (more info) + n/a
    + $HOME/.pki/cacert.pem + Installed on the client CA's certificate (more info) + n/a
    + /etc/pki/libvirt/private/serverkey.pem + Installed on the server Server's private key (more info) n/a
    + /etc/pki/libvirt/servercert.pem + Installed on the server Server's certificate signed by the CA. + (more info) CommonName (CN) must be the hostname of the server as it + is seen by clients. All hostname and IP address variants that mi= ght + be used to reach the server should be listed in Subject Alt Name + fields.
    + /etc/pki/libvirt/private/clientkey.pem + Installed on the client Client's private key. (more info) n/a
    + /etc/pki/libvirt/clientcert.pem + Installed on the client Client's certificate signed by the CA + (more info) Distinguished Name (DN) can be checked against an access + control list (tls_allowed_dn_list). +
    + $HOME/.pki/libvirt/clientkey.pem + Installed on the client Client's private key. (more info) n/a
    + $HOME/.pki/libvirt/clientcert.pem + Installed on the client Client's certificate signed by the CA + (more info) Distinguished Name (DN) can be checked against an access + control list (tls_allowed_dn_list). +
    +

    + If 'pkipath' is specified in URI, then all the client + certificates must be found in the path specified, otherwise the + connection will fail with a fatal error. If 'pkipath' is not + specified: +

    +
      +
    • For a non-root user, libvirt tries to find the certificates + in $HOME/.pki/libvirt first. If the required CA certificate cannot + be found, then the global default location + (/etc/pki/CA/cacert.pem) will be used. + Likewise, if either the client certificate + or the client key cannot be found, then the global default + locations (/etc/pki/libvirt/clientcert.pem, + /etc/pki/libvirt/private/clientkey.pem) will be used. +
      • +
    • For the root user, the global default locations will always be = used.
      • +
    +

    + Background to TLS certificates +

    +

    +Libvirt supports TLS certificates for verifying the identity +of the server and clients. There are two distinct checks involved: +

    +
      +
    • The client should know that it is connecting to the right +server. Checking done by client by matching the certificate that +the server sends to the server's hostname. May be disabled by adding +?no_verify=3D1 to the +remote URI. +
      • +
    • The server should know that only permitted clients are +connecting. This can be done based on client's IP address, or on +client's IP address and client's certificate. Checking done by the +server. May be enabled and disabled in the libvirtd.conf file. +
      • +
    +

    +For full certificate checking you will need to have certificates +issued by a recognised Certificate +Authority (CA) for your server(s) and all clients. To avoid the +expense of getting certificates from a commercial CA, you can set up +your own CA and tell your server(s) and clients to trust certificates +issues by your own CA. Follow the instructions in the next section. +

    +

    +Be aware that the default +configuration for libvirtd allows any client to connect provided +they have a valid certificate issued by the CA for their own IP +address. You may want to change this to make it less (or more) +permissive, depending on your needs. +

    +

    + Setting up a Certificate Authority (CA) +

    +

    +You will need the GnuTLS +certtool program documented here. In Fedora, it is in the +gnutls-utils package. +

    +

    +Create a private key for your CA: +

    + 
    +certtool --generate-privkey > cakey.pem
+
    +

    +and self-sign it by creating a file with the +signature details called +ca.info containing: +

    + 
    +cn =3D Name of your organization
+ca
+cert_signing_key
+
    + 
    +certtool --generate-self-signed --load-privkey cakey.pem \
+  --template ca.info --outfile cacert.pem
+
    +

    +(You can delete ca.info file now if you +want). +

    +

    +Now you have two files which matter: +

    +
      +
    • cakey.pem - Your CA's private key (keep this very s= ecret!) +
      • +
    • cacert.pem - Your CA's certificate (this is public). +
      • +
    +

    cacert.pem has to be installed on clients and +server(s) to let them know that they can trust certificates issued by +your CA. +

    +

    +The normal installation directory for cacert.pem +is /etc/pki/CA/cacert.pem on all clients and servers. +

    +

    +To see the contents of this file, do: +

    + 
    certtool -i --infile cacert.pem
+
+X.509 certificate info:
+
+Version: 3
+Serial Number (hex): 00
+Subject: CN=3DLibvirt Project
+Issuer: CN=3DLibvirt Project
+Signature Algorithm: RSA-SHA
+Validity:
+        Not Before: Mon Jun 18 16:22:18 2007
+        Not After: Tue Jun 17 16:22:18 2008
+[etc]
+
    +

    +This is all that is required to set up your CA. Keep the CA's private +key carefully as you will need it when you come to issue certificates +for your clients and servers. +

    +

    + Issuing server certificates= +

    +

    +For each server (libvirtd) you need to issue a certificate +containing one or more hostnames and/or IP addresses. +Historically the CommonName (CN) field would contain the +hostname of the server and would match the hostname used +in the URI that clients pass to libvirt. In most TLS implementations +the CN field is considered legacy data. The preferential mechanism +is to use Subject Alt Name (SAN) extension fields to validate +against. In the future use of the CN field for validation may be +discontinued entirely, so it is strongly recommended to +include the SAN fields. +

    +

    +In the example below, clients will be connecting to the +server using a URI of +qemu://compute1.libvirt.org/system, so the CN +must be "compute1.libvirt.org". +

    +

    +Make a private key for the server: +

    + 
    +certtool --generate-privkey > serverkey.pem
+
    +

    +and sign that key with the CA's private key by first +creating a template file called server.info. +The template file will contain a number of fields to define +the server as follows: +

    + 
    +organization =3D Name of your organization
+cn =3D compute1.libvirt.org
+dns_name =3D compute1
+dns_name =3D compute1.libvirt.org
+ip_address =3D 10.0.0.74
+ip_address =3D 192.168.1.24
+ip_address =3D 2001:cafe::74
+ip_address =3D fe20::24
+tls_www_server
+encryption_key
+signing_key
+
    +

    +The 'cn' field should refer to the fully qualified public +hostname of the server. For the SAN extension data, there +must also be one or more 'dns_name' fields that contain all +possible hostnames that can be reasonably used by clients +to reach the server, both with and without domain name +qualifiers. If clients are likely to connect to the server +by IP address, then one or more 'ip_address' fields should +also be added. +

    +

    +Use the template file as input to a certtool +command to sign the server certificate: +

    + 
    +certtool --generate-certificate --load-privkey serverkey.pem \
+  --load-ca-certificate cacert.pem --load-ca-privkey cakey.pem \
+  --template server.info --outfile servercert.pem
+
    +

    +This gives two files: +

    +
      +
    • serverkey.pem - The server's private key. +
      • +
    • servercert.pem - The server's public key. +
      • +
    +

    +We can examine this certificate and its signature: +

    + 
    certtool -i --infile servercert.pem
+X.509 certificate info:
+
+Version: 3
+Serial Number (hex): 00
+Subject: O=3DLibvirt Project,CN=3Dcompute1.libvirt.org
+Issuer: CN=3DLibvirt Project
+Signature Algorithm: RSA-SHA
+Validity:
+        Not Before: Wed Oct 04 09:09:44 UTC 2017
+        Not After: Thu Oct 04 09:09:44 UTC 2018
+Extensions:
+        Basic Constraints (critical):
+                Certificate Authority (CA): FALSE
+        Subject Alternative Name (not critical):
+                DNSname: compute1
+                DNSname: compute1.libvirt.org
+                IPAddress: 10.0.0.74
+                IPAddress: 192.168.1.24
+                IPAddress: 2001:cafe::74
+                IPAddress: fe20::24
+
    +

    +Note the "Issuer" CN is "Libvirt Project" (the CA) and +the "Subject" CN is "compute1.libvirt.org" (the server). +Notice that the hostname listed in the CN must also +be duplicated as a DNSname entry +

    +

    +Finally we have two files to install: +

    +
      +
    • serverkey.pem is +the server's private key which should be copied to the +server only as +/etc/pki/libvirt/private/serverkey.pem. +
      • +
    • servercert.pem is the server's certificate +which can be installed on the server as +/etc/pki/libvirt/servercert.pem. +
      • +
    +

    + Issuing client certificates= +

    +

    +For each client (ie. any program linked with libvirt, such as +virt-manager) +you need to issue a certificate with the X.509 Distinguished Name (DN) +set to a suitable name. You can decide this on a company / organisation +policy. For example: +

    + 
    +C=3DGB,ST=3DLondon,L=3DLondon,O=3DLibvirt Project,CN=3Dname_of_client
+
    +

    +The process is the same as for +setting up the +server certificate so here we just briefly cover the +steps. +

    +
      +
    1. +Make a private key: +
      +certtool --generate-privkey > clientkey.pem
+
      +
      2. +
    2. +Act as CA and sign the certificate. Create client.info containing: +
      +country =3D GB
+state =3D London
+locality =3D London
+organization =3D Libvirt Project
+cn =3D client1
+tls_www_client
+encryption_key
+signing_key
+
      +and sign by doing: +
      +certtool --generate-certificate --load-privkey clientkey.pem \
+  --load-ca-certificate cacert.pem --load-ca-privkey cakey.pem \
+  --template client.info --outfile clientcert.pem
+
      +
      3. +
    3. +Install the certificates on the client machine: +
      +cp clientkey.pem /etc/pki/libvirt/private/clientkey.pem
+cp clientcert.pem /etc/pki/libvirt/clientcert.pem
+
      +
      4. +
    +

    + Troubleshooting TLS certificate= problems +

    +
    +
    failed to verify client's certificate
    +
    +

    +On the server side, run the libvirtd server with +the '--listen' and '--verbose' options while the +client is connecting. The verbose log messages should +tell you enough to diagnose the problem. +

    +
    +
    +

    You can use the virt-pki-validate shell script +to analyze the setup on the client or server machines, preferably as root. +It will try to point out the possible problems and provide solutions to +fix the set up up to a point where you have secure remote access.

    + + --=20 2.23.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sat Apr 20 01:15:02 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) client-ip=207.211.31.81; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1574434054; cv=none; d=zohomail.com; s=zohoarc; b=iNLNDe+wuww/5nyZotcfZrB55KH/uiWHkQsiD+8vIHJxUuPTWkuLIL2Ce4cyrcAbgy7vYjeyqVSNh9gz07brmAIFpGb+gq/wsUKODaQiRU5ErXU7WdMvp9Dvjak4ks/W72T2guOoKgvJcUZlCcRd6BRANs2wwClxir+ejjgx/wY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1574434054; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=vCqJz4RFw9l+aZdPglKVaOiLRx5rbjFveJOcJvVitAY=; b=EbwkiBgWsGB8nwAzi94z/W+6YT5Ikae4UY9c7TbRJ6zxT75rvWVLwakhYCnT3BzbUkkjyEpwXdrTzCjqZFolVRbItVhGtiVHTCiKE0+izCgpaDuhB5iT0rq3MGFMg00NW0ket3OgtEMMNayNHLbwGp0kaqCe54EQJdDIv/QDiYg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by mx.zohomail.com with SMTPS id 1574434054674908.7682684002694; Fri, 22 Nov 2019 06:47:34 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-145-4ArhzFHCMySFNsx8JyO8jw-1; Fri, 22 Nov 2019 09:47:31 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0D1EEDB62; Fri, 22 Nov 2019 14:47:25 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C117D7700A; Fri, 22 Nov 2019 14:47:24 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 343714E56C; Fri, 22 Nov 2019 14:47:24 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id xAMElCLI017854 for ; Fri, 22 Nov 2019 09:47:12 -0500 Received: by smtp.corp.redhat.com (Postfix) id AA1B51036C8C; Fri, 22 Nov 2019 14:47:12 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-112-49.ams2.redhat.com [10.36.112.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9FB961036C7E; Fri, 22 Nov 2019 14:47:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574434053; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=vCqJz4RFw9l+aZdPglKVaOiLRx5rbjFveJOcJvVitAY=; b=A4iCB7tv2oM+07p9C/uM4vGWMsp6+QXEXbu51QAX+VKMZeQg0gcYyaBEeKiqF/jEZnbH1c YYUpesVK2aYKhmuJrnfjnN/8ZFfUKQZu+y5EC1ZTAgWkfm6VHTTB8SBcYPqS+Tmv8Y6fUa Xa6NtmpAzbNBNuTvYENW0PYwwNqjP9M= From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: libvir-list@redhat.com Date: Fri, 22 Nov 2019 14:46:49 +0000 Message-Id: <20191122144702.3780548-3-berrange@redhat.com> In-Reply-To: <20191122144702.3780548-1-berrange@redhat.com> References: <20191122144702.3780548-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 02/15] docs: move docs about remote driver URIs into URI docs X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: 4ArhzFHCMySFNsx8JyO8jw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) The docs about remote URIs in uri.html are somewhat sparse with the full docs being in remote.html. Move all the URI content from remote.html into uri.html so the user only needs to look in one place for URI info. Signed-off-by: Daniel P. Berrang=C3=A9 Reviewed-by: Michal Privoznik --- docs/remote.html.in | 278 +------------------------------------------- docs/uri.html.in | 263 ++++++++++++++++++++++++++++++++++++----- 2 files changed, 238 insertions(+), 303 deletions(-) diff --git a/docs/remote.html.in b/docs/remote.html.in index 5a0ebe4790..0b0dc87f6f 100644 --- a/docs/remote.html.in +++ b/docs/remote.html.in @@ -34,7 +34,7 @@ the system-wide QEMU daemon on a remote machine called qemu://compute1.libvirt.org/system.

    -The section on remote URIs +The section on remote URIs describes in more detail these remote URIs.

    @@ -109,279 +109,9 @@ even with graphical management applications. As with = the classic ssh transport netcat is required on the remote side.

    -The default transport, if no other is specified, is tls. -

    -

    - Remote URIs -

    -

    -See also: documentation on ordinary ("local") URIs. -

    -

    -Remote URIs have the general form ("[...]" meaning an optional part): -

    -

    driver[+transport]://[= username@][hostname][:port]/[= path][?extraparameters] -

    -

    -Either the transport or the hostname must be given in order -to distinguish this from a local URI. -

    -

    -Some examples: -

    -
      -
    • xen+ssh://rjones@towada/system
      — Connec= t to a -remote Xen hypervisor on host towada using ssh transport and = ssh -username rjones. -
      • -
    • xen://towada/system
      — Connect to a -remote Xen hypervisor on host towada using TLS. -
      • -
    • xen://towada/system?no_verify=3D1
      — Con= nect to a -remote Xen hypervisor on host towada using TLS. Do not verify -the server's certificate. -
      • -
    • qemu+unix:///system?socket=3D/opt/libvirt/run/libvirt/libv= irt-sock
      — -Connect to the local qemu instances over a non-standard -Unix socket (the full path to the Unix socket is -supplied explicitly in this case). -
      • -
    • test+tcp://localhost:5000/default
      — -Connect to a libvirtd daemon offering unencrypted TCP/IP connections -on localhost port 5000 and use the test driver with default -settings. -
      • -
    • qemu+libssh2://user@host/system?known_hosts=3D/home/user/.ssh/kn= own_hosts
      — -Connect to a remote host using a ssh connection with the libssh2 driver -and use a different known_hosts file.
      • -
    • qemu+libssh://user@host/system?known_hosts=3D/home/user/.ssh/kno= wn_hosts
      — -Connect to a remote host using a ssh connection with the libssh driver -and use a different known_hosts file.
      • -
    -

    - Extra parameters -

    -

    -Extra parameters can be added to remote URIs as part -of the query string (the part following ?). -Remote URIs understand the extra parameters shown below. -Any others are passed unmodified through to the back end. -Note that parameter values must be -URI-es= caped. -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Name Transports Meaning
    - name - - any transport - - The name passed to the remote virConnectOpen function. The - name is normally formed by removing transport, hostname, port - number, username and extra parameters from the remote URI, but in certain - very complex cases it may be better to supply the name explicitly. -
    - Example: name=3Dqemu:///system
    - tls_priority - tls - A vaid GNUTLS priority string -
    - Example: tls_priority=3DNORMAL:-VERS-SSL3.0
    - mode - unix, ssh, libssh, libssh2 -
    -
    auto
    automatically determine the daem= on
    -
    direct
    connect to per-driver daemons<= /dd> -
    legacy
    connect to libvirtd
    -
    - Can also be set in libvirt.conf as remote_mod= e -
    - Example: mode=3Ddirect
    - command - ssh, ext - The external command. For ext transport this is required. - For ssh the default is ssh. - The PATH is searched for the command. -
    - Example: command=3D/opt/openssh/bin/ssh
    - socket - unix, ssh, libssh2, libssh - The path to the Unix domain socket, which overrides the - compiled-in default. For ssh transport, this is passed to - the remote netcat command (see next). -
    - Example: socket=3D/opt/libvirt/run/libvirt/libvirt-sock=
    - netcat - ssh, libssh2, libssh - The name of the netcat command on the remote machine. - The default is nc. For ssh transport, libvirt - constructs an ssh command which looks like: - -
    command -p port [-l username] hostname netcat -U socket
-
    - - where port, username, hostname can be - specified as part of the remote URI, and command, netcat - and socket come from extra parameters (or - sensible defaults). - -
    - Example: netcat=3D/opt/netcat/bin/nc
    - keyfile - ssh, libssh2, libssh - The name of the private key file to use to authentication to the remote - machine. If this option is not used the default keys are used. -
    - Example: keyfile=3D/root/.ssh/example_key
    - no_verify - ssh, tls - SSH: If set to a non-zero value, this disables client's strict host key - checking making it auto-accept new host keys. Existing host keys will - still be validated. -
    -
    - TLS: If set to a non-zero value, this disables client checks of the - server's certificate. Note that to disable server checks of - the client's certificate or IP address you must - change the libvirtd - configuration. -
    - Example: no_verify=3D1
    - no_tty - ssh - If set to a non-zero value, this stops ssh from asking for - a password if it cannot log in to the remote machine automatically - (eg. using ssh-agent etc.). Use this when you don't have access - to a terminal - for example in graphical programs which use libvirt. -
    - Example: no_tty=3D1
    - pkipath - tls - Specifies x509 certificates path for the client. If any of - the CA certificate, client certificate, or client key is - missing, the connection will fail with a fatal error. -
    - Example: pkipath=3D/tmp/pki/client
    - known_hosts - libssh2, libssh - Path to the known_hosts file to verify the host key against. LibSSH2 and - libssh support OpenSSH-style known_hosts files, although LibSSH2 does not - support all key types, so using files created by the OpenSSH binary may - result into truncating the known_hosts file. Thus, with LibSSH2 it's - recommended to use the default known_hosts file is located in libvirt's - client local configuration directory e.g.: ~/.config/libvirt/known_hosts. - Note: Use absolute paths. -
    - Example: known_hosts=3D/root/.ssh/known_hosts -
    - sshauth - libssh2, libssh - A comma separated list of authentication methods to use. Default (is - "agent,privkey,password,keyboard-interactive". The order of the methods - is preserved. Some methods may require additional parameters. -
    - Example: sshauth=3Dprivkey,agent
    + The choice of transport is determined by the URI scheme, + with tls as the default if no explicit transport is req= uested. +

    libvirtd configuration file<= /a>

    diff --git a/docs/uri.html.in b/docs/uri.html.in index 6da9eb9746..49f92773f8 100644 --- a/docs/uri.html.in +++ b/docs/uri.html.in @@ -153,65 +153,270 @@ here. Remote URIs

    -Remote URIs are formed by taking ordinary local URIs and adding a -hostname and/or transport name. As a special case, using a URI -scheme of 'remote', will tell the remote libvirtd server to probe -for the optimal hypervisor driver. This is equivalent to passing -a NULL URI for a local connection. For example: +Remote URIs have the general form ("[...]" meaning an optional part): +

    +

    driver[+transport]://[= username@][hostname][:port]/[= path][?extraparameters] +

    +

    +Either the transport or the hostname must be given in order +to distinguish this from a local URI. +

    +

    +Some examples: +

    +
      +
    • xen+ssh://rjones@towada/system
      — Connec= t to a +remote Xen hypervisor on host towada using ssh transport and = ssh +username rjones. +
      • +
    • xen://towada/system
      — Connect to a +remote Xen hypervisor on host towada using TLS. +
      • +
    • xen://towada/system?no_verify=3D1
      — Con= nect to a +remote Xen hypervisor on host towada using TLS. Do not verify +the server's certificate. +
      • +
    • qemu+unix:///system?socket=3D/opt/libvirt/run/libvirt/libv= irt-sock
      — +Connect to the local qemu instances over a non-standard +Unix socket (the full path to the Unix socket is +supplied explicitly in this case). +
      • +
    • test+tcp://localhost:5000/default
      — +Connect to a libvirtd daemon offering unencrypted TCP/IP connections +on localhost port 5000 and use the test driver with default +settings. +
      • +
    • qemu+libssh2://user@host/system?known_hosts=3D/home/user/.ssh/kn= own_hosts
      — +Connect to a remote host using a ssh connection with the libssh2 driver +and use a different known_hosts file.
      • +
    • qemu+libssh://user@host/system?known_hosts=3D/home/user/.ssh/kno= wn_hosts
      — +Connect to a remote host using a ssh connection with the libssh driver +and use a different known_hosts file.
      • +
    +

    + Extra parameters +

    +

    +Extra parameters can be added to remote URIs as part +of the query string (the part following ?). +Remote URIs understand the extra parameters shown below. +Any others are passed unmodified through to the back end. +Note that parameter values must be +URI-es= caped.

    - - + + - + + + + + + + + + + + + + - + + + + + + + + + + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - + + + + +
    Local URI Remote URI Name Transports Meaning
    - xen:///system + name - xen://oirase/system + any transport Connect to the Xen hypervisor running on host oirase - using TLS. + The name passed to the remote virConnectOpen function. The + name is normally formed by removing transport, hostname, port + number, username and extra parameters from the remote URI, but in certain + very complex cases it may be better to supply the name explicitly. +
    + Example: name=3Dqemu:///system
    - NULL + tls_priority tls - remote://oirase/ + A vaid GNUTLS priority string +
    + Example: tls_priority=3DNORMAL:-VERS-SSL3.0
    + mode + unix, ssh, libssh, libssh2 +
    +
    auto
    automatically determine the daem= on
    +
    direct
    connect to per-driver daemons<= /dd> +
    legacy
    connect to libvirtd
    +
    + Can also be set in libvirt.conf as remote_mod= e     		Connect to the "default" hypervisor running on host oir= ase - using TLS.
    + Example: mode=3Ddirect
    - xen:///system + command ssh, ext - xen+ssh://oirase/system + The external command. For ext transport this is required. + For ssh the default is ssh. + The PATH is searched for the command. +
    + Example: command=3D/opt/openssh/bin/ssh
    + socket Connect to the Xen hypervisor running on host oirase - by going over an ssh connection. unix, ssh, libssh2, libssh + The path to the Unix domain socket, which overrides the + compiled-in default. For ssh transport, this is passed to + the remote netcat command (see next). +
    + Example: socket=3D/opt/libvirt/run/libvirt/libvirt-sock=
    - test:///default + netcat ssh, libssh2, libssh - test+tcp://oirase/default + The name of the netcat command on the remote machine. + The default is nc. For ssh transport, libvirt + constructs an ssh command which looks like: + +
    command -p port [-l username] hostname netcat -U socket
+
    + + where port, username, hostname can be + specified as part of the remote URI, and command, netcat + and socket come from extra parameters (or + sensible defaults). + +
    + Example: netcat=3D/opt/netcat/bin/nc
    + keyfile + ssh, libssh2, libssh + The name of the private key file to use to authentication to the remote + machine. If this option is not used the default keys are used. +
    + Example: keyfile=3D/root/.ssh/example_key
    + no_verify + ssh, tls + SSH: If set to a non-zero value, this disables client's strict host key + checking making it auto-accept new host keys. Existing host keys will + still be validated. +
    +
    + TLS: If set to a non-zero value, this disables client checks of the + server's certificate. Note that to disable server checks of + the client's certificate or IP address you must + change the libvirtd + configuration. +
    + Example: no_verify=3D1
    + no_tty + ssh + If set to a non-zero value, this stops ssh from asking for + a password if it cannot log in to the remote machine automatically + (eg. using ssh-agent etc.). Use this when you don't have access + to a terminal - for example in graphical programs which use libvirt. +
    + Example: no_tty=3D1
    + pkipath + tls + Specifies x509 certificates path for the client. If any of + the CA certificate, client certificate, or client key is + missing, the connection will fail with a fatal error. +
    + Example: pkipath=3D/tmp/pki/client
    + known_hosts + libssh2, libssh + Path to the known_hosts file to verify the host key against. LibSSH2 and + libssh support OpenSSH-style known_hosts files, although LibSSH2 does not + support all key types, so using files created by the OpenSSH binary may + result into truncating the known_hosts file. Thus, with LibSSH2 it's + recommended to use the default known_hosts file is located in libvirt's + client local configuration directory e.g.: ~/.config/libvirt/known_hosts. + Note: Use absolute paths. +
    + Example: known_hosts=3D/root/.ssh/known_hosts +
    + sshauth Connect to the test driver on host oirase - using an unsecured TCP connection. libssh2, libssh + A comma separated list of authentication methods to use. Default (is + "agent,privkey,password,keyboard-interactive". The order of the methods + is preserved. Some methods may require additional parameters. +
    + Example: sshauth=3Dprivkey,agent
    -

    -Remote URIs in libvirt offer a rich syntax and many features. -We refer you to the libvirt -remote URI reference and full documentation -for libvirt remote support. -

    test:///... Test URIs

    --=20 2.23.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sat Apr 20 01:15:02 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) client-ip=205.139.110.61; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1574434051; cv=none; d=zohomail.com; s=zohoarc; b=PPh6ABkz+AhrU9K63WqzrUc8pJjWUCUM3IkPYn73bzoIRvx8B2cSAk7Kr5fMFqmtqYa//+kKOmVFpa8qF+l5F1QloIxjn8q7tJiV7JnWFySPWQ/he9rSxLBVM8qioiieuByHt9H9ZCZebVYdl4a9+809rQWxxau/iqTkBiyCFXg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1574434051; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=Ix9YVtjPSWAlqmKH0BRfZrvVMRXgIKnoj1vxeYVvHvc=; b=NT9hirtxTj+gBi9qo9Abylab0thx8viHm4xaJads8Wpl0gQ3dx3xhFhvQ67Qe9xTQQWmykO6QHKq6YGsZkrr0vPA4FK9lnBfj6mM98YnqGDCo7zVvxzBpFccbsoih9FeJYLgjKEADb+iPq+/Ca3mShEo4wV0NWpB0MlDfMhjywg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by mx.zohomail.com with SMTPS id 1574434051908930.6182812284491; Fri, 22 Nov 2019 06:47:31 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-428-XW4MuxBIMzeCarZBatqh6w-1; Fri, 22 Nov 2019 09:47:26 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A9509107ACCA; Fri, 22 Nov 2019 14:47:20 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7132F2AAB1; Fri, 22 Nov 2019 14:47:20 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id E27AE4E562; Fri, 22 Nov 2019 14:47:19 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id xAMElHlZ017864 for ; Fri, 22 Nov 2019 09:47:17 -0500 Received: by smtp.corp.redhat.com (Postfix) id B63831036C83; Fri, 22 Nov 2019 14:47:17 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-112-49.ams2.redhat.com [10.36.112.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id 084BF1036C7E; Fri, 22 Nov 2019 14:47:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574434050; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=Ix9YVtjPSWAlqmKH0BRfZrvVMRXgIKnoj1vxeYVvHvc=; b=MfuVXQv9F5jTAS+J4y5NEvlcul2CjN9+IPkpLxua4GHM4CtUK8iodWrY+i8wdl1vSGxXkk VTTLpZCVdG2Wwu27FF02fB7r782geloXHk2oUMpdpaHmc0SM3YCZly3epQCk73tTSNewAA 7SXfWjPnpKlrkvugtPkWeIntT9rsnBE= From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: libvir-list@redhat.com Date: Fri, 22 Nov 2019 14:46:50 +0000 Message-Id: <20191122144702.3780548-4-berrange@redhat.com> In-Reply-To: <20191122144702.3780548-1-berrange@redhat.com> References: <20191122144702.3780548-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 03/15] docs: introduce rst2html as a mandatory tool for building docs X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: XW4MuxBIMzeCarZBatqh6w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) The rst2html tool is provided by python docutils, and as the name suggests, it converts RST documents into HTML. Basic rules are added for integrating RST docs into the website build process. This enables us to start writing docs on our website in RST format instead of HTML, without changing the rest of our website templating system away from XSLT yet. Signed-off-by: Daniel P. Berrang=C3=A9 Reviewed-by: Michal Privoznik --- docs/Makefile.am | 33 +++++++++++++++++++++++++++------ libvirt.spec.in | 2 ++ m4/virt-external-programs.m4 | 5 +++++ mingw-libvirt.spec.in | 1 + 4 files changed, 35 insertions(+), 6 deletions(-) diff --git a/docs/Makefile.am b/docs/Makefile.am index 2a104bc837..7a8adbde2b 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -173,14 +173,26 @@ gif =3D \ =20 internals_html_in =3D \ $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/internals/*.html.in)) -internals_html =3D $(internals_html_in:%.html.in=3D%.html) +kbase_rst =3D \ + $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/kbase/*.rst)) +kbase_rst_html_in =3D \ + $(kbase_rst:%.rst=3D%.html.in) +internals_html =3D \ + $(internals_html_in:%.html.in=3D%.html) \ + $(internals_rst_html_in:%.html.in=3D%.html) =20 internalsdir =3D $(HTML_DIR)/internals internals_DATA =3D $(internals_html) =20 kbase_html_in =3D \ $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/kbase/*.html.in)) -kbase_html =3D $(kbase_html_in:%.html.in=3D%.html) +kbase_rst =3D \ + $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/kbase/*.rst)) +kbase_rst_html_in =3D \ + $(kbase_rst:%.rst=3D%.html.in) +kbase_html =3D \ + $(kbase_html_in:%.html.in=3D%.html) \ + $(kbase_rst_html_in:%.html.in=3D%.html) =20 kbasedir =3D $(HTML_DIR)/kbase kbase_DATA =3D $(kbase_html) @@ -191,9 +203,14 @@ dot_html_generated_in =3D \ news.html.in dot_html_in =3D \ $(notdir $(wildcard $(srcdir)/*.html.in)) +dot_rst =3D \ + $(notdir $(wildcard $(srcdir)/*.rst)) +dot_rst_html_in =3D \ + $(dot_rst:%.rst=3D%.html) dot_html =3D \ $(dot_html_generated_in:%.html.in=3D%.html) \ - $(dot_html_in:%.html.in=3D%.html) + $(dot_html_in:%.html.in=3D%.html) \ + $(dot_rst_html_in:%.html.in=3D%.html) =20 htmldir =3D $(HTML_DIR) html_DATA =3D $(css) $(png) $(gif) $(dot_html) @@ -222,11 +239,11 @@ EXTRA_DIST=3D \ apibuild.py genaclperms.pl \ site.xsl subsite.xsl newapi.xsl page.xsl \ wrapstring.xsl \ - $(dot_html_in) $(gif) $(apipng) \ + $(dot_html_in) $(dot_rst) $(gif) $(apipng) \ $(fig) $(png) $(css) \ $(javascript) $(logofiles) \ - $(internals_html_in) $(fonts) \ - $(kbase_html_in) \ + $(internals_html_in) $(internals_rst) $(fonts) \ + $(kbase_html_in) $(kbase_rst) \ aclperms.htmlinc \ hvsupport.pl \ $(schema_DATA) @@ -281,6 +298,10 @@ EXTRA_DIST +=3D \ %.png: %.fig convert -rotate 90 $< $@ =20 +%.html.in: %.rst + $(AM_V_GEN)$(MKDIR_P) `dirname $@` && \ + $(RST2HTML) $< > $@ + %.html.tmp: %.html.in site.xsl subsite.xsl page.xsl \ $(acl_generated) $(AM_V_GEN)name=3D`echo $@ | sed -e 's/.tmp//'`; \ diff --git a/libvirt.spec.in b/libvirt.spec.in index a6219da604..5c47dd3d7c 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -265,6 +265,8 @@ BuildRequires: automake BuildRequires: gettext-devel BuildRequires: libtool BuildRequires: /usr/bin/pod2man +# Replace with python3-docutils when we drop py2 support +BuildRequires: /usr/bin/rst2html %endif BuildRequires: gcc BuildRequires: git diff --git a/m4/virt-external-programs.m4 b/m4/virt-external-programs.m4 index 0f995998c3..ed634a4c73 100644 --- a/m4/virt-external-programs.m4 +++ b/m4/virt-external-programs.m4 @@ -33,6 +33,11 @@ AC_DEFUN([LIBVIRT_CHECK_EXTERNAL_PROGRAMS], [ then AC_MSG_ERROR("xsltproc is required to build libvirt") fi + AC_PATH_PROGS([RST2HTML], [rst2html rst2html.py rst2html-3], []) + if test -z "$RST2HTML" + then + AC_MSG_ERROR("rst2html is required to build libvirt") + fi AC_PATH_PROG([AUGPARSE], [augparse], [/usr/bin/augparse]) AC_PROG_MKDIR_P AC_PROG_LN_S diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in index c29f3eeed2..35f1abc13d 100644 --- a/mingw-libvirt.spec.in +++ b/mingw-libvirt.spec.in @@ -82,6 +82,7 @@ BuildRequires: automake BuildRequires: gettext-devel BuildRequires: libtool %endif +BuildRequires: python3-docutils =20 BuildRequires: mingw32-libssh2 BuildRequires: mingw64-libssh2 --=20 2.23.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list From nobody Sat Apr 20 01:15:02 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) client-ip=205.139.110.61; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1574434059; cv=none; d=zohomail.com; s=zohoarc; b=BPzdljBSnC5HfdZAI1NMAlOiNHz9U860zx1inG+NHvkaJ0patMNaIrE0sEiV+a6QQxP6F5ILeJ1eM60EJGPAeJBOermDwRAwtqFHeyDfWZE3j9W/1lFFzZB/DGG9AAVoYMyky84AplADq4xd8c1o2yAyVxv6FE9G3nrVBqztExE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1574434059; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=7w48HMxjF4M+JHNCiTFXp+BK11B/46k/U9Jv6Qb+Rys=; b=S1ZYNrmUpPA3fi/Wsjy+TBQKe3jyDBHv80pBH6rrqzSKlC8RvRTlNTpUe4sDiJyfTsRC/dDbjy5fAYiTYpafM4giPsB4ruoFd6nwQIdVSx0G2b1aQrApOFNEJbdT9EMu25R+fAPhmdLxawSv8FeEtA7i6vqsnq0O/bFBZ9Rin9I= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by mx.zohomail.com with SMTPS id 1574434059080873.3959638410832; Fri, 22 Nov 2019 06:47:39 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-176-i8a-_vprNgaiFehH_gBCqw-1; Fri, 22 Nov 2019 09:47:36 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 456A2107ACC9; Fri, 22 Nov 2019 14:47:30 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0476263742; Fri, 22 Nov 2019 14:47:30 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 9860E18089CE; Fri, 22 Nov 2019 14:47:29 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id xAMElKbp017874 for ; Fri, 22 Nov 2019 09:47:20 -0500 Received: by smtp.corp.redhat.com (Postfix) id 4D1FD1036C83; Fri, 22 Nov 2019 14:47:20 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-112-49.ams2.redhat.com [10.36.112.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id 12EDC1036C7E; Fri, 22 Nov 2019 14:47:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574434057; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=7w48HMxjF4M+JHNCiTFXp+BK11B/46k/U9Jv6Qb+Rys=; b=ED9N86xjp6292we3YJJ9nAhZ0+tVRF6CoETiMQ3qVqBB8KKttpW7C9hvKTjXJmAKEppM+a gnkJNfafqDmQf7uMkv8x3zq1YA2Zt8lggl7Bl+t5fXGvARn3zTrFt2qosur/JpHFaE9Lge ZPJxedgFoDC3p/S9D5EEJkwBFdpExJs= From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: libvir-list@redhat.com Date: Fri, 22 Nov 2019 14:46:51 +0000 Message-Id: <20191122144702.3780548-5-berrange@redhat.com> In-Reply-To: <20191122144702.3780548-1-berrange@redhat.com> References: <20191122144702.3780548-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH v2 04/15] docs: adapt filling of section for rst2html output X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-MC-Unique: i8a-_vprNgaiFehH_gBCqw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) The HTML from rst2html doesn't have

    immediately under the tag, instead there is at least one
    in between. There are also many things added in the section that we don't want to have copied over, since our templating system already adds suitable elements. We only need to copy the