FOG dashboard questions

rado

Hi all, first of all, thanks authors for FOG, but I have few problems using it.

Is it possible to add kernel parameters to default pxe file via FOG? I thought that adding parameters to FOG_KERNEL_ARGS in Other Information -> FOG Settings is the way, but as I understood it, it adds those parameters to database and they are then used only when generating pxe files for concrete machines, not default file. I need nomodeset in default for some clients. Or am I supposed to do it manually?
When I kill multicast task (for whole group in Active Multicast Tasks or per machine in Active Tasks - no matter in which order) udp-sender and gzip keep hanging and I must -TERM them. Is it expected behaviour?

And now some minor problems:
3) Why don’t Kernel Arguments in Group Management persist in input box while in Host Management they do?

In Active Multicast Tasks, there is a progress bar which keeps on 0% while imaging. Should it work, or have I some problems in configuration?
And one more question (just to be sure) - I have problems with multicasting (new kernel 3.8.8 on clients, my colleague says igmp is set up on for this vlan, unicast goes well ~2GB/min), but it could be some other devices on switch which are slowing it down (I haven’t opportunity to test it on separate switch) - what I want to ask is if there isn’t some speed setting for multicast somewhere in FOG? Because I’m constantly getting 1MB/s (according to FOG graph) and when unicasting it jumps up and down around say 40 MB/s. Just to be sure

Thanks for replies.

Tom Elliott

Try a newer kernel. My kernels don’t have modeset enabled at all so should work cross platform.

[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url] (Also, in FOG 0.33b you can do this, by editing the PXEFileGenerator.class.php file, but you will have to update the password on the FOG Settings page.)
Sort of. The way multicast works, it has to sync all systems to pick up the information at the right times. If you cancel the task while it’s in progress, it doesn’t know what to do anymore. So yes, it will hang and probably need to be killed.
Group Management is a means of individually adjusting a “group” of hosts. So the reason you don’t see the args in the group page is because it’s too complicated to read the information. It affects the hosts through a looping process rather than just adjusting the group and adding the information there. Trust me, it’s pretty complicated to try to add a per group recognition. Initially it’s simple, but to guess all the actions somebody wants becomes far too much to handle.
I don’t know, but I don’t think it will work. FOGSTAT’s (in 0.32) isn’t set for Multicast tasks, unless you added the functionality.
There isn’t a speed setting for multicast on fog. This is because multicast works on UDP. Speed shouldn’t be an issue, except in multicast items have to sync to be on the same level. If two systems are really slow, it will slow the rest of them down as well. This is normal, no matter what adjustments you make.

rado

Thanks,

[quote=“Tom Elliott, post: 21286, member: 7271”]Try a newer kernel. My kernels don’t have modeset enabled at all so should work cross platform.[/quote]

sorry, I’m not sure if I understood: “your kernels” are those in Other Information -> Kernel Updates? I am using the latest - 3.8.8 from there. Or “your kernels” are these?:
[quote=“Tom Elliott, post: 21286, member: 7271”]1) [url]https://mastacontrola.com/fogboot/kernel/bzImage[/url] (Also, in FOG 0.33b you can do this, by editing the PXEFileGenerator.class.php file, but you will have to update the password on the FOG Settings page.)[/quote]

[quote=“Tom Elliott, post: 21286, member: 7271”]2) Sort of. The way multicast works, it has to sync all systems to pick up the information at the right times. If you cancel the task while it’s in progress, it doesn’t know what to do anymore. So yes, it will hang and probably need to be killed.[/quote]

So to be sure - it’s not possible to write FOG the way it -KILLs (or better -TERMs) udp-sender (and other associated processes) when clicking “kill” button in FOG management (in Active Multicast Tasks)? Maybe you misunderstood me (or maybe I misunderstood you), but I’m not talking about cancelling multicast on client side but on server side.

[quote=“Tom Elliott, post: 21286, member: 7271”]3) Group Management is a means of individually adjusting a “group” of hosts. So the reason you don’t see the args in the group page is because it’s too complicated to read the information. It affects the hosts through a looping process rather than just adjusting the group and adding the information there. Trust me, it’s pretty complicated to try to add a per group recognition. Initially it’s simple, but to guess all the actions somebody wants becomes far too much to handle.[/quote]

OK, I think I understand - I thought there is a database table for groups where these (and other) settings is stored per group, but now I looked at fog database and code (/var/www/fog/management/includes/groups.edit.include.php) and now it makes sense.

[quote=“Tom Elliott, post: 21286, member: 7271”]4) I don’t know, but I don’t think it will work. FOGSTAT’s (in 0.32) isn’t set for Multicast tasks, unless you added the functionality.[/quote] Sorry, I don’t know what FOGSTAT is, but do you say it’s (the progressbar) working only for unicast?

[quote=“Tom Elliott, post: 21286, member: 7271”]5) There isn’t a speed setting for multicast on fog. This is because multicast works on UDP. Speed shouldn’t be an issue, except in multicast items have to sync to be on the same level. If two systems are really slow, it will slow the rest of them down as well. This is normal, no matter what adjustments you make.[/quote]

I think there shouldn’t be speed problems with my clients - I am imaging only two clients and unicast on these two clients went on approx 2 GB/s.

