I’ve added this feature to the “working-RC-2” branch of the the github repository.

To test it for yourself:

git clone https://github.com/fogproject/fogproject.git git checkout working-RC-2

Then run your install as you normally would.

Please see:
https://news.fogproject.org/fog-client-v0-11-4-released/

0.11.4 now downloads from the storage node if locations are setup.

There’s now way to control the flow of how a form get’s processed, unfortunately. The Data get’s uploaded then the “variables” are suitable to test. This includes files (regardless of size). That said, i have included a jquery method that will test the variables before they go to be “processed” and if the name is not set, it will no longer submit, wait, then test. It will immediately prevent the submit action and point you to the name not being filled out (or using invalid characters).

@fry_p My department manually enrolls over 1K Chromebooks about every semester.

That easy compared to putting the carts for them together and wiring them, figuring 30 power adapters in a space the size of a mini-fridge. If it’s not done thoughtfully, the carts will be completely destroyed by usage - cables strung everywhere. Sometimes we use 100 zip ties per cart.

Just remembered Tom.
I’ll do a pull request for the text when I can.

@Wayne-Workman

I agree in that situation it probably would be best to keep it the way it is. My situation is a little different. Most of my groups are much smaller, in comparison, with similar hardware/software setups on every machine in the group.

I organize my groups based on room/lab in the school, every room has similar hardware ect. So it’s much different, it sounds. I’d just like to see a central location where I could see what settings are on larger groups of computers without having to go into each host to check it. Even if it were on a separate settings page. That’s all.

I just ran into an issue this morning where I’m adding printers to a group. I navigate to the group, click on printers, select printer for group, click add printer, click update and then all of my selections disappear. You have no idea whether your changes were ever applied to the group. To me it would be nice to see the printer check box remain checked after update is selected, and maybe the update button grayed out. Something simple to let the user know that things have actually been applied without having to go into each host.

Cheers,

Joe

@ablohowiak I’ve updated the code already to give a 600ms wait time. I think relying on 3 characters would be good, but sometimes I find it’s useful to be able to search using a single character. The original delay was set at 300ms. It should give a fair balance I think.

Thanks Tom, I won’t be able to check this out until end of the day but much appreciated

Since @Tom-Elliott doesn’t think it’d be a good thing to do additional polling (which I can understand), I’ve put together something which I feel is significantly lighter on the servers.

I’ve written a BASH script that will query the FOG DB for all storage nodes, and then send out a single lonesome regular-old ping to each one.

If the ping succeeds within the specified WaitTime, the node is enabled in the DB, and it’s bandwidth chart is enabled.
If the ping fails to return within the specified WaitTime, the node is disabled in the DB, and it’s bandwidth chart is disabled.

You can clone the project from here, it includes more instructions.
https://github.com/wayneworkman/MonitorFogStorageNodes

I’ll be implementing this at work on Tuesday with our 15-server FOG System, which is currently being plagued by power outages due to construction, maintenance, storms, and server moves.

Additionally, the script writes a simple html document that you can view by going to x.x.x.x/nodestatus.html
Here is sample outputs of what the html document looks like:

1_1467506022893_Fog Storage Node Status 2.png
0_1467506022892_Fog Storage Node Status 1.png

@Tom-Elliott Okay, that makes sense then. I’d be in favor of removing it, but I’m also in favor or reducing complexity if it helps troubleshooting and your sanity for working on the code.

Added. There’s no indicator, sorry just to much like work for now. But I have tested it and it does work.

@Quazz said in Group Snapins:

You might be interested in post download scripts for this. Will accomplish basically the same thing, but in a more universal manner.

A post install script is the best for pushing drivers, since the target computer has access to the network using FOS, once windows boots and the drivers are not loaded you are off-line.

There are two tutorials that will help you.
https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins

https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog

This one has some background info that is useful.
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script-under-construction

@Wayne-Workman Awesome, thanks for the heads up. I will look around to see if I can find it

@ITCC it is set how it’s set because how it works. It’s not a “host” thing as we don’t have a decent mechanism, in my opinion, to find hosts. Because hosts are found by MAC address the simplest mechanism is to use to Mac table to work against.

@Tom-Elliott That’s exactly what I needed thanks Tom.

nfsiostat will be the tool I use to demonstrate how latencies can degrade network saturation. I’ll be highlighting the RTT (round trip time) with different numbers of unicast tasks running simultaneously. I’ll also highlight total overall NFS throughput. I predict that once HDD seek times are maxed and the HDD can no longer keep up with the number of simultaneous reads, that network performance will drop below 1Gbps, and latencies will skyrocket.

The man page:
http://man7.org/linux/man-pages/man8/nfsiostat.8.html

@george1421 This sort of plugin would highly aid in the FOG Integrity Checker plugin - which is yet to be completed because it’s missing the scheduling part…

Second this request.

@Tom-Elliott Just thinking about the next steps here…

I have to work on a few extra projects for my real job right now, but I’m thinking ahead a little.

In funcs.sh, can we move the code to pickup the kernel parameters and to call hostinfo.php into its own sub function? That we can reuse and call at different points in both the init scripts and via the post install scripts? That way I can reuse that code and have a consistent way of getting the parameters.

I could imagine a sub called getKernelParams() that could be called, and in that sub function if the ( boottype=usb ) then it would call a second function getHostInfo() to pick up the host info (that way too we can call getHostInfo() by its self to pick up the host details from the post install script(s) too (at this time I personally don’t care about the kernel parameters in the post install script, but if I did I could just call the getKernelParams instead). Then of course the /bin/fog script would need to take advantage of these new functions.

Added.

I have not added a way to upload your own files. However, I have added a way to define your own file name. All you have to do is upload your own file and point the boot settings to use that new file. The handling for colour and cpair commands are left just as text boxes. You need multiple changes, you just need to enter a new line and type. This leaves potential errors being left unto the users, but should be able to allow more people to make their own color schemes for the boot menu.

Useful links:

http://ipxe.org/cmd/colour
http://ipxe.org/cmd/cpair

of course, I should note, you can, I suppose, inject any ipxe code in these fields, however I doubt that will be much use to others as they’re stilled called only in their relevant functions (get_console/alt_console/host).