1
0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-10-19 07:33:46 +03:00

* NEWS virsh.1 docs//* include/libvirt/libvirt.h[.in] qemud/mdns.h

src/libvirt.c src/qemu.conf src/remote_internal.c src/xend_internal.c
  tests/confdata/libvirtd.conf tests/confdata/libvirtd.out: patch from
  Atsushi SAKAI fixing a ot more typo
Daniel
This commit is contained in:
Daniel Veillard
2008-03-17 10:27:31 +00:00
parent 7ae13660cf
commit 08ecf61b35
22 changed files with 111 additions and 104 deletions

View File

@@ -11,11 +11,11 @@ of applications using libvirt.
<li><a href="#ACL_server_username">Username/password auth</a></li>
<li><a href="#ACL_server_kerberos">Kerberos auth</a></li>
</ul><h3 name="ACL_server_config">Server configuration</h3><p>
The libvirt daemon allows the adminstrator to choose the authentication
mechanisms used for client connections on each network socket independantly.
The libvirt daemon allows the administrator to choose the authentication
mechanisms used for client connections on each network socket independently.
This is primarily controlled via the libvirt daemon master config file in
<code>/etc/libvirt/libvirtd.conf</code>. Each of the libvirt sockets can
have its authentication mechanism configured independantly. There is
have its authentication mechanism configured independently. There is
currently a choice of <code>none</code>, <code>polkit</code>, and <code>sasl</code>.
The SASL scheme can be further configured to choose between a large
number of different mechanisms.
@@ -44,7 +44,7 @@ session to authenticate using the user's password. This is akin to <code>sudo</c
auth, but does not require that the client application ultimately run as root.
Default policy will still allow any application to connect to the RO socket.
</p><p>
The default policy can be overriden by the adminstrator using the PolicyKit
The default policy can be overriden by the administrator using the PolicyKit
master configuration file in <code>/etc/PolicyKit/PolicyKit.conf</code>. The
<code>PolicyKit.conf(5)</code> manual page provides details on the syntax
available. The two libvirt daemon actions available are named <code>org.libvirt.unix.monitor</code>
@@ -100,7 +100,7 @@ and/or TLS sockets, Kerberos will also be used for them. Like DIGEST-MD5, the Ke
mechanism provides data encryption of the session.
</p><p>
Some operating systems do not install the SASL kerberos plugin by default. It
may be neccessary to install a sub-package such as <code>cyrus-sasl-gssapi</code>.
may be necessary to install a sub-package such as <code>cyrus-sasl-gssapi</code>.
To check whether the Kerberos plugin is installed run the <code>pluginviewer</code>
program and verify that <code>gssapi</code> is listed,eg:
</p><pre>
@@ -111,7 +111,7 @@ Plugin "gssapiv2" [loaded], API version: 4
security flags: NO_ANONYMOUS|NO_PLAINTEXT|NO_ACTIVE|PASS_CREDENTIALS|MUTUAL_AUTH
features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION|NEED_SERVER_FQDN
</pre><p>
Next is is neccessary for the adminsitrator of the Kerberos realm to issue a principle
Next is is necessary for the adminsitrator of the Kerberos realm to issue a principle
for the libvirt server. There needs to be one principle per host running the libvirt
daemon. The principle should be named <code>libvirt/full.hostname@KERBEROS.REALM</code>.
This is typically done by running the <code>kadmin.local</code> command on the Kerberos