Developers

@LittleTux Please check the speech bubble in the top right corner.

@sjensen Looking at the pictures you posted it looks like you added space to partition /dev/sda3. That seems kind of strange from my point of view.

It’s very hard to help you in such a situation where we don’t know what exactly was done and how it was initially setup. Lets give it a try nevertheless. Please run the following commands and post all outputs here:

lsblk
pvscan
lvscan
sfdisk -d /dev/sda

@itay Do you plan to update to CentOS 8 as well or keep 7 (still some years before end of life!)?

@itay Yep. You can upgrade.

I would suggest making a backup first just to be on the safe side. Better if your FOG server is a VM, create a snapshot before.

@lebrun78 said in Error 2691 add to domain ok:

Yes, I now unterdstand the problem, fog client is running with local\install account, not system.

Ahhhhhhh, there we go. One tiny bit of information that was still missing to solve this!

Have you example to access samba share with client running under system account ?

Just just a public readable share!?

@LittleTux The other server has its own CA and certificates and it’s not a good idea to copy things over from that.

From the output you posted we see that most of the files match (same fingerprints and verify OK) but the key file doesn’t!! This is causing the issue for sure.

So let’s check the backup of the old files you have to see if we can get things back this way. How did you take that backup copy? Does it have the file .srvprivate.key in it (on Linux systems files starting with a dot are kind of hidden)?

@LittleTux I find it strange we see the “Data::RSA FOG Server CA cert found” and “Middleware::Authentication Cert OK” messages. As far as I see it this would mean the client does use the certificate provided by the new server already.

I just backup the /opt/fog/snapins/ssl directory of the old one in case of certificate client/server issues :-).

Did you copy this backup of the certificate, key and CA of your old server to the new install at some point yet?

Please run the following commands to see if the certs are somehow messed up:

openssl x509 -noout -fingerprint -md5 -in /opt/fog/snapins/ssl/CA/.fogCA.pem
openssl x509 -noout -fingerprint -md5 -in /var/www/html/fog/management/other/ca.cert.pem

openssl x509 -noout -modulus -in /var/www/fog/management/other/ssl/srvpublic.crt | openssl md5
openssl rsa -noout -modulus -in /opt/fog/snapins/ssl/.srvprivate.key | openssl md5

openssl verify -verbose -CAfile /opt/fog/snapins/ssl/CA/.fogCA.pem /var/www/fog/management/other/ssl/srvpublic.crt

@lebrun78 Did you see this part of my post as well?

Can you please try running the test tool as local SYSTEM account to see if it shows a different output than ran as AD admin. Download MS sysinternals tool PsExec and run psexec -s -i cmd.exe to get a command shell run as SYSTEM. Now start your script/tool here and compare the output to what you get running as AD admin.

@hancocza That sounds like we hit an error that was introduced in iPXE some time within the last year. Would you be keen to find out which change exacly it was to hopefully report to the iPXE devs and get it fixed?

That would mean you’d compile a fair amount of binaries and test all of them. Would you be willing? Half a day of work should be enough I suppose.

It’s not too complicated and you will learn using an awesome feature of git called “bisect”…

@chipdewolfe Great! Thanks for sharing this here.