@Sebastian-Roth why do you think documentation should be in a separate repo?

I like the idea of dropping a fully configured conf file into place. If it’s there beforehand, would the installation of dnsmasq overwrite it?

We have working firewall rules documented here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_security

FOG External Reporting sounds good to me. I’ll get the endpoint name changed sometime tonight and submit a PR for that.

I’m still needing to put together the last pieces of this, the presentation layer. This will be coming over the next couple weeks. Plans are to render some basic bar graphs showing the information gathered from the last 7 days, and to make available the database dump. Probably a cron-job to refresh those things every hour.

Maybe we call it “Rainman”?

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.

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

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

I could probably get this working. Just as simple as adding a cron job and script via the installer, and using the .fogsettings file to connect to the db and execute the commands.

@george1421 Considering the maintenance commands wipe out multicast sessions and stuck snapins, this is probably not something to run every hour… The most frequent I might recommend is daily. Probably sometime on Sunday night might be best.

The API and UI could be separated while still using the same port. The virtualhost config would look something like this:

<VirtualHost *:80>
        ServerName dev.localhost
        DocumentRoot /home/projects/smk/cms
        ErrorLog /var/log/apache2/smk-cms-error.log
</VirtualHost>

<VirtualHost *:80>
        ServerName my-project.localhost
        DocumentRoot /home/projects/smk/deploy
        ErrorLog /var/log/apache2/smk-deploy-error.log
</VirtualHost>

Reference:
https://stackoverflow.com/questions/6069892/different-virtualhosts-with-the-same-port

If this separation were done, I would think the installer could ask you if you want to install the API (defaulting to yes) and ask if you want to install the UI (defaulting to yes). This would allow the admin to break stuff apart.

I also think the database portion should be broken out, and the installer should ask if you want to install that or not (defaulting to yes).

There should be installation arguments for these things too.

Also, not wanting to delay 1.6 as noted by others. I would like to see this separation in a later release. As George has noted, if these things are separated it becomes easier to work on each one independently, meaning the learning curve to contribute is lower. Particularly with using popular frameworks.

Just my 2 cents.

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”

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:

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

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

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.

SMB isn’t know for it’s security lots of vulnerabilities in the past.

Might look at socat instead of netcat.
https://stackoverflow.com/questions/13294893/broadcasting-a-message-using-nc-netcat

Man page:
https://linux.die.net/man/1/socat

I thought the replicator used rsync? Or maybe it was scp…

@Tom-Elliott helped me run an imaging task over SMB once (via samba). It did work, no noticeable bad performance at the time. This was 3 or 4 years ago though.

Future readers can also try this: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Database_Maintenance_Commands

@JJ-Fullmer A lot of the new client’s printer documentation is in the forums. The wiki does need updated concerning printers.

I might suggest checking if you have free space on your disk. Also check the Apache error log during the time you try to register hosts. There are other things to try but I don’t want to write a book here just yet.

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

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.

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.

@DARUN974 said in Fog installation with ubuntu focal:

My problem is that I have a proxy and difficult to initialise.

This is the problem.