Custom Full Host Registration for 1.3.4

JGallo

Server

FOG Version: 1.3.4
OS: Ubuntu 16.04

Client

Service Version:
OS: Windows 7 Pro

Description

Hello Everyone,
Finally made the jump over to 1.3.4 and I must say I like it a lot. One question I have is in FOG 1.2 we were able to customize the init.xz file so that we can remove options like IP and auto join. I tried the same steps on the FOG wiki pages and I get to the point of mounting the init files mount -o loop init{,_32} initmountdir and basically the mount options just pop up. Has the process changed in customizing the FOG registration menu? Is there an easier way now on 1.3.4 like through the web UI? Thank you all for the hard work you guys do for FOG.

george1421

There are no reasons to “hack” the inits now days.

I’m not sure what you are talking about removing IP (please explain). The auto join part is managed by the FOG client which can be managed by the FOG Web GUI.

FOG Configuration->FOG System Settings->FOG Client- … Depending on what you want to fog client to do.

BTW: FOG 1.3.5 was just released over the weekend after a lengthy RC testing cycle.

JGallo

@george1421
During the Full host registration process, questions like hostname, image ID, and eventually IP address, user 1, users 2, etc. In the past, we could like you said “Hack” the init file to correspond to a custom host registration menu and allows you to remove variables like user 1, user 2, etc. during the full host registration. This for me had streamlined the host registration when we are adding new hosts to the FOG database and imaging new computers at that point.

I will be updating to 1.3.5 as I just read about the update after I posted this question. The link to creating the Custom FOG Registration is here:

https://wiki.fogproject.org/wiki/index.php?title=Create_Custom_Fog_Registration_menu

Modifying the init files for fog 1.0 and higher are explained here:

https://wiki.fogproject.org/wiki/index.php?title=Modifying_the_Init_Image

In the first link, you can see what options you can remove. Second link explains how to modify the init files for different versions of FOG. Hence my question regarding the last step to mounting the init file into the initmountdir in terminal it just goes to the help options for mount. Really weird. Is there an easier way now with version 1.3.* ? I hope this makes sense now.

george1421

@JGallo As for excluding questions you will need to “adjust” the fog init scripts for that.

Because the virtual hard drive (init.xz) is compacted you will need to expand it and then loop mount the expanded virtual hard drive to interact with it. Unfortunately that is still true today. I’ve had to do that a few times to “tweak” things in the fog scripts.

I just skimmed the first link and it appears a bit stale. The second link is spot on, and the one I referenced when working with the inits. Yes you need to (unzip) then mount, make your changes, and then unmount and finally re(zip) up the inits.

george1421

@george1421 I just remembered there are postinit scripts now. Depending when they are called, you may be able to overwrite the fog.registration, with a patched one each time the FOS engine starts. That way you would never have to touch the inits and when you upgrade the script will stay as you placed it because its never in the inits to begin with. I even wrote a quick guide on this: https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins

@Senior-Developers for the postinit scripts, when are they called and can we patch/replace a fog script in the inits on the fly?

Tom Elliott

@george1421 They’re called when fog is called. So yes, you should be able to overwrite any of the scripts fog calls before FOG actually calls them.

george1421

@Tom-Elliott Nice so depending on what FOG is doing at the time, you can swap out/overwrite any fog script other than fog. That should fit with the OP’s plans nicely and not require unsealing the inits.

JGallo

@george1421 Great. I will have to tinker around with the post init scripts see if I can successfully achieve those changes I’m looking for. I will go over your guide and eventually take a shot at this. Thank you.

george1421

@JGallo How I would go about this is as such

Temporarily extract and mount the inits on the fog server using the guidance from the wiki.
Copy the required FOG original registration script from the mounted inits to /images/dev/postinitscripts
Review my script because the postinitscripts are called on each boot up of the FOS engine. In my tutorial there is a master switch statement and what you want to do is copy the original file you copied to the /images/dev/postinitscripts back to the FOS hard drive only during registration. This will allow you to “patch” the FOG supplied scripts with the one you will alter in /images/dev/postinitscripts.

JGallo

@george1421 Hello, so I have been pulling my little hair I have off my head because for some reason my custom script are not being called nor are the changes I make within the init files just to see if it works. So this is what I have done:

