@george1421 ok thanks for the information

@tom-elliott
Thanks Tom

There are a couple of issues that have come up since 1.5.4 has been released that have been fixed in 1.5.5 (still unreleased at this time).

Roll your FOS kernel back to 4.15.2 to get past the mbr/gpt issue. Make sure you download both the 32 and 64 bit PC kernels (not ARM). Edit the www.conf file to update/include these settings, then reboot your FOG server. pm.max_children = 35 pm.max_requests = 2000 php_admin_value[memory_limit] = 256

If you are having issues with multicasting then we will need to have you switch to the 1.5.5 working branch to get that update.

@junkhacker That’s probably the best path to follow actually. There’s no rush for us to purchase everything at once. Worst case we have enough nodes now to get us by if we do need more. Thanks again for the help!

@dholland said in "Copy" image to repository:

I have my fog server at one site, and a fog repository at the other site.

Lets makes sure our terms are the same.

You have a FOG Server at your HQ and a FOG Storage node at the remote location? If this is the case if both the FOG Server (master node) and the Storage node are in the same storage group then replication happens automatically.

In addition at your remote location you will configure the dhcp scope to pxe boot from the IP address of your FOG Storage node.

The last bit of magic you need is to install the Location plugin. Then allocate each server to a plugin location. Finally when you register target computers you will need to assign that target computer to a Location. That way the target computer knows where to pull its image from.

During the pxe boot process the target system will need to make a http lookup call to your FOG Server at HQ but all file transfer will happen with the local storage node.

@george1421 @Wayne-Workman
thanks guys, originally the idea was more so that i could have a stable image with an IP for the fog server that could interface with a machine deployed now, to a server used in the future. But yes, ultimately I’m trying for a seperate box/vm to run fog for those reasons at each site. I’m just coming into a situation though and there is already excessive amounts of dedicated boxes that run pseudo important tasks, but maybe consolidating those will give me some hardware to run fog on anyways. more of a project is all.

thanks though!

@vascomorais Seems like your question has mostly been answered, but I wanted to pipe in on your comment ‘I can ask the forum’. YES! These forums are amazing. There are numerous people(Including senior developers) that will respond quickly and intelligently and assist you with problems you have with the system. I can’t say enough good about this community.

Hope FOG works for you, it’s been a lifesaver for me and my organization!

Philip

@jpaul As a test place a dumb (unmanaged) switch between one of the troubled target computers and the building switch and try it again.

If this works, then you need to get with your networking admins to check the network switches to ensure that (if) spanning tree is enabled, you are using one of the fast stp protocols (RSTP, MSTP, fast-STP, or what ever your switch port manufacturer calls it).

@skydraw35 said in Host Registration:

I put the background and it work in Legacy/Bios for me !
I have a last question, when i up/receive my image, can i put the uefi ?

Not sure I follow you here. From the sounds of it registration works for you when BIOS/Legacy booted?

Are you asking if you register it via BIOS can you then deploy/capture images in UEFI mode?

I would think so, as long as you set the host machine to boot UEFI and the iPXE menu loads up. I dont think the registration of the machine is tied to BIOS/UEFI mode at all. Images and PXE booting are however, so you couldnt for example (at least not easily) capture a UEFI image and then deploy on a machine BIOS booted for example.

With the change you made to DHCP, you should test and see if UEFI now works too for registration.

Disable Bitlocker was no alternative. That’s the result of my tests today.

At first I tried to only unlock the bitlocked drive, but this will not withstand a reboot. So my unlocked image gets locked again when I reboot.

When I disable BL that means I have to remove the BL encryption, so that the dd in funcs.sh ( dd if=$part bs=512 count=1 2>&1 | grep -i ‘-FVE-FS-’ ) is not able to find the BL-signature.
But that would mean I have to deploy truly clean images and encrypt EVERY deployed image afterwards. This is a no-go. It costs time in encryption and (even worse) it creates one dedicated key for every new deployed computer.
We need to use one remotely stored key for all deployed computers. That makes best sense in our use-case an I cannot change that decission. TPM will not work for us and would no make sense either as we need to have that mentioned key. Windows update will not hesitate us here … its an embedded W7 for dedicated systems.

Finally I patched funcs.sh (uncommented that bitlocker check) and made a new init.xz of it.

So my remaining question here:

How I have to use the setupcomplete.cmd correctly in terms of:

receive the new hostname . Here my first attempt was to wait some time as I observed that snappins take about some minutes until they get delivered … Will that naming take same time? set a static IP which depends from hostname ( I already have prepared a batch file for that …)

Will that all have to go into setupcomplete.cmd?
How and when will that get executed?

Regards

@quinniedid which is what I guessed. 🙂

From a security standpoint I dont see using NFS for imaging as an issue. As mentioned you can set it to allow only from a specific IP range. That should be enough to prevent issues (if a adversary is already on that subnet you have bigger issues). Especially if you dont have sensitive data in the share and if your FOG server is behind a firewall.

