I haven’t looked in a while, but I believe the history table on the SQL db will contain all of this information. I added a bunch more logging a while ago in an attempt to at least maintain the data. I haven’t gotten around to actually parsing the table into a nicely formatted report or anything, but the data, itself, should be there.

@Quazz Possibly, yes. I’m trying to rework the way these things get specified. Currently in 4 million lines of code lol.

FOS already contains a registry editor too, just in case anybody was unsure. That’s how we do “hostname early”

@Wayne-Workman forgot to write here but this should be good now.

Also I think you are not understanding what registration is doing.

When it sends the information to the server it’s sending all macs that it finds. The order the macs are sent is based on how it comes into the machine.

So a machine with two Ethernet cards might come up with: eth0 and eth1

When fog pulls the macs it pulls it in order. So eth0, eth1 would be sent.

If eth0 is the nic that’s not communicating it doesn’t matter. It’s just sending information it’s finding. You could work this by disconnecting the nic that doesn’t communicate to fog, or switch the ports around so eth0 is the nic communicating to fog.

Either way, this isn’t something we can fix with a simple arp as we need to know which nic is communicating to the fog server, not the fog servers MAC address.

This likely will not be addressed for 1.5.0 as we really are trying to get a machenism that doesn’t rely on the MAC address. While we could make this work, it would not be a simple thing, and would only be used for a very short amount of time.

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