FOG NFS Challenge: Can you do it?

[Wayne Workman]

Earlier today, Tom was helping me via TeamViewer to solve this.

He did swap out the IDs, and it didn’t work.

[BryceZ]

What about swapping the order they’re listed?

[Wayne Workman]

I will try that,

but the purpose of this is to finalize the WiKi article I’m working on, “Troubleshoot NFS”.

Ideally, the standard options for a basic self-contained 1.2.0 FOG server should work and not need changed… somehow…

Somehow, a host can upload an image to /images/dev… Just need to figure out how to do that from a regular Linux Live CD.

[Wayne Workman]

It didn’t help…

[CODE][root@D620 administrator]# mount -t nfs 10.0.0.3:/images/dev/ /FOGdev
[root@D620 administrator]# cd /FOGdev
[root@D620 FOGdev]# touch test
touch: cannot touch ‘test’: Read-only file system
[root@D620 FOGdev]# mkdir test
mkdir: cannot create directory ‘test’: Read-only file system
[root@D620 FOGdev]# ssh 10.0.0.3
root@10.0.0.3’s password:
Last login: Mon May 25 13:00:14 2015 from 10.0.0.12
[root@localhost ~]# cat /etc/exports
/images/dev *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=1)
/images *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=2)
/opt/fog/clamav *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=3)
[root@localhost ~]# servcie xinetd restart
-bash: servcie: command not found
[root@localhost ~]# service nfs restart
Redirecting to /bin/systemctl restart nfs.service
[root@localhost ~]# service rpcbind restart
Redirecting to /bin/systemctl restart rpcbind.service
[root@localhost ~]# exit
logout
Connection to 10.0.0.3 closed.
[root@D620 FOGdev]# cd …
[root@D620 /]# umount /FOGdev
[root@D620 /]# mount -t nfs 10.0.0.3:/images/dev/ /FOGdev
[root@D620 /]# cd /FOGdev
[root@D620 FOGdev]# touch test
^C
[root@D620 FOGdev]# mkdir test
mkdir: cannot create directory ‘test’: Read-only file system
[root@D620 FOGdev]# ls
[root@D620 FOGdev]# ls -a
. … .mntcheck
[root@D620 FOGdev]# [/CODE]

[Tom Elliott]

Exports was setup slightly improperly.

It was assigning the subtree options (which we really don’t want and/or need) so the fsid

If a path is given (e.g. mountpoint=/path or mp=/path) then the nominated path must be a mountpoint for the exportpoint to be exported.
fsid=num|root|uuid
NFS needs to be able to identify each filesystem that it exports. Normally it will use a UUID for the filesystem (if the filesystem has such a thing) or the device number of the device holding the filesystem (if the filesystem is stored on the device).
As not all filesystems are stored on devices, and not all filesystems have UUIDs, it is sometimes necessary to explicitly tell NFS how to identify a filesystem. This is done with the fsid= option.

For NFSv4, there is a distinguished filesystem which is the root of all exported filesystem. This is specified with fsid=root or fsid=0 both of which mean exactly the same thing.

Other filesystems can be identified with a small integer, or a UUID which should contain 32 hex digits and arbitrary punctuation.

Linux kernels version 2.6.20 and earlier do not understand the UUID setting so a small integer must be used if an fsid option needs to be set for such kernels. Setting both a small number and a UUID is supported so the same configuration can be made to work on old and new kernels alike.

Basically what this means, the fsid needs to be directed at filesystem UUID, or UID of a valid user. Setting to 1 and 2 ordered it, but the subtree would make it so the previous (root or /images in our case) was opened under the user with UID 1 which likely doesn’t have valid permissions. On our init’s there is a userID to UID 1 and 2, but they don’t point to the same as a normal distro so they always assumed root, but on distro’s this is not the same. On the init’s UID 1 is mapped to the daemon user which likely has a link to the root user directly, while UID 2 is linked to the bin user. Most likely these two users don’t actually exist anywhere on the system and therefor it defaults back to the root user. This is just a guess. Either way, the installer should fix this for us now.

[Wayne Workman]

Tom, that’s just great!

However, my troubleshooting article will now only work for those with r3473 or later.

Any way at all to get something to work with r3472 or earlier? The troubleshooting article ought to help out 1.2.0 users at the least.

[Tom Elliott]

@Wayne-Workman Ummm, have them upgrade to 3473…

[Wayne Workman]

@Tom-Elliott said:

@Wayne-Workman Ummm, have them upgrade to 3473…

ha! well then… dang…

I suppose they will need to use the debug deployment to test NFS…

I really want a work around…

[Tom Elliott]

@Wayne-Workman said:

@Tom-Elliott said:

@Wayne-Workman Ummm, have them upgrade to 3473…

ha! well then… dang…

I suppose they will need to use the debug deployment to test NFS…

I really want a work around…

I really think that would be the best work around. We know all worked in the init, so boot to debug an blam, you have yourself a way to test if nfs is at least working.

[Wayne Workman]

For future readers,

to test without using the debug deployment (just using a LIVE CD instead),

inside /etc/exports on the FOG server,
Set the fsid for /images to 0 and /images/dev to 1

Save that, exit that, then run this:
exportfs -a

(got all that info from Tom)

Expect a completed “Troubleshoot NFS” article soon!

And some of my terrible artwork for Tom, too. lol