• As I sit here working on making the daily fog installation tests more reliable, I wondered to myself when I should remove the older OSs (centos7, rhel7, etc). I thought it’d be nice to know how often what OS is being used to install FOG on. So I propose the following.

    I can create a publicly available API that simply accepts a “string” being submitted. Using this, I can put together a popularity contest type thing that will allow us to see what people are installing FOG on. I can build the API (I have scaffolding that I can use to get this done pretty fast) and run it, and make the results publicly viewable.

    Within the FOG Installer scripts, I can add a question about participating in the popularity contest. I think this should default to “Yes”. If “Yes” is chosen, a simple curl call is executed sending the output of lsb_release --all to the API.

    Thoughts on this? I’m willing to put it all together and submit the pull requests for it. Though wanted feedback before I went after it.

  • @Sebastian-Roth as well as all the others ( @developers @moderators @testers )

    Would we want anything besides kernel information? I had some ideas:

    Number of hosts
    Number of images
    Number of each type of image
    Number of systems imaged in the last 7 days
    Number of storage nodes
    Number of storage groups
    Other things?

    It’s been said before, but will say it again. This is all anonymous data. There is no way to correlate this data back to any system.

    It just provides us insight (and possibly bragging rights). imagine us being able to say “FOG imaged a bazillion systems last week, we’re proud of that” or maybe “FOG assists with managing a quadrillion million computer systems every day”. I’m being funny with the imaginary figures here, but you get the idea. It’d be nice to make statements like that on the home page fogproject.org

  • Moderator

    @wayne-workman said in Popularity Contest:

    I assume you mean FOS kernel, not FOG server’s kernel.

    Exactly, thanks!

  • @sebastian-roth I’ll look into it. I assume you mean FOS kernel, not FOG server’s kernel. Hold on the release while I poke at this please.

  • Moderator

    @Wayne-Workman Do you think adding the kernel version used might be possible? We see many people using non-default kernel versions and it might be interesting to add that information as well.

    I have not looked into it yet. So no idea how much work it might be. Just bringing up the idea before it fades away in my head.

  • Tried emailing chuck, he has not replied. For now, I’ve removed all of the fogproject.org references, and HTTPS is working directly (redirect does not work). This is fine until Chuck can help with the DNS records.

  • @sebastian-roth Right, the alias is fine, please leave it as-is.

    I tried without the subject alternative name and got browser errors related to SSL. The front-end is in AWS CloudFront, which uses AWS ACM for ssl certs. I can’t make a cert with the fogproject SAN in it without the verification. Right now, it’s not set-up as I figured we wanted to get the redirect working right. If that can’t be done, no big deal.

  • Moderator

    @wayne-workman said in Popularity Contest:

    For the results to have a good redirect from stats.fogproject.org, I need the SSL cert to include that subject alternative name.

    That’s interesting. While I can look it up using the host command I can’t ping it.

    $ host stats.fogproject.org
    stats.fogproject.org is an alias for fog-external-reporting-results.theworkmans.us.
    $ ping stats.fogproject.org
    ping: stats.fogproject.org: Name or service not known

  • @Sebastian-Roth if you can get an A record created for stats-api.fogproject.org with a value of I can get the ssl cert and such fixed on my side (using lets encrypt). Once that’s all done, we can update the reporting script to use the new URL.

    For the results to have a good redirect from stats.fogproject.org, I need the SSL cert to include that subject alternative name. Please create this record, it’ll allow me to create that SSL cert. These values below are not secrets, and they will timeout in 72 hours from now (sometime wednesday). if it’s not made by then I can get new values. This is part of how AWS verifies the cert your making is legit.




    If this can’t be done for whatever reason, I can use the original results URL and it’ll work fine, just redirects from stats.fogproject.org won’t work.

    Here’s the changes on the cloud side if you were interested.

  • @Sebastian-Roth So when I try:

    curl -X POST -H "Content-Type: application/json"  -d '{"fog_version":"testing","os_name":"testing","os_version":"testing"}' https://stats-api.fogproject.org/api/records

    This is the result:

    curl: (6) Could not resolve host: stats-api.fogproject.org

  • Yeah the back-end only takes entries, nothing else.

    The frontend url is less important, as that’s not needed in the fog codebase anywhere. It’s just a place one visits to see results. I can get HTTPS setup for it.

  • Moderator

    @Wayne-Workman said in Popularity Contest:

    Right now it’s: https://fog-external-reporting-entries.theworkmans.us:/api/records

    This URL does not seem to work in the browser. It’s the backend API URL if I am not on the wrong track. But we want the frontend URL http://fog-external-reporting-results.theworkmans.us/ right? Can you setup HTTPS as well?

  • Sounds good.

  • Moderator

    @george1421 Good point! Though I would use a more simple name that is easy to remember and type, e.g. stats.fogproject.org?

  • Thoughts on the external reporting DNS name?

    Right now it’s: https://fog-external-reporting-entries.theworkmans.us:/api/records

    This works fine, but it’s not a fogproject.org address.

    If nobody has an opinion, I’m happy to leave it as-is forever, but I think it may be more appropriate if there’s an A Record created like fog-external-reporting-entries.fogproject.org. This can be set to the public IP of the server I’ve setup to record the entries, and also could be easily changed in the future if needed. I’m not immortal, nor is anyone else here so this is why I bring it up.

    We really need to get it the way we want it before the next release.

  • Moderator

    @Wayne-Workman said in Popularity Contest:

    I suggest we look at both locations and send the one from the file with a newer timestamp.

    While that would surely work I would really like to untangle this convoluted solution now and for ever. The more I think about it the less I want to add more if then else, check this, link here, try again, whatever. Let’s discuss the details in a new topic.

    Please leave the reporting script as it is right now. It’s really good you added it this way so we got notice of this.

  • good point… I suggest we look at both locations and send the one from the file with a newer timestamp.

    Or maybe there is a better way?

  • Moderator

    @Wayne-Workman Nice!

    Looking at the data I am wondering how versions 1.5.2, 1.5.5 and 1.5.6 can make it into the database. From my point of view this is a good sign those installs still have an old version of the web UI sitting in /var/www/fog and the new one in /var/www/html/fog.

    While I would hope we can figure out a way to detect those situations and let people know I would still think that we need a more generic way of grabbing the version info instead of using a static path for system.class.php.

  • Moderator

    @Wayne-Workman Sounds awesome but right now I get a “Bad Gateway” message instead.