Fog Installer - Distro check

[Sebastian Roth]

@Wayne-Workman Thanks for letting us know. Your tests distro tests are awesome man!

Arch has gone from PHP 7.1.12 to 7.2 lately - see here. The function call _(...) is an alias for gettext(...) which is used for translation strings. But I haven’t found why there should be an issue with that yet.

Can you do me a favor? On one of the Arch installations - if you still have one around - please create a file info.php in FOG web root directory with the following content:

<?php
phpinfo();
?>

Save and open in browser http://x.x.x.x/fog/info.php to see if you can figure if gettext extension is on or not. On my server I see “GetText Support enabled”

[Tom Elliott]

@sebastian-roth get text must be enabled in arch though I’m pretty sure we do this already.

I am aware 7.2 removes native mcrypt functions though which will impact things such as the client authentication. I haven’t had time to figure out a better alternative to replace these calls yet sorry.

[Wayne Workman]

@sebastian-roth Arch’s default apache root dir is very interesting: /srv/http
Anyways, I added that file to there and when viewing it via browser, I don’t see any indicators that gettext is on. Here’s a copy of the page:
https://mega.nz/#!EskiSSwT!Aj2px-ZMpwcDj90TBbpJRdB6G04AcBhrMR5WcPwlj6g

[Sebastian Roth]

@Wayne-Workman Thanks for that. Looking through it I found --with-gettext=shared in the compile options. So enabling the shared module still needs to be done. As Tom said this should be done by the installer. Ahhh, I think I know what’s up. The installer does regex-matching to enable the modules - see here:

...
sed -i 's/;extension=gettext.so/extension=gettext.so/g' $phpini ...
...

Now what changed in Arch is that they don’t use the .so extension in the configuration anymore. See here. I’ll fix our regex today.

As we don’t backport fixes to the master branch this one will be screwed with Arch for a long time I am afraid.

[Wayne Workman]

@sebastian-roth said in Fog Installer - Distro check:

As we don’t backport fixes to the master branch this one will be screwed with Arch for a long time I am afraid.

That’s how it should be. Also, looks like working branch failed again today.

[Sebastian Roth]

@Wayne-Workman Ok, I just pushed a fix (hope I got that right) to the working branch. Let’s see if that’s doing the job. If so I might push it to dev-branch soon as well.

[Wayne Workman]

@sebastian-roth Looks like you fixed it, good job man.

[george1421]

@wayne-workman Thank you for keeping focus on these distro checks!!

[Wayne Workman]

These distributions have completed 73 successful clean installations in a row using their latest patches with the FOG master branch:

• CentOS 7
• Debian 8
• Debian 9
• Ubuntu 16

We’re still waiting for a single winner to rise above the rest. The race for most-stable distribution continues.

[Wayne Workman]

@developers @moderators There were a ton of failures last night. Not sure why. When I get home this evening I’ll check it out.

[Wayne Workman]

@developers @moderators I’ve determined most of these failures are due to the remi repository being broken somehow. Some errors from CentOS 7:

package remi-release-7 is not installed
curl: (22) The requested URL returned error: 503 Service Temporarily Unavailable
error: skipping http://rpms.remirepo.net/enterprise/remi-release-7.rpm - transfer failed
Retrieving http://rpms.remirepo.net/enterprise/remi-release-7.rpm
curl: (22) The requested URL returned error: 503 Service Temporarily Unavailable
error: http://rpms.remirepo.net/RPM-GPG-KEY-remi: import read failed(2).
../lib/common/functions.sh: line 580: yum-config-manager: command not found
../lib/common/functions.sh: line 581: yum-config-manager: command not found

I checked on the Fedora ones, similar errors.

However, I’ve tried to reproduce the errors manually and I cannot.

I have to conclude that there was in fact a problem of some kind with the Remi repository, and that it now appears to be fixed. As far as Arch Linux goes, I really don’t have any idea. Everyone’s welcome to look at the logs though.

[Sebastian Roth]

@Wayne-Workman Thanks for looking into this. I maybe found what’s wrong on Arch. MariaDB says:

Installation of system tables failed! Examine the logs in /var/lib/mysql for more information.

DB seems to be not up. Possibly just a rename of the init file in Arch as I saw errors about that too.

[Wayne Workman]

@sebastian-roth Everything is back to the way it was this morning, with no effort from me.

So, we no longer have much of a tie going on. Debian 8, Debian 9, and Ubuntu 16 are now tied for FOG stability. CentOS didn’t fail out because of anything CentOS did, but rather because of the dependency on the remi repo to get certain PHP packages that FOG needs. I’m confident that if CentOS didn’t need the remi repo for FOG, it’d still be tied for leader. But it is what it is I guess.

It would be nice if we could in the future not require external repositories beyond what the OS ships with (like epel and remi and others).

[Sebastian Roth]

@Wayne-Workman Yes, good point. We should look into what is still needed. I think a lot of it came in when PHP7 was still new…

[Sebastian Roth]

Repos are still needed… I spoke too soon: https://github.com/FOGProject/fogproject/issues/224

[Wayne Workman]

@sebastian-roth Well thanks for looking into it.

[Wayne Workman]

Last night, all Ubuntu 17 failed. Looks like a problem with one of their repo mirrors. us.archive.ubuntu.com/ubuntu zesty/main

[Wayne Workman]

Ubuntu 17 still failing.

[Sebastian Roth]

@Wayne-Workman Well I think the issue with Ubuntu is that Zesty (17.04) is history since 13th of January 2018! Seems like it’s gone from the official mirrors now too.
See here: https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes and https://wiki.ubuntu.com/Releases

Ubuntu 17.04 will be supported for 9 months until January 2018. If you need Long Term Support, it is recommended you use Ubuntu 16.04 LTS instead.

[Wayne Workman]

@sebastian-roth Ah you are right. I’ll get that out of there then and setup 17.10