Обсуждение: BUG #4883: tar xf fails on NFS4 mounts
The following bug has been logged online: Bug reference: 4883 Logged by: Alfred Monticello Email address: ajmcello78@gmail.com PostgreSQL version: All Operating system: Linux Description: tar xf fails on NFS4 mounts Details: in doc/Makefile, tar is run to extract an archive with xf options. Needs oxf to map to owner of person running tar, otherwise Invalid Argument occurs and the Makefile errors out. A better solution might be to compact postgres as UID/GID 0 instead of UID 258 which does not exist on my system. Problem only occurs when mounting NFSv4 from a Solaris box using ZFS. Client is Ubuntu Jaunty. Tar tries to preserve UID 258 but errors out because it doesn't exist.
On Friday 26 June 2009 00:04:02 Alfred Monticello wrote: > in doc/Makefile, tar is run to extract an archive with xf options. Needs > oxf to map to owner of person running tar, otherwise Invalid Argument > occurs and the Makefile errors out. > > A better solution might be to compact postgres as UID/GID 0 instead of UID > 258 which does not exist on my system. > > Problem only occurs when mounting NFSv4 from a Solaris box using ZFS. > Client is Ubuntu Jaunty. Tar tries to preserve UID 258 but errors out > because it doesn't exist. Are you running the extraction as root user?
Peter Eisentraut <peter_e@gmx.net> writes:
> Are you running the extraction as root user?
As far as I can find, there is no explicit recommendation in the
installation instructions that you not do the build as root.
Perhaps we should add one.
regards, tom lane
On Thu, Jun 25, 2009 at 2:29 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > On Friday 26 June 2009 00:04:02 Alfred Monticello wrote: > > in doc/Makefile, tar is run to extract an archive with xf options. Needs > > oxf to map to owner of person running tar, otherwise Invalid Argument > > occurs and the Makefile errors out. > > > > A better solution might be to compact postgres as UID/GID 0 instead of > UID > > 258 which does not exist on my system. > > > > Problem only occurs when mounting NFSv4 from a Solaris box using ZFS. > > Client is Ubuntu Jaunty. Tar tries to preserve UID 258 but errors out > > because it doesn't exist. > > Are you running the extraction as root user? > Yes. I am user root. It is an interesting problem. Tar fails because it tries to preserve ownership and group. However over an NFSv4 and ZFS, the NFS client where I am working on tries to remap unknown usernames and groups to nobody.nogroup, which tar does not seem to like. I tried GNU version 1.22 and it also failed the same way. I can manually run chown or chgrp to an unknown UID and GID, and they will get mapped as nobody.nogroup. So I guess the source of the problem really lies with tar... I'm working on a new server and am building a several of source packages. Postgres and Apache httpd are the only two out of about 25 that have had this problem. Postgres had a problem as soon as I unpacked it with tar, it complained about UID 258. All the other packages I have unpacked with tar unpacked with 0 as the UID and GID. # make make -C doc all make[1]: Entering directory `/nfs/fsp1/web/postgresql-8.3.7/doc' gzip -d -c man.tar.gz | /bin/tar xf - /bin/tar: man1/clusterdb.1: Cannot change ownership to uid 258, gid 258: Invalid argument /bin/tar: Error exit delayed from previous errors make[1]: *** [manl/.timestamp] Error 2 make[1]: Leaving directory `/nfs/fsp1/web/postgresql-8.3.7/doc' make: *** [all] Error 2 #
ajmcello <ajmcello78@gmail.com> writes:
> # make
> make -C doc all
> make[1]: Entering directory `/nfs/fsp1/web/postgresql-8.3.7/doc'
> gzip -d -c man.tar.gz | /bin/tar xf -
> /bin/tar: man1/clusterdb.1: Cannot change ownership to uid 258, gid 258:
> Invalid argument
> /bin/tar: Error exit delayed from previous errors
> make[1]: *** [manl/.timestamp] Error 2
Hmm, that is *not* about unpacking the source tarball as I first thought
--- it's about unpacking the documentation sub-tarballs. Which is
something that people are quite likely to try to do as root,
particularly for the html tarball which is unpacked only in the install
step. Maybe putting "o" into the options in doc/Makefile is a good
idea. I'm wondering why we've not had complaints before, though.
BTW, why are there uses of both "tar" and "$(TAR)" in there?
regards, tom lane
On Fri, Jun 26, 2009 at 1:44 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote: > =A0Maybe putting "o" into the options in doc/Makefile is a good > idea. I wonder why we have tarballs inside of tarballs. Why not just have the files directly in a subdirectory of the install tarball already? > I'm wondering why we've not had complaints before, though. On a local filesystem tar will happily restore the user even if there's no userid 258 in /etc/passwd. Presumably the file we eventually install does get the right owner along the way anyways. --=20 greg http://mit.edu/~gsstark/resume.pdf
On Thu, Jun 25, 2009 at 5:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > ajmcello <ajmcello78@gmail.com> writes: > > # make > > make -C doc all > > make[1]: Entering directory `/nfs/fsp1/web/postgresql-8.3.7/doc' > > gzip -d -c man.tar.gz | /bin/tar xf - > > /bin/tar: man1/clusterdb.1: Cannot change ownership to uid 258, gid 258: > > Invalid argument > > /bin/tar: Error exit delayed from previous errors > > make[1]: *** [manl/.timestamp] Error 2 > > Hmm, that is *not* about unpacking the source tarball as I first thought > --- it's about unpacking the documentation sub-tarballs. Which is > something that people are quite likely to try to do as root, > particularly for the html tarball which is unpacked only in the install > step. Maybe putting "o" into the options in doc/Makefile is a good > idea. I'm wondering why we've not had complaints before, though. > > BTW, why are there uses of both "tar" and "$(TAR)" in there? > > regards, tom lane Oh, yeah I see that now it uses both. I sent a report to the tar group, maybe its something they can fix. I got that error when both unpacking the source tarball and within the doc directory. Everything seems to work fine by hand, chown, chgrp, etc..Maybe its a system call issue with tar, though it all worked fine in NFSv3 which does not use an ID mapper daemon. I guess not too many people are using NFSv4 (I had to specify nfs4 in fstab, its turned off by default in Ubuntu 9.04 jaunty). Maybe I should go back to 3... The only downside with adding o to tar that I can see is if it isn't supported by a non-GNU version of tar.
Greg Stark <gsstark@mit.edu> writes:
> On Fri, Jun 26, 2009 at 1:44 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> Maybe putting "o" into the options in doc/Makefile is a good
>> idea.
> I wonder why we have tarballs inside of tarballs.
That's been complained about before, but getting rid of it is a larger
change than I care to undertake right now.
regards, tom lane
ajmcello <ajmcello78@gmail.com> writes: > The only downside with adding o to tar that I can see is if it isn't > supported by a non-GNU version of tar. It's required by the Single Unix Spec http://www.opengroup.org/onlinepubs/007908799/xcu/tar.html (although that specifically disallows the ordering "oxf" that you suggest) and I see it in tar on HPUX 10.20, which ought to be about ancient enough for anybody. regards, tom lane
Tom Lane wrote: > ajmcello <ajmcello78@gmail.com> writes: > > The only downside with adding o to tar that I can see is if it isn't > > supported by a non-GNU version of tar. > > It's required by the Single Unix Spec > http://www.opengroup.org/onlinepubs/007908799/xcu/tar.html > (although that specifically disallows the ordering "oxf" that you > suggest) and I see it in tar on HPUX 10.20, which ought to be about > ancient enough for anybody. My old BSD has: -o Write very old style tar archive, omitting the storage of direc- tories. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes: > Tom Lane wrote: >> It's required by the Single Unix Spec >> http://www.opengroup.org/onlinepubs/007908799/xcu/tar.html >> (although that specifically disallows the ordering "oxf" that you >> suggest) and I see it in tar on HPUX 10.20, which ought to be about >> ancient enough for anybody. > My old BSD has: > -o Write very old style tar archive, omitting the storage of direc- > tories. Yeah, and we later found out that it was horribly broken in GNU tar 1.14, which is still out there. So it got reverted. I'm currently thinking that the best solution is to dodge the problem entirely by getting rid of the sub-tarballs. There's no very good reason why we don't ship those generated doc files "loose" in the tarball. The man files are already extracted into man1/ and man7/ as the first step of using them, so we should just make that be the shipped state of the tree. The .html files could similarly be dumped into an html/ subdirectory after they're created, instead of being wrapped up in a tarball. regards, tom lane
ajmcello wrote:
> The only downside with adding o to tar that I can see is if it isn't
> supported by a non-GNU version of tar.
On solaris 9 and 10 at least, tar -o means set ownership of extracted
files to the runner and not the uid in the tar, which I assume is what
we want here.
Note, this is on Solaris /usr/bin/tar
I'd suggest that if this works on...
A) solaris 8+
B) hp-ux
C) AIX 5.x+
D) Free/Net/OpenBSD
it would be safe for 'unix' systems, as there really aren't many other
flavors of 'unix' in common use anymore.
On Thursday 02 July 2009 02:45:24 John R Pierce wrote: > ajmcello wrote: > > The only downside with adding o to tar that I can see is if it isn't > > supported by a non-GNU version of tar. > > On solaris 9 and 10 at least, tar -o means set ownership of extracted > files to the runner and not the uid in the tar, which I assume is what > we want here. > > Note, this is on Solaris /usr/bin/tar > > I'd suggest that if this works on... > > A) solaris 8+ > B) hp-ux > C) AIX 5.x+ > D) Free/Net/OpenBSD > > it would be safe for 'unix' systems, as there really aren't many other > flavors of 'unix' in common use anymore. But it doesn't, hence this thread.
On Thursday 02 July 2009 09:56:35 Peter Eisentraut wrote: > On Thursday 02 July 2009 02:45:24 John R Pierce wrote: > > ajmcello wrote: > > > The only downside with adding o to tar that I can see is if it isn't > > > supported by a non-GNU version of tar. > > > > On solaris 9 and 10 at least, tar -o means set ownership of extracted > > files to the runner and not the uid in the tar, which I assume is what > > we want here. > > > > Note, this is on Solaris /usr/bin/tar > > > > I'd suggest that if this works on... > > > > A) solaris 8+ > > B) hp-ux > > C) AIX 5.x+ > > D) Free/Net/OpenBSD > > > > it would be safe for 'unix' systems, as there really aren't many other > > flavors of 'unix' in common use anymore. > > But it doesn't, hence this thread. I meant rather, hence the other thread, where we had to revert this.
Peter Eisentraut <peter_e@gmx.net> writes:
> I meant rather, hence the other thread, where we had to revert this.
I think that thread was on -packagers rather than any public list.
For the record: Dave Page reported that the initial wrap of 8.4.0
failed to build on OS X 10.4. Investigation disclosed that its
version of tar was misinterpreting the "o" switch, and that this
wasn't Apple's fault but rather a bug common to all GNU tar 1.14.x
versions (up to x=91 IIRC). Given the lack of prior complaints
and the likelihood that 1.14.x is still in use elsewhere,
we decided to revert to the old coding for 8.4.
regards, tom lane