Problem is, localtime_r() returns a pointer to converted time or
NULL in case of an error. But checking the glibc sources, error
will occur iff a NULL has been passed as an either of arguments
the function takes. But GCC fails to see that:
../../tools/virsh-network.c: In function 'cmdNetworkDHCPLeases':
../../tools/virsh-network.c:1370:12: error: potential null pointer dereference [-Werror=null-dereference]
ts = *localtime_r(&expirytime_tmp, &ts);
~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
On LXC domain startup we have already called virDomainObjSetDefTransient
to fill vm->newDef.
There is no need to call virDomainLiveConfigHelperMethod which has the
ability to fill newDef if it's NULL.
On LXC domain startup we have already called virDomainObjSetDefTransient
to fill vm->newDef.
There is no need to call virDomainLiveConfigHelperMethod which has the
ability to fill newDef if it's NULL.
On LXC domain startup we have already called virDomainObjSetDefTransient
to fill vm->newDef.
There is no need to call virDomainLiveConfigHelperMethod which has the
ability to fill newDef if it's NULL.
A few functions using virDomainLiveConfigHelperMethod use the generic
name 'vmdef' to point to the persistent definition.
Use persistentDef and/or persistentDefCopy to make its purpose obvious.
In Fedora >= 21, there is a new crypto priority framework
that sets TLS policies globally for all apps. To activate
this with GNUTLS we must request "@SYSTEM" instead of
the traditional "NORMAL" string. The '@' causes gnutls todo
a lookup in its config file for the 'SYSTEM' keyword entry.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Support reading the TLS priority from the client configuration
file via the "tls_priority" config option, eg
$ cat $HOME/.config/libvirt/libvirt.conf
tls_priority="NORMAL:-VERS-SSL3.0"
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The virConnectOpenInternal method opens the libvirt client
config file and uses it to resolve things like URI aliases.
There may be driver specific things that are useful to
store in the config file too, so rather than have them
re-parse the same file, pass the virConfPtr down to the
drivers.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add support for a "tls_priority" URI parameter in remote
driver URIs. eg
qemu+tls://localhost/session?tls_priority=NORMAL:-VERS-SSL3.0
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add a "tls_priority" config option to /etc/libvirt/libvirtd.conf
to allow the administrator to override the built-in default
setting. This only affects the server side configuration.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Extend the virNetTLSContextNew* constructors to allow
the TLS priority string to be passed in, overriding the
compile time default.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently libvirt calls gnutls_set_default_priority()
which on old systems resolves to "NORMAL" while new
systems it resolves to "@SYSTEM". Either way, this
is a global default that is identical across all apps.
We want to allow distros to flexibility to define a
custom default string for libvirt priority, so add
a --tls-priority=STRING flag to configure to enable
this to be set.
It is expected that distros would use this when creating
RPM/Deb/etc packages, according to their preferred crypto
handling policies.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently we set the gnutls log function when creating a
TLS context, however, the setting is in fact global, not
per context. So we should be setting it when we first call
gnutls_global_init() instead.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
We need to use the gnutls_priority_set_direct method which
was not introduced until 2.1.7, so bump version to 2.2.0
which is the first stable release with it included. This
release dates from Dec 2007 so it is reasonable to ditch
support for the 1.x.x series for gnutls releases entirely.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently if a guest has listen address 0.0.0.0 or [::] and you run
"virsh domdisplay $domain" you always get "spice://localhost:$port".
We want to print better address if someone is connected from a different
computer using "virsh -c qemu+ssh://some.host/system". This patch fixes the
behavior of virsh to print in this case "spice://some.host:$port".
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1332446
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
We use libxml2 APIs in the test (e.g. xmlFreeDoc) but not link
with -lxml2 which can cause problems:
/usr/bin/ld: virschematest.o: undefined reference to symbol 'xmlFreeDoc@@LIBXML2_2.4.30'
//usr/lib/x86_64-linux-gnu/libxml2.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:4702: recipe for target 'virschematest' failed
Reported-by: Katerina Koukiou <k.koukiou@googlemail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
So the story goes like this. The testSchemaDirs() function is
called with: a) the schema file, b) list of the directories that
contains XMLs documents that should be checked against the schema
file from a). However, the directories in the list are really
just their names and it's up to testSchemaDirs to construct the
absolute path and call testSchemaDir() which then does the actual
validation. The absolute path is constructed, but never actually
used (maybe due to a typo). Thus a VPATH build is broken.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
In commit 1e38ef72 the disk startup policy check was moved prior to the
call to virDomainObjSetDefTransient which dropped the disk from the
config rather than the def to be started which is a bug.
Additionally we'd not report the disk change event for this since the
disk aliases were not set at that point.
Finally 'volume' based disks would not work with startup policy too.
Fix it by moving it back after the definition is copied, aliases are
assigned and disk sources are translated.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1341415
