| View previous topic :: View next topic |
| Author |
Message |
Dragonlord
Guru
Joined: 22 Aug 2004
Posts: 446
Location: Switzerland
|
 Posted: Sat Jul 11, 2009 4:24 pm Post subject: RSync defunct: invalid user nobody |
 |
|
Suddenly this week my Gentoo Portage Server stopped working. Whenever I try to sync using a client I get the following:
| Quote: | # emerge --sync
>>> Starting rsync with rsync://192.168.1.10:880/portage...
>>> Checking server timestamp ...
@ERROR: invalid uid nobody
rsync error: error starting client-server protocol (code 5) at main.c(1504) [receiver=3.0.5]
>>> Retrying... |
And so forth. The rsyncd.conf contains still the same as it did before:
| Quote: | pid file = /var/run/rsyncd.pid
max connections = 5
use chroot = yes
uid = nobody
gid = nobody
hosts allow = 192.168.1.0/24
hosts deny = * |
I also tried "-2" but nothing works. Nobody does exist and is as it should be
| Quote: | | uid=65534(nobody) gid=65534(nobody) Gruppen=65534(nobody) |
What's going on? Why can rsync "suddenly" no more work with UID? Some code changes or something else going on? Since I can't sync anymore my clients right now and this is annoying.
Concerning infos:
net-misc/rsync-3.0.5 USE="iconv -acl -ipv6 -static -xattr -xinetd"
Linux server 2.6.20-hardened-r5 #6 SMP Thu Aug 2 16:24:16 CEST 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3600+ AuthenticAMD GNU/Linux
_________________
DragonDreams: Leader and Head Programmer |
|
| Back to top |
|
 |
linear
Apprentice
Joined: 12 Aug 2004
Posts: 222
|
| Posted: Thu Jul 16, 2009 10:18 pm Post subject: |
|
|
Okay,
I see that you have "use chroot = yes", and from the 'man rsyncd.conf' documentation:
| Code: | When "use chroot" is false or the inside-chroot path is not "/",
rsync will: (1) munge symlinks by default for security reasons
(see "munge symlinks" for a way to turn this off, but only if
you trust your users), (2) substitute leading slashes in abso-
lute paths with the module's path (so that options such as
--backup-dir, --compare-dest, etc. interpret an absolute path as
rooted in the module's "path" dir), and (3) trim ".." path ele-
ments from args if rsync believes they would escape the module
hierarchy. The default for "use chroot" is true, and is the
safer choice (especially if the module is not read-only).
When this parameter is enabled, rsync will not attempt to map
users and groups by name (by default), but instead copy IDs as
though --numeric-ids had been specified. In order to enable
name-mapping, rsync needs to be able to use the standard library
functions for looking up names and IDs (i.e. getpwuid() , get-
grgid() , getpwname() , and getgrnam() ). This means the rsync
process in the chroot hierarchy will need to have access to the
resources used by these library functions (traditionally
/etc/passwd and /etc/group, but perhaps additional dynamic
libraries as well). |
So, if I read this correctly, if you do not have an /etc/passwd and an /etc/group within the chroot module's filesystem, it will not be able to figure out who nobody:nobody is. Also, I wonder if the order of the configurations within the rsyncd.conf is significant... I noticed in the example within the man page that they put the "uid = nobody' and 'gid = nobody' before the 'use chroot = yes'.
| Code: | A more sophisticated example would be:
uid = nobody
gid = nobody
use chroot = yes
max connections = 4
syslog facility = local5
pid file = /var/run/rsyncd.pid
[ftp]
path = /var/ftp/./pub
comment = whole ftp area (approx 6.1 GB)
[sambaftp]
path = /var/ftp/./pub/samba
comment = Samba ftp area (approx 300 MB)
[rsyncftp]
path = /var/ftp/./pub/rsync
comment = rsync ftp area (approx 6 MB)
<snip> |
Not sure if that is pertinent to this issue, but it would be something to check.
HTH. |
|
| Back to top |
|
|
Dragonlord
Guru
Joined: 22 Aug 2004
Posts: 446
Location: Switzerland
|
| Posted: Fri Jul 17, 2009 7:51 pm Post subject: |
|
|
It seems to work with directly using the UID of nobody. Strange thing though since nobody has / as home so it should have access to everything it needs to figure out the UID from the username.
_________________
DragonDreams: Leader and Head Programmer |
|
| Back to top |
|
|
linear
Apprentice
Joined: 12 Aug 2004
Posts: 222
|
| Posted: Sat Jul 18, 2009 12:13 am Post subject: |
|
|
Yes... and there is the rub.
Nobody can have a home of '/', but where is your chroot starting? Is '/' the root of the overall chroot filesystem? Or are you chrooting to another location like /usr/portage or /pub/portage or something like that?
If I understand it correctly, what the manual was saying is; If you are setting up a chroot and the root of the rsync chroot is *not* '/', then you will have issues mapping names to UIDs, *unless* you have something set up within the chroot to help with the mapping. By default, it will look for /etc/passwd and /etc/group to help with the mapping and may need some other dynamic libraries as well.
HTH. |
|
| Back to top |
|
|
curmudgeon
Veteran
Joined: 08 Aug 2003
Posts: 1744
|
| Posted: Sun May 06, 2012 9:02 am Post subject: |
|
|
I am having this problem now:
| Code: |
# SYNC=rsync://server/gentoo-portage/ emerge --sync
>>> Starting rsync with rsync://192.168.0.1/gentoo-portage/...
>>> Checking server timestamp ...
@ERROR: invalid uid nobody
rsync error: error starting client-server protocol (code 5) at main.c(1516) [Receiver=3.0.9]
>>> Retrying...
!!! Exhausted addresses for server
|
This clearly began after the upgrade (on the server side) of glibc from 2.13-r4 to 2.14.1-r3.
The client has no problem syncing with rsync.gentoo.org.
Any thoughts? |
|
| Back to top |
|
|
curmudgeon
Veteran
Joined: 08 Aug 2003
Posts: 1744
|
| Posted: Sun May 06, 2012 9:10 am Post subject: |
|
|
| Rebuilding rsync solves the problem. That should be noted somewhere. |
|
| Back to top |
|
|
gbetous
l33t
Joined: 15 Jan 2004
Posts: 679
Location: Toulouse
|
| Posted: Mon May 07, 2012 3:49 pm Post subject: |
|
|
Hi !
Thanks for the tip !!!
I rebuild both on client and server side, and restarted rsyncd on server. Then it works fine.
_________________
Core2Quad Q6600
ASUS P5B-V (i965 video intégrée)
~amd64 / KDE
|
|
| Back to top |
|
|
curmudgeon
Veteran
Joined: 08 Aug 2003
Posts: 1744
|
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3008
Location: Edge of marsh USA
|
| Posted: Fri Jun 08, 2018 7:44 pm Post subject: |
|
|
I just got bit by this. I maintain a local repository to support several local Gentoo machines. I found this thread, rebuilt rsync and restarted rsyncd on the server only and all is well again.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
jlpoole
Guru
Joined: 01 Nov 2005
Posts: 491
Location: Salem, OR
|
| Posted: Sun Jul 29, 2018 11:59 am Post subject: |
|
|
| figueroa wrote: | | I just got bit by this. I maintain a local repository to support several local Gentoo machines. I found this thread, rebuilt rsync and restarted rsyncd on the server only and all is well again. |
Thank you, figueroa. Like you, I have one Gentoo server that serves several local Gentoo servers with the portage snapshot.
I have an older server that had this problem too. I rebuilt rsync. Tried and got the same error message. I then restarted the rsync daemon on the very new server and then tried again to emerge --sync from the old server and it worked, too.
I'm guessing that the rsync daemon caches values that get reset on "restart" of the daemon. |
|
| Back to top |
|
|
pascuol
n00b
Joined: 03 Dec 2006
Posts: 39
|
| Posted: Sun Apr 14, 2019 1:29 pm Post subject: |
|
|
Same error after upgrade of glibc to : sys-libs/glibc-2.28-r6
restart of rsyncd on server side was enough
 |
