Fog Installer - Distro check

[Wayne Workman]

@sebastian-roth It’s truly dis-heartening to me to be shown awesome libraries from yesteryear that didn’t take off… My heart goes out to Twill. However, Requests has gained substantial community support (not due to any of my doings) and probably has a much longer future than other libraries. I was hoping someone had Selinium experience - but I really do think we can do just fine with Requests.

[Wayne Workman]

A heads up - seems like Ubuntu 18 is having a lot of problems these past few days. I’ve not looked into it yet.

[Wayne Workman]

I’ve added Fedora 28 server to the list.

[Wayne Workman]

Looks like there is a possible issue with php-fpm on Ubuntu 16. I’ll look into it in more detail this evening.

[Wayne Workman]

@developers I’ve looked into the Ubuntu 16.04 problems for the last two hours and have determined the problem is being intermittently caused by a problematic ppa.launchpad.net server: 91.189.95.83. The apt-get update command times out, and because it was not successfully run, lots of packages fail to install. I’ve also looked over all of the commits in the working, dev-branch, and master branch of the fogproject github repository around the days that the Ubuntu 16.04 failures started happening, there are no commits that would cause this.

The workaround: If the installer fails for you, manually run apt-get update until it succeeds. Once it has succeeded, run the installer again and it should work.

[Sebastian Roth]

@Wayne-Workman Thanks heaps for digging into this!

[Wayne Workman]

Just an update,

You will notice that the link in my signature is different, the one there is the new one.
Long story short, I setup an email server for myself, which caused DNS & ssl problems to arrise with the fogtesting dashboard. So - I moved the site to a t2.nano in AWS. The same VM here at my house is still doing 100% of all testing, but when it gets done it does a quick rsync to the aws box to update the website with the new dashboard & files.

[Wayne Workman]

I’ve added Fedora 29 Beta to the daily installation tests. I’ll remove it and add the official release as soon as that’s available. I’ve also updated all of my ‘clean’ snapshots with the latest patches.

[Wayne Workman]

I’ve removed Fedora29-Beta, and setup a Fedora29 minimal server today, from the official release ISO. I’m pretty sure I remembered to do everything this time (like firewalld and selinux). We’ll see how it goes tomorrow morning.

[Wayne Workman]

So the issue with Fedora 29 is the Remi repo, they don’t seem to be caught up with the recent release. Their website still lists the beta version. I tried manually installing the remi repo for fedora 29 beta, doesn’t work. I don’t think there’s anything we can do until Remi Repo gets their end fixed. Most likely, when it’s fixed, everything will just start working because it appears the fog installer is creating the correct commands.

[Wayne Workman]

So as expected, the remi repo removed Fedora 29 beta, and added Fedora 29 release. Dev-branch and master are passing the installation tests, but working is failing which seems strange. Ubuntu 18 on working branch also failed - this test was run immediately after the Fedora 29 working test, so maybe it’s something with my vm host or internet at that time. It’s normal for this test system to have the occasional blip (it is what it is) so we’ll see what the tests say tomorrow.

[Sebastian Roth]

@Wayne-Workman About Fedora 29: I do see the following message over and over again:

Remi's RPM repository - Fedora 29 - x86_64       47  B/s | 2.3 kB     00:49    
Failed to synchronize cache for repo 'remi', ignoring this repo.

Not exactly sure if that is causing the broken installation.

Now Ubuntu 18 on the working branch. I really have no idea what is going wrong here. It seems to stop right in the middle of an apt… call. From the last lines of log output it looks like it. Possibly your test install VM got interrupted!!!

[Wayne Workman]

@Sebastian-Roth Yesterday’s issues were just a blip. All green today.

[Wayne Workman]

Seems Fedora29 is having some problem related to apache.
These are in the logs:

[Thu Nov 29 05:20:30.553661 2018] [proxy_fcgi:error] [pid 8980:tid 140162887972608] [client 10.0.0.48:40096] AH01067: Failed to read FastCGI header
[Thu Nov 29 05:20:30.553706 2018] [proxy_fcgi:error] [pid 8980:tid 140162887972608] (104)Connection reset by peer: [client 10.0.0.48:40096] AH01075: Error dispatching request to : 

Also - these logs and the dashboard are in AWS s3 now. The bash scripts that makes this stuff is adding an extra / somewhere and s3 does not handle this like Apache. So when you click the links and it says “page not found” you just need to remove the extra slash.

[Wayne Workman]

Fedora29 is still having issues, I looked at it this morning, the installer is failing on “Updating Database”. Here’s the log: http://fogtesting.theworkmans.us/Fedora29/fog/2018-12-01_04-41_fog.log

Also - I’m going to remove Fedora 25, 26, and 27 from the tests. Patches aren’t released for some of those anymore, nobody should be freshly installing fog on those.

[Tom Elliott]

@Wayne-Workman don’t forget to check selinux

[Wayne Workman]

@Tom-Elliott Just checked, It is in permissive mode.

[Sebastian Roth]

@Wayne-Workman I’ve done a manual test install and from what it looks like to me the issue is that php-json package is not being installed. Well that’s just the short story. I think (@Tom-Elliott might know more about this) that we used PHP from the REMI repos. But as Fedora 29 comes with PHP 7.2.12 in the official repositories (which is great) those are used for installation instead of the REMI PHP packages (seem to be on 7.2.12 as well). REMI had the JSON functions provided by a different package (maybe php-pecl-json*) which was installed via dependency I suppose. Now with Fedora 29 we need to add php-json explicitly to the package list.

I suppose this would cause trouble for other RedHat based systems so I am not sure of the best way to solve this. I’m in hope that we can remove external repositories form the installer altogether soon!! Debian stable is on PHP 7.0, CentOS 7 can go with PHP 7.0 using an official extra repo (see here), Ubuntu is on PHP 7.2, …!? What do you think?

Edit: As well I am wondering about RedHat installs. I guess there are people out there with a proper license using FOG. But we can’t actually test our installer as it’s impossible to even get a package (version) listing online. So if we go for PHP 7.x without external repos we wouldn’t care about RedHat much I suppose.

[Wayne Workman]

@Sebastian-Roth said in Fog Installer - Distro check:

I guess there are people out there with a proper license using FOG. But we can’t actually test our installer as it’s impossible to even get a package (version) listing online.

Once I’ve completed moving the install tests to AWS, we will have RHEL 7 in the tests. I’ve made a lot of progress. I have Terraform scripts that do a complete build-out of everything necessary for the tests to start running in an AWS account. This includes new Python scripts to replace what the old BASH scripts do at my house (interacting with the AWS API instead of interacting with libvirtd, as well as running the FOG installation tests). I’m still actively working on this, but it’s getting close to functional.

[Sebastian Roth]

@Wayne-Workman Great work. I am looking forward to see if FOG will install on RHEL 7 at all right now.