Custom Full Host Registration for 1.3.4

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.

george1421

@JGallo it may be in the funcs.sh (or what ever the name is) script too, if its not in /bin/fog directly.

george1421

@JGallo I just had a chance to debug the postinit scripts and they do run as advertised.

I setup a debug capture.
In the /images/dev/postinitscripts/fog.postinit on the FOG server, I just added a single line.

dots "Testing postinit scripts"

Then from the debug capture console on FOS, I entered fog
on FOS I got

Running post init scripts......
Testing postinit scripts...
Done...

So that is telling me the master postinit script is being called by the fog startup scripts.

In your post init scripts don’t forget if you have to reference your script path using the fog defined variable ${postinitpath}
Such as:

. ${postinitpath}fog.postinit

JGallo

@george1421 So what I need to figure out is why my fog.postinit script is not working. There is literally nothing in the postinit script other than the comments of what to change and basically the following:

. ${postinitpath}fog.postselect

I went ahead and tested a dots “Testing postinit scripts” and still the post init scripts are being skipped.

I get the following everytime:

*Running post init scripts…Skipped
*Press [Enter] key to continue

I do have the debug flags. So something is causing my postinitscript to be skipped. LOL

george1421

@JGallo So yours is saying skipped. In my case It ran.

If you are running this from a putty shell (I guess even the console for that matter) Press Ctrl-C to break out of the script. At this point we need to understand why it skipped. There is a check in the first few lines of the /bin/fog script that tests the existence of a file/path (stating from memory) and if that doesn’t exist it will print skipped and continue on. That I think is your case. We need to understand why that conditional is causing the postinit to skip.

I need to unpack the inits a work here to look at the code agian.

unpack not needed. Ref: https://github.com/FOGProject/fogproject/blob/master/src/buildroot/package/fog/scripts/bin/fog

recommendation, when you exit out after the skipped part. key in
df -h
and
echo ${storage}

and post the results. It looks like your mount may be failing.

Tom Elliott

Mind trying this patch out? @george1421 Your method worked because you were in an “init” “imaging” needed tasking, but I think the problem is storage information was never passed for registration type tasks.

I’ve fixed this in the working group.

@jgallo please try:
wget -O /var/www/fog/lib/fog/bootmenu.class.php https://raw.githubusercontent.com/FOGProject/fogproject/3adec9a54254a9d466e129417f16163f396c358a/packages/web/lib/fog/bootmenu.class.php

This should replace your bootmenu with one that will insert the storage information based on the “web” interface it’s passing through.

george1421

@Tom-Elliott said in Custom Full Host Registration for 1.3.4:

Your method worked because you were in an “init” “imaging” needed tasking,

True when I was debugging last night I was doing an debug capture. So of course it would have that variable set. Thanks for catching that one!

JGallo

@george1421 After I type in:

df -h

I get:

Filesystem
/dev/root

along with size, space used, etc. I assume this part must be in debug mode correct? I see Tom recommended something so I will give that a try as well.

JGallo

@Tom-Elliott So I got a chance to try the bootmenu link you posted and I get a chainlink error and could not boot: input/output error followed by the ipxe.org link. This is fixed by re-running the fog installer and then the ipxe booted normally. Not sure if I did that correctly but all I did was run that wget and it seemed like it downloaded the bootmenu.class.php.

george1421

@JGallo said in Custom Full Host Registration for 1.3.4:

I get a chainlink error and could not boot: input/output error followed by the ipxe.org link

What we need there is to capture this chainlink error. With that patched file installed call the following url from a browser and post the results here. http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00` That will provide us with the text that is used to create the iPXE boot menu.

JGallo

@george1421
#!ipxe
set fog-ip 10.170.200.20
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
iseq ${platform} efi && set key 0x1b || set key 0x1b
iseq ${platform} efi && set keyName ESC || set keyName Escape
prompt --key ${key} --timeout 3000 Booting… (Press ${keyName} to access the menu) && goto menuAccess || sanboot --no-describe --drive 0x80
:menuAccess
login
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param username ${username}
param password ${password}
param menuaccess 1
param debug 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain -ar http://10.170.200.20/fog/service/ipxe/boot.php##params

george1421

@JGallo And this what you get when you call the boot.php file with the mac address I gave you?

If so can you tail the apache error log and see if php is throwing an error. This IS an incomplete iPXE menu, which means that something is wrong with that patched file.

The head of a valid ipxe menu should look like this:

#!ipxe
set fog-ip 192.168.1.53
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
cpuid --ext 29 && set arch x86_64 || set arch i386
goto get_console
:console_set
colour --rgb 0x00567a 1 ||
colour --rgb 0x00567a 2 ||
colour --rgb 0x00567a 4 ||
cpair --foreground 7 --background 2 2 ||
goto MENU
:alt_console
cpair --background 0 1 ||
cpair --background 1 2 ||
goto MENU
:get_console
console --picture http://192.168.1.53/fog/service/ipxe/bg.png --left 100 --right 80 && goto console_set || goto alt_console
:MENU
menu
colour --rgb 0x00567a 0 ||
cpair --foreground 1 1 ||
cpair --foreground 0 3 ||
cpair --foreground 4 4 ||
item --gap Host is unregistered
item --gap -- -------------------------------------
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.keyreg Update Product Key
item fog.deployimage Deploy Image
item fog.multijoin Join Multicast Session
item fog.quickdel Quick Host Deletion
item fog.sysinfo Client System Information (Compatibility)

JGallo

@george1421 That is what I get. I will try to tail the apache logs and see if anything I can get there. If I restore the the original boot.php file, should expect different results when calling the boot.php file with the mac address: 00:00:00:00:00:00?

Custom Full Host Registration for 1.3.4

184

11.6k

17.1k

154.6k