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/

https://news.fogproject.org/fog-1-5-3/

@sebastian-roth in my testing language translation worked properly using the common provided version

@fog_newb Yes, that’s the expected part.

Because php-gettext is now part of the php7.4-common package, there’s not really a need to include it as part of the packages line.

You should be good to go now.

@fog_newb Please try again? After updating of course.

@fog_newb This should be fixed in the latest.

Issue is ubuntu 21.04 is using php{ver}-common for php-gettext where in the past it was its own package. I updated the code to check for php{ver}-gettext which showed it as part of php{ver}-common and the install went through properly. Going to double check language packs download properly too.

Got the language-packs to install properly too.

Thank you,

@jonhwood360
I’ll try to document better:

• 1. Why would we use this per host? Unless you mean per server containing images?
• 2. Not a totally new database. It would integrate with the existing FOG database, under it’s own tables for definition and association
• 3. Services have a web based portion under /var/www/fog/lib/service (plugins would use /var/www/fog/lib/plugin/{pluginname}/service/} which controls the event loops, but the systemd is what starts and maintains the service operationally speaking (so reboots of the server would start the relevant service.)

@b_man Edit the fog menu item for full and quick registration:

Forgive me if my menu pointing is off. I’m running working-1.6 which has separated the ipxe menu from the fog configuration section. The point I’m making is still relevant though so hopefully you can adapt to follow what I’m saying.

FOG Configuration Page
iPXE Menu Configuration
fog.reg

Edit the boot options and append shutdown=1 like so:
mode=autoreg shutdown=1

Do the same for fog.reginput

You should now longer have the machine reboot, rather it will completely shutoff after registration is complete.

Another method would be to edit FOG_KERNEL_ARGS and add shutdown=1 to it. (FOG Configuration Page->FOG Settings->Kernel Args) This will make it so all tasks will always shutdown when complete.

@florent I don’t control the donation system we currently have.

But, what do you consider “big customers”.

I would imagine 12 big customers (so to speak) but that only equates to a total of $12000 (which is not enough for 1 developer (let alone 2).

Plus, if it’s funded solely through “donations”, then a customer can simply not pay for that year. This means there’s no accountability.

I think 12 is a pretty large number, but it isn’t enough to support a full on paid system.

Even in a “good” scenario where we are running on the idea that there is enough donations to support 2 developers in the year, that’s only 2 developers. What of the people who are simply doing troubleshooting?

The point of this thread, I think, is to get more people interested in donating their time. Instead it’s asking us to give more (which is impossible at this point.)

Think about it. @Sebastian-Roth is saying he’s readying to step back and eventually fully away from the project. That leaves me to do the development. Who’s going to step up to do the troubleshooting to those who are “paying” for support? I’m only one person.

@jonhwood360 What I could suggest, then, would be to build a Plugin.

My thoughts of how this plugin would operate:

1. To allow the admin full configuration capabilities, make the plugin create a Database that would contain a “primary” table for storing definition of the item such as the name, description, and configuration items (Such as sha256 hash, or md5 or whatever may be preferred).
2. An association table so you can associate which images you want to be managed by said definition.
3. Create a service file to run on a regular interval. (This part would have to be manually done as creating the systemd or init file on subsequent reboots.) So documentation would need to be on point.

I would need to figure out how to integrate plugin service files. Not a huge issue as we currently inject classes, hooks, and events. I just need to add code to allow injecting services which hasn’t been done yet.

Why do I say a plugin? Because at one point there was a plugin being worked on, but then other things got in the way. If you’re keen to assist it would certainly help us out and you’d get to learn a few cool things along the way.

@astrugatch The issue is the “team” is built of mostly people helping on their own free time.

There’s not really a way for us to “work full time” on FOG as there’s not enough income received to do such a feat. As such, our “support team” comes from the community as a whole.

Believe me, if I could get paid to program on FOG all day, everyday, I would. Unfortunately that’s not feasible as of currently.

I’m only one person, and with Sebastian, that made 2 developers working mostly to keep things functioning.

While we have a few more developers on titled on the team, the large majority of active Developers was @Sebastian-Roth and myself.

@Fog_Newb @Sebastian-Roth I have updated the dev-branch and working-1.6 to what I hope should do better translation.

@Fog_Newb I will need some time to create an ubuntu 21.04 to find out about the gettext installation error.

Thank you for the report and information.