Update Fog 1.5.9 to 1.5.10 / Update in general

[ChrisChoke]

Describe the bug
Upgrade from 1.5.9 on Debian 10 to 1.5.10 on Debian 12

To Reproduce
Steps to reproduce the behavior:

1. Upgrade Debian OS from 10 to 11 to 12
2. cd fogproject
3. git pull && git checkout stable
4. cd bin
5. execute ./installfog.sh

       Running from here will fail.
       You are in /opt/fogproject/bin which is a folder that will
       be moved during installation.

Expected behavior
No exited script run.

Screenshots
If applicable, add screenshots to help explain your problem.

Software (please complete the following information):

• FOG version 1.5.9/1.5.10
• FOS kernel [e.g. 5.15.68]
• OS: Debian 12

Additional context

fogproject/lib/common/functions.sh

Lines 1043 to 1051 in 24bb5a6

	case $currentdir in
	*$webdirdest*|*$tftpdirdst*)
	echo "Please change installation directory."
	echo "Running from here will fail."
	echo "You are in $currentdir which is a folder that will"
	echo "be moved during installation."
	exit 1
	;;
	esac

The script exited here because if i run the script the variables $webdirdest and $tftpdirdst are empty.
So in my opinion the case condition pattern will be like this:

case $currentdir in 
     **|**) 
         echo "Please change installation directory." 
         echo "Running from here will fail." 
         echo "You are in $currentdir which is a folder that will" 
         echo "be moved during installation." 
         exit 1 
         ;; 
 esac 

i think because of this, the bash interpreter means it is the default conditions pattern to catch everthing.
I havent looked deeper why the variables are empty. what i can say is the variables are not empty if i have not a .fogsettings file.
so on "fresh" install it works and on upgrade it do not.
Don't know why i am the only one who have trouble with it.

i dont know what the asterisks beside the $webdirdest and $tftpdirdst means in the case pattern, but i very often prefixes variables in conditions with an underscore to prevent a condition check to an empty variable which ends in an syntax error.

case "_$currentdir" in 
     *_$webdirdest*|*_$tftpdirdst *) 
         echo "Please change installation directory." 
         echo "Running from here will fail." 
         echo "You are in $currentdir which is a folder that will" 
         echo "be moved during installation." 
         exit 1 
         ;; 
 esac 

the second problem on upgrade is the packagelist in the .fogsettings file. If i do an OS update as well, the fog installer will use this list again. that do not work as well, because on debian 12 there are no php7.3 packages and it hangs on "mariadb" package after the "m4" package. Then yo have to quit manually with ctrl-C.
i think we should update the packagelist always we run the script based on the OS Version.

hope this information is useful for us. i could try to figure out what the problem is. But i dont know how much time i need to dig through the bash code :-)

best regards
Chris

[mastacontrola]

This doesn't happen to everybody and as such is an edge case though easily fixed:

Please set the webdirdest and tftpdirdest variables in your /opt/fog/.fogsettings file:

webdirdest is usually, on Debian at least:
/var/www/html
tftpdirdst is usually:
/tftpboot

Thank you

[ChrisChoke]

Oh no I am a fool. Sorry and thanks for your quick reply.

I looked again on my .fogsettings and my
osid had an extra character at the end.
osid='2'g
I swear, I really don't know what happened here. But with that, the config.sh from Ubuntu directory wasn't load.
I will try again on Friday morning when I am back to office.
I will close this right after the update.

Chris

[ChrisChoke]

okay, thank you Tom. we can revert this issue. all of this was my fault because of my .fogsettings.

But i have to reinstall the fog-client on all of the clients.
after upgrading to the latest stable the fog-clients in version 12 couldn't established secure channel.

Middleware::Authentication Waiting for authentication timeout to pass
Middleware::Communication Download: https://192.168.1.10/fog/management/other/ssl/srvpublic.crt
Middleware::Communication ERROR: Could not download file
Middleware::Communication ERROR: The request was aborted: Could not create SSL/TLS secure channel.

