Custom Full Host Registration for 1.3.4

[george1421]

@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"
debugPause

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

echo "Done Patching"
debugPause

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.

[JGallo]

@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 fog.man.reg file to inspect it and confirm the file copy?

[george1421]

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

[JGallo]

@george1421 So placed the debug flags back. Once the patching was done, I hit control-c and inspected /bin/fog.man.reg 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?

[george1421]

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

[JGallo]

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

df -h

and got

filesystem             Mounted on
/dev/root                 /

[Tom Elliott]

@george1421 said in Custom Full Host Registration for 1.3.4:

echo “Installing Patch”
debugPause

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

echo “Done Patching”
debugPause

I might recommend a script of:

currfile="/bin/fog.man.reg"
newfile="${postinitpath}fog.reg.man.fix"

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

echo "Testing path for our fixed file at ${postinitpath}fog.man.reg.fix"
debugPause

# Test path and run copy if found and matched.
if [[ -r $newfile ]]; then
    echo "Found file preparing to copy"
    debugPause
    cp -f $newfile $currfile >/dev/null 2>&1
    [[ ! $? -eq 0 ]] && echo "Copy Failed" || echo "Copy Succeeded"
    debugPause
else
    echo "Failed to find file sorry"
    debugPause
fi

[george1421]

@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/fog.man.reg and not fog.reg.man

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]

[JGallo]

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

[Tom Elliott]

@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 fog.man.reg file and let FOG handle it like it normally would.

[george1421]

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

[JGallo]

@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/fog.man.reg That way as @george1421 has said to prevent any updates from replacing the script by accident.

[JGallo]

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

[Tom Elliott]

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