Mounted init and init_32 and copied the fog.reg.man script to desktop. Unmounted inits
Created a script in /images/dev/postinitscripts/fog.custom and pasted everything from fog.reg.man on desktop. Modified fog.custom to reflect the changes I want.
Modified the fog.postinit script in /images/dev/postinitscripts/fog.postinit to call fog.custom
Boot a computer to fog and test my script. No luck. I noticed that postinitscript is being skipped
So just for the hell of it, I mounted the inits again and placed a copy of fog.custom in the bin folder and modified fog script to run fog.custom instead of fog.man.reg by modifying the fog script. unmounted inits and tried again. No luck.
For some reason nothing changes. When registering a host it asks me questions I deleted in the fog.custom script that replaces the fog.man.reg script. So I went ahead and remounted the inits and this time just for testing modified the funcs.sh in /usr/share/fog/lib of the inits. I figured this would be a good idea to see if my changes are actually working. All I did was add a couple of lines of text to the displaybanner inside where the credits are. Saved and unmounted and tested one more time. No luck.

Please keep in mind I’m learning bash scripting as I’m modifying these things and by all means no expert at scripting but interesting stuff when diving into FOG here. In any case, I am having trouble getting any changes made at this point. I might have to just restart from scratch and try again. Given what I have done, am I missing something here in the steps on getting my script to be called properly from the postinitscripts? Thank you.

george1421

@JGallo I have to step out of the office for a few minutes, but I will update you when I get back. You may need to do some advanced debugging.

Since you are messing with the registration process and there is no debugging process around registration we will force the issue. What you need to do is set this kernel parameter in the global settings for FOG isdebug=yes This will instruct the FOS engine to load and then drop to the command prompt on the target computer. This will allow you to test different parts of your code in a controlled execution. Once you have your script perfected then we can work on delivery to the target computer.

Understand that by putting the isdebug=yes it will have an impact on image deployment until the value is removed. But for what you need to do next is the easiest way to get it working.

When you get dropped to the command prompt on the FOS engine, key in fog to start the registration process, if you hit an error press ctrl-C to exit. Fix the issue and then key in fog again to start the debugging session over again.

Just be aware you are waking on uncharted territory so there may be a few pits along the way. Just stick with it and we will get it worked out.

george1421

@george1421 To setup the debugging tools for debugging registration I want you to collect/do the following things.

Install notepad++ its a much cleaner text editor than notepad.
Install putty on your windows computer, you will use this to connect to FOS.
Install the following kernel parameter isdebug=yes into FOG Configuration->FOG System Settings->General Settings->FOG_KERNEL_ARGS

Once that stuff is setup then:

PXE boot an unregistered computer and select manual registration
FOS should boot and then display a page or two of instructions but eventually drop you to a command line prompt.
Key in ip addr show and note the IP address of the FOS engine
Key in passwd and give root a (any) password. This will be only temporary since FOS runs out of ram. Upon a reboot the password will be gone.
Now that FOS’ root has a password you can use putty to connect to the FOS engine. Putty will help you with copy and pasting your updates into the fog.reg.man file.
Now update the fog.reg.man with your fixes (copy and paste from notepad++ works really well here).
Start the registration process by keying in fog at the FOS engine command line. If something goes sideways press ctrl-c to exit out of the script.
Edit your changes in notepad++ and then past into fog.reg.man.
key in fog at the command prompt and debug again.

Once you prefect the fog.man.reg file then we can work on delivery to the target computer using the post install script method.

JGallo

@george1421 Sweet. So my changes work via this method. I can confirm that it’s exactly what I would like the fog.man.reg to do. At first I had trouble using vim since it’s been many years since I have used it and had to go online to get a quick refresher on it’s operations. I still was unable to copy and paste from Notepad++ into putty. Is there a special way to do this?

What I did is just stay in putty and use vim to manually edit the changes. It wasn’t much but mainly just deleting lines of code that essentially represented items used during the full host registration. Checked the fog database after it successfully registered and sure enough it’s in the database.

george1421

@JGallo said in Custom Full Host Registration for 1.3.4:

Is there a special way to do this?

This part is easy. Copy from putty, start up vi and then enter insert mode and right click and putty will paste in the contents of the copy buffer.

OK now that you have a solid and working change to the fog.reg.man. Place an unedited copy of that file in /images/dev/postinstall scripts directory on the fog server and then edit it to match what you changed in the FOS engine. The part we haven’t created yet, will copy that file to the FOS engine during the boot up of FOS.

I have not done this part yet, but I will work on it tonight. For debugging tomorrow you will need to reinsert the isdebug kernel flag. But for now you can remove it so that FOG functions normally.

george1421

@JGallo Well this is what I have so far. It hasn’t been debugged, its not much more than a mash up of already published code. You will use the same process as you did before to debug this code.

For future readers of this thread: The script below is more than the OP really needs for this specific task. I've included the full script which will eventually be turned into a tutorial page for other that may want to extend and use the full capabilities of the postinit system.

