• Senior Developer

    @Junkhacker working-1.6 has been updated with this.

    I agree that most will not mind.

    I just didn’t want people to get into this unknowningly.

    I don’t know how many people use the -y switch, so that was why I wanted to “err” on keeping things as they are.

  • Developer

    @Tom-Elliott i think we should default to Y/n instead of y/N

    most people don’t care one way or the other and will just click through, let the people who care chose not to send it

  • Senior Developer

    Added ability to turn on/off this “feature”.

      FOG would like to collect some data:
          We would like to collect the following information:
            1. OS Name (CentOS, RedHat, Debian, etc....)
            2. OS Version (8.0.2004, 7.2.1409, 9, etc....)
            3. FOG Version (1.5.9, 1.6, etc....)
    
      What is this information used for?
          We would like to simply track the common types of OS
          being used, along with the OS Version, and the various
          versions of FOG being used.
    
      Are you ok with sending this information? [Y/n]
    

    When Selected either yes or no, the screen will tell status as well:

     * Here are the settings FOG will use:
     * Base Linux: Redhat
     * Detected Linux Distribution: CentOS Linux
     * Server IP Address: ....
     * Server Subnet Mask: ....
     * Hostname: fogserver
     * Installation Type: Normal Server
     * Internationalization: 0
     * Image Storage Location: /images
     * Using FOG DHCP: Yes
     * DHCP router Address: ...
     * Send OS Name, OS Version, and FOG Version: Yes
    

    Or:

     * Here are the settings FOG will use:
     * Base Linux: Redhat
     * Detected Linux Distribution: CentOS Linux
     * Server IP Address: ....
     * Server Subnet Mask: ....
     * Hostname: fogserver
     * Installation Type: Normal Server
     * Internationalization: 0
     * Image Storage Location: /images
     * Using FOG DHCP: Yes
     * DHCP router Address: ...
     * Send OS Name, OS Version, and FOG Version: No
    
  • Senior Developer

    Analytics:

    information resulting from the systematic analysis of data or statistics.
    

    What are we gathering,
    OS Name/Type, OS Version, FOG Version

    What are we doing?
    Analyzing how many of a type of OS and version, along with the number of “versions” run out in the wild.

    While the data we’re gathering is, right now, only very basic, I think analytics is still the true term.

    If we decide analytics is not the term to use, I still think it’s important to add (and I’m working on doing that) a way for the admins to disable if they don’t want their information being reported. We’re not doing much or collecting any metrics of the data in the sense of IPs or how we can best improve our code base. We are, after all, collecting and sending data to another source.

    This information we are gathering is still a form of data we can use to gather what Operating Systems and versions, along with the general FOG version being used in the wild.

  • Developer

    @Wayne-Workman how about “install survey”


  • Maybe we call it “Rainman”?

    alt text

  • Senior Developer

    @Tom-Elliott said in Popularity Contest:

    I think analytics is the appropriate term, even if the information we’re using is minimal.

    I don’t agree! The term “analytics” implies way more than we do and it might turn down people who use FOG and don’t like analytic stuff that is going on all over the web.

    Why should we name it something we don’t want to do - and I am absolutely sure I never add real analytics stuff to FOG myself.


  • I’ve validated the installation code as I’ve written it does work against all the major distributions - and I’ve also discovered my daily test for Ubuntu 20 was really Ubuntu 18 🤦 (fixed now).

    Below is what the data looks like in my test environment. It’s interesting to note that RedHat changes it’s distribution name from major release to major release. It’s of no consequence for our use, but I think that’s interesting.

    versions_out_there.png

    The server-side’s code is in this PR:
    https://github.com/FOGProject/fog-community-scripts/pull/62

    The FOG Server’s code is in this PR:
    https://github.com/FOGProject/fogproject/pull/405

  • Senior Developer

    @Wayne-Workman I think that’d work best, yes.


  • @Tom-Elliott Looks fine to me. Should I submit a pull request to the dev-branch since you’ve already added this to the 1.6 branch?

  • Senior Developer

    @Wayne-Workman, @Sebastian-Roth

    I think analytics is the appropriate term, even if the information we’re using is minimal.

    I’ve added similar code, slightly revised.

    Please take a look and let me know:

    https://github.com/FOGProject/fogproject/commit/1435d1b1852e452295359fb045f3bb38f01ba18f
    This introduces the information - but I had a typo which is where the “second” link comes in.

    AND

    https://github.com/FOGProject/fogproject/commit/acfc6445d3b8f9497bf2b63e69e3faec0c51ee51

    Thank you,


  • What do you want it to be called?

    Tom had used the “analytics” term in his suggestions which is why I named everything like that, as later on it might be expanded to do more than simply collecting versions. Originally I named everything “popularity”

  • Senior Developer

    @Wayne-Workman Well done! Haven’t had a chance to test but looks fine on first sight.

    May I ask you to rename it all. The word “analytics” has just so much background to it - we don’t do real analytics here…


  • Got a bit more done on this today.

    The comparison between my work and the dev-branch can be seen here.

    This is what the settings look like:
    fog_analytics_settings.png

    This is what the cron job looks like - this is dynamically generated when the installer runs:
    fog_analytics_cron_job.png

    This is what the logging on your local FOG Server will look like:
    fog_analytics_logging.png

    I’ll be using the daily installation tests against my own fogproject fork to test against all the major OSs here shortly. I’ll validate the cron jobs get created correctly on each and then I’ll manually change all of the cron jobs to run every minute. This is so I can test immediately rather than waiting a week.

  • Senior Developer

    @george1421 Sorry I have not found enough time to look into this last week. Would have been nice to add this to the upcoming FOG release but I think there are a few questions still to answer, so I won’t rush into it.

    Using CRON and keeping it kind of separte from the other code seems like a good idea to me too. Still wondering if using a UUID is better than clearing the DB and wait for new input once a week. I do like the later approach but would spread the time even more. Across one whole way! Plus we have people from different timezones which adds to the randomization as well. So if we don’t need a UUID, is ther a point in using one?

    Making it a installer question I am wondering if many people just use the default No and we lack a fair amount of stats?! Currently we have a global user count polling and inserting information on the FOG web UI logon screen anyhow. Adding general stats like OS version and brand doesn’t make it a real analytics tool (I don’t think we should name it anylytics!) and so I am wondering if there is really a point in asking via the installer as we have done stats since a long time.


  • @Junkhacker absolutely. In fact, I was planning to make daily dumps of the database available.

  • Developer

    @Wayne-Workman shall we make the stats public, because “why not” and to be transparent about what we collect?


  • I have the information collection portion of the server completed. Code is currently sitting in my fork of fog-community-scripts.

    Here’s what the request looks like right now:

    curl -X POST -H "Content-Type: application/json"  -d '{"fog_version":"12.34.56","os_name":"Debian","os_version":"10"}' http://fog-popularity-contest.theworkmans.us:/api/records
    

    ^ That’s a live link, should work for whoever tries it. If it’s stored ok, the reply is

    {"message":"record recorded"}
    

    Here’s a screenshot of the first test record saved, and the table layout.
    database.png

    I’ll work on the client side next, will follow the conclusion of the guidance provided by everyone here.

    I do plan on adding https to the server side.
    As far as presentation of the data, not sure on that yet. Kicking around ideas of rendering some basic graphs in .png format every day and serving those, as well as making a daily database dump available for download.


  • @Junkhacker I think this is the right move.

  • Developer

    @Wayne-Workman i realize i’m coming into this really late, but why not randomize what day of the week we collect the data as well, and we can just look at the window of “last 7 days” when we look at the data?

368
Online

7.9k
Users

14.8k
Topics

139.7k
Posts