Found it in the client, settings.json, changed https = 1. Did not correct the issue, but it did cause the client to look at https://…

@bballmcoe said in srvpublic.crt has wrong IP:

1/3/2024 9:24 AM Middleware::Communication Download: http://fog.xxx.org/fog/management/other/ssl/srvpublic.crt

One thing I just noticed:
1/3/2024 9:24 AM Middleware::Communication Download: http://fog.xxx.org/fog/management/other/ssl/srvpublic.crt
Should it be looking at https? I did run the installer to setup https/ssl If I can figure out how to change this I’ll give it a try.

I should have started with: I recently built a new FOG server alongside the older production server, on a different IP. After the build and FOG install, I shutdown the old, and renamed/re-IP’d the new.

Clients will PXE boot and accept the image fine. However, they are not joining the domain, and are not changing the hostname. Fog.log on a client shows that it cannot find srvpublic.crt
When I decode and view srvpublic.crt it has the IP address that the server had while I was building it. I did follow the process to change the IP. I did rerun the install.sh with the -recreateCA and -recreatekeys options. srvpublic.crt was overwritten but still has old IP. I don’t know if this is preventing the file from being found by the client, but I do see it in the correct directory /var/www/html/fog/management/other/ssl.

--------------------------------Authentication--------------------------------

1/3/2024 9:24 AM Client-Info Version: 0.11.5
1/3/2024 9:24 AM Client-Info OS: Windows
1/3/2024 9:24 AM Middleware::Authentication Waiting for authentication timeout to pass
1/3/2024 9:24 AM Middleware::Communication Download: http://fog.xxx.org/fog/management/other/ssl/srvpublic.crt
1/3/2024 9:24 AM Middleware::Communication ERROR: Could not download file
1/3/2024 9:24 AM Middleware::Communication ERROR: The request was aborted: Could not create SSL/TLS secure channel.
1/3/2024 9:24 AM Middleware::Authentication ERROR: Could not authenticate
1/3/2024 9:24 AM Middleware::Authentication ERROR: The system cannot find the file specified.

srvpublic.crt

Certificate Subject
Common Name (CN) 10.50.232.155 (Incorrect IP)
Certificate Issuer
Common Name (CN) FOG Server CA
Certificate Properties
Subject CN=xx.xx.232.155 (Incorrect IP)
Issuer CN=FOG Server CA
Valid From 2024-01-03 16:58:02
Valid To 2033-12-31 16:58:02
Key Size 4096 bits
Key Algorithm RSA
Sig. Algorithm sha256WithRSAEncryption
Serial Number 7B:87:31:FF:BC:1B:45:58:50:B3:5D:08:A8:70:96:63:8D:83:66:84 (705220820937184578402239102187179516367776999044)
Selected Certificate Extensions
SANs DNS:fog.xxx.org, IP:xx.xx.252.126 (correct IP)

@Tom-Elliott
Habit, simply habit. I looked back at the wiki documentation and it definitely does not say to use sh. I do apologize for the confusion and hopefully this helps someone in the future.

@rodluz

Ding, ding, ding, we have a winner! Looks like that did it. Thanks everyone.

@Sebastian-Roth

/bin/bash --version
GNU bash, version 4.4.20(1)-release (x86_64-redhat-linux-gnu)

]# ls -al /bin/bash
-rwxr-xr-x. 1 root root 1150560 Apr 7 2022 /bin/bash

which bash
/usr/bin/bash

ls -al $(which bash)
-rwxr-xr-x. 1 root root 1150560 Apr 7 2022 /usr/bin/bash

@Sebastian-Roth

[root@fog bin]# sh installfog.sh
Installing LSB_Release as needed

• Attempting to get release information…Done
  installfog.sh: line 399: syntax error near unexpected token >' installfog.sh: line 399: exec &> >(tee -a “$workingdir/error_logs/foginstall.log”)’
  [root@fog bin]#

@Sebastian-Roth said in Update to 1.5.10:

As Requested:

[root@fog bin]# ps -p $$
    PID TTY          TIME CMD
 102699 pts/0    00:00:00 bash
[root@fog bin]# echo $0
-bash
[root@fog bin]# echo $SHELL
/bin/bash

I have looked over the previous similar posts but have not found my solution as of yet.
CentOS 7
Fog 1.5.9
Using Git
When I run installfog.sh I get the following:

installfog.sh: line 399: syntax error near unexpected token `>'
installfog.sh: line 399: `    exec &> >(tee -a "$workingdir/error_logs/foginstall.log")'

/error_logs/fog_error_1.5.10.log:

/usr/bin/lsb_release
/usr/bin/systemctl
systemd
ln: failed to create symbolic link '/usr/lib/systemd/system/mysql.service': File exists
ln: failed to create symbolic link '/etc/systemd/system/mysql.service': File exists

I’m stuck here.

Hello everyone,

Bit of a weird one. My techs discovered an issue with the Microsoft Photos app and Win 10 21H2 after sysprepping a new image.
When creating a new image:
The Microsoft Photos app will allow one to print. The print dialog window appears as normal.
After the sysprep:
No longer able to print. The print dialog windows does not appear.
Anyone else having this problem?

Thank you sir

Yes, that is the article I used. The migration went seemingly well, until my tech started to create an image. That’s when we noticed the CA issues. Upon further investigation, some hosts were no longer under control. My tech discovered that deleting the certificate the client was given, and importing the old certificate (from my backup), corrected communication. I was then able to determine that FOG was giving new hosts a new certificate dated back to the day of migration. Which led me to the article that caused me to convert my old FogCA.pem to a .der file, and overwrite the newer ca.cert.der.

1.5.9. However, I believe I just fixed my issue. I won’t be able to confirm until my tech creates a new image, but uninstalling the client from a bad host and reinstalling the client caused it to pull the proper cert. That host is now under control.
What I did:
I found an old CA file, fogCA.pem, in /snapins/ssl/CA. Then performed this:
mv /var/www/html/fog/management/other/ca.cert.der /var/www/html/fog/management/other/ca.cert.der_orig
openssl x509 -in /opt/fog/snapins/ssl/CA/fogCA.pem -out /var/www/html/fog/management/other/ca.cert.der -outform DER
Courtesy of: https://forums.fogproject.org/topic/15908/fog-server-ca-download

I recently performed a migration to 1.5 following all the steps in the Migrate FOG document. I copied over the /snapins/ssl directory as indicated, but this does not include the ca.cert.der, this may not be relevant.
Existing hosts are under control, but new hosts, and new images, are pulling a newer CA, which is halting host control. My best guess is that the new installation created that ca.cert.der file and uses it to pass to a client. I’m at a loss. My workaround has been to import a copy of the old certificate onto the new hosts, and delete the newer incorrect one. This gives me back host control. How do I get this correct, older certificate to install on new hosts and new images moving forward?