@Sebastian-Roth working-1.6 has the same breakage.
The centos8 failure there is just a fluke. For some reason I’ve not figured out yet, centOS 8 and RHEL 8 are entirely unreliable to test within this automation I’ve built. I think it has something to do with SSH settings but not sure.
I was able to get the installation tests working again last night. Looks like on the dev-branch, Ubuntu and Debian are having issues with MySQL and MariaDB. Seems too closely related to be a fluke. I will check tomorrow’s results and see if it’s the same.
Look at that, Raspbian and Red Hat are in the list now. Also, 359 dev installations/upgrades since we started tracking.
Somewhere around 85 systems are very closely tracking the latest dev branch, with many others tracking a bit less closely.
@Tom-Elliott I took an easier route. The intent of your request was to see the exact values. So I added a JSON text object to the solution.
There is a link for downloading the current JSON data on the dashboard now. Though you can go directly to it using this link: https://fog-external-reporting-results.theworkmans.us/external_reporting.json
This is the PR that accomplished this if you were curious. https://github.com/FOGProject/fog-community-scripts/pull/70
@Tom-Elliott it’s likely possible to do.
The graphs use Python’s pyplot module. Here is the exact spot in the script for the OS Versions graph:
https://github.com/FOGProject/fog-community-scripts/blob/c527036bc4623f7f6225a48c545d37edc269d112/external_reporting/external_reporting/do_web_tasks.py#L88
I’ll see if I can add some numbers.
327 dev installations out there now, at least. Not a single one is Red Hat Enterprise Linux.
Which, I suppose makes sense. If you’re paying to use RHEL, you’re probably in a business setting and wouldn’t install from a developer branch because you want something stable.
Also notably there are zero Arch dev systems out there since we started tracking. This is a bigger point as I can’t think of a reason why an Arch Linux user wouldn’t dive into fog dev branch.
@astrugatch I haven’t done anything on this yet.
@moderators would there be any issue with using a forums topic to host torrent files for a fog VM image?
That looks to be the case. Just a fluke. Today, it installed fine.
I noticed today that Ubuntu 16.04 failed it’s installation test on the dev-branch. This is unusual for Ubuntu. Normally, Ubuntu passes it’s installation tests.
Attached are the logs from the run.
2021-03-01_12-33-PM_output.log
2021-03-01_12-33-PM_fog_error.log
2021-03-01_12-33-PM_apache.log
@cyannella said in Fog for Dev - Save each capture in its own folder automatically.:
How do I launch rsync myself with the parameters after FOG captures the device image?
Research about FOG’s post download scripts. This should get you started: https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script
You could also hook into web calls for when the image capture reports it is complete. Could do a one-liner exec statement in the php, and any number of more-fancy things.
Maybe the solution is simpler. maybe a clever bash script that runs within cron to do what you want with recent images. There is a DB with all the capture dates in it after all… python could do this too.
Reviving this thread on my lunch break. What would a docker container for FOG look like?
Immediate thoughts:
/opt/fog/.fogsettings too.For the VM image, I could probably get this going in a couple weekends. In my VM environment at home, I can create qcow2 disk types. Though I can convert qcow2 to vmdk rather easily. Could make a qcow2 as well as vmdk torrents individually for distribution.
I’ve added some more steps that should avoid those errors.
I’ve updated the chown command in the wiki. The user fogproject is something that came about after this article was written. The user used to be just fog
@george1421 said in Fedora 33 and Ubuntu 16:
I think there is surely a value in creating a supported operating system list for the FOG project.
Agreed. Though @Tom-Elliott wants to get everything OS agnostic by replacing PHP components with NodeJS ones, getting the UI and API away from making native OS calls, so on.
It’s a good plan, but a ton of work and probably years away. In the mean time, we could limit scope of the installer script by choosing a handful of OSs.
I’m having a lot of problems integrating Fedora 33 into the daily tests. This has been the reason for the lapse in testing here this last month.
I use Debian 10 as a bastion host, and use SSH Proxy Jump through Debian 10 to get to the other OSs. This has worked with every other OS that I’ve added. The Terraform configuration for Fedora 33 is here.
It’s not working for Fedora 33. I’ve gone over this issue probably a dozen times. Manual tests of this functionality work fine, so I’m unable to reproduce the problem. At this point, I need to leave Fedora 33 behind as there is value being lost in not testing the other more-popular OSs.
Good news is I’ve added Ubuntu 16 to the daily tests. This is because it’s still quite popular among dev-branch users.
Ubuntu 16.04 End-Of-Life is April 30, 2021. I suggest on this date the FOG Project drop support for Ubuntu 16.04 entirely. I urge the community currently using Ubuntu 16.04 to move to something newer.
I’m also down with making a Ubuntu image. Since that seems to be most popular. I wouldn’t want to mess with more than one.
A docker container is a good idea.
I was thinking with a VM image using Debian, I could pull down the packages FOG needs locally, and set apt-get to use those local packages. All the packages would also be pre-installed in the image.
As far as running something first-boot, if I’m building it I wouldn’t set it up like that. I’d say the admin can log into the VM (however they do that), and just run the fog installer which would already be there for them.
With this approach, there’s no changes to the installer or the code base. I hoped to automate building this image, creating a new one with each FOG release, and distributing via torrent.
If admins want to update, they would need internet and comment/uncomment some lines in their sources.list file, and update the fog repo with git pull.
Because the OS would be a chosen one, I can write up some documentation on setting a static IP, as well as putting a readme in the image saying the same.
Though a docker image is good too. idk if it would be easier or not. I don’t know docker very well.