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.

@Sebastian-Roth, @Wayne-Workman, @george1421 I agree.

I think the GUID generation can be done relatively simply. We may already have a GUID generated at install time. (FOG_UUID in FOG Settings I think.) Though I don’t know how generalized it is, and it’s more a random ID, not an actual UUID (in UUID Standard)

So my thoughts:

Keep this “polling/analytics” separate from the main fog code base (Maybe under utils?)

Ask, on next update/install, if the admin would like to send analytics data to fog, and potentially what to send?

Store this section to it’s own configuration file.

So the asking requests something like:

Would you like to send analytic data for FOG? (y/N)
We would like to collect the information once a week, on Sunday’s at 03:00:00. (This allows us to delete entries older than a week.)

The information we would like to collect are:

• Randomly Generated UUID -> This allows us to track the information anonymously, but also not continually add the request to the queue, data is inserted once, then updated as needed.
• FOG Version -> This will allow us to track what versions of FOG are currently in use.
• OS -> This tells us what type of OS you are using to host the fog server.
• OS Version -> This tells us what version of OS you are using to host the fog server
• Timestamp -> Just the date and time this was sent.

We allow the user to select what they’re comfortable sending. I think this is just a better method overall.

The utility should simply create a simple shell script to send the data the user would like in real time. To collect the FOG Version, should should be able to do a lookup of the /var/www/fog/lib/fog/system.class.php and look up FOG_VERSION in the file.
OS and OS Version should look at lsb_release -a if the command exists, or look at /etc/os-release, or fallback as needed. Finally, the utility would then create the crontab to perform the task regularly.

Getting UUID = echo $(cat /proc/sys/kernel/random/uuid)
We call the configuration file something like /opt/foganalytics/.foganalytics
The script would be called something like /opt/foganalytics/foganalytics
Crontab would look like: 0 3 * * 0 /usr/bin/bash /opt/foganalytics/foganalytics >/dev/null 2&>1

Does this all make sense and sound doable?

What about this?

https://wiki.archlinux.org/index.php/Solid_state_drive/Memory_cell_clearing

From what I can gather, you can disable the “frozen state” from the BIOS, so sure it’s an extra step, but should still be possible.

The only machine that I see a warning is Lenovo. They have their own proprietary tool to perform erase operations.

I’ve seen this request but not quite sure how to move forward.

Please understand, Access controls, with this iteration of FOG Server, are coded after the fact.

What do I mean by this?

FOG didn’t really have any real security controls in place. You, indeed, needed to be logged in to do actions of course, but there weren’t any utilities in place for “modifying” access.

For a period of time, there was a thing called “mobile” user which basically just allowed a user to use a mobile interface. This interface was coded along side the FOG system, and was a cumbersome tool to maintain. So when we moved to a responsive design, I removed that “mobile” gui as the new GUI is also mobile accessible.

The Access control plugin is a huge leap toward getting a tool available to limit access based on rules/roles etc…, but it’s not a perfect system as it relies on the User existing in the database first.

I’m sure we could work to add a utility to enable a “default” role association but right now it doesn’t exist.

https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

Essentially that will do what you’re looking for.

You do not install the fog software directly. You just need to configure the node to have FTP and NFS.

You will miss a few little details such as disk size and what not.

Simple.

You can not NFS share an NFS share.

What does this mean:

You have mounted the NFS Share to your FOG server. Then you’re trying to make that share be NFS shared from the FOG Server.

So you’re NFS sharing an NFS share. This is simply not allowed.

If you want the NFS share to work with minimal issue, you would need to setup a new Storage node, that just points to the relevant information for the NAS itself.

So, for example, you would create a new node within the group called:

NASNode
ipofnas
/volume1/images

etc…

There’s likely many posts with more direct implication of setting this kind of thing up.

@marted what OS are you trying to get installed?

Was somebody playing in the BIOS settings? I know this is too generic of a question, but this sounds more like somebody set these hosts to a “SATA” mode of RAID. Can you ensure all machines sata operation mode is set to either AHCI or IDE?

AHCI would be the best case.

The fact that Windows doesn’t see the drive is what’s leading me to believe there’s an issue with the setting. This is because if Windows cannot see it, then the driver is missing. My guess, is the other machines had a driver installed as part of the original setup.

I’ll even further surmise that the other machines have a “Recovery” partition. Because of this partition, restoring the windows os on these machines has the missing driver as an option.

By wiping the disks, you’re effectively removing the recovery partition as well. So windows doesn’t have a driver for the IDE contrller.

FOG shouldn’t have an issue deploying the image unless the driver is also missing from the kernel. That being said, you wouldn’t have been successful in wiping the disks either.

What version of FOG are you using?

@rets34 you probably need to remove MySQL proper. apt-get remove --purge mysql-server

Followed by the commands I gave below.

I gave the gist to get you up and running right away. Why you would reboot again, when that broke this the first time, seems strange. This is a server and should not need to be restarted every time you want to update fog.

@bluedark And you’re 100% certain this ISO is capable of installing XP?

Exactly how large is the ISO, how much memory is available to the machines you’re trying to load the ISO from?

If the ISO is 2GB for example, then you need at least 2GB of RAM for the ISO to load to the machine.