SOLVED Custom Full Host Registration for 1.3.4

  • Moderator

    @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 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 Sweet. So my changes work via this method. I can confirm that it’s exactly what I would like the 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.

  • Moderator

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

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

    Once that stuff is setup then:

    1. PXE boot an unregistered computer and select manual registration
    2. FOS should boot and then display a page or two of instructions but eventually drop you to a command line prompt.
    3. Key in ip addr show and note the IP address of the FOS engine
    4. 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.
    5. 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 file.
    6. Now update the with your fixes (copy and paste from notepad++ works really well here).
    7. 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.
    8. Edit your changes in notepad++ and then past into
    9. key in fog at the command prompt and debug again.

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

  • Moderator

    @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 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 script to desktop. Unmounted inits

    • Created a script in /images/dev/postinitscripts/fog.custom and pasted everything from 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 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 script. So I went ahead and remounted the inits and this time just for testing modified the 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.

  • Moderator

    @JGallo How I would go about this is as such

    1. Temporarily extract and mount the inits on the fog server using the guidance from the wiki.
    2. Copy the required FOG original registration script from the mounted inits to /images/dev/postinitscripts
    3. 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.

  • @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.

  • Moderator

    @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.

  • Senior Developer

    @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.

  • Moderator

    @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:

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

  • Moderator

    @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
    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:

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

    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.

  • Moderator

    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.