Hello,
- Original Message -
> This is sort of a v2 of the "Structured syslog" series.
>
> Patches 1-4 allow callers virLogMessage to add arbitrary additional data,
> and use it in virRaiseErrorFull and its callers. This data is sent
> to journal (and ignored for other outputs).
Any comme
- Original Message -
> Given systemd's fast adoption across a wide range of Linux distros,
> in particular the enterprise distros from Red Hat & SUSE, we're
> going to have journald support in places where structured logging
> really matters, likely expanding to all Linux distros in a reaso
Thanks for the review.
- Original Message -
> On Thu, Sep 20, 2012 at 08:24:08PM +0200, Miloslav Trmač wrote:
> > ... and update all users. No change in functionality, the parameter
> > will be used in later patches.
> >
> > diff --git a/src/util/logging.h b/src/util/logging.h
> > index
Hello,
Thanks for the review, and I'm sorry about the late response.
- Original Message -
> While I agree with the effort to try to standardize on metadata to
> be collected with log messages, I can't say I like the Lumberjack
> design, or this proposed usage in libvirt.
>
> First it is n
- "Daniel P. Berrange" wrote:
> @@ -635,49 +620,25 @@ secretLookupByUUIDString(virConnectPtr conn,
> const char *uuid)
>
> pptr = secretFind(driver, uuid);
> if (pptr == NULL) {
> +char uuidstr[VIR_UUID_STRING_BUFLEN];
> +virUUIDFormat(uuid, uuidstr);
> vi
- "Daniel Veillard" wrote:
> On Mon, Sep 07, 2009 at 04:12:39PM +0200, Miloslav Trmač wrote:
> > +if ((size_t)st.st_size != st.st_size) {
>
> shouldn't we chaeck against SECRET_MAX_XML_FILE instead ?
No, this code reads the secret value, not the XML, and there's little reason to
impose
- "Daniel Veillard" wrote:
> > +default:
> > +VIR_ERROR(_("unexpected secret usage type %d"), def->usage_type);
> > +break;
>
> Hum, since the virSecretDefPtr is allocated by our own code, it's
> probably better to remove the default so that the compiler can tell us
>
- "Daniel Veillard" wrote:
> > +/* Make sure ... INTERNAL_CALL can not be set by the caller */
> > +verify((VIR_SECRET_GET_VALUE_INTERNAL_CALL &
> > +VIR_SECRET_GET_VALUE_FLAGS_MASK) == 0);
>
> ??? what's that ? an assert at compile time ? I don't know that construct
> I would rathe
- "Daniel P. Berrange" wrote:
> > > I reckon this snippet of code could usefully be put into the util.h file
> > > as virFileGenerateRandomkey(), or alternatively perhaps secret_conf.h,
> > > as virSecretGenerateRandomKey(unsigned char *buf, size_t buflen);
> > This code, with its limitation
- "Maximilian Wilhelm" wrote:
> Anno domini 2009 Miloslav Trmač scripsit:
>
> > diff --git a/src/storage_encryption.c b/src/storage_encryption.c
> > new file mode 100644
> > index 000..ccb29ed
> > --- /dev/null
> > +++ b/src/storage_encryption.c
> > @@ -0,0 +1,241 @@
>
> [...]
> > +#inc
- "Daniel P. Berrange" wrote:
> On Thu, Aug 20, 2009 at 08:18:13PM +0200, Miloslav Trma?? wrote:
> > If the element does not specify a secret
> > during volume creation, generate a suitable secret and add it to the
> > tag. The caller can view the updated tag
> > using virStorageVolGetXMLD
- "Daniel Veillard" wrote:
> On Sun, Aug 16, 2009 at 10:48:00PM +0200, Miloslav Trmač wrote:
> > This implementation stores the secrets in an unencrypted text file,
> > for simplicity in implementation and debugging.
> >
> > (Symmetric encryption, e.g. using gpgme, will not be difficult to ad
- "Daniel Veillard" wrote:
> On Sun, Aug 16, 2009 at 10:47:58PM +0200, Miloslav Trmač wrote:
> > +static virDrvOpenStatus
> > +remoteSecretOpen (virConnectPtr conn,
> > + virConnectAuthPtr auth,
> > + int flags)
> > +{
> > +if (inside_daemon)
> > +
- "Daniel Veillard" wrote:
> On Sun, Aug 16, 2009 at 10:47:55PM +0200, Miloslav Trmač wrote:
> > /**
> > + * virSecretFreeName:
> > + * @secret_: a secret object
> > + *
> > + * Destroy the vol object, this is just used by the vol hash callback.
> > + * Returns 0 in case of success and -1 in
- "Daniel Veillard" wrote:
> On Sun, Aug 16, 2009 at 10:47:54PM +0200, Miloslav Trmač wrote:
> > Rather than add explicit accessors for attributes of secrets, and
> > hard-code the "secrets are related to storage volumes" association
> in
> > the API, the API uses XML to manipulate the associa
- "Daniel P. Berrange" wrote:
> > diff --git a/docs/schemas/storageencryption.rng
> b/docs/schemas/storageencryption.rng
> > --- /dev/null
> > +++ b/docs/schemas/storageencryption.rng
> > @@ -0,0 +1,37 @@
> > +
> > +
> > +
> > + unencrypted
> > + default
> > +
- "Daniel P. Berrange" wrote:
> >
> >
> > @@ -74,6 +76,7 @@
> >
> >
> >
> > +
> >
> >
>
> To allow removal of "" for non-encrypted cases, I
> believe we'd need to add
>
>
>
>
>
> Unless that's 'encryption' schema rule itself ha
Hello,
based on your comments, here is a proposal for a "secret management" API.
Rather than add explicit accessors for attributes of secrets, and hard-code the
"secrets are related to storage volumes" association in the API, the proposed
uses XML to manipulate the association as well as other a
Hello,
- "Daniel P. Berrange" wrote:
> On Fri, Jul 24, 2009 at 07:25:54AM -0400, Miloslav Trmac wrote:
> > A client in this case is the central, fully trusted, management
> > system (e.g. oVirt), there is no need to protect against it.
> > A more likely f
- "Daniel P. Berrange" wrote:
> > Not quite: the main case of a "dumb" client would be a large-scale
> > virtualization management software that contains a primary store
> > of encryption information, and gives each node access only to those
> > keys that are currently necessary by the node
- "Daniel P. Berrange" wrote:
> For the domain XML I agree that libirt would not need to worry about
> multiple LUKS keys, but for the storage volume XML we would need to
> expose the fact that there are multiple keys,or allow creation of
> volumes with multiple keys.
I don't know. Does a f
- "Daniel P. Berrange" wrote:
> On Tue, Jul 21, 2009 at 01:12:05PM +0200, Miloslav Trma?? wrote:
> > ---
> > src/qemu_driver.c | 51
> ++-
> > 1 files changed, 50 insertions(+), 1 deletions(-)
>
> IIUC this should only be needed when startin
- "Daniel P. Berrange" wrote:
> On Tue, Jul 21, 2009 at 01:12:03PM +0200, Miloslav Trma?? wrote:
> > ---
> > src/qemu_driver.c | 87
>
> > 1 files changed, 73 insertions(+), 14 deletions(-)
>
> I have a feeling this patch is going to cl
- "Daniel P. Berrange" wrote:
> On Tue, Jul 21, 2009 at 01:12:01PM +0200, Miloslav Trma?? wrote:
> This looks fine as a way to integrate. BTW, the XML schemas should be
> updated under docs/schemas/domain.rng and docs/schemas/storagevol.rng
Will do.
Mirek
--
Libvir-list mailing list
Libvi
- "Daniel P. Berrange" wrote:
> As per other mails, I don't think its neccessary to drop the secrets
> from volumes here. At least not until we introduce keystores as an
> explicit public API
As per other mails, it is necessary not to tell the secrets to clients. Given
that, libvirt does not
- "Daniel P. Berrange" wrote:
> On Tue, Jul 21, 2009 at 01:12:00PM +0200, Miloslav Trma?? wrote:
> > Supports only virStorageVolCreateXML, not
> virStorageVolCreateXMLFrom.
> >
> > Curiously, qemu-img does not need the passphrase for anything to create
> > an encrypted volume. This implemen
- "Daniel P. Berrange" wrote:
> On Tue, Jul 21, 2009 at 01:11:57PM +0200, Miloslav Trma?? wrote:
> > +#include
> > +#include
> > +
> > +enum virStorageEncryptionFormat {
> > +VIR_STORAGE_ENCRYPTION_FORMAT_UNENCRYPTED = 0,
> > +VIR_STORAGE_ENCRYPTION_FORMAT_QCOW, /* Both qcow and qcow
Daniel,
thanks for the review.
- "Daniel P. Berrange" wrote:
> > New XML tags are defined to represent encryption parameters (currently
> > format and passphrase, more can be added in the future), e.g.
> >
> > c2lsbHk=
> >
> > (passphrase content uses base64)
>
> I don't th
28 matches
Mail list logo
