I like to rebuild a number of Fedora source packages for performance and some tweaking.
In the past I have used rpmbuild for that purpose, but this weekend I started using mock.
So far I built about a dozen source packages successfully, but then got a SELinux snag when building glibc (I am using the targeted policy on F14).
The wiki has instructions on how to set SELinux for mock: http://fedoraproject.org/wiki/Using_Mock_to_test_package_builds#SELinux_poli...
I followed the instructions but the result of running Make was different from the expected, there was an error. [1].
My question is if the policy files of the wiki page are current? They are three years old, which is a long time in dog years or Fedora years!
I wonder if anybody could tell me where to get updated policy files as I am not proficient on SELinux? Or maybe can I just ignore the error and use what I got as a .pp file was created?
(I am using this after installing mock so if there was no error the next step per the wiki would be: restorecon -R /var/lib/mock /usr/bin/mock
I have not done the above yet.)
---------
[1]
[root@d3000 selinux.local]# make -f /usr/share/selinux/devel/Makefile PackageMaintainers_MockTricks_mock.if:13: Error: duplicate definition of mock_domtrans(). Original definition on 13. Compiling targeted PackageMaintainers_MockTricks_mock module /usr/bin/checkmodule: loading policy configuration from tmp/PackageMaintainers_MockTricks_mock.tmp /usr/bin/checkmodule: policy configuration loaded /usr/bin/checkmodule: writing binary representation (version 10) to tmp/PackageMaintainers_MockTricks_mock.mod Creating targeted PackageMaintainers_MockTricks_mock.pp policy package rm tmp/PackageMaintainers_MockTricks_mock.mod.fc tmp/PackageMaintainers_MockTricks_mock.mod
[root@d3000 selinux.local]# ls PackageMaintainers_MockTricks_mock.fc PackageMaintainers_MockTricks_mock.pp tmp PackageMaintainers_MockTricks_mock.if PackageMaintainers_MockTricks_mock.te
[root@d3000 selinux.local]# ls tmp all_interfaces.conf PackageMaintainers_MockTricks_mock.mod.role iferror.m4 PackageMaintainers_MockTricks_mock.tmp
On 1 May 2011 19:29, Piscium groknok@gmail.com wrote:
My question is if the policy files of the wiki page are current? They are three years old, which is a long time in dog years or Fedora years!
I wonder if anybody could tell me where to get updated policy files as I am not proficient on SELinux? Or maybe can I just ignore the error and use what I got as a .pp file was created?
(I am using this after installing mock so if there was no error the next step per the wiki would be: restorecon -R /var/lib/mock /usr/bin/mock
I have not done the above yet.)
An update: I ran restorecon, rebuilt glibc, and still got the same alert from SELinux: "SELinux is preventing /builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl/elf/ld.so from using the execstack access on a process."
Despite the alert, the eight binary packages were built as expected, and there were no error messages at the end of the build log. There were some earlier about broken pipes and so on.
Most of the error messages I looked at happened while tests were being performing as part of the build process, and this probably explains why there was no error at the end, i. e., failures during tests were not deemed serious enough to warrant scuppering the whole build.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/02/2011 03:12 AM, Piscium wrote:
On 1 May 2011 19:29, Piscium groknok@gmail.com wrote:
My question is if the policy files of the wiki page are current? They are three years old, which is a long time in dog years or Fedora years!
I wonder if anybody could tell me where to get updated policy files as I am not proficient on SELinux? Or maybe can I just ignore the error and use what I got as a .pp file was created?
(I am using this after installing mock so if there was no error the next step per the wiki would be: restorecon -R /var/lib/mock /usr/bin/mock
I have not done the above yet.)
An update: I ran restorecon, rebuilt glibc, and still got the same alert from SELinux: "SELinux is preventing /builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl/elf/ld.so from using the execstack access on a process."
Despite the alert, the eight binary packages were built as expected, and there were no error messages at the end of the build log. There were some earlier about broken pipes and so on.
Most of the error messages I looked at happened while tests were being performing as part of the build process, and this probably explains why there was no error at the end, i. e., failures during tests were not deemed serious enough to warrant scuppering the whole build.
Is one of the libraries marked with the execstack flag?
man execstack
You might want to see if you clear the execstack flag if everything works.
On Sun, 1 May 2011 19:29:50 +0100 Piscium groknok@gmail.com wrote:
I like to rebuild a number of Fedora source packages for performance and some tweaking.
In the past I have used rpmbuild for that purpose, but this weekend I started using mock.
So far I built about a dozen source packages successfully, but then got a SELinux snag when building glibc (I am using the targeted policy on F14).
The wiki has instructions on how to set SELinux for mock: http://fedoraproject.org/wiki/Using_Mock_to_test_package_builds#SELinux_poli...
I followed the instructions but the result of running Make was different from the expected, there was an error. [1].
My question is if the policy files of the wiki page are current? They are three years old, which is a long time in dog years or Fedora years!
Right. Thats out of date. As far as I know you don't need to do anything special anymore. Mock handles it all.
Just run mock out of the box? Does it fail? If so, how?
kevin
On 2 May 2011 14:06, Kevin Fenzi kevin@scrye.com wrote:
On Sun, 1 May 2011 19:29:50 +0100 Piscium groknok@gmail.com wrote:
I like to rebuild a number of Fedora source packages for performance and some tweaking.
In the past I have used rpmbuild for that purpose, but this weekend I started using mock.
So far I built about a dozen source packages successfully, but then got a SELinux snag when building glibc (I am using the targeted policy on F14).
The wiki has instructions on how to set SELinux for mock: http://fedoraproject.org/wiki/Using_Mock_to_test_package_builds#SELinux_poli...
I followed the instructions but the result of running Make was different from the expected, there was an error. [1].
My question is if the policy files of the wiki page are current? They are three years old, which is a long time in dog years or Fedora years!
Right. Thats out of date. As far as I know you don't need to do anything special anymore. Mock handles it all.
Just run mock out of the box? Does it fail? If so, how?
I am not sure what you mean by "just" "out of the box". I ran mock with the "--no-clean" option to save the time to download and install the whole chroot environment. I did "mock --update" before, and I changed the default optflags. Other than that it was a pristine chroot.
Yesterday I built glibc with rpmbuild (i. e. without mock) and got the same SELinux alert as with mock. Some months ago on F13 I built glibc with rpmbuild without an alert, so it seems that something changed between F13 and F14, possibly in glibc.
As I said, while glibc self-tests failed, the whole build succeeded, so yesterday I installed the glibc packages that I built and so far everything seems fine.
I am pasting below the alert message I got from SELinux. I kept the mock build log that shows the failed tests (some of them failed while testing execstack). If anybody is interested I can upload it somewhere (I am not sure if I can email to the list, can I?).
This makes me wonder if the Koji servers that do the Fedora builds have SELinux enabled?
-----------------
SELinux is preventing /builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl/elf/ld.so from using the execstack access on a process.
***** Plugin allow_execstack (53.1 confidence) suggests ********************
If you believe that None should not require execstack Then you should clear the execstack flag and see if /builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl/elf/ld.so works correctly. Report this as a bug on None. You can clear the exestack flag by executing: Do execstack -c None
***** Plugin catchall_boolean (42.6 confidence) suggests *******************
If you want to allow unconfined executables to make their stack executable. This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla Then you must tell SELinux about this by enabling the 'allow_execstack' boolean. Do setsebool -P allow_execstack 1
***** Plugin catchall (5.76 confidence) suggests ***************************
If you believe that ld.so should be allowed execstack access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep ld-linux.so.2 /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Objects Unknown [ process ] Source ld-linux.so.2 Source Path /builddir/build/BUILD/glibc-2.13/build-i686-linuxn ptl/elf/ld.so Port <Unknown> Host d3000 Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.9.7-40.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name d3000 Platform Linux d3000 2.6.35.12-90.fc14.i686 #1 SMP Fri Apr 22 16:14:44 UTC 2011 i686 i686 Alert Count 8 First Seen Sun 01 May 2011 17:38:44 IST Last Seen Sun 01 May 2011 18:14:25 IST Local ID df1866d2-1dcb-4bd9-bcc0-88a350597d97
Raw Audit Messages type=AVC msg=audit(1304270065.850:25864): avc: denied { execstack } for pid=967 comm="ld-linux.so.2" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1304270065.850:25864): arch=i386 syscall=mprotect per=8 success=no exit=EACCES a0=bf924000 a1=1000 a2=1000007 a3=bf9248c8 items=0 ppid=966 pid=967 auid=1000 uid=1000 gid=490 euid=1000 suid=1000 fsuid=1000 egid=490 sgid=490 fsgid=490 tty=pts2 ses=1 comm=ld-linux.so.2 exe=/builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl-nosegneg/elf/ld.so subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Hash: ld-linux.so.2,unconfined_t,unconfined_t,process,execstack
audit2allow
#============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'allow_execstack'
allow unconfined_t self:process execstack;
audit2allow -R
#============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'allow_execstack'
allow unconfined_t self:process execstack;
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/03/2011 03:32 PM, Piscium wrote:
On 2 May 2011 14:06, Kevin Fenzi kevin@scrye.com wrote:
On Sun, 1 May 2011 19:29:50 +0100 Piscium groknok@gmail.com wrote:
I like to rebuild a number of Fedora source packages for performance and some tweaking.
In the past I have used rpmbuild for that purpose, but this weekend I started using mock.
So far I built about a dozen source packages successfully, but then got a SELinux snag when building glibc (I am using the targeted policy on F14).
The wiki has instructions on how to set SELinux for mock: http://fedoraproject.org/wiki/Using_Mock_to_test_package_builds#SELinux_poli...
I followed the instructions but the result of running Make was different from the expected, there was an error. [1].
My question is if the policy files of the wiki page are current? They are three years old, which is a long time in dog years or Fedora years!
Right. Thats out of date. As far as I know you don't need to do anything special anymore. Mock handles it all.
Just run mock out of the box? Does it fail? If so, how?
I am not sure what you mean by "just" "out of the box". I ran mock with the "--no-clean" option to save the time to download and install the whole chroot environment. I did "mock --update" before, and I changed the default optflags. Other than that it was a pristine chroot.
Yesterday I built glibc with rpmbuild (i. e. without mock) and got the same SELinux alert as with mock. Some months ago on F13 I built glibc with rpmbuild without an alert, so it seems that something changed between F13 and F14, possibly in glibc.
As I said, while glibc self-tests failed, the whole build succeeded, so yesterday I installed the glibc packages that I built and so far everything seems fine.
I am pasting below the alert message I got from SELinux. I kept the mock build log that shows the failed tests (some of them failed while testing execstack). If anybody is interested I can upload it somewhere (I am not sure if I can email to the list, can I?).
This makes me wonder if the Koji servers that do the Fedora builds have SELinux enabled?
SELinux is preventing /builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl/elf/ld.so from using the execstack access on a process.
***** Plugin allow_execstack (53.1 confidence) suggests ********************
If you believe that None should not require execstack Then you should clear the execstack flag and see if /builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl/elf/ld.so works correctly. Report this as a bug on None. You can clear the exestack flag by executing: Do execstack -c None
***** Plugin catchall_boolean (42.6 confidence) suggests *******************
If you want to allow unconfined executables to make their stack executable. This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla Then you must tell SELinux about this by enabling the 'allow_execstack' boolean. Do setsebool -P allow_execstack 1
***** Plugin catchall (5.76 confidence) suggests ***************************
If you believe that ld.so should be allowed execstack access on processes labeled unconfined_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep ld-linux.so.2 /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Objects Unknown [ process ] Source ld-linux.so.2 Source Path /builddir/build/BUILD/glibc-2.13/build-i686-linuxn ptl/elf/ld.so Port <Unknown> Host d3000 Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.9.7-40.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name d3000 Platform Linux d3000 2.6.35.12-90.fc14.i686 #1 SMP Fri Apr 22 16:14:44 UTC 2011 i686 i686 Alert Count 8 First Seen Sun 01 May 2011 17:38:44 IST Last Seen Sun 01 May 2011 18:14:25 IST Local ID df1866d2-1dcb-4bd9-bcc0-88a350597d97
Raw Audit Messages type=AVC msg=audit(1304270065.850:25864): avc: denied { execstack } for pid=967 comm="ld-linux.so.2" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1304270065.850:25864): arch=i386 syscall=mprotect per=8 success=no exit=EACCES a0=bf924000 a1=1000 a2=1000007 a3=bf9248c8 items=0 ppid=966 pid=967 auid=1000 uid=1000 gid=490 euid=1000 suid=1000 fsuid=1000 egid=490 sgid=490 fsgid=490 tty=pts2 ses=1 comm=ld-linux.so.2 exe=/builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl-nosegneg/elf/ld.so subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Hash: ld-linux.so.2,unconfined_t,unconfined_t,process,execstack
audit2allow
#============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'allow_execstack'
allow unconfined_t self:process execstack;
audit2allow -R
#============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'allow_execstack'
allow unconfined_t self:process execstack;
You should report this as a bug in gcc.
On 3 May 2011 20:36, Daniel J Walsh dwalsh@redhat.com wrote:
big snip
#============= unconfined_t ============== #!!!! This avc can be allowed using the boolean 'allow_execstack'
allow unconfined_t self:process execstack;
You should report this as a bug in gcc.
You mean _glibc_?
Anyway, I am pasting below an excerpt of the build log that shows the errors more likely related to the SELinux alert:
/builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl-nosegneg/elf/tst-tls9-static.o: In function `do_test': /builddir/build/BUILD/glibc-2.13/elf/tst-tls9.c:16: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking make[2]: *** [/builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl-nosegneg/elf/tst-execstack.out] Error 1 /builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl-nosegneg/elf/tst-execstack-needed: error while loading shared libraries: /builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl-nosegneg/elf/tst-execstack-mod.so: cannot enable executable stack as shared object requires: Permission denied make[2]: *** [/builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl-nosegneg/elf/tst-execstack-needed.out] Error 127 /builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl-nosegneg/elf/tst-execstack-prog: error while loading shared libraries: /builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl-nosegneg/elf/tst-execstack-prog: cannot enable executable stack as shared object requires: Permission denied make[2]: *** [/builddir/build/BUILD/glibc-2.13/build-i686-linuxnptl-nosegneg/elf/tst-execstack-prog.out] Error 127 make[2]: Target `tests' not remade because of errors. make[2]: Leaving directory `/builddir/build/BUILD/glibc-2.13/elf' make[1]: *** [elf/tests] Error 2
Just upgraded to F14. Small home network environment. As before my upgrade from F13, my /home directory is an NFS mounted partition exported from my F13 (not yet upgraded) server. Nothing changed on the server. Where all my imported /home files on the client had the correct ownership before the upgrade, they now all show a UID and GID of 99 (nobody) on the client. This is obviously rendering filess nearly useless.
Authentication is through NIS. "ypcat passwd" yields expected listing with all imported user IDs with the expected UIDs and GIDs (all above 499).
On 05/03/11 14:10, Mark Eackloff wrote:
Just upgraded to F14. Small home network environment. As before my upgrade from F13, my /home directory is an NFS mounted partition exported from my F13 (not yet upgraded) server. Nothing changed on the server. Where all my imported /home files on the client had the correct ownership before the upgrade, they now all show a UID and GID of 99 (nobody) on the client. This is obviously rendering filess nearly useless.
Authentication is through NIS. "ypcat passwd" yields expected listing with all imported user IDs with the expected UIDs and GIDs (all above 499).
Do you mount via the fstab? If so, add to the mount line options: user, uid=YourUID,gid=YourGID and remount.
On 05/03/2011 05:18 PM, JD wrote:
On 05/03/11 14:10, Mark Eackloff wrote:
Just upgraded to F14. Small home network environment. As before my upgrade from F13, my /home directory is an NFS mounted partition exported from my F13 (not yet upgraded) server. Nothing changed on the server. Where all my imported /home files on the client had the correct ownership before the upgrade, they now all show a UID and GID of 99 (nobody) on the client. This is obviously rendering filess nearly useless.
Authentication is through NIS. "ypcat passwd" yields expected listing with all imported user IDs with the expected UIDs and GIDs (all above 499).
Do you mount via the fstab? If so, add to the mount line options: user, uid=YourUID,gid=YourGID and remount.
Did not mount. Complained about an error with the options. I looked in the man pages for bot mount and mount.nfs and could not find uid= or gid=. Tried it with just user but still, everything on the mounted partition was owned by "nobody".
Mark
On Tue, May 3, 2011 at 5:10 PM, Mark Eackloff meackloff@cox.net wrote:
Just upgraded to F14. Small home network environment. As before my upgrade from F13, my /home directory is an NFS mounted partition exported from my F13 (not yet upgraded) server. Nothing changed on the server. Where all my imported /home files on the client had the correct ownership before the upgrade, they now all show a UID and GID of 99 (nobody) on the client. This is obviously rendering filess nearly useless.
Authentication is through NIS. "ypcat passwd" yields expected listing with all imported user IDs with the expected UIDs and GIDs (all above 499).
Set Domain in "/etc/idmapd.conf" to your NIS domain on both server and client.
On 05/03/2011 06:25 PM, Tom H wrote:
On Tue, May 3, 2011 at 5:10 PM, Mark Eackloffmeackloff@cox.net wrote:
Just upgraded to F14. Small home network environment. As before my upgrade from F13, my /home directory is an NFS mounted partition exported from my F13 (not yet upgraded) server. Nothing changed on the server. Where all my imported /home files on the client had the correct ownership before the upgrade, they now all show a UID and GID of 99 (nobody) on the client. This is obviously rendering filess nearly useless.
Authentication is through NIS. "ypcat passwd" yields expected listing with all imported user IDs with the expected UIDs and GIDs (all above 499).
Set Domain in "/etc/idmapd.conf" to your NIS domain on both server and client.
Tried it but no banana. Same result. The comments in that file say that the default is the host's DNS name, which is what I was using, against popular advice, for my NISDOMAIN.
Mark
On 05/04/2011 09:27 AM, Mark Eackloff wrote:
Tried it but no banana. Same result. The comments in that file say that the default is the host's DNS name, which is what I was using, against popular advice, for my NISDOMAIN.
What you said is a bit unclear...so just want to make sure....
You said... "host's DNS name". To me that could mean "fully qualified domain name". But, that isn't what it needs/wants. It wants only the "domain" part.
So, if your host names are aaa.foo.com and bbb.foo.com the entry in the file is foo.com
On 05/03/2011 09:37 PM, Ed Greshko wrote:
On 05/04/2011 09:27 AM, Mark Eackloff wrote:
Tried it but no banana. Same result. The comments in that file say that the default is the host's DNS name, which is what I was using, against popular advice, for my NISDOMAIN.
What you said is a bit unclear...so just want to make sure....
You said... "host's DNS name". To me that could mean "fully qualified domain name". But, that isn't what it needs/wants. It wants only the "domain" part.
So, if your host names are aaa.foo.com and bbb.foo.com the entry in the file is foo.com
Yes, I'm specifying just the foo.com part. I'm running Bind, mostly just as a name-caching server. But I've also created an unpublished domain "eackloff.com" for my internal network. But thanks for asking for the clarification.
Mark
On Tue, 2011-05-03 at 22:09 -0400, Mark Eackloff wrote:
On 05/03/2011 09:37 PM, Ed Greshko wrote:
On 05/04/2011 09:27 AM, Mark Eackloff wrote:
Tried it but no banana. Same result. The comments in that file say that the default is the host's DNS name, which is what I was using, against popular advice, for my NISDOMAIN.
What you said is a bit unclear...so just want to make sure....
You said... "host's DNS name". To me that could mean "fully qualified domain name". But, that isn't what it needs/wants. It wants only the "domain" part.
So, if your host names are aaa.foo.com and bbb.foo.com the entry in the file is foo.com
Yes, I'm specifying just the foo.com part. I'm running Bind, mostly just as a name-caching server. But I've also created an unpublished domain "eackloff.com" for my internal network. But thanks for asking for the clarification.
Mark
PGP key available
I found a reboot was necessary to ensure the change to /etc/idmapd.conf was valid
I think the man page lies about the default. force Domain = foo.com and reboot
John
On 05/04/2011 04:10 AM, John Austin wrote:
On Tue, 2011-05-03 at 22:09 -0400, Mark Eackloff wrote:
On 05/03/2011 09:37 PM, Ed Greshko wrote:
On 05/04/2011 09:27 AM, Mark Eackloff wrote:
Tried it but no banana. Same result. The comments in that file say that the default is the host's DNS name, which is what I was using, against popular advice, for my NISDOMAIN.
What you said is a bit unclear...so just want to make sure....
You said... "host's DNS name". To me that could mean "fully qualified domain name". But, that isn't what it needs/wants. It wants only the "domain" part.
So, if your host names are aaa.foo.com and bbb.foo.com the entry in the file is foo.com
Yes, I'm specifying just the foo.com part. I'm running Bind, mostly just as a name-caching server. But I've also created an unpublished domain "eackloff.com" for my internal network. But thanks for asking for the clarification.
Mark
PGP key available
I found a reboot was necessary to ensure the change to /etc/idmapd.conf was valid
I think the man page lies about the default. force Domain = foo.com and reboot
John
I agree, you can't believe everything you read. But I left the Domain = in there and the machine has been restarted a couple of times. No change.
On Tue, May 3, 2011 at 9:27 PM, Mark Eackloff meackloff@cox.net wrote:
On 05/03/2011 06:25 PM, Tom H wrote:
On Tue, May 3, 2011 at 5:10 PM, Mark Eackloffmeackloff@cox.net wrote:
Just upgraded to F14. Small home network environment. As before my upgrade from F13, my /home directory is an NFS mounted partition exported from my F13 (not yet upgraded) server. Nothing changed on the server. Where all my imported /home files on the client had the correct ownership before the upgrade, they now all show a UID and GID of 99 (nobody) on the client. This is obviously rendering filess nearly useless.
Authentication is through NIS. "ypcat passwd" yields expected listing with all imported user IDs with the expected UIDs and GIDs (all above 499).
Set Domain in "/etc/idmapd.conf" to your NIS domain on both server and client.
Tried it but no banana. Same result. The comments in that file say that the default is the host's DNS name, which is what I was using, against popular advice, for my NISDOMAIN.
Did you restart the rpcidmapd service?
On 05/04/2011 10:36 AM, Tom H wrote:
On Tue, May 3, 2011 at 9:27 PM, Mark Eackloffmeackloff@cox.net wrote:
On 05/03/2011 06:25 PM, Tom H wrote:
On Tue, May 3, 2011 at 5:10 PM, Mark Eackloffmeackloff@cox.net wrote:
Just upgraded to F14. Small home network environment. As before my upgrade from F13, my /home directory is an NFS mounted partition exported from my F13 (not yet upgraded) server. Nothing changed on the server. Where all my imported /home files on the client had the correct ownership before the upgrade, they now all show a UID and GID of 99 (nobody) on the client. This is obviously rendering filess nearly useless.
Authentication is through NIS. "ypcat passwd" yields expected listing with all imported user IDs with the expected UIDs and GIDs (all above 499).
Set Domain in "/etc/idmapd.conf" to your NIS domain on both server and client.
Tried it but no banana. Same result. The comments in that file say that the default is the host's DNS name, which is what I was using, against popular advice, for my NISDOMAIN.
Did you restart the rpcidmapd service?
Yes. The OS has been restarted a couple of times. Still, everything in /home belongs to user 99.
Don't hijack threads. When you have a new topic, compose a new message and don't just reply to an existing one. Changing the Subject line does not make this OK.
poc
Stink! Sorry about that.
Mark
On 05/03/2011 06:29 PM, Patrick O'Callaghan wrote:
Don't hijack threads. When you have a new topic, compose a new message and don't just reply to an existing one. Changing the Subject line does not make this OK.
poc
On Tue, 03 May 2011 17:10:27 -0400 Mark Eackloff wrote:
Just upgraded to F14. Small home network environment. As before my upgrade from F13, my /home directory is an NFS mounted partition exported from my F13 (not yet upgraded) server. Nothing changed on the server. Where all my imported /home files on the client had the correct ownership before the upgrade, they now all show a UID and GID of 99 (nobody) on the client. This is obviously rendering filess nearly useless.
Authentication is through NIS. "ypcat passwd" yields expected listing with all imported user IDs with the expected UIDs and GIDs (all above 499).
I guess this an NFS version problem which I had also.
Add "nfsvers=3" to your mount options and retry.
For me, I hat to add the option to my automounter files, YMMV.
--Frank Elsner
-
Daniel J Walsh -
Dr J Austin -
Ed Greshko -
Frank Elsner -
JD -
Kevin Fenzi -
Mark Eackloff -
Patrick O'Callaghan -
Piscium -
Tom H