Found and fixed. Will be in the next RC.

@Sebastian-Roth I did add this already to 1.6. (Partly). The put in red has not been done yet, as I currently just “continue” if the node is not online. Will work to put into red, but I don’t consider this as “high” priority for now.

@JJ-Fullmer no it would not. The idea is to get a good working list of issues that will then be addressed for RC 2

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

I’ve fixed the storage node disabled issue for home page and for the fog settings page. They are now purely jquery based meaning they’re asynchronous. This basically means they will no longer block simply due to a node being offline.

This will be released in RC-3.

Fog 1.6 already does this

Access control plugin has been removed. This removal will be forced in RC-3. This is because it can cause MANY more issues than would be worth trying to adjust for. Hopefully you all understand.

Instead of Analytics, or Rainman (though I love this movie), or “Install survey”

Something that’s more explicit to what it’s doing:

FOG External Reporting

Issue confirmed. I was tryign to fix a bad status update in the repo earlier and apparently one of my links ended up in the mix.

I deleted the entire repo and readded what was requried back.

This should be fixed now.

Please re-pull your repo (this only affected git users).

@Wayne-Workman I think this is the ever known fixparts issue.

@Jo2220 Please recreate the same tasking but as a debug task. (Create like you normally would but before you confirm the task, check the box for “Schedule as debug”.

THen boot the client. It will bring you to a prompt. At that prompt type:

fixparts /dev/sda

You will likely be told some information, allow the changes and write them. After that, start the upload tasking with: fog

You will have to press enter a bunch of times, but you should be good after that point.

Group snapins should properly deploy. Will be available for RC-5.

@ManofValor You would still need to unmount, because the space is used by your main system. Simply removing all the data in the mounted partition will only free up space on the mount point.

@Raymond-Bel
it’s from line endings not being read properly.
^M translates to (Native) mode line endings (but it confuses installers).
fix hopefully in SVN now.

It’s not something I can tell when submitting either. It’s only when one informs me like this, so thanks.

@VijayBomble glad you resolved the issue but could you provide information as to what the problem was and what you did to fix it?

Fixed for RC-9

@templink Please run:

sudo mysql -u root
Within mysql please run:

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

Then you should be good to go.

Found out exactly what the issue was. It’s because of the damn WOL tasking son of a.

Sorry it was so hard to replicate/troubleshoot.

It is now fixed in RC-9 thanks for reporting.

As a meantime fix, so you don’t have to constantly run in to the problem.

Edit your /opt/fog/.fogsettings file.

Look for packages=' and remove sysv-rc-conf from the packages list.

Found and fixed for RC-14.

More often than not, (unless you’re still using the legacy version of the fog client), the CPU usage starts to become high because of replication. This slows the CPU because it’s got to process the data, and read it from disk to send it where ever it needs to be distributed.

You could try:

service FOGImageReplicator stop
service FOGSnapinReplicator stop