Trouble installing SmartClient on MacOS Sierra
-
@Daniel-Miller Dang… should have expected that.
I am not that great a C# coder than Joe is who created the whole new fog-client three years ago. Looking around I came across this: https://www.pinvoke.net/default.aspx/shell32/SHSetKnownFolderPath.html
Maybe we can use this on MacOS X to save the cert store in a different place?!
As well I am wondering what would happen if we change the fog-client code to not do:
var store = new X509Store(StoreName.Root, StoreLocation.LocalMachine);
but
var store = new X509Store(StoreName.Root, StoreLocation.CurrentUser);
But I have no idea where it would put the store then and if things would work this way?!
-
@Daniel-Miller I just compiled a new SmartInstaller for you that does use the
StoreLocation.CurrentUser
. Lets see if that makes a difference on your MacOS X.Cant promise anything. Its just a first try and I am not really sure if it will run properly even if the installer itself is fixed. The whole project building and signing the binaries is a very complex process and I am not sure I got it all right.
-
@Sebastian-Roth
I can give it a go. Will need another link though; that one is returning an http error 404. -
@Daniel-Miller Strange, the link worked yesterday. Will upload somewere else later on.
-
@Daniel-Miller I know this doesn’t look very official uploading the installer to some cloud thing but it’s just for testing and the easiest for me right now: https://cloud.mi.hdm-stuttgart.de/index.php/s/LZnrNB9cWrmqsz7
-
@Sebastian-Roth no worries
Good News:
The installer finished up without error.
After rebooting the machine and logging back into the admin user, the tray icon appeared, the service process appears to be running, and/opt/fog-server/fog.log
appears to be initially happy:6/28/2019 11:29 AM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo &configure&newService&json 6/28/2019 11:29 AM Middleware::Response Success 6/28/2019 11:29 AM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo &mac=00:25:00:F0:83:DF|00:25:00:F0:6F:45|00:25:4B:FF:FE:FB:69:24&newService&json 6/28/2019 11:29 AM Middleware::Response Invalid host 6/28/2019 11:29 AM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?clientver&newServic e&json 6/28/2019 11:29 AM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?newService&json 6/28/2019 11:29 AM Service Creating user agent cache 6/28/2019 11:29 AM Middleware::Response Module is disabled on the host 6/28/2019 11:29 AM Middleware::Response Module is disabled on the host 6/28/2019 11:29 AM Middleware::Response Module is disabled globally on the FOG server
Bad News:
Certificate store appears to be~/.config/.mono/certs/Trust
with respect to the installing user account and the service doesn’t appear to be reliably pulling from that store after further reboots. From/opt/fog-service/fog.log
:------------------------------------------------------------------------------ --------------------------------Authentication-------------------------------- ------------------------------------------------------------------------------ 6/28/2019 11:44 AM Client-Info Version: 0.11.16 6/28/2019 11:44 AM Client-Info OS: Mac 6/28/2019 11:44 AM Middleware::Authentication Waiting for authentication timeout to pass 6/28/2019 11:46 AM Middleware::Communication Download: http://fogserver/fog/management/other/ssl/srvpublic.crt 6/28/2019 11:46 AM Data::RSA ERROR: Unable to retrieve FOG Server CA 6/28/2019 11:46 AM Data::RSA ERROR: FOG Server CA NOT found in keystore 6/28/2019 11:46 AM Middleware::Authentication ERROR: Could not authenticate 6/28/2019 11:46 AM Middleware::Authentication ERROR: Value cannot be null. Parameter name: authority 6/28/2019 11:46 AM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo&configure&newService&json 6/28/2019 11:46 AM Middleware::Response Success 6/28/2019 11:46 AM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo&mac=00:25:00:F0:83:DF|00:25:00:F0:6F:45|00:25:4B:FF:FE:FB:69:24&newService&json 6/28/2019 11:46 AM Middleware::Authentication Waiting for authentication timeout to pass 6/28/2019 11:48 AM Middleware::Communication Download: http://fogserver/fog/management/other/ssl/srvpublic.crt 6/28/2019 11:48 AM Data::RSA ERROR: Unable to retrieve FOG Server CA 6/28/2019 11:48 AM Data::RSA ERROR: FOG Server CA NOT found in keystore 6/28/2019 11:48 AM Middleware::Authentication ERROR: Could not authenticate 6/28/2019 11:48 AM Middleware::Authentication ERROR: Value cannot be null. Parameter name: authority 6/28/2019 11:48 AM Middleware::Response Success 6/28/2019 11:48 AM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?clientver&newService&json 6/28/2019 11:48 AM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?newService&json 6/28/2019 11:48 AM Service Creating user agent cache 6/28/2019 11:48 AM Middleware::Response ERROR: Unable to get subsection 6/28/2019 11:48 AM Middleware::Response ERROR: Object reference not set to an instance of an object 6/28/2019 11:48 AM Middleware::Response ERROR: Unable to get subsection 6/28/2019 11:48 AM Middleware::Response ERROR: Object reference not set to an instance of an object 6/28/2019 11:48 AM Middleware::Response ERROR: Unable to get subsection 6/28/2019 11:48 AM Middleware::Response ERROR: Object reference not set to an instance of an object 6/28/2019 11:48 AM Service Initializing modules
Being the service appears to start as root, I’m not entirely certain how it was initially able to access the cert store (I blame unicorns). Unfortunately, the constructor for X509Store appears to be doing exactly what it was told without any pleasant side effects.
Additionally, even when the service was checking in, the fog server didn’t appear to be acknowledging the communications; the http requests were showing up in other_vhosts_access.log on the fog server, but no pending registrations appeared in the web interface and, when I manually added the host and scheduled a hardware inventory, no task reboot information appeared to be passed to the client. This may be attributable to the lack of CA (or the aforementioned unicorns).
I did try swapping out the Zazzles.dll with the one posted in Client not authenticating, but it is giving the same results.
-
@Daniel-Miller Well at least looks like we are making a bit of progress here. Not perfect but still seems like we got some space to try things out.
First I might ask you to try and run the installer as
root
and see if you can make it work that way.6/28/2019 11:46 AM Data::RSA ERROR: Unable to retrieve FOG Server CA 6/28/2019 11:46 AM Data::RSA ERROR: FOG Server CA NOT found in keystore
This is most probably due to it not finding the cert store in the right place. No chance to make it work using the Zazzles.dll I patched for Linux.
-
@Sebastian-Roth Nice call.
Installation, both under the auspices of asudo su -l
in terminal and asroot
through ARD, appear to be behaving after a manual kick to launchctl. The newest iMacs don’t seem to be triggering a pending host notification, but they are logging the communication on the client and in the apache logs. I suspect there might be too many mac addresses, but I am thinking that is a Monday problem. -
Cross linking a new post on the same issue: https://forums.fogproject.org/topic/13611/unable-to-complete-smartinstaller-exe-on-macos-mojave-10-14-6
Probably something we should try to fix but it’s a tough one, I don’t have Mac OS X to test and very little time. @Daniel-Miller Are you willing and keen to setup a fog-client development environment and help work on this?
-
@Sebastian-Roth I have a couple units I can probably play with and might be able to find a little time to cobble something together.
-
@Daniel-Miller Any news on this topic?
-
@Sebastian-Roth
Start of semester … time is an illusion
It is just a matter of relaunching the installer if on a mac and not running as ‘root’ in addition to the change you made. That was just substituting StoreLocation.CurrentUser for StoreLocation.LocalMachine in GenericSetup.cs, yes? I have some logic framed in for the relaunch that puts it in the right user context, but something about how the installer is built isn’t getting the auxiliary files (.sh, .dll, etc.) packed with the executable, so while the relaunched environment looks right, I can’t definitively say it works. Can drop the diff here unless you have a better means of getting things from point A to B. -
@Daniel-Miller I have read you message at least four times now but I still don’t fully understand.
That was just substituting StoreLocation.CurrentUser for StoreLocation.LocalMachine in GenericSetup.cs, yes?
Yes I think so. Just checked the diff I had lying around:
diff --git a/SetupHelper/GenericSetup.cs b/SetupHelper/GenericSetup.cs index a9b7a72..d4e2f41 100644 --- a/SetupHelper/GenericSetup.cs +++ b/SetupHelper/GenericSetup.cs @@ -110,7 +110,7 @@ namespace FOG try { - var store = new X509Store(StoreName.Root, StoreLocation.LocalMachine); + var store = new X509Store(StoreName.Root, StoreLocation.CurrentUser); store.Open(OpenFlags.ReadWrite); store.Remove(cert); store.Close(); @@ -129,7 +129,7 @@ namespace FOG try { var cert = new X509Certificate2(location); - var store = new X509Store(StoreName.Root, StoreLocation.LocalMachine); + var store = new X509Store(StoreName.Root, StoreLocation.CurrentUser); store.Open(OpenFlags.ReadWrite); var cers = store.Certificates.Find(X509FindType.FindBySubjectName, "FOG Project", true); @@ -168,7 +168,7 @@ namespace FOG try { X509Certificate2 CAroot = null; - var store = new X509Store(StoreName.Root, StoreLocation.LocalMachine); + var store = new X509Store(StoreName.Root, StoreLocation.CurrentUser); store.Open(OpenFlags.ReadOnly); var cers = store.Certificates.Find(X509FindType.FindBySubjectName, "FOG Project", true); @@ -191,7 +191,7 @@ namespace FOG try { - var store = new X509Store(StoreName.Root, StoreLocation.LocalMachine); + var store = new X509Store(StoreName.Root, StoreLocation.CurrentUser); store.Open(OpenFlags.ReadWrite); store.Remove(cert); store.Close();
but something about how the installer is built isn’t getting the auxiliary files (.sh, .dll, etc.) packed with the executable
Can you be more specific on what’s going wrong here or why you think the files are not packed?
Which version are you trying to build from? Latest
master
? Since we talked about this last in June (!) I have pushed a commit to update dependencies. This is causing a bit of trouble and I have not found the time to properly get this right again. Please use commit b2995511 for now! Sorry for that.You might also want to change the build script to get more output:
diff --git a/build.ps1 b/build.ps1 index 0773e88..f15bfc0 100644 --- a/build.ps1 +++ b/build.ps1 @@ -118,7 +118,7 @@ Copy-Item "$PSScriptRoot\bin\FOGService.msi" $InstallerMSI Copy-Item "$PSScriptRoot\bin\FOGService.msi" "$PSScriptRoot\out\FOGService.msi" Write-Host "Building Smart Installer" -Invoke-Expression ($msbuild + $installerConfig) | out-null +Invoke-Expression ($msbuild + $installerConfig) #| out-null Write-Host "ILMerging Smart Installer"
-
@Sebastian-Roth
That diff matches the one I had for GenericSetup.cs.Lots of little things, like Visual Studio complaining about the name of OSX-FOG-TRAY.ZIP (renamed it to make it happy, but don’t know if I found all the references), SmartInstaller.exe only being 4.5 MB, and initial error messages about not being able to find Zazzles.dll when running the executable. Resynches off the current master and that commit seems to do the same thing, so I’m almost certain it’s something wrong with how my environment is set up and very likely due to MS not distributing ilmerge any more. Does this GitHub for ILMerge look like the same beast?
And this is all assuming I am actually synching to the points I am intending to … I’m a little new to using source control.
-
@Daniel-Miller said:
That diff matches the one I had for GenericSetup.cs.
Good.
Lots of little things, like Visual Studio complaining about the name of OSX-FOG-TRAY.ZIP (renamed it to make it happy, but don’t know if I found all the references)
Right, I keep forgetting about this one. Should have fixed that a long time ago. I usually rename it after cloning the fresh source and soon forget about it. It’s good others look into this as well.
SmartInstaller.exe only being 4.5 MB, and initial error messages about not being able to find Zazzles.dll when running the executable. Resynches off the current master and that commit seems to do the same thing, so I’m almost certain it’s something wrong with how my environment is set up and very likely due to MS not distributing ilmerge any more. Does this GitHub for ILMerge look like the same beast?
Yes, sounds very much like it. Something I have not noticed yet as we have our build environment set up since a long time. Good three years ago when I updated the build instrcutions in README.md the download from Microsoft still was available. The one you found in github looks very promising but seems like there are no official MSI releases that you can simply install as it used to. I will look into that and get back to you in a few hours.
And this is all assuming I am actually synching to the points I am intending to … I’m a little new to using source control.
What you usually do on the command line - and I assume you have the same options in a GUI GIT tool:
- Clone a copy of the repo - you can skip that as you’ve already done that:
git clone https://github.com/FOGproject/fog-client
- Now the repo is on
master
branch latest version and you want to checkout a different version:cd fog-client; git ccheckout b2995511
- Open the project in Visual Studio - or reload if you had it open already!
- Clone a copy of the repo - you can skip that as you’ve already done that:
-
@Daniel-Miller Have not found the time to work on this but doing a bit more search engine foo I found this: https://github.com/mono/nuget/blob/master/Tools/ILMerge/ILMerge.msi
You might use that older version of ILMerge till we get the other one ready.
-
@Sebastian-Roth Seems to be a lot happier on the build side, but the exe is still a bit anemic, only 6.2MB as opposed to the 8.9MB that is on my servers. It does run and properly relaunches, so the requisite dlls are there, but fails during the Installing Files stage with errors in the log
9/11/2019 4:59 PM Installer ERROR: Method: <Install>b__0 9/11/2019 4:59 PM Installer ERROR: Central Directory corrupt.
I would guess the service scripts, tray executables, etc. still aren’t getting bundled in.
Looking at the build script, I don’t see where they get attached, or are those supposed to be configured as resources in the properties for UniversalInstaller?
-
@Daniel-Miller Yeah, still sounds like there is something missing. Try removing the
| out-null
at the end of the lines to get more output from the commands inbuild.ps1
. As well you might want to try this if you have a Windows PC at hand: Copy the SmartInstaller.exe over to that PC and use 7-Zip to extract the EXE file. Within the extracted files you find one that is several MB in size called.text
. Again, rightclick that file and use 7-Zip to extract it. It will do some extraction but also print an error message. But again you should have files extracted. How many files does it extract from your binary on the second run?9/11/2019 4:59 PM Installer ERROR: Method: <Install>b__0 9/11/2019 4:59 PM Installer ERROR: Central Directory corrupt.
I haven’t seen this error before. I’ve dug through the code but can’t seem to figure out why it says
b__0
!? When extracting manually as described above you get filenames likeZazzles
and so on. -
@Sebastian-Roth Never seen that error before, you say? Now don’t I feel special.
Extracting.text
gives me 50 files and they seem to reasonably match (by filename and checksum) the 48 extracted from production version. Extra files are a Modulespt and ShutdownGUIpt.Google-foo indicates the “Central Directory corrupt” error results from some interaction with a zip archive and the b__0 might be a reference to some helper class. Only place I’m seeing in the install process that might bump into that would be the extraction of osxfogtray.zip. I still don’t see where that zip gets bundled in either the working build or the production build, but just for ho-hos I decided to take a peek at what that file looks like and it appears to be 0 bytes in size. As that probably isn’t right for a zip archive, I checked the repo and oddly enough the file ./UniversalInstaller/Scripts/OSX-FOG-TRAY.zip is 0 bytes in size and it looks like it has been that way since the initial commit.
-
@Daniel-Miller Ohhh gosh!! I see our build process is pretty well messed up. Sorry for all the issues you run into and wast all your time on.
Please download the OSX Tray ZIP here for now: https://github.com/FOGProject/fog-client/releases/download/0.11.16/OSXFOGTray.zip
Thank you very much for sticking around even though things are not going very well. We just don’t have enough people to help out and work on all the different FOG components and so things get messy - too bad.