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.

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/

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.

@Wayne-Workman do you have console from the browser? Another option, I suppose, is to clear content and cache entirely and see if that helps. Everything, except upload of pictures, seems to be working for me. The upload issue is kinda what caused the entire breakage of the system.

@Wayne-Workman try a hard refresh on your browser. I saw similar and hard refresh did the trick for me

Hello All,

We ran into an issue with our VPS due to my trying to update things. For that I’m sorry. I just wanted to let you all know that the backup that was reverted was as of midnight on 01/21/2019, so anything posted from that point till now has magically disappeared.

I do want to give my sincerest apologies and we only have the forums available currently. I will be working to get news, dev, and wiki back up and running as well as our main home page.

Again, please work with us as we work to get back up and know this was unintentional. I made a mistake trying to upgrade things so things would work without issue. And I ended up breaking things worse than intended.

Thank you for understanding and patience.

Due to the security controls of the fog client, I understand what you’re wanting and could probably code this relatively easily, however I think it would probably work better if you did an api script that ran on a schedule.

Essentially the request would be:

put <url>/fog/host

data:
{
[
‘hostIDs’: get <url>/fog/host/ids data: [{“pending”: 1}],
‘pending’: 0
]
}

Of course a bit more output may be needed, but the principal is the same and could be scripted from your fog server.

@hj104 Chances are the time is based on UTC time, as FOG_TZ_INFO (in fog settings) is likely unset at the moment.

I’m guessing here, that the task scheduler appears to be checking every minute?

Also what does the task scheduler log show?

How about the most relevant question of all, maybe I missed it, what version of fog are you running?

@ty900000 The problem with using 114, is it’s missing an argument. So the Segfault is double’d due to -c/-a0 and not likely due to either of the arguments, but rather the fact partclone is segfaulting as it cannot determine file size, as it is literally commented out of the code. This means, a raw (imager) image file will not be generated at all. (/images/<imagename>/d1p<#ofparttion_to_be_cloned_in_imager_format>.img will be missing comletely.)

In my case the partition number was 2, and in yours it appears the partition number is 3.

I have created a fork of the partclone repository and implemented what I would think should address the issue by reimplementing the filesize display capabilities. As @Sebastian-Roth learned, simply uncommenting the line allowed partclone to work properly (as far as we could tell).

Until we patch the issue on our side (either by using our forked copy of the repository or directly implementing it as a part of the build process), this is still going to be a problem. I think we have a way to fix it, just haven’t had time to implement and have you (or anybody else who’d be willing) to test it.

@TOXYKILLER as long as we know the network is privately spaced and not going to cause issues, that is fine.

Then I would suggest asking your network team to give your fog server a reserved IP address. This is similar to a static IP but you wouldn’t have to keep jumping thru loops to get your server to operate, as it seems your dhcp lease times are very short. The reserved ip still resides with the dhcp server and you wouldn’t have to make any changes to the network configuration on the server for this to work.

Once you have a stationary fog server ip, I think we can get your machine up and running.

@TOXYKILLER you work with DOD Network Information Center?