@jamaal said in FOG API help:

One more question. How would I add location via api?

Not something I can properly answer. Though looking at the repo I think the @JJ-Fullmer’s powershell module does not handle locations: https://github.com/darksidemilk/FogApi/tree/master/FogApi/Public

@p4cm4n The short answer is that its possible. What you will need to do is create a customized version of the fog.man.reg file. ref: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg

If you know programming (helpful to understand process flow) but not maybe php you can make adjustments to this file bypassing the prompts and filling in the static details.

Then you can use a postinit script to replace the FOG issued fog.man.reg with your custom coding.

https://forums.fogproject.org/topic/14278/creating-custom-hostname-default-for-fog-man-reg

The last bit I need to think about a bit. I know if the FOG server passes a parameter to FOS linux after FOG does it thing (registration, imaging, etc) it will shutdown instead of reboot. I think the parameter is shutdown=1 I think… you can also set that in your custom fog.man.reg and have FOG shutdown after taking inventory. I know you can set it at a global level, but you might only want to shutdown after registration but not imaging.

Now I’ve worked on a few big imaging projects. I have used a custom fog.man.reg file to speed up registration. I’ve also made use of barcodes. For one project the computer name was a composite of the country, city LUN code, and then the dell serial number. In one case I created a barcode with the country and lun code (i.e. USNYC) on a bit of paper. Our workflow would be then when entering the name we would scan the paper then scan the dell asset tag on the computer and finally press enter on the keyboard, From there all of the rest of the FOG required fields were defaulted.

Another project we didn’t register the computers with FOG because FOG would not manage them once imaged. In this workflow we used the fog ipxe menu Deploy Image. We picked the image, the image would deploy and then using a post install script the name of the computer was calculated. The country and city lun codes were calculated based on the client’s IP address and then we use dmidecode to read the dell asset tag. So once we picked deploy and the image to deploy we did not touch the computer until it was ready to move to the user’s desk.

@bsawyers What is the output of ls -la /var/www/os There is something not right here. Either the apache doc root is in some other location or … something.

Thanks for the reply guys. I forgot to mention that the device either boots from a specific M2 drive (have tried other M2 drives and nothing), and if the drive is not present then it boots from the network. I already pxe booted winpe and some and some live linux distros in order to run the tools to attempt to resolve the firmware thing.

I was under the impression that though iscsi may not be a go, I could achieve the same result using an NFS share, I believe I saw some mentions of that in some of the threads that came up during my searches.

Independent of truenas I would like to get a nice setup going, though I have another vm running bareos for backups, FOG seems really convenient for backups, booting into diags, etc. In any case, I’ll read up on those 2 links and head over to the ipxe wiki to see if I can pick something up. Thanks again guys.

@tenorio-leandro You might start by telling us some specs: versions of FOG and fog-client as well as the Linux OS and version you use.

Are you sure you used the correct FOG server IP and webroot? See here: https://forums.fogproject.org/topic/13091/fog-service-setup-unable-to-install-ca-certificate

If you FOG Server is Ubuntu 20.04 or newer and you enabled HTTPS then you might need to use https://github.com/FOGProject/fog-client/releases/download/0.12.0/SmartInstaller_fixed-tls.exe

As well we have references that anti virus software can block the communication: https://forums.fogproject.org/topic/9489/client-11-9-will-not-install-fails-at-ca-certificates

@george1421 said in Doubt about boot in computer:

@tenorio-leandro For uefi yes its possible to boot from pendrive.

https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

Thanks, I will make this. Thanks a lot!

@smccloud Ok as long as you have it going, but seeing the error probably would have made me suggest that you install the dev-branch which supports debian 11 and ubuntu 20.10. But working is working…

I still think there is value in upgrading to the dev-branch to get support for imaging 20H2 and later images. The dev-branch is on 1.5.9.114 or later as of today.

I would also recommend that you install the latest FOS Linux kernels 5.10.x that is done under the Web UI->FOG Configuration->Kernel update. Just be aware if you update the kernel now and then install 1.5.9.114 you will need to redownload the 5.10.x series of kernels.

@george1421 Found the fix and got the servers updated. Thank you guys for your time!

@george1421 No worries, I was just curious! I think you’ve given me all the information I’ve needed. I appreciate your response time and assistance!:)

@luiztpd The rebuilding ipxe tutorial is here: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

Make sure you have the latest FOS Linux kernel -> Web UI->Fog Configuration-> Kernel update. You will want 5.10.x series of kernels for both x64 and x32 systems.

Lastly you can update to the dev branch (suggested if you need to deploy Win10 20H2 or later versions of windows) to get the fixes for those OS’) all you need to do is change into the git repository you downloaded then do the following:

git pull git checkout dev-branch git pull cd bin ./installfog.sh

That will update your fog install to the pre-release version of 1.5.10. That release is stable and will most likely be what 1.5.10 will be released as.

Now when 1.5.10 is released you will need to switch back to the master branch this way.

git pull git checkout master git pull cd bin ./installfog.sh

@ericdelpozo OK I understand your troubles and your idea.

I have one question. Are these computers both bios (legacy) and uefi or are they all bois or all uefi. uefi based computers are easier to boot via usb. But we can make it work both ways.

@george1421

Thanks for some advise what to look and search for. I will dig into CCTK for sure. I unserstand there are many things to do and there is no time 🙂 Good Luck and Thanks !!!

Thanks @george1421, will look into this especially the USB to ethernet (will have to purchase though).

@george1421 I will go ahead and start off with changing the root and the admin passwords. Those are the two that I was really wanting to change. Thank you for your time!

@george1421 said in Does FOG use or install the log4s?:

I do see two CVE alerts from 2018 and 2006 regarding log4net

Thanks George for bringing this up. We might look into updating or even removing log4net from the fog-client.

@george1421 That worked! I added the two additional tables to the export command and the “test” host was imported.

@brakcounty said in Newly captured images are being owned by "root" instead of "fogproject":

Well all of my other images in /images are owned by fogproject:root. If this isn’t a problem then I’ll leave it alone.

That’s done when you re-run the FOG installer. Just don’t worry about it. They’ll work either way.

@pamadmax Its great that you have it solved. Intermittent communications would also cause this pattern.

Just to clarify the point a bit about dual dhcp servers. If your fog server is on the same imaging network and its “the dhcp server” for your imaging network, then you don’t need a dhcp-relay service listening on this subnet. Actually you should clearly not have it listening on this subnet. You can have the dhcp-relay service on your router, that’s fine, but not listening on the imaging network’s vlan.

The issue is this, if the dhcp-relay service IS listening on the imaging subnet, the relay service will relay the dhcp request to your main server. With the FOG dhcp server also listening there is a chance that your pxe booting computer will get two OFFERS. One from your FOG server and one from the dhcp-relay service as a proxy for your primary dhcp server, hence the comment about 2 dhcp servers.

You have it worked out, so that is all that really matter here. Good going on finding the problem. I’m sure that misconfiguration on the LAG trunk was causing other strange issues on your network too.

@Pilar Please post pictures of the configuration in the web UI.