@AlexisPHC So i just took a few to look and figured it out. Please repull/install and all should work now.

Thanks for letting me know.

@AlexisPHC @JJ-Fullmer Are you able to test/help out on this?

I feel like this shouldn’t be a problem but I believe you’re the closest I have to who has been using the FOG Client consistently.

Thank you!

@AlexisPHC Yes

@AlexisPHC Can you please try a pull -> re-install and see if this is still happening?

I did have to create an “override” for the check, that is still secure (at least in hope).

@mashina pulling the update, and installing it, + the CTRL+SHIFT+R in the browser (once the install completes) should be sufficient.

@AlexisPHC Sorry, foujnd the issue and a fix is pushed.

In trying to allow for searching the value as part of things I inadvertently removed the “inputValue” field which is what is supposed to be what you can edit. I re-added that and left the ability to search based on the value information.

This should be fixed in the latest version. (You may still need to do a hard refresh as suggested, but should be able to edit the fields at least now.)

Thank you!

@AlexisPHC Can you please attempt a Hard refresh (CTRL + SHIFT + R in chrome) on your browser:

The “groups” are there (that’s what you see for the “BOLD” (FOG Boot Settings)

They are grouped still. The big difference is things are properly paginated which is a change to how things were done in the past.

@AlexisPHC The branches are separate from things so if someone removed it in dev-branch/stable/master and I didn’t know about it for working-1.6 it wouldn’t have been removed there.

I just updated to account for this that should help you out.

@AlexisPHC I’m apologizing, yes SYSSERIAL is existing (in working-1.6).

If you’re willing (and slightly daring) you could update to the working-1.6 branch (give us another tester of it) and SYSSERIAL is re-introduced overthere.

I am workign with 2 different systems and often look in the primary place I’m working to find information. I can assure you the SYSSERIAL lookup/adjustment is in the working-1.6 branch (and that just happened to be where I was when I looked this up so again my apologies)

@AlexisPHC You can set this by putting the name field of quick registration as {SYSSERIAL}

@christop Roger, sorry I’ve been doing a lot of programming in python lately and introduced “int(…)” which isn’t valid PHP syntax. This is corrected in the latest, please pull/install and let me know if it helps?

Thank you for letting me know.

@AUTH-IT-Center Sorry I hadn’t seen this, glad this is fixed now.

@Fog_Newb This should be fixed in the latest dev-branch please let me know if it’s not.

Thank you!

@christop Also, another output for informatoin would be:

sudo systemctl -l status FOGMulticastManager.servcie

Now I’m not saying this isn’t a feature that will (or will not) be added. I am not a C# programmer and wouldn’t really know how to start doing this.

That said, even if we did add this feature, you’d still need to disable the service for sysprep so that when the machine does boot you don’t have an issue.

Since you have to disable the service anyway, I’m not sure it’s worth the effort to put in a “stop” feature into the client.

Could even OOBE sysprep load/startup mode potentially be detected? Possibly, but why would we put that much into the FOG Client when it’s just as easy to disable to service when doing configuration stuff such as you’re doing?

@AlexisPHC Sure, it might be possible to do this, but you can just disable the service from actively running, which is actually suggested anyway?

Install the service (while totally disconnected from the FOG Server.)

Set the service to a disabled state.

Load machine into “Audit Mode” Do work…

This would be independent of dedicated hardware or anything like that.

https://wiki.fogproject.org/wiki/index.php/FOG_Client#FOG_Client_with_Sysprep

@AlexisPHC The FOG client has no knowledge that the machine is in audit mode. All other normal services for audit mode still run similarly. (Not just FOG Client related, but networking, Antivirus, etc… etc…)

Now what we normally have people do when building their “golden” image is basically turn off Domain joining or disable any items for the machine. That or just ensure the machine you’re working on isn’t registered to the FOG server until you’re ready to capture the image.

This baseline machine should only be used for “golden image” creation and shouldn’t have any direct relationship to the FOG server until you’re ready to capture and deploy to that machine (after all your configurations are completed.)

I just want to be clear your expectation of “Well the fog client should know that the machine is in audit mode and not do actions it would normally do otherwise” doesn’t really make much sense in the context of programming. Or machines. All the FOG Client knows is “I’m supposed to do x, y, and z actions, I’m going to do x, y, and z actions”.

All of these things can be enabled/disabled in the FOG UI as well, so if you’re really wanting it to do these things, you should disable the items you don’t want happening there if you really much use a machine that’s already pre-configured in the UI. At least for the time you don’t want those things occurring.

@christop I don’t know what OS version you’re using:

Most likely there’s an error I’m not seeing.

I have finally run into the odd issue of udp-sender not being where it used to be expected (‘/usr/sbin/udp-sender’ vs ‘/usr/local/sbin/udp-sender’) and just pushed a fix for it, but the fact that yours isn’t saying the file is missing but just dead stops is odd to me. Usually that’s indicative of a typo or syntax error which is why I’m going to ask for the logs.

See my Signature line here and it should point you to one of the varients of error files.

If redhat based, you’ll likely see the error in the www-error.log from php-fpm

If ubuntu based, you’ll like see the error in the apache2 error.log file.

If you can give us that we might help direct.

I did push a fix for a completely unrelated issue so maybe that helps you too? I doubt it, but you never know.

@christop The UDPCAST_MAXWAIT should be the time (in minutes) for all udpcast started jobs.

If your setting isn’t working (I don’t know why it wouldn’t be, but there could have been a change that broke this unexpectedly) it would default back to 60 seconds in total.

The value is stored in minutes on the UI side of things and then converted to seconds when and where required.

I see a potential typo in /var/www/fog/lib/service/multicasttask.class.php at line 660 though, that seems might have been there for a while.

If you can change it to multiply by 60. Otherwise you were just multiplying by six:

So 10 * 6 = 60 seconds (one minute). 15 * 6 = 90 (1 minute 30 seconds)

YOu can fix this by updating your UI value from 10 to the period you’re expecting. Or you can edit the file.

i’m pushing what i hope will fix the issue in dev-branch if you’re wanting to go by a method that’s more “developed already” kind of thing.