I have one other question - I set up group in FOG which contains only one host and when I tried to multicast it and looked at the traffic (using iftop) there was no multicast address and the traffic was going directly to host’s ip address. Is it OK?

I try to test it on separate switch (with only server and 2 hosts). And also other test - to make multicast session manualy starting udp-sender and udp-receivers from commandline.

Tom Elliott

[quote=“rado, post: 21319, member: 21581”]Thanks,
sorry, I’m not sure if I understood: “your kernels” are those in Other Information -> Kernel Updates? I am using the latest - 3.8.8 from there. Or “your kernels” are these?:[/quote]

My kernels are at the [url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]

In FOG 0.33B, I added a page similar to what you see on the Kernel Updates page for published kernels as well. This way, you don’t have to download manually and can use the GUI as it was intended. I imagine this functionality would also work for previous revisions.
[quote=“rado, post: 21319, member: 21581”]
So to be sure - it’s not possible to write FOG the way it -KILLs (or better -TERMs) udp-sender (and other associated processes) when clicking “kill” button in FOG management (in Active Multicast Tasks)? Maybe you misunderstood me (or maybe I misunderstood you), but I’m not talking about cancelling multicast on client side but on server side.[/quote]
It is possible, though if you’re not wanting the clients to stop their imaging when you’ve killed the task in the FOG GUI, it wouldn’t be recommended. If you kill the udp-sender item, it will stop sending the data to the clients as I understand it, which would break all the systems being imaged at the time.
[quote=“rado, post: 21319, member: 21581”]
OK, I think I understand - I thought there is a database table for groups where these (and other) settings is stored per group, but now I looked at fog database and code (/var/www/fog/management/includes/groups.edit.include.php) and now it makes sense.[/quote] Glad to be of assistance then!
[quote=“rado, post: 21319, member: 21581”]
Sorry, I don’t know what FOGSTAT is, but do you say it’s (the progressbar) working only for unicast?
[/quote]
FOGSTATS is usually defined in the init.gz file under bin/fog

Inside of this file, is how the FOG System actually performs the tasks. There are other fog scripts within the init.gz’s bin directory, but fog is the primary one. For 0.32, FOGSTATS is not defined except for on the Single Disk (Resizable) imaging types. I can re-take a look at the code base for MC imaging to see if FOGSTATS is set, the other part of the fog script is it needs to redirect to a file called /tmp/status.fog on the client side. This data is sent by the fog.statusreport script within the init.gz bin directory as well. However, if the file’s not obtaining any data, the progress bar will not be updated. Again, I’d have to take a look at the FOG Script to give you more detailed information.
[quote=“rado, post: 21319, member: 21581”]
I think there shouldn’t be speed problems with my clients - I am imaging only two clients and unicast on these two clients went on approx 2 GB/s.[/quote]

[quote=“rado, post: 21319, member: 21581”]
I have one other question - I set up group in FOG which contains only one host and when I tried to multicast it and looked at the traffic (using iftop) there was no multicast address and the traffic was going directly to host’s ip address. Is it OK?[/quote]
Again, I’d have to look at the code that interprets this data/call. My guess, though, is this is normal. Why multicast to one system? It could potentially bring down a network all so one system can be imaged. It would make sense, that if there’s only the one job, that it images it using the Unicast methods we’re so near and dear to.

[quote=“rado, post: 21319, member: 21581”]
I try to test it on separate switch (with only server and 2 hosts). And also other test - to make multicast session manualy starting udp-sender and udp-receivers from commandline.[/quote]
Did this work?

rado

Hi,

[quote=“Tom Elliott, post: 21321, member: 7271”]
It is possible, though if you’re not wanting the clients to stop their imaging when you’ve killed the task in the FOG GUI, it wouldn’t be recommended. If you kill the udp-sender item, it will stop sending the data to the clients as I understand it, which would break all the systems being imaged at the time.
Glad to be of assistance then!
[/quote]

Yes, but, isn’t this what you imagine under “kill” button? Or maybe I don’t understand what is it intended for.

[quote=“Tom Elliott, post: 21321, member: 7271”]
FOGSTATS is usually defined in the init.gz file under bin/fog

Inside of this file, is how the FOG System actually performs the tasks. There are other fog scripts within the init.gz’s bin directory, but fog is the primary one. For 0.32, FOGSTATS is not defined except for on the Single Disk (Resizable) imaging types. I can re-take a look at the code base for MC imaging to see if FOGSTATS is set, the other part of the fog script is it needs to redirect to a file called /tmp/status.fog on the client side. This data is sent by the fog.statusreport script within the init.gz bin directory as well. However, if the file’s not obtaining any data, the progress bar will not be updated. Again, I’d have to take a look at the FOG Script to give you more detailed information.
[/quote]
OK, thanks for explanation, I somehow understand, for now it’s not so important. Does this work in FOG 0.33?

[quote=“Tom Elliott, post: 21321, member: 7271”]
Did this work?
[/quote]

Yes - in the end the problem was with our clients in classroom (MSI DC 100). When shut down they probably set their ethernet card to 10 Mbit mode. When powered on or unplugged from switch speed of deploying immediately grew to cca 100 Mbit/s. This didn’t happen with our other platform.

rado

Hi, my colleague found this regarding 10 Mbit mode: h ttps://communities.intel.com/thread/11355?start=15&tstart=0

FOG dashboard questions

168

11.6k

17.1k

154.6k