is this normal?

Chris

[darksidemilk]

If you're still on the same server and your cert is all the same and what not, then you may be able to just reset the host encryption on all hosts and they'll connect after a service restart.
If your cert was updated/recreated in the update process, then reinstalling the clients is the easiest option

[ChrisChoke]

Okay thanks for explaining.
I am on the same server.
The certificates are recreated in the update process. The certificates from the webroot directory.
Shouldn't the certificates recreated? I thought that's normal, and the script do it on every execution.

[darksidemilk]

They might have been as part of 1.5.9->1.5.10 but I'm not sure. They typically aren't recreated every time you run the installer unless you use the arguments to enforce that

    -C    --recreate-CA     Recreate the CA Keys
    -K    --recreate-keys   Recreate the SSL Keys

(see also https://docs.fogproject.org/en/latest/command-line-options)

[ChrisChoke]

okay i have some more information. I looked in the foginstall.log and checked the Certificates creation date on the hdd.
First, i haven't forced recreating the certificates.

here some parts of the foginstall.log

* Configuring services

 * Setting up fogproject user..................................OK
 * Locking fogproject as a system account......................OK
 * Setting up fogproject password..............................OK
 * Stopping FOGMulticastManager.service Service................OK
 * Stopping FOGImageReplicator.service Service.................OK
 * Stopping FOGSnapinReplicator.service Service................OK
 * Stopping FOGScheduler.service Service.......................OK
 * Stopping FOGPingHosts.service Service.......................OK
 * Stopping FOGSnapinHash.service Service......................OK
 * Stopping FOGImageSize.service Service.......................OK
 * Setting up and starting MySQL...............................OK
 * Setting up MySQL user and database..........................Skipped
 * Backing up user reports.....................................Done
 * Stopping web service........................................OK
 * Setting up Apache and PHP files.............................OK
 * Testing and removing symbolic links if found................OK
 * Backing up old data.........................................OK
 * Copying new files to web folder.............................OK
 * Creating the language binaries..............................Done
 * Creating config file........................................OK
 * Creating redirection index file.............................Skipped
 * Downloading kernel, init and fog-client binaries............Done
 * Copying binaries to destination paths.......................OK
 * Enabling apache and fpm services on boot....................OK
 * Creating SSL Certificate....................................OK
 * Creating auth pub key and cert..............................OK
 * Resetting SSL Permissions...................................OK
 * Setting up Apache virtual host (SSL)........................OK
 * Starting and checking status of web services................OK
 * Changing permissions on apache log files....................OK
 * Backing up database.........................................Done

* Press [Enter] key when database is updated/installed.
 * Update fogstorage database password.........................OK
 * Granting access to fogstorage database user.................Skipped
 * Setting up storage..........................................OK
 * Setting up and starting DHCP Server.........................Skipped
 * Compiling iPXE binaries trusting your SSL certificate.......OK
 * Configuring default iPXE file...............................OK
 * Setting up and starting TFTP Server.........................OK
 * Setting up and starting VSFTP Server........................OK
 * Setting up FOG Snapins......................................OK
 * Setting up UDPCast..........................................OK
 * Configuring UDPCast.........................................OK
 * Building UDPCast............................................OK
 * Installing UDPCast..........................................OK
 * Installing FOG System Scripts...............................OK

root@fog:/opt/fog/snapins/ssl# ls -lha
total 28K
drwxrwxr-x 3 fogproject www-data 4.0K Sep  3 15:36 .
drwxrwxr-x 3 fogproject www-data 4.0K Dec 15  2020 ..
drwxrwxr-x 2 fogproject www-data 4.0K Dec 16  2020 CA
-rwxrwxr-x 1 fogproject www-data   94 Sep  6 07:43 ca.cnf
-rwxrwxr-x 1 fogproject www-data 1.7K Dec 17  2020 fog.csr
-rwxrwxr-x 1 fogproject www-data  227 Dec 17  2020 req.cnf
-rwxrwxr-x 1 fogproject www-data 3.2K Dec 17  2020 .srvprivate.key
root@fog:/opt/fog/snapins/ssl# cd CA/
root@fog:/opt/fog/snapins/ssl/CA# ls -lha
total 20K
drwxrwxr-x 2 fogproject www-data 4.0K Dec 16  2020 .
drwxrwxr-x 3 fogproject www-data 4.0K Sep  3 15:36 ..
-rwxrwxr-x 1 fogproject www-data 3.2K Dec 17  2020 .fogCA.key
-rwxrwxr-x 1 fogproject www-data 1.8K Dec 17  2020 .fogCA.pem
-rwxrwxr-x 1 fogproject www-data   41 Sep  6 07:43 .fogCA.srl

the CA certificate isnt recreated. you can see above the date. Only the ca.cnf and .fogCA.srl are recreated.
so nothing changed, but the fog-client was not able to connect with our fog-server. Resetting the host encryption data didnt helped either.

i had to reinstall the fog-client on all the host. i could not getting back to service.
maybe its known issue like here?! https://forums.fogproject.org/topic/16160/fog-client-unable-to-connect-via-https

edit: the puplic certificate from the apache server is recreated.
-rw-r--r-- 1 www-data www-data 1.8K Sep 6 07:43 srvpublic.crt
Not Before: Sep 6 05:43:52 2024 GMT
could this be the problem?

Chris

[darksidemilk]

edit: the puplic certificate from the apache server is recreated. -rw-r--r-- 1 www-data www-data 1.8K Sep 6 07:43 srvpublic.crt Not Before: Sep 6 05:43:52 2024 GMT could this be the problem?

Chris

@ChrisChoke Yes that would be the problem and pretty much requires a reinstall of the fogservice, at least that's the easiest answer in that case.
The fog client downloads that public cert from /var/www/html/fog//management/other/ssl/srvpublic.crt aka https://{your-fog-server}/fog//management/other/ssl/srvpublic.crt
But if the service has already downloaded a previous version of the cert (stored in "C:\Program Files (x86)\FOG\tmp\public.cer")
If the CA is really the same, and matches the CA cert the client has stored at "C:\Program Files (x86)\FOG\ca.cert.der" then deleting the public.cer file, resetting host encryption, and resetting the service may also do the trick. Maybe even just deleting the public.cer file and then maybe restarting the service.
You could also go to https://192.168.1.10/fog/management/other/ssl/srvpublic.crt and see if you can access that page it's trying to update the cert from. If you don't see certificate text or a download of the cert from that page, then there's a different problem.

That forum post is also an old post with an older version of the client, that issue is fixed, the client works fine with http or https.

[ChrisChoke]

@darksidemilk thank you for your really detailed explanation.

If that could be the problem, then i think this problem will be touched on every execution of the foginstall.sh script or not?

fogproject/lib/common/functions.sh

Line 1965 in 3527eca

openssl x509 -req -in $sslpath/fog.csr -CA $sslpath/CA/.fogCA.pem -CAkey $sslpath/CA/.fogCA.key -CAcreateserial -out $webdirdest/management/other/ssl/srvpublic.crt -days 3650 -extensions v3_ca -extfile $sslpath/ca.cnf >>$error_log 2>&1

the signing of the public certificate is not wrapped by any 'if condition' like it is with the CA key and cert. So it looks like we creating new public certificate on every run of the script.
maybe i could test it later this day or tomorow.

i already reinstalled the fog-client on all clients manually. Just 4 clients left, at the moment. that is not a really big thing for me, because i have just 30 clients or something around. But it was really annoying to walk throught the offices 😊

Chris

[darksidemilk]

It for sure doesn't happen on every run of this installer so I could be mistaken. If I can I'll try to test installing 1.5.9 on a test server and upgrading to try and recreate the issue. Just have to make some time to do that