Custom Full Host Registration for 1.3.4
-
@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.
-
@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.
-
@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.
-
@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 filefog.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.
-
@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.
-
@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.
-
@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.
-
@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.
-
@george1421 I will take a look in there as well. I’m very curious now myself diving this deep in the Rabbit hole.
-
-
@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 gotRunning 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
-
@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 continueI do have the debug flags. So something is causing my postinitscript to be skipped. LOL
-
@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.
-
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.
-
@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!
-
@george1421 After I type in:
df -h
I get:
Filesystem
/dev/rootalong 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.
-
@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.
-
@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.
-
@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 -
@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)