|
| Back to top |
|
|
twalter
Tux's lil' helper
Joined: 07 Apr 2004
Posts: 103
Location: Churchill, Canada
|
| Posted: Thu Apr 18, 2019 12:47 pm Post subject: |
|
|
| Add another to the list. Weird how it's the first time after all these years. |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3008
Location: Edge of marsh USA
|
| Posted: Mon Nov 02, 2020 6:29 pm Post subject: |
|
|
Still not fixed, nor any warnings, x86 server updated to sys-libs/glibc-2.32-r2 three days ago. Rebuilding rsync on the server and restarting rsyncd is still the fix.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
hardly
n00b
Joined: 30 Jan 2010
Posts: 26
|
| Posted: Fri Nov 06, 2020 9:34 pm Post subject: |
|
|
+1
Thanks for the cool thread guys. Still relevant! |
|
| Back to top |
|
|
r7l
Tux's lil' helper
Joined: 16 Feb 2019
Posts: 93
|
| Posted: Thu Mar 31, 2022 2:15 pm Post subject: |
|
|
| Ran into this issue just now. Rebuilding Rsync did fix the issues as said years ago. Seems still relevant. Thanks |
|
| Back to top |
|
|
freke
Veteran
Joined: 23 Jan 2003
Posts: 1059
Location: Somewhere in Denmark
|
| Posted: Thu Mar 31, 2022 7:39 pm Post subject: |
|
|
| r7l wrote: | | Ran into this issue just now. Rebuilding Rsync did fix the issues as said years ago. Seems still relevant. Thanks |
Recently updated sys-libs/glibc?
https://forums.gentoo.org/viewtopic-t-1147884.html |
|
| Back to top |
|
|
r7l
Tux's lil' helper
Joined: 16 Feb 2019
Posts: 93
|
| Posted: Fri Apr 01, 2022 2:40 pm Post subject: |
|
|
| You're correct. Must have missed that message. Thanks allot! |
|
| Back to top |
|
|
|
Networking & Security
