I know I’ve been out of this for a little bit. I check in here or there, but just been extremely busy.

I don’t want to stop contributing, I just am taking time for myself after my workly duties.

I have to give a big gratitude and thanks for everyone here trying to help out whether by code, by helping the rest of the community, or documentation.

@Sebastian-Roth I know you’re busy but you’ve kept the project rolling even with the minimal availability you have. Thank you.
@george1421 I’m sure you’re busy, but I still see you posting and helping where possible and amenible. Thank you.
@Wayne-Workman I know you’re helping where you can as well. (Of course I can’t exactly post everybody because I’ve been busy and honestly not keeping up with the forums as much as I probably should.)

@everyone Thank you. Thank you for still believing in this project. We’re doing the best with what we have. Please understand in we’re lacking, it’s most likely unintentional. I know I’m just busy.

https://news.fogproject.org/fog-1-3-5-and-client-0-11-11-officially-released/

https://news.fogproject.org/fog-1-5-0-rc-11/

TLDR; Rerun the fog installer if you have lost “Database Connectivity” to your fog server, or run the ALTER USER syntax shown below.

So Ubuntu 16, among others I suppose, enable a “security updates” to be applied automatically as a “default” to things. Why, well it makes it simpler to ensure your Ubuntu systems are in compliance and patched for any potential exploits. This causes unknown and unexpected issues.

I figured it’d be a safe thing to express that there could be problems (as many of you have already experienced) that when these updates go up (with or without your knowledge) it can break functionality in unexpected and inopportune ways.

The quickest fix is to simply rerun the fog installer which should correct the problem.

As a note, it seems this problem is specific only when the mysql account is the 'root' user AND the password is blank.

The “fix” if you must do it manually is to open a terminal and obtain root:
Super (Windows Key) + T then sudo -i (in most cases).

From there, open mysql with mysql -u root

NOTE: MySQL MUST be run with ROOT.

Run:

ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY ''; AND
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';

It’s okay if one of them fails. This is going to fix Most people’s issues.

I would highly recommend removing the unattended-upgrades as many of these “sudden” issues came as a security patch ubuntu pushed out. By default Ubuntu typically set’s this for you as enabled and it can cause havoc on you as you (the admin) may not have “done” anything.

To prevent this problem from happening in the future you could run:

apt-get -y remove unattended-upgrades (AS Root again).

FOG is still actively being developed. It’s not necessarily readily apparent, but we can assure you things are still being worked on. These updates may not be communicated in a way that everybody just knows, but can easily be seen if one were to look at our repository site.

Between our own schedules and lives, we can get very busy. We try to keep things updated and help out on the forums even during lull periods. This might mean we aren’t pushing an RC or release as frequently. It may mean we’re working on other things for the project, such as can be seen if looking at our github site.

Our forums are heavily active, and this should point as an indicator to our “status” as well.

If anybody would like to see an increase in developers donating their time to making this free software, consider donating either with monetary support or by spending personal time to help with development.

FOG is an open source project - it’s even in the name. It is driven by people donating their time and resources. The releases of FOG revolve around when developers can spare a few hours throughout the week. Sometimes that will mean releases will be further, sometimes that will mean releases will be faster. That’s just the nature of our project, and many other open source projects.

Hey everybody,

I know you see me here on occasion from time to time. Life decisions have made it more difficult for me to do things I would normally be doing. Rest assured, I am still around, and while I’m not quite as active as I was in the past, it’s not because I don’t want to be.

I had to move, and as part of that I have none of my normal development stuff readily available. Part of the move made me not have a laptop, until today.

I need to setup my dev environment again, so it may take a little bit, but I will be back up.

That’s correct. The main reason fog is constantly moving forward is because the codebase is improved upon. Major bugs tend to be addressed for the next release. We don’t do an LTS because there’s really two main people working on fog in a consistent manor. Those two are @Joe-Schmitt and myself. Debian and Libreoffice have the team too be able to perform such a feat. Their product is Opensource but they have an employment team which can afford them that luxury. FOG has a team but we make no money and as such are required to work full time jobs. We work on FOG in our free time. I’ve had the ability to even work on it from work because we used the software.

