--ofZMSlrAVk9bLeVm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi,
We're trying to improve the debugability of Gluster backed VMs and one
of the features for this is to be able to gather "statedumps". These
statedumps include memory allocation details and other information about
the Gluster client. QEMU is one of the applications that can be
configured to use libgfapi.so Gluster client.
Gluster provides the /var/run/gluster/ directory and the libgfapi.so
library that qemu (in block/gluster.c) uses that. Would there be a
problem for the "qemu" packages to use add the "qemu" user to a
"gluster" group? I'm not sure yet how this is done for other packages
with their own users, but there would be a dependent installation order
of some kind (needs rpm triggers?).
What is your opinion on this issue, or would you recommend an other
approach?
Thanks,
Niels
PS:
https://bugzilla.redhat.com/1445569 can be used to reply as well
=46rom
http://lists.gluster.org/pipermail/gluster-devel/2017-April/052629.h=
tml:
On Tue, Apr 25, 2017 at 07:53:06PM +0200, Niels de Vos wrote:
Hi,
=20
Recently a new ability to trigger statedumps through the Gluster-CLI [0]
has been added. This makes it possible to get statedump from
applications that use gfapi. By default, statedumps are saved under
/var/run/gluster/... and this directory is only writable by root.
Applications that use gfapi do not require root permissions (like QEMU),
and therefore fail to write the statedump :-/
=20
One approach would be to create a "gluster" group and give the group
permissions to write to /var/run/gluster/... Other 'fixes' include
setting ACLs on the directory so that specified users can write there.
because many daemons have a "home directory" that does not exist, it
probably is not a good idea to use $HOME to store statedumps.
=20
What suggestions do others have?
=20
Thanks,
Niels
=20
=20
0.
https://github.com/gluster/glusterfs/blob/master/doc/debugging/statedu= mp.md
--ofZMSlrAVk9bLeVm
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJZAKJrAAoJECXo5AApwsWzvQgP/RQqbBW/rZ6K6/bJsOr4cY16
j8Ts9hubHpPQeGsM5auL7x58f/Yk1v8DZGLMpgihriKA7wrWygeEjGZiYUqw5sKH
oW6wYbMvEjwSZJF7/MN6jq0U9wPY8waOpxNpvdM3mvNvy8EGzT4Yo/SqXmkwcLQM
Q9v22rOffd9LiuvZmr6N7ftE6xwkbe24P0wD9Rsw9E99R33hr8oCAjdNtVo3jgKa
7ZKMwr5AwQPCVmEkY8sa7AKJi7KLB7oitawGsIvlfwyjQRZO0EMvrDxwxnSLwIlg
6X6SjP7XyBNixM35KKDvBoxgBoE7xmh9kniXkqvEmZRPMG3te7/yPoVh55f4UuDK
gtHXgb+xnQ09Z5eJ5+x23mG26jxXCE/18bOPPUpA4APmyfypPO2JpYO6RABrKmrK
IMurqEnuwpY/rBD4UXUnQiLJtB3tBx8kGtc3Hb8VXLCvJhpnzWQNgRGXsuSLcbTs
W29ZWFr97C5VJcMdMsZJ0haGB7bNyrSOcF6xcUtc8Eg6ELz++c6y2t7IlyKaniVW
PAtuZ3ZlaUt8pw6aLJ4UgaE9kfKUgeEMPFgQIQe8UkTNp3H6N+A9P3QGe9fvl16c
LkjXd5wTZuIDxCEKn/iRSx7oJaVoRsd9BmQB61a7XRPSOJI8yyf4JfMN0kL36UUy
c/y5huVBKyY4sTNzYpu2
=mYzO
-----END PGP SIGNATURE-----
--ofZMSlrAVk9bLeVm--