[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging



Here is what we have gathered so far:

1. Virtlogd is not the right answer to XSA-180 because it is inherently
   designed to work within libvirt.
2. Syslog is not suitable because it doesn't provide a fd for QEMU to
   write to.
3. Logrotate is not suitable because it only rotates periodically.
4. Syslog + logrotate combo is not suitable because (see above).

We can, however, just make recommendation that system administrators can
easily set up and call it a day. There are suggestions that we can
recommend conserver or sympathy, but I haven't seen a concrete viable
proposal yet. What I hope is that we can have a document in tree in the
end.

Another way is to invent our own "virtlogd" -- it could be a new daemon,
it could be xenconsoled. The major concern is that we're adding a
critical component to the system and it may not scale well. We can make
a compromise by using non-blocking fd to make the new component less
critical and doesn't hinder scalability.

Another way is to alter libxl API and ask the application to pass in a
fd for logging. The major concern is that this is not suitable in the
context of a security issue.

My ultimate goal is to remove the custom patch we have in QEMU tree so
that we don't create a problem for distro maintainers.  So I'm fine with
any solution really.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.