Maintaining many different versions is difficult. And we don’t have a support team. WYSIWYG and I think we’ve done pretty well on support, even if we don’t have the ability to do dedicated support for our product. 1.5 was a major step toward modernizing the GUI. 1.6 will vastly improve on this. It was only recently we kind of came up with a road map on how best to proceed. Of note, 1.5 will be maintained until 1.6 is released. 1.6 is focused on making he GUI much more modern. 1.7 will be focused mostly toward fixing and refactoring the FOG client. 1.8 will focus on making the FOS system more modular and usable. I don’t know yet for 1.9. 2.0 will bridge the gap for our rewrite based on the work from 1.5 and up. While we do plan to try to do backports where possible, it’s much easier to ask people to update to the latest version than it is to try to maintain many different versions with backports in mind. At least for what FOG does.

I doubt this will appease anybody, but it’s what I think needs to be said. We are working hard and provide support for our product as best we can. The community makes fogs support system, I think, one of the best around. Add to that and you can almost always have a developer working side by side to help and fix issues as they come up, I don’t think it’s unfair to ask users to update to a specific version. Even if there are bugs, we will always try to correct what we can, when we can. (And normally it’s a pretty quick turn around).

I’m not perfect and I’ll give you that. We don’t even have a test suite to know if things are working as intended. We have to rely on the community and suggestions are great, just understand our answers won’t always be what people want to hear.

https://news.fogproject.org/fog-1-4-0-officially-released/

https://news.fogproject.org/fog-1-4-4-officially-released/

https://news.fogproject.org/fog-1-5-0-rc-12/

@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.

@JYost I’m not aware of anything that would have changed regarding the type of network used especially if it works fine for the on-board network but not when you do it through the USB C dongle adapter?

The FOG Client can use dongles as well, but the fact you’re seeing the recovery screen when coming off the USB Adapter? That is strange and different and more likely something manufacturer specific (best I can guess.)

As for the FOG Client software operationality: the USB Dongle should work just fine if it’s associated to the device and has the expected snapins, etc… If it’s a generic Adapter, you may have enabled “ignore for client” on the mac address just to ensure all machines using that dongle aren’t getting assigned the same Hostname, Snapins, printers, etc…

Though, normally/ideally when the FOG Client checks in it looks up all MAC’s passed in, and attempts to find the host using any one of the MAC addresses associated to that machine even if ti’s not the one directly plugged in. It’s possible the onboard mac (when unplugged and system initially loaded) isn’t even recognized or sending as part of this authentication process, but without the FOG Client logs, I can only make WAGs at this point. Probably still some what blind with the logs, but at least we have data to work with that way.

As for the recovery screen, I’m not sure I have an answer for that. I can make another Guess there, and most likely it’s related to the kernel version. You could try some older version kernels using the kernel updater page and see if one of those older ones don’t force your machine into a Recovery Screen. It still seems very vendor specific, but I’ve seen odd issues of firmware temporary writes that do some weird things to Network devices between the FOS and Windows boots that might be happening in your case as well. Again, just a WAG.

@Fog_Newb Does this mean things are working as you expected now?

@Fog_Newb Can you try pulling again?

I have made a slight change to what you performed as I’m handling this in /opt/fog/service/lib/service_lib.php under the Service_Register_Signal_handler function. This should be the central point where all the FOG Services get their base line order and configuration for starting the processes. So, from your original code, you are only applying it to MulticastManager.

While I believe that, currently, is the only service that may spawn children (due to the udpcast calls), I’m still of the mind to handle it more centrally so maybe a future process spawning thing will not need the same action.

I have pushed what i hope to fix this (using your baseline of course) and hope this hsould work for your needs.

Thank you for testing in advance and sorry for missing this before the stable release.

@RAThomas I wont make you do a PR. I already pushed it if you wanted to use the the pushed code. thanks for testing and letting us all know!