FOG Configuration->iPXE Menu Settings->PXE Menu Timeout

@jgallo
in User/Channel to post to you either choose to sent it to a user or a channel.
You are setting the destination, the access token is going to make it send from your user. This integration doesn’t create a bot like other slack integrations. You could create a separate slack user called fogbot to connect this integration and that would make it send as a different user.
But lets say you don’t do that, here’s what will happen in 2 different fixes

So if you change User/Channel to post to to @fogbot

then it will send updates from your slack user in a direct message to fogbot in slack.

If you change User/Channel to post to to #fogimaging then updates of imaging actions will send from your slack user to the #fogimaging channel.

Hopefully that helps as I’m guessing that you’re thinking that you’re setting a user to post as because many other slack integrations require that. This one is a bit more basic as it just uses the user in the access token and sends it to a choice of destination.

So think of access token as the source and User/Channel to post to as the destination

Just bumping this, since nobody has responded yet.

The issue is that both iPXE (ipxe.efi) and the FOS linux kernel (bzImage) are not signed. So secure booting is not supported natively by the FOG Project.

In contrast Ubuntu has a signed shim and grub kernel they use to jump start into the ubuntu linux kernel. If someone was a little skilled they could probably make iPXE and FOS boot using a similar shim.

@greg-plamondon said in Windows Boot manager set as default after imaging:

Windows Boot Manager after successfully imaging a PC.

My bet is after FOG pushes the image and the workstation reboots, LAN will still be set until Windows OOBE runs, then windows set the boot order to WBM. I’ve seen this happen on my VM I use for MDT reference image build.

If you were using Dells, Dell has a CCTK tool you can use to reset the boot order.

A little google-fu shows that this is a particularly annoying issue when you have a dual boot computer. One solution that was posted was to set a firmware password once the boot order is set. From the one post I saw, if there is a firmware password, windows can’t mess with firmware settings.

@igorpa2 Well with Normal FOG servers and Storage Nodes there are some things you need to keep in mind.

Both Normal and Storage nodes and support pxe booting of clients. You would point the dhcp server scope to boot from the fog server that is closest to the client. The pxe booting client computer must be able to contact the full fog server during pxe booting to find out where it’s assigned fog server is located. Storage nodes must be in contact with the main fog server 100% of the time. All of the file transfers will happen between the client and the assigned storage node. You can only capture images to the master fog server. Storage nodes can only send images to target computes. For every computer that the FOG service is installed, it must be able to react the master FOG server to check in for waiting tasks. The Location plugin can be used to assign target computers to specific storage nodes. If the location plugin is not used then a random storage node will be assigned to the target computer.

The idea of a normal or master FOG server and storage nodes are to place storage nodes at remote locations behind sometimes slow WAN links. The remote clients would then load the pxe booting and imaging files from the local FOG server, not needed to pull the imaging across the slow WAN links. You can also use the master node and storage node on the same campus for load sharing if you are sending out a large number of unicast images to many clients. But then if you are imaging many clients at one time, multicasting is a better way to image.

BTW you can mark it as solved. Got it up and running from the info you guys gave me thank you!

@aperiamb Try disabling the firewall as a test (and leave it disabled while we try to figure out what is the cause here so we don’t have to go back and forth)

I personally suspect PHP-FPM to be the real culprit, a PHP error would produce a blank page on index.php (as opposed to an apache error page which will give an error code)

What’s the output of

tail -50 /var/log/php-fpm/www-error.log

and

tail -50 /var/log/php-fpm/error.log

@sebastian-roth OP also mentioned separate virtual and physical environments. It just occurred to me he can use the physical server for his physical subnet utilizing one of the NIC’s and just spinning up a linux VM for FOGing on his Virtual subnet. No additional cost this way. Good thinking.

@fernando-gietz I feel foolish now. This taught me the lesson that I shouldn’t change multiple variables when trying to troubleshoot an issue.

Here is a screen shot of my working config:
0_1529084567169_fogworks.PNG

I think I had an incorrect group search DN set. When I put the correct DN I also messed around with the Group Member Attribute. I changed it back to sAMAccountName and presto! Thanks for everything boys!

Thanks I figured as much but was wondering why my storage nodes only had minimal traffic between them even though i had re-uploaded an image.

@george1421 Just went through the UBNT thread, that appears to be working! One thing, in case others come across this, that tripped me up was in the command there are " written out. At first, I thought this was something to do with the character escaping on the forums but it is not, you literally need the command as follows:

set subnet-parameters "filename "ipxe.efi";"

You can also do this via the Config Tree in the GUI, just copy everything between the first and last double quotes and paste into the subnet-parameters section of the subnet.

@george1421 I appreciate your assistance here! I guess I will be going to Ubiquiti to see if I can find/file a bug report to fix that up.

[Edit] Not sure why, but I can’t seem to mark your post as the right answer… I’ve marked mine summerizing everything instead. Have an up-vote though 🙂

Follow up documentation from UBNT Help

Notes
In the example above the custom option string requires quotes to be injected directly into the dhcpd.conf. As literal quotes are not allowed in the cli command we replace our quotes with the special entity format for a quote " this will be translated back to a literal quote when building the dhcpd.conf

While I don’t use IE, can you white list the FOG URL in your IE pop-up blocker? I would think there should be a way to allow pop-ups from specific web sites since many responsive web sites use these type of pop-ups.

Ok, found the problem. I didn’t realize that one of the other guys had setup the 2 boot options in the Superscope options and I was setting them in the Scope. This has been sorted.

Sorry to waste your time and thank you for the quick reply.

@tom-elliott I am willing to try I am already at 1.5.3 on SL69…

so writing with george1421… I issued those commands.:

git clone https://github.com/FOGProject/fogproject.git
cd fogproject
git checkout working
cd bin
[root@fog:/opt/fogproject/bin ]% ./installfog.sh
installing…

Yes. it is working !
file /etc/httpd/conf.d/fog.conf was rewritten correctly.

then I switched back to the master
git checkout master
thank you all.

@quinniedid Sure!

Base steps were I created a new image in GPT format.

Afterwards, on the FOG server itself I edited the config file located at /var/www/fog/service/ipxe/refind.conf

Below are what I have the values at. This was after some troubleshooting so some may be back to their default values.

timeout -1
scanfor internal,external (I also have both lines commented out at the moment)
uefi_deep_legacy_scan is uncommented
scan_delay 5

From my memory that is all that is changed. After the imaging is completed in UEFI, it will boot straight to the OS instead of pushing itself through FOG and/or rEFInd.

Hope this works for you!

I’d recommend running nothing except FOG on your FOG server. We’re not able to troubleshoot integration with other 3rd party software, that’s on you.

Yes, I also think that this stick is faulty. I posted this question here hoping that it was not the case.

Anyway, thank you very much for the answers guys.

I’ll just use this PC for some other project. Thank you all again.

Bye

@george1421 Your suggestion worked! Thank you very much.

@george1421 George, thank you. The issue has actually been resolved. For some reason, checking what was using .1.25 did not cross my mind. As soon as I did a scan of our network, I found that someone had booted up our old imaging server which was located at 1.25. Once I turned it back off, Fog returned back to normal.

Issue has been resolved!