@pastorn said in help with multi-cast deploy:

the DHCP is on windows server 2022

Can you please post pictures of the settings?

Hi,

I just rebuilt two proxmox debian 11 containers with FOG 1.5.10

Master node > install HTTPS
Storage node > install HTTPS

Install plugin Location

Master node and storage node are in the default storage group
Master node > default’s Master node

Create new location > location_1
storage groupe > default
storage node > defaultmember
storage node protocol> HTTPS

Create new location > location_2
storage groupe > default
storage node > secondary node
storage node protocol> HTTPS

Create snapin in default storage group with replication enabled

Configure one host with location_1
Deploy snapin > OK, it works

Configure one host with location_2
Be sure the snapin is replicated into the storage node
Deploy snapin > it doesn’t work
What am i doing wrong ?

Here is the snapin log

---------------------------------SnapinClient--------------------------------- ------------------------------------------------------------------------------ 03/07/2023 12:39:24 Client-Info Client Version: 0.13.0 03/07/2023 12:39:24 Client-Info Client OS: Windows 03/07/2023 12:39:24 Client-Info Server Version: 1.5.10 03/07/2023 12:39:24 Middleware::Response Success 03/07/2023 12:39:24 SnapinClient Running snapin snapin_1 03/07/2023 12:39:24 Middleware::Communication Download: https://xxxxxxxx//fog/service/snapins.file.php?mac=00:23:24:19:46:64&taskid=2 03/07/2023 12:39:24 Data::RSA ERROR: Certificate validation failed 03/07/2023 12:39:24 Data::RSA ERROR: Trust chain did not complete to the known authority anchor. Errors: La signature du certificat ne peut pas être vérifiée. (NotSignatureValid) 03/07/2023 12:39:24 Middleware::Communication SSL certificate chain error: Une chaîne de certificats a été traitée mais s’est terminée par un certificat racine qui n’est pas approuvé par le fournisseur d’approbation. 03/07/2023 12:39:24 Middleware::Communication ERROR: Could not download file 03/07/2023 12:39:24 Middleware::Communication ERROR: La connexion sous-jacente a été fermée : Impossible d'établir une relation de confiance pour le canal sécurisé SSL/TLS. 03/07/2023 12:39:24 SnapinClient C:\Program Files (x86)\FOG\tmp\file.zip 03/07/2023 12:39:24 Middleware::Communication URL: https://xxxxxxxxx/fog/service/snapins.checkin.php?taskid=2&exitcode=-1&mac=00:23:24:19:46:64&newService&json ------------------------------------------------------------------------------

@smazzola We need more information to be able to help. Please provide what has been asked or we’ll close this topic.

@Warsonix I really needed to get those laptops imaged asap, so I just used a USB-C to Ethernet adapter on those and it worked. I haven’t touched those laptops since then.
Funnily enough, I have to re-image them next week, so I’ll let you know what happens.
I have done a lot of changes to my FOG server since then, so it’s really going to depend on your setup too.

@tahitiju said in Multicast is very slow:

I try to deploy an image to some PCs but performance is very low (2MB/min) using multicast.
For the purpose of the test, FOG server (1Gb NIC), clients (1Gb NIC) and dhcp are connected together using a Linksys Switch ( 16 x 1Gb ports / unmanaged) .
Using unicast, performance seems normal (~1,5GB/min deploying 14 PCs).

A few things jump out at me with this. Multicasting can be very taxing on inexpensive network hardware. When you are getting 2MB/min how many systems are you multicasting to? Do you get the same performance when multcasting to 1 or 2 machines?

Multicast imaging moves at the speed of the slowest computer in the mcast group.

1,5GB/min is on the slow end of the scale. On a well managed 1GbE network, imaging to current hardware, I would expect about 6GB/min. If put your fog server on 10GbE network I would expect about 13GB/min. I’m only pointing it out that there might be something in your network infrastructure that is slowing things down.

A 1GbE network link will saturate with 3 simultaneous unicast deployments.

