Gluster users - Aug 2013 - GlusterFS extended attributes, "system" namespace

Hi,

I'm running GlusterFS 3.3.2 and I'm having trouble getting
geo-replication to work.  I think it is a problem with extended attributes. 
I'll using ssh with a normal user to perform the replication.

On the server log in /var/log/glusterfs/geo-replication/VOLNAME/ssh?.log I'm
getting an error "ReceClient: call ?:?:? (xtime) failed on peer with
OSError".  On the replication target I'm getting the same error, but
with a stack trace leading back to where it tries to set extended attributes in
the Python replication code.  It appears to be trying to get the attribute
"system.glusterfs.xyz.xtime" at line 365 of
/usr/lib/glusterfs/glusterfs/python/syncdaemon/resource.py:
"Xattr.lgetxattr(path, '.'.join([cls.GX_NSPACE, uuid,
'xtime')], 8))".

I don't know anything about extended attributes, but I can't get
anything in the "system" namespace manually, even running as root -
e.g.
	touch a
	getfattr -n system.test a

The above returns "Operation not supported" rather than "No such
attribute".  The "user" and "trusted" namespace work
fine - this is on ext3 with user_xattr set in the mount options, and also on the
server (ext4).

On the server side I can see files have things set in the "trusted"
namespace (e.g. with "getfattr -m - filename").

Should the setting of GX_NSPACE set the namespace to be "system" for
non-root or should it always be "trusted"? (line 248 in resource.py) 
If I force it to be "trusted" it seems to get further (I get
occasional "Operation not permitted" lines, but I think this is file
permission related).

Iain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130828/502830d0/attachment.sig>

On 08/28/2013 11:15 PM, Iain Buchanan wrote:
> Hi,
>
> I'm running GlusterFS 3.3.2 and I'm having trouble getting
geo-replication to work.  I think it is a problem with extended attributes. 
I'll using ssh with a normal user to perform the replication.
>
> On the server log in /var/log/glusterfs/geo-replication/VOLNAME/ssh?.log
I'm getting an error "ReceClient: call ?:?:? (xtime) failed on peer
with OSError".  On the replication target I'm getting the same error,
but with a stack trace leading back to where it tries to set extended attributes
in the Python replication code.  It appears to be trying to get the attribute
"system.glusterfs.xyz.xtime" at line 365 of
/usr/lib/glusterfs/glusterfs/python/syncdaemon/resource.py:
"Xattr.lgetxattr(path, '.'.join([cls.GX_NSPACE, uuid,
'xtime')], 8))".
> I don't know anything about extended attributes, but I can't get
anything in the "system" namespace manually, even running as root -
e.g.
> 	touch a
> 	getfattr -n system.test a
>
> The above returns "Operation not supported" rather than "No
such attribute".  The "user" and "trusted" namespace
work fine - this is on ext3 with user_xattr set in the mount options, and also
on the server (ext4).
Yes, 'system' is not allowed to be used by a
process.
> On the server side I can see files have things set in the
"trusted" namespace (e.g. with "getfattr -m - filename").
>
> Should the setting of GX_NSPACE set the namespace to be "system"
for non-root or should it always be "trusted"? (line 248 in
resource.py)  If I force it to be "trusted" it seems to get further (I
get occasional "Operation not permitted" lines, but I think this is
file permission related).
Looks like a bug. Please change 'system' to 'user' in
resource.py file,
and see if it works.

Regards,
Amar
> Iain
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users