Removing MACs from multicast task without starting over

[danboid]

Thinking about it, if you’re manually booting 50/60 machines all with passwords, I think 20 minutes is cutting it a bit fine. 30 minutes seems much more doable for that size of task so I think I’d prefer to use a 1800 second timeout as default.

[danboid]

I have created a gh ticket for this feature request:

https://github.com/FOGProject/fogproject/issues/496

[george1421]

@danboid said in Removing MACs from multicast task without starting over:

Do you want me to open a github ticket for this?

Well we need to look at what can be done today and what can be done in the future. So the quick answer is what we can do today to make things a bit easier for you right away.

As for the server wait before imaging that is a global setting in the FOG Configuration -> FOG Settings page.

The number of multicast clients are defined when you create the multicast task.

On the other site, for those clients that don’t make it in time for the stream I can create a one-off virtual hard drive where we can hard code a shutdown timeout and/or pass a parameter from the FOG server to set the timeout. The parameter passed from the fog server will still be static, but could be adjusted globally from the fog server. What would be missing is an admin editable field in the web ui. I’ll need to think about that for a bit. But it should be possible.

[Sebastian Roth]

On the client side the udp-receiver is used. Again there are two value of interest that should be used (I can’t say for certain because I haven’t looked at the FOS Linux code yet to confirm)
–start-timeout
–receive-timeout

Yeah that might be a good option to make clients shutdown after a certain amount of time. I’d suggest we use the same value we have in the web UI already (UDPCAST MAXWAIT) and shutdown clients after that time.

With some crude testing it appears that udp-receive will exit with exit code 0 on a successful reception and 255 on a receive timeout (–start-timeout) so we can trap when it unsuccessfully starts the stream.

Sounds reasonable.

I won’t talk much about udp-sender (FOG server side) as I think --min-receivers and --max-wait are already in use and adjustable as much as it makes sense. Receivers count is set to the amount of clients you have in your group (if done as a group deploy) and I don’t see a point in doing this any other way. This is one of two start signals: a) all clients are connected or b) max-wait time is over.

[george1421]

@sebastian-roth said in Removing MACs from multicast task without starting over:

I’d suggest we use the same value we have in the web UI already (UDPCAST MAXWAIT) and shutdown clients after that time.

I can see that, but the doubt I have is that I don’t think that value is passed onto FOS Linux since that (currently) is a server side parameter.

I won’t talk much about udp-sender (FOG server side) as I think --min-receivers and --max-wait are already in use and adjustable

Yes I’m not seeing any value in changing the server side because that is well established and working well. The only “nice to have” would be on the client side if they don’t get on the stream in time they will just sit and wait forever. It does sound like the OPs setup is a bit more complex since it requires an Imaging admin to enter a bios password to boot them into imaging. But that is a bit out of scope on this issue.

[Sebastian Roth]

@george1421 said in Removing MACs from multicast task without starting over:

I can see that, but the doubt I have is that I don’t think that value is passed onto FOS Linux since that (currently) is a server side parameter.

Absolutely right. That would be a next step to improve the way machines act when booted into a multicast task but can’t pick it up - either because the whole session times out on the server side or because a particular client is too late to join.

Anyone keen to draft the changes involved to get this to work?

@danboid You might want to update the github issue report to reflect things discussed here.

[george1421]

@sebastian-roth said in Removing MACs from multicast task without starting over:

Anyone keen to draft the changes involved to get this to work?

I’ll take a look at the FOS Linux side tonight. I have the build environment still setup at home when i was failing at integrating partclone 0.3.20 into the image.

For the kernel parameter to FOS, should we use MCASTMAXWAIT as the variable? If its not set then set the default timeout to 15 minutes?

[Sebastian Roth]

@george1421 said in Removing MACs from multicast task without starting over:

For the kernel parameter to FOS, should we use MCASTMAXWAIT as the variable? If its not set then set the default timeout to 15 minutes?

I had a quick look at the kernel parameters used so far. Looks like they are mostly in camel case, so you might spell it as mcastMaxWait.

I am not sure about the default yet. People are used to the behavior of clients waiting forever. While I do see this as a huge improvement to shut those down instead I am still wondering if changing the default could cause consequences in some circumstances?

And if we add the default I wonder if 10 minutes is better just so it’s the same default we use for --max-wait on the server side. But I am fine with 15 minutes too.

[george1421]

@sebastian-roth said in Removing MACs from multicast task without starting over:

And if we add the default I wonder if 10 minutes is better just so it’s the same default we use for --max-wait on the server side.

Ideally we would want the fog php code to manage this kernel parameter, but in the case the parameter isn’t set then give it this value is what I was thinking. The actual fix will require 2 parts. 1) in FOS coding (what I will work on) and 2) In the php code to add the parameter to the settings and then have the php code pass that kernel parameter on the multicast startup. That part is above my skill set it seams.

[danboid]

Oh so you can already configure the udpcast max wait in the current stable release? That’s good news. I have closed my github ticket because it focused on adding the max wait timeout. I’m happy enough with it being a global setting, I don’t need to change it per task.

I didn’t know to look for this setting until raising this problem here. I have mostly stuck to FOGs presets every time I’ve used it up until now, I just up the max number of clients, update the FOG kernel and tweak the DHCP config if required.

There doesn’t seem to be a guide to setting up multicast tasks in the official docs? Am I missing it? If there is such a guide it should mention adjusting this setting to suit your situation first.

[Sebastian Roth]

@george1421 said in Removing MACs from multicast task without starting over:

In the php code to add the parameter to the settings and then have the php code pass that kernel parameter on the multicast startup. That part is above my skill set it seams.

I will look into that. Though as I said I will use the parameter we already have and pass it to the kernel instead of adding a new setting parameter.

Thanks you for checking out the FOS part.

[Sebastian Roth]

@george1421 Ok, so the PHP code is done (github commit ref). When you get to it, would be great if you can open a pull request on the FOS repo or post a diff here.

[Sebastian Roth]

Transferred to github to we don’t loose track of it: https://github.com/FOGProject/fos/issues/48

@danboid said in Removing MACs from multicast task without starting over:

I also seem to be having an issue with machines not changing their hostname to match what they’re known as to the FOG server. We’re using Windows 10 on the clients. I’ve installed the FOG client, set the address of the FOG server for the client and it has worked for most of the machines but not all. They’re all on the same network / switch but there are two types of PC with different network adapters if that could make a difference?

Just figured this part of your request is still open. Not a great idea to ask for several different things in one topic. As Wayne said early on we need the fog-client log (usually in C:\fog.log) to be able to help. Probably best if you open a new topic if this is still an issue for you - and post fog-client logs as well.