Posts made by quinniedid

@Sebastian-Roth

I just meant that I am having to rebuild the FOG server on an updated OS. I figured that an up to date version of initrd with NFSv4 support enabled would be a good idea. We have been utilizing NFSv4 for about a year and a half now. This was a requirement from our Cyber security team.

I am was running Ubuntu 18.04 before and now running Ubuntu 22.04. The new server is currently in production with the old initrd_NFSv4 george1421 made for me, working. I just wanted to make sure there wasn’t new code in the initrd that could be an issue later down the road, that would interfere with new features and what not. Which is why I guess I was asking if we could get the newest version but built to enable NFSv4 support.

@george1421 said in Feature request for FOG 1.6.x - Configure image capture to use NFSv4 instead of NFSv3:

Changes needed to FOS for NFSv4 support

Understand these instructions are for the FOG Devs and not the general FOG admin. You need to know the insides of FOS Linux development to understand some of my notations. I did not test with the option of port=2049. The hope is that is the default so it shouldn’t be needed. By defining a specific port firewall rules can be crafted much easier than with NFSv3 and earlier.

1. In buildroot the nfs-utils packages in the nfs-utils.mak file nfsv4 support must be enabled.

NFS_UTILS_CONF_OPTS = \
        --enable-nfsv4 \
        --enable-nfsv41 \
...
HOST_NFS_UTILS_CONF_OPTS = \
        --enable-nfsv4 \
        --enable-nfsv41 \
...

2. nfsvers=4 must be added to the mount command in the following files in the overlay fs directory
   ./rootfs_overlay/bin/fog line:14
   ./rootfs_overlay/bin/fog.mount line:17,20
   ./rootfs_overlay/bin/fog.av line:15
   ./rootfs_overlay/bin/fog.photorec

3. Done. Now rebuild initrd filesystem in buildroot

I’ve compiled a FOG 1.5.9 NFSv4 version of the initrd here: https://drive.google.com/file/d/1EHLhmM9-kXpFO7kfk3H1ydEZF3q8lID1/view?usp=sharing

@george1421 It has been quite some time but I have been tasked with having to completely rebuild FOG on a new OS. I was wondering if you could spare some time to generate a new initrd-NFSv4 from the “dev-branch” for me?

Or if there are instructions somewhere I can follow to do this myself, I would be very much willing to do that as well.

@Trev-lchs We are an all HP shop. We have to use rEFInd version 0.10.9 for all of our systems to boot correctly. This is definitely something with HP’s EFI setup.

I ran into this problem myself, which you can reference the post https://forums.fogproject.org/topic/11993/refind-pxe-booting-issue

Let me know if you were able to get this working with this version

@JJ-Fullmer I am sure you are incredibly busy. I was just wondering if you had a few minutes to help me out with the FOG API and changing inventory values?

@george1421 Do you know of any pointers you could provide me?

I have been battling this for the last few days. I don’t know if my json body is wrong or what?

I am trying to update the inventory item “other2” with an IP address

When I try to test doing this from Postman, I have tried formatting different ways and no luck. I am hoping you can help point me in the right direction. I am also using powershell to perform a fair amount of automation

$params = @{
    Uri         = "http://<URL>/fog/host/283"
    Headers     = @{ 
    'fog-api-token' = "$fog_api_token"
    'fog-user-token' = "$fog_user_token"
    'Content-type' = "application/json"
     }
    Method      = 'PUT'
    Body = $jsonbody
}
Invoke-RestMethod @params

JSON Body:

{
    "inventory":  {
                      "other2":  "10.1.5.35"
                  }
}

@george1421 I was able to get it working, yes. I was able to do both a capture and a deploy with NFSv4 being setup.

I now have the ability to only open two ports in the firewall for all of my FOG clients. Ports 2049/tcp and 80/tcp. I have a DHCP relay server that sits on each network, and it delivers the both ipxe.efi and default.ipxe via TFTP and everything else is done with HTTP. I haven’t figured out a way to boot not using TFTP but it seems that only works if HTTP network boot is an option for the device. This way I do not have to expose a TFTP service on the FOG server or having to use a helper to get it where it needs to be.

