Custom Full Host Registration for 1.3.4

  • Server
    • FOG Version: 1.3.4
    • OS: Ubuntu 16.04
    • Service Version:
    • OS: Windows 7 Pro

    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.

  • Senior Developer

    @JGallo YEs, that is correct. rc-3 has the fix too and so it will remain going forward.

  • @george1421 @Tom-Elliott With the changes in 1.4.0-rc-2 that made us able to use the fog.postinit script with full host registration, those changes will be in the next release of FOG correct? I’m planning this summer to upgrade from 1.2.0 Definitely looking forward to this upgrade especially with the LDAP plug in.

  • @george1421 @Tom-Elliott I will go ahead and restore the fog.postinit script back to its intended use. Call the patch.fullreg script to reflect exactly what we are trying to do, that is to copy our custom script and replace /bin/ That way as @george1421 has said to prevent any updates from replacing the script by accident.

  • Moderator

    @JGallo Its a matter of personal style and what you might do in the future.

    But for your case, what I would do is this (as a compromise).

    What we put into the fog.postinit, remove it from the postinit script and put it into a new file cleaning out the fog.postinit from any extra code. Lets say you place Tom’s code into a file (in the same directory as fog.postinit) called patch.fullreg and then in the fog.postinit you then would call the patch file only with
    . ${postinitpath}patch.fullreg That way your patch code is maintained in its own container without the chance of it getting overwritten by a FOG update (as a FOG managed script might i.e. fog.postinit )

  • Senior Developer

    @JGallo The postinit script that the system calls is intended to be a “caller” system. Meaning you should use it to call other scripts, but it is still a script none-the-less. For your particular use case, I don’t think the “postselect” script is necessary. All you need to do is replace the existing file and let FOG handle it like it normally would.

  • @george1421 LOL wow and of course it works now. I’m glad this was figured out. Making the changes and testing the scripts I can confirm that it works.

    With that said, taking a step further, is the fog.postinit script suppose to have anything other than calling our custom scripts? Or should we skip the additional scripts (as you recommended earlier in the post ex - patch.fullreg, fog.postselect)? Once again thank you for taking a look at that. I’m glad there were some discoveries along the way that I’m sure will be useful for many others.

  • Moderator

    @JGallo Ok setting this up on my home dev box, I’ve come to the conclusion that this works as I outlined IF I would have frick’n spelled the manual registration file correctly.

    the real name is /bin/ and not

    Even Tom missed it because he copied my script to start with.

    Using tom’s script but with the proper file names it works. It was working with the file names I was using, except it didn’t overwrite the manual registration file.

    [moderator note, I’m going to correct Tom’s post to reflect the proper file names in question]

  • Senior Developer

    @george1421 said in Custom Full Host Registration for 1.3.4:

    echo "Installing Patch"

    cp -f ${postinitpath} /bin/

    echo "Done Patching"

    I might recommend a script of:

    . /usr/share/fog/lib/
    echo "Testing path for our fixed file at ${postinitpath}"
    # Test path and run copy if found and matched.
    if [[ -r $newfile ]]; then
        echo "Found file preparing to copy"
        cp -f $newfile $currfile >/dev/null 2>&1
        [[ ! $? -eq 0 ]] && echo "Copy Failed" || echo "Copy Succeeded"
        echo "Failed to find file sorry"

  • @george1421 I will wait. While in debug mode, I typed

    df -h

    and got

    filesystem             Mounted on
    /dev/root                 /

  • Moderator

    @JGallo well in this case the postinitpath should be set by the master fog script. If it is not set correctly then things will fall down.

    You could manually set it, but if you are still in debug mode, could you post the output of this command df -h at this point for the postinitpath to work, the FOS engine needs a connection back to the fog server over nfs to reach the script. Since the postinit script…

    Wait that variable needs to be set, because the main fog program calls the postinit by issuing . ${postinitpath}fog.postinit

    Instead of having you keep thrashing this around let me look at it tonight, there has to be something missing.

  • @george1421 So placed the debug flags back. Once the patching was done, I hit control-c and inspected /bin/ and looks like the original file because my changes aren’t there. I also echoed the postinitpath and it returned a blank line.

    Could I theoretically set the postinit path prior to cp the custom fog script? Or instead of using the variable postinit to manually enter the postinitpath?

  • Moderator

    @JGallo Right in the code I provided, if you are in debug mode it will pause just before copying the file and just after copying the file.

    On the pause just after copying the file press ctrl-c to break out of the script. Then inspect the file date. If its not correct then manually key in the copy command to see what error is thrown. I might suspect I have the source path off for some reason.

    You might also want to key in echo "${postinitpath}" on the command line (after the control-c) to see if the postinitpath is properly set.

  • @george1421 Yes. It is successful in echoing those words. I went as far as actually echoing “Installing my patch” and it works. LOL. So we know the script is being called but not too sure on the file copy. If I place the debug flags back, can I pull the file to inspect it and confirm the file copy?

  • Moderator

    @JGallo OK the forum really manged your code in the post.

    Let go back to basics. Insert this code in your fog.postinit

    echo "Installing Patch"
    cp -f ${postinitpath} /bin/
    echo "Done Patching"

    If that doesn’t work then we will need to install the debug kernel parameters again and figure out what is going wrong on the other end. If you see the Installing Patch in registration mode then we know the script is being called.

  • @Tom-Elliott @george1421 This is what I have as far as post init scripts:

    code for fog.postinit

    ## This file serves as a starting point to call your custom pre-imaging/post init loading scripts.
    ## <SCRIPTNAME> should be changed to the script you're planning to use.
    ## Syntax of post init scripts are
    . ${postinitpath}fog.postselect

    code for fog.postselect

    . /usr/share/fog/lib/
    # 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 ] && return
        if ]; do
            ]; then
                            ] && echo "$res"
    setIDs "imageid" "image" "" "" 20
    if ]; then
        while ]; do
        res=$(curl -ks --data "mac=$mac&advanced=$(echo -n 1 | base64)&host=$host&imageid=$imageid&doimage=$realdoimage&location=$location64&username=$user64" http://${web}service/auto.register.php 2>/dev/null)
        echo "$res"
        usleep 2000000
    . /bin/fog.inventory
    usleep 2000000

  • @Tom-Elliott Thank you. I went ahead and updated to 1.4.0-rc-2 and it seems like like post init scripts are running because I get a message that says Patching registration files and eventually states that it’s Done Patching Registration files. Unfortunately it’s not copying the file I have set up to copy. So we know that the post init scripts are running. Not sure if the copy script is working because when testing a host by trying to do a full register of a host I still get asked questions I removed from my custom

  • Senior Developer

    So I pushed up RC-2 for 1.4.0 in a semi-official manner rather than have you jump directly on working branch.

  • Senior Developer

    I’m sorry, you’ll need to install the working branch then. I’ve moved attemptLogin to fogbase now and it appears the changes I suggested, I overlooked that change sorry.

  • Moderator

    @JGallo It looks like line 1168 is causing the error in the patched boot menu file.

    From DM: The OP is also using the ldap plugin too. Only worth mentioning since the error being thrown is referencing attemptLogin().

    [editor note] I fixed the previous thread to include the error log in a code block for easier review[end note]

Log in to reply





Looks like your connection to FOG Project was lost, please wait while we try to reconnect.