The FOG performance numbers displayed on the target computer are a composite number of how fast the fog server can pull the image off the disk, send it over the next, the client receiving the image, expanding it in memory and then writing it to disk. Any one component that is slow will impact the overall performance score.

@Tom-Elliott

It’s every device we’ve tired. We’ve tired both UEFI and MBR. iPXE booting is working with everything else we have and is able to utilize the NIC just fine.

Dropping down to the CLI, the OS can see and list the mac addresses just fine. It appears that it’s just however FOGs init/boot is looking at or for the MAC address is the issue.

@george1421 thank you very much

@Noseman The tools used within FOS (FOG OS doing all the hard work when capturing and deploying) are no official Microsoft certified software products but from open source community. They work in 99% of cases but I can imagine there can be special states of the filesystem or certain edge cases those tools simply cannot handle (yet).

Great you found a workaround!

@wass Since all of the boot loaders you mentioned are bios boot loaders and you are seeing the no configuration methods succeeded it sounds like the computer is in bios mode. Its strange that iPXE and bios mode computers are not able to configure the interface. For bios the boot loaders undionly.kpxe or ipxe.kpxe should work on 99.8% of all computers. Does this computer have multiple nic cards?

@kamburta Pretty sure this is known and fixed in the dev-branch versions of the FOG repository.

@repier89 Nice you got that external NIC adapter to try and see if it’s a network issue or now. And yes, we have a winner. 😉

Please schedule a debug deploy task for the HP Probook 450 G9 and boot into it. Run lspci -nn | grep -i net and post output here.

@Sebastian-Roth @rodluz

Thanks so much for the info, guys!

@Almeida I suggest you update to 1.5.10 or at least manually update the FOS kernel.

@KaiHerlemann Yes, @JJ-Fullmer is right there. The installer is not made to handle custom certificates properly yet. We never found the time to make this work reliably. But if you are good with managing this yourself you can still do it.

The whole topic is a bit complex due to the different tools and layers involved.

Basic web access to the web UI - just adjust Apache config as you like But along with that the iPXE boot loader is using HTTP/HTTPS to load the menu items. So if you switch to HTTPS you also need to compile your own iPXE binaries - not very hard: https://docs.fogproject.org/en/latest/development/fog-release/#ipxe (but use ./buildipxe.sh /path/to/your/CAcert.pem and skip the armsupport=1 if you don’t have ARM CPUs) Now this was the easy part. I started to write about the fog-client here but then realized I did so in the wiki already: https://wiki.fogproject.org/wiki/index.php?title=HTTPS#Custom_CA_and_certificates

I know, this is not ideal having to stich together the pieces from various sources and make up the rest yourself. So if you are keen we would appreciate if you document exactly what you do and we’ll add it to the official documents. That would be really great!

@KaiHerlemann said:

Usually we use ACME to create certificates.

I would not setup a FOG server open to the public. There are ways to get certificates through ACME without facing it to the web, e.g. opening ports only for the time of cert renewal on the firewall, doing cert renewal on a separate machine and copy those over and so on. Please consider wisely because FOG is not made to run on a public IP/hostname safely.

@JJ-Fullmer said:

I would suggest at install time NOT selecting ssl and then altering the config to use your custom certificate.

In the one hand I agree. Doing it this way you can go step by step. On the other hand if you do a fresh install (don’t if you have a running server) then I tend to suggest you enable SSL straight away because it will generate a SSL enabled Apache config for you and save you some time.

thanks @Tom-Elliott

worked for me in the fog.deployimage option
like this
params
param mac0 ${net0/mac}
param arch ${arch}
set username myuser
set password mypassword
param username ${username}
param password ${password}
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

The Problem with my previous approach was i tried do set this in one line
like

params
param mac0 ${net0/mac}
param arch ${arch}
param set username myuser
param set password mypassword
param qihost 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

make obviously no sense when i look at it now 😉

@LLamaPie Thanks for testing and letting me know.

@JJ-Fullmer I think I have determined this is a problem in an internal process with the api. Gonna try to narrow it down some more.

@Richarizard504 Then I may suggest you provide the full fog.log file from that client having the issue. We might find out what’s wrong with some more context.