@Sebastian-Roth Quickly looking at that discussion it seems that maybe SSH might be the future but it comes with some performance loss and some other struggles.

I would be more than happy to just have NFSv4 be the default standard because at least that is improvement until a more in depth development and assessment can be done to do something different.

Thank you all!!!

@george1421 I was able to capture and deploy!!! Thank you for helping me through this process. I am being forced to use this starting in September now.

How much modification would it take to even just allow NFSv4 to work in FOG as it stands today?

@george1421 Thank you for that SSH tip!!! Saves me from having to go into the office almost everyday to test this stuff.

I don’t have any network access into my test environment but at least I can do it from a Windows or Linux client that’s already on the network instead of the console.

This is the command result:

Now what I am unsure of is if I did make any modification to the boot.php. I will try and find that file and make the necessary modifications.

UPDATE: I was able to change the boot.php file which is what you had mentioned at the very beginning. I was thinking that was part of the initrd file but clearly it is not. It is capturing right now. After it is done, I will be testing a deploy as well.

@george1421 I have been testing quite a bit of the day with all sorts of different configurations on the server. Come to find out it appears that in the initrd that you uploaded, for some reason the NFS mount is being mounted as “Read Only File System”.

If I issue on the FOS client mount -t nfs -o vers=4 10.0.0.5:/capture /images I am able to then write to the /images directory no problem… The only issue is that I still can’t continue to run the capture as it marks /images directory as read-only again.

I don’t know what to look for in FOS for the reason why it is mounting the NFS as a read-only file system?

@george1421 Here are my settings and OS information. I am using your initrd that you uploaded, don’t know if I mentioned that or not.

From the client:

NFS debug enabled I see access denied… It seems like everything is configured correctly:

@george1421 I am having a hard time understanding what is going on here. I have followed the above steps. I see that it checks the mounted file system and checks it but once we start getting to preparing backup location, I get failed…

Any ideas?

@george1421 If you can provide some guidance on what you did to get NFSv4 working for FOG and the modifications that were needed, I will do my best to create a tutorial so that others can accomplish the same until the feature request can be implemented.

As for the /etc/exports you are simply showing the output there, but I am guess this is the same file that is modified for the uid and gid? Where do I go to update the mount command? nfs-utils I am at a loss as to how to begin with making those modifications?

I see that there are other modifications that you did but it wasn’t entirely clear whether those were actually necessary or not?

Any help or guidance would be great! Thank you for helping out this amazing community!

Reference: Feature request for FOG 1.6.x - Configure image capture to use NFSv4 instead of NFSv3

@george1421 We are now being required to get NFSv4 utilized in our environment; have about 3 months before they shut off our server…

I have tried to follow some of the steps that you have taken to get this working. What I am confused about is where to make modifications to the FOS linux OS?

Would you be able to provide a little more details into the steps you took to get this working?

Thank you!

@sebastian-roth Because we are using VMs that are thin provisioned, Windows only optimizes, which we tried and the same result and behavior happened. Increasing the value of how much space to use https://forums.fogproject.org/topic/15416/out-of-disk-space-fog-capture-error/7#, did fix our issue and we only had to increase the value from 5 to 8 for a successful capture.

Thank you for your help!

@sebastian-roth I am sorry. Totally spaced all the details…

FOG: 1.5.9
bzImage Version: 5.10.19

This is what I am seeing:

We have VM images that we use to create golden images from. All of our VMs are capturing fine except for this one VM. It is continuing to fail on shrinking, even though it passes the shrinking test…

Here is the messages log output: messages.txt

@sebastian-roth Ok. We were finally able to test this today. I tried both the standard bg and bgdark images and all of them are doing the same thing.

@sebastian-roth I just wanted to check-in. Just letting you know I am trying to get this tested but because of the holidays and COVID exposure I am unable to be on-site to test this. It will most likely be in early January as to being able to go back on-site. I will provide an update once we are able to get this tested. We are using a custom background and will try to use a default background of both the white and black.