Samba would have the ability to allow only connecting from approved users or groups, the problem with that is passing the credentials to connect.

In Clonezilla I used to capture and deploy via SSH, which I really liked, but havent had any issues with how FOG handles it via NFS.

Your first warning, as it seems you have figured out, is I think kind of a basic way NFS works. Client machines have to be able to see/query the server for the share to use it. The second warning is just an extension of that, whats the point in knowing the share is on the server if you cant mount and use it.

Its a windows-service executable (exe) which I have to call with arg /install to install it.
Normaly I would install this by hand in the mother-image I deploy to all clients. But the development of that service delays, so I have to postpone that installation.
Before the install-call of the executable I have to remove the write-lock of the partition, means I have to call another system-executable in advance. After a successful installation I want to reboot.
The SW is an cmake based development. I have no cmake configs which created a Visual Studio deployment project (msi - even if an msi would be good for doing this … I have my doubts) so I have to create this afterwards in the Visual Studio. That is not a good attempt at all, no other co-worker will accept that sh***. So I am looking for an easy-going way … maybe WiX will get it. I have to read the docs, but if anybody has some better suggestions, please tell me.

@jla This is fixed in FOG 1.5.3. Because 1.5.3 was released days ago, and this post from 30 days ago says it was fixed in working-branch: https://forums.fogproject.org/topic/11875/snapin-upload-limit-of-8mb-is-too-small So my advice to you is update to 1.5.3 and see how it goes.

@wayne-workman Ok cool, I will look into it, Thank you.

@george1421

Yes, sorry to have disturbed you

@george1421 I am pretty sure it comes down to the Nvidia NVS 310 GPU’s for me. It may even come down to the specific make/model of them, but all of my Dell Precision T3620’s have them. The i7-6700 in each also has built in Intel iGPU.

The NVS 310 has 2x DP connections, and when connected to either the UEFI menu renders scrambled and vertically smashed. Switching to a motherboard output, using the iGPU, it renders as expected. Come to think of it, it was also scrambling and condensing the ESXi installer…at the time I presumed it was ESXi, but now I am certain it was the specific GPU.

You may even recall me “complaining” that the text size/resolution was different in UEFI vs BIOS. This is not the case using the iGPU for me. Now BIOS and UEFI are identical in size and format.

@george1421 said in iPXE Menu Colors Help:

I know messing with the iPXE colors is a bit mind blowing

Its especially hard when half the settings dont change anything because your GPU/background removal has rendered them moot (and your not aware of it). For me the problem was even with documentation and going through it meticulously as soon as I would start to wrap my head around it I would make a change and nothing would happen (or something other than expected), which would lead to presuming I didnt have my head around it. For example setting rgb either has no effect or results in transparency or a default color when in fallback mode. So imagine setting an rgb value to what you know is blue and getting white instead. Makes you question things lol.

After switching GPU’s and getting it to render in normal mode and not fallback, I have sorted out the formatting and added my own background.

Like you I have the multi-gpu setting on auto, have been using BIOS 2.6.1 and 2.8.1 (thats how long I have been working on this lol) and had leading up to this a single monitor connected DP to the NVS 310 (now the iGPU motherboard DP port).

To be honest, if it was my personal computer I would likely look into firmware updates for the NVS…but in my case I am happy just using the iGPU for staging. Thanks for the input

@steveo (I’m only considering creating fog storage nodes using fog) well since you have so many and they are all physical there should be a way to use FOG to clone the storage nodes. I need to think about the best approach here. But you should be able to install the OS, and at least download the fog repo to the system.

Here is where it get into some speculation.

Now when you install fog, it creates a .fogsettings file. The .fogsettings file lists all of answers to the questions you supplied when you first installed fog. So when you reinstall fog like during an upgrade the installer will reference that file instead of asking the user questions over again. I wonder if we can leverage that by dropping that file in the proper location during storage node image deployment. Then running the installer with the -y command post deployment?? The only caveat here is that you should only install FOG once the storage node has its forever IP address. There is a script to reset the IP address after the fact to. Its just depends on what ever is easiest. You also should probably consider how you will seed the storage node before you send it out to the remote location.

Also during image deployment, you can have the fog master node give the fog storage node its name. Once your storage nodes have been created you won’t need them in the fog database unless you want to reimage them again.

With that many storage nodes, you might consider setting up a dedicated mysql server. Remember that storage nodes don’t have a local database, it uses the database on the master (root) fog server. That will be 400 open connections.

@tom-elliott I expected that may be the case. I did not mean to imply any issue, just observations in case someone is impatient (I almost tried a reboot while it was on #2).

Now its back to trying to get the colors of the menu the way I’d like (https://forums.fogproject.org/topic/11972/ipxe-menu-colors-help).

Thanks