Create the Patch action file on the FOG server.
This code will copy your patched registration file from the FOG server to the FOS engine, overwriting the original fog.reg.man. You must call the patch file fog.reg.man.fix

touch /images/dev/postinitscripts/patch.fullreg
chmod 755 /images/dev/postinitscripts/patch.fullreg
vi /images/dev/postinitscripts/patch.fullreg
Paste in this code:

#!/bin/bash

dots "Patching Registration files"
debugPause

cp -f ${postinitpath}fog.reg.man.fix /bin/fog.reg.man

dots "Done Patching Registration files"
debugPause

Create the FOG selector script.
This script will only call the patch if a manual registration is selected. There is no need to patch the registration file at any other time. It won’t hurt to do the patch each time since the original script is only used during manual registration.

touch /images/dev/postinitscripts/fog.postselect
chmod 755 /images/dev/postinitscripts/fog.postselect
vi /images/dev/postinitscripts/fog.postselect
Paste in this code:

#!/bin/bash

. /usr/share/fog/lib/funcs.sh

# place script commands here that should execute every time for every FOS action


# I added some additional check here just in case you wanted to highly customize the postinit script's actions. This section is not mandatory.
if [[ -n $mode && $mode != +(*debug*) && -z $type ]]; then
    case $mode in
        wipe)
            # fog wipe disk
            ;;
        checkdisk)
            # fog check disk
            ;;
        badblocks)
            # fog disk surface test
            ;;
        autoreg)
            # fog quick registration
            ;;
        manreg)
            # fog full registration
            . ${postinitpath}patch.fullreg
            ;;
        inventory)
            # fog full inventory
            ;;
        quickimage)
            # fog quick image
            ;;
        *)
            # all other generic operations
            ;;
    esac
    # place script commands here that should be run for any of the utility functions
else
    case $type in
        down)
            # fog image deploy
            ;;
        up)
            # fog image capture
            ;;
        *)
            # the code should never get here, we'll just add so the script doesn't break
            ;;
    esac
    # place script commands here that should be run for either image capture or deploy
fi

Update the fog.postinit script to call our new selector script.

vi /images/dev/postinitscripts/fog.postinit
Append the following to the end of the fog.postinit script

. ${postinitpath}fog.postselect

That’s about it.

Just a reminder this has not been tested or debugged. I can guaranty there are at least a handful of bugs in it. But in general this is the concept to patch fog original scripts with custom scripts without having to unpack, patch and repack the inits each time.

JGallo

@george1421 Thank you. Learning new stuff as I go along. This FOG server is a test server. I have another one running right now using storage nodes but it’s on 1.2 and hence why I’m testing all this out first prior to making the jump over the summer.

JGallo

@george1421 So everything is changed here and for some weird reason the postinitscripts are being skipped even in debugged mode. Going to start over and then make these changes. Strange that the postinitscripts are skipped so I will try again and see what happens. I did start with 1.3.4 and upgraded to 1.3.5 since update came out during the time I have been experimenting with this. So a clean start will resolve any unknowns.

JGallo

@george1421 So did a full install of both Ubuntu 16.04 and FOG 1.3.5 and followed these steps. Placed the debug flags and when running fog from a test computer it states “Post init scripts …skipped” So it’s obvious FOG is skipping everything here for post init scripts. I did notice that you named fog.reg.man.fix but I went ahead and changed the file name to reflect that. Original file in the /bin folder is fog.man.reg not sure it makes a difference that FOG is skipping the scripts.

Does the post init scripts need to be triggered somewhere or is it enabled by default? I just did a fresh install in the event I might have changed something accidentally. So as of right now there is a fresh install of FOG and Ubuntu. Nothing has been tampered with the inits so basically I just created all the files in your steps and made changes to the fog.postinit script. Thank you for your help on this. I hope after this is successful, the Wiki page is updated for the Custom Host Registration to reflect 1.3.5 version of FOG so that others can use this.

george1421

@JGallo Well the next step is for me to unpack the inits and see why not/what conditions are the postinst script are called. It was my understanding that they were called on every startup of the master fog script. I wasn’t aware there might be a conditional on the call. Give me a bit and I will have some time to check into this.

I agree about the wiki update. What typically happens is that we will write a tutorial and then open discussion on the tutorial. Once the tutorial has been proven then the info is gleaned and move into the wiki. That way once it hits the wiki we know for sure it will work for people.

JGallo

@george1421 I will take a look in there as well. I’m very curious now myself diving this deep in the Rabbit hole.

Custom Full Host Registration for 1.3.4

Server

Client

Description

186

11.6k

17.1k

154.6k