Posts made by Daniel Miller

Daniel Miller

@Sebastian-Roth Alrightly, rebuilt Zazzles with the change and now the installer is happy. FOGService isn’t starting, however, or at least fog tray isn’t starting and when I manually start it it is complaining about not being able to connect to the bus.

Daniel Miller

@Sebastian-Roth it’s almost like an open source project depends on free labor or something …

All right, still don’t see how that gets brought it, but it is building, a healthy 8.75 MB, and the installation process is now happy with the install files segment. But now we’re back to the Cert Pinning issue, however (names changed to protect the guilty).

 9/12/2019 4:28 PM Data::RSA ERROR: Unable to retrieve FOG Server CA
 9/12/2019 4:28 PM Data::RSA ERROR: FOG Server CA NOT found in keystore
 9/12/2019 4:28 PM Middleware::Communication Download: http://fogserver/fog/management/other/ca.cert.der
 9/12/2019 4:28 PM Data::RSA Injecting root CA: 
 9/12/2019 4:28 PM Data::RSA ERROR: Unable to inject CA
 9/12/2019 4:28 PM Data::RSA ERROR: Access to the path '/usr/share/.mono/certs/Trust' is denied.

Which brings us back to GenericSetup and the cert store. Currently the diff between my current and commit b299551 is:

@@ -108,11 +108,11 @@ namespace FOG
             var cert = RSA.ServerCertificate();
             if (cert == null) return false;
 
             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();
                 return true;
             }
@@ -127,11 +127,11 @@ namespace FOG
         public static bool InstallFOGCert(string location)
         {
             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);
 
                 var validKeyPresent = false;
                 if (cers.Count > 0)
@@ -166,11 +166,11 @@ namespace FOG
         {
             var cert = new X509Certificate2();
             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);
 
                 if (cers.Count > 0)
                 {
@@ -189,11 +189,11 @@ namespace FOG
 
             if (cert == null) return;
 
             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();
             }
             catch (Exception ex)

Unless I’m missing something, those are the changes you made, yes? I am a bit confused about why it is trying to throw it in /usr/share. There has been a change in the version of mono (6.0.0.327), but running the version of SmartInstaller.exe you sent works as expected when executed under the context of root.

There anything else I should need to clean out other than SetupHelper.* in ./bin to make sure it has the right version in the exe build? Other thoughts?

Daniel Miller

@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

@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

@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

@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

@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

@Sebastian-Roth Nice call.
Installation, both under the auspices of a sudo su -l in terminal and as root 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.

Daniel Miller

@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

@Sebastian-Roth
I can give it a go. Will need another link though; that one is returning an http error 404.

Daniel Miller

@Daniel-Miller said in Trouble installing SmartClient on MacOS Sierra:

SmartInstaller.log

Daniel Miller

@Sebastian-Roth names were changed to protect the guilty.

Daniel Miller

@Sebastian-Roth
Well, not the same, but likely related. The mono issue noted the problem was present on both Linux and macOS, but for different reasons. If the changes in that version of zazzles takes over the cert handling from mono, that solution might work, but the installer removes the client when it detects the failed install so I don’t have a means to test if it does. These are all new installations as part of an attempt to solve a large package deployment issue here, so I don’t have a previously working client base to play with unfortunately.

                     ..#######:.    ..,#,..     .::##::.   
                .:######          .:;####:......;#;..      
                ...##...        ...##;,;##::::.##...       
                   ,#          ...##.....##:::##     ..::  
                   ##    .::###,,##.   . ##.::#.:######::. 
                ...##:::###::....#. ..  .#...#. #...#:::.  
                ..:####:..    ..##......##::##  ..  #      
                    #  .      ...##:,;##;:::#: ... ##..    
                   .#  .       .:;####;::::.##:::;#:..     
                    #                     ..:;###..        
                                                           
                ###########################################
                #     FOG                                 #
                #     Free Computer Imaging Solution      #
                #                                         #
                #     https://www.fogproject.org/         #
                #                                         #
                #     Credits:                            #
                #     https://fogproject.org/Credits      #
                #     GNU GPL Version 3                   #
                ###########################################
                #           FOG Service Installer         #

------------------------------------License-----------------------------------

FOG Service Copyright (C) 2014-2017 FOG Project
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under certain
conditions. See your FOG server under 'FOG Configuration' -> 'License' for
further information.

----------------------------------Information---------------------------------

Version................................................................0.11.16
OS.........................................................................Mac
Current Path........................................../Users/x/Downloads
Install Location............................................../opt/fog-service

-----------------------------------Configure----------------------------------

FOG Server address [default: fogserver]: fogserver
Webroot [default: /fog]:                 
Enable tray icon? [Y/n]:                 y

----------------------------------Installing----------------------------------

Getting things ready....................................................[Pass]
Installing files........................................................[Pass]
Saving Configuration....................................................[Pass]
Applying Configuration..................................................[Pass]
Pinning FOG Project.....................................................[Fail]

Installation failed, cleaning system

-----------------------------------Uninstall----------------------------------

Uninstalling............................................................[Pass]

-----------------------------------Finished-----------------------------------

See /Users/x/Downloads/SmartInstaller.log for more information.

ASEGCB0240-06:opt x$ ls -al /opt
total 0
drwxr-xr-x   2 root  wheel    68 Jun 27 10:23 .
drwxr-xr-x  40 root  wheel  1428 Jun 26 16:37 ..

Daniel Miller

This is still an issue. Tested with Mono 5.20.1 Stable (5.20.1.19) on macOS 10.11.6, 10.13.6, and 10.14.5 with SmartInstaller.exe distributed with 1.5.5 and 1.5.6.

SmartInstaller.log

output from mono --version

Mono JIT compiler version 5.20.1.19 (2018-10/886c4901747 Tue Apr  9 12:37:29 EDT 2019)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           
	SIGSEGV:       altstack
	Notification:  kqueue
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	Interpreter:   yes
	LLVM:          yes(600)
	Suspend:       hybrid
	GC:            sgen (concurrent by default)

Issue on the mono GitHub related to this is certmgr System.UnauthorizedAccessException: Access to the path “/usr/share/.mono” is denied. #12005 and it is still in an open status.

Daniel Miller

@Fernando-Gietz
Well, you may not intend to support such at the moment, but it does work in 1.5.6 provided the groups are specified in the web interface as a comma separated list, which may cause its own problems for some group names. It actually doesn’t look like much more needs to be done to flesh out that first enhancement beyond the UI elements and input validation.

I would suggest taking a look at the sequence of events for the bindings and searches, or at least making sure that the permissions contexts in which those searches occur are consistent. I think the quick and dirty fix I put in at line 547 won’t mess up anything, but I don’t have a lot of experience with either php and ldap.

And for posterity (read: when I forget what I did), diff against ldap.class.php released with 1.5.6 for the changes to address the issues for this thread:

547a548
>             $bind = @$this->bind($bindDN, $bindPass);
616,617c617,618
<             '(&(|(name=%s))(%s=%s))',
<             implode(')(name=', (array)$adminGroups),
---
>             '(&(|(cn=%s))(%s=%s))',
>             implode(')(cn=', (array)$adminGroups),
640,641c641,642
<             '(&(|(name=%s))(%s=%s))',
<             implode(')(name=', (array)$userGroups),
---
>             '(&(|(cn=%s))(%s=%s))',
>             implode(')(cn=', (array)$userGroups),

Daniel Miller

@Fernando-Gietz
Names changed to protect the guilty

Single point change with one group:

string(6) "member" string(77) "(&(|(cn=admins))(member=uid=JohnDoe,ou=People,dc=domain,dc=org))" array(1) { [0]=> string(15) "admins" }

Single point change with two groups:

string(6) "member" string(102) "(&(|(cn=admins)(name=admins2))(member=uid=JohnDoe,ou=People,dc=domain,dc=org))" array(2) { [0]=> string(15) "admins" [1]=> string(18) "admins2" }

Two point change with one group:

string(6) "member" string(77) "(&(|(cn=admins))(member=uid=JohnDoe,ou=People,dc=domain,dc=org))" array(1) { [0]=> string(15) "admins" }

Two point change with two groups:

string(6) "member" string(100) "(&(|(cn=admins)(cn=admins2))(member=uid=JohnDoe,ou=People,dc=domain,dc=org))" array(2) { [0]=> string(15) "admins" [1]=> string(18) "admins2" }

So long as no one puts in two or more groups, the filter is correct. If someone does put in two or more comma separated group names, the second and following attribute searches will not be consistent with the first.

Daniel Miller

@Fernando-Gietz
I actually changed it both on that line and for the implode() ‘glue’ for both the $adminGroups and $userGroups. if either of those two arrays were to contain more than one entry, the second and following groups would have the incorrect attribute name.

        $adminGroups = explode(',', $adminGroup);
        $adminGroups = array_map('trim', $adminGroups);
        $filter = sprintf(
            '(&(|(cn=%s))(%s=%s))',
            implode(')(cn=', (array)$adminGroups),
            $grpMemAttr,
            $this->escape($userDN, null, LDAP_ESCAPE_FILTER)
        );
        /**
         * The attribute to get.
         */
        $attr = array($grpMemAttr);

and

        $userGroups = explode(',', $userGroup);
        $userGroups = array_map('trim', $userGroups);
        $filter = sprintf(
            '(&(|(cn=%s))(%s=%s))',
            implode(')(cn=', (array)$userGroups),
            $grpMemAttr,
            $this->escape($userDN, null, LDAP_ESCAPE_FILTER)
        );
       /**
         * The attribute to get.
         */
        $attr = array($grpMemAttr);

Daniel Miller

@george1421
Well, var_export() to get the string. after beating my head against things, looks like var_dump() drops it to console.

Passwords and user account names are all in the lower 127 ASCII

While poking around getting the variable exports in place, I ended up putting wireshark on it to troubleshoot how I broke things (think I moved some parentheses). When I put the original file back, I noticed the following traffic:

Simple Bind as search user
search for the user dn
Simple Bind as the authenticating user
Search for the user dn again
Search for the admin group with the user listed in the member attribute
search for the mobile group with the user listed in the member attribute
search for the user listed in any group
Request an unbind

I could see where this may cause an issue if the binding context were changed to the authenticating user during the second simple bind; in our implementation, non-system users don’t have permission to search the directory for anything other than themselves.

Inserting another call to $bind = @$this->bind($bindDN, $bindPass); before the call to _getAccessLevel() on line 547 made things happy and got me to the management page.

Daniel Miller

@george1421 Like I said, I can successfully authenticate with the match groups disabled, so that should mean that the search bind dn and password are correct, but if I change the bind password to a known bad value I get:

 AH01071: Got error 'PHP message: Plugin LDAP::authLDAP() Cannot bind to the LDAP server ldap://ldap.domain.org:389\n', referer: http://10.10.25.15/fog/management/index.php?node=home

Daniel Miller

SERVER
FOG Version: 1.5.6
OS: Ubuntu 16.04.6 LTS

DESCRIPTION:
I don’t know if this is by accident (belongs in general problems) or design (should be a feature request), but it appears that the LDAP plugin distributed with FOG 1.5.6 can not successfully query group information from an OpenDirectory implementation using an rfc2307bis schema. I have an LDAP configuration that works when group matching is not enabled. When I enable group matching, I receive errors such as this in /var/log/apache2/error.log (names changed to protect the guilty):

 AH01071: Got error 'PHP message: Plugin LDAP::_result(). Search Method: search; Filter: (&(|(name=admins))(member=uid=JohnDoe,ou=People,dc=domain,dc=org)); Result: 0\nPHP message: Plugin LDAP::_result(). Search Method: search; Filter: (&(|(name=admins))(member=uid=JohnDoe,ou=People,dc=domain,dc=org)); Result: 0\nPHP message: Plugin LDAP::_result(). Search Method: search; Filter: (member=*); Result: 0\nPHP message: Plugin LDAP::_getAccessLevel() Group Search DN did not return any results. Group Search DN: ou=groups,dc=domain,dc=org\nPHP message: Plugin LDAP::authLDAP() Access level is still 0 or false. No access is allowed!\n', referer: http://10.10.25.15/fog/management/index.php?node=home

The filter recorded here is not correct for our LDAP structure: performing an ldapsearch for (&(|(name=admins))(member=uid=JohnDoe,ou=People,dc=domain,dc=org)) against our group OU will produce no results, but querying for (&(|(cn=admins))(member=uid=JohnDoe,ou=People,dc=domain,dc=org)) produces the expected results. I don’t see anywhere in the web ui to change the attribute for the name of the group, but I went in and changed the attribute in lines 616-617 and 640-641 of ldap.class.php. After doing so, however, I continue to see the same errors, but with the correct ldap filter.

 AH01071: Got error 'PHP message: Plugin LDAP::_result(). Search Method: search; Filter: (&(|(cn=admins))(member=uid=JohnDoe,ou=People,dc=domain,dc=org)); Result: 0\nPHP message: Plugin LDAP::_result(). Search Method: search; Filter: (&(|(cn=admins))(member=uid=JohnDoe,ou=People,dc=domain,dc=org)); Result: 0\nPHP message: Plugin LDAP::_result(). Search Method: search; Filter: (member=*); Result: 0\nPHP message: Plugin LDAP::_getAccessLevel() Group Search DN did not return any results. Group Search DN: ou=groups,dc=domain,dc=org\nPHP message: Plugin LDAP::authLDAP() Access level is still 0 or false. No access is allowed!\n', referer: http://10.10.25.15/fog/management/index.php

I also get similar errors if I change the Group Search DN to a known bad value.

 AH01071: Got error 'PHP message: Plugin LDAP::_result(). Search Method: search; Filter:  (&(|(cn=admins))(member=uid=JohnDoe,ou=People,dc=domain,dc=org)); Result: 0\nPHP message: Plugin LDAP::_result(). Search Method: search; Filter:  (&(|(cn=admins))(member=uid=JohnDoe,ou=People,dc=domain,dc=org)); Result: 0\nPHP message: Plugin LDAP::_result(). Search Method: search; Filter: (member=*); Result: 0\nPHP message: Plugin LDAP::_getAccessLevel() Group Search DN did not return any results. Group Search DN: ou=group,dc=domain,dc=org\nPHP message: Plugin LDAP::authLDAP() Access level is still 0 or false. No access is allowed!\n', referer: http://10.10.25.15/fog/management/index.php?node=home

Based on this, it looks like something isn’t behaving with respect to $searchdn in _result() during a group search, but I don’t see any smoking guns. I have tried changing the search scope in the web interface to each of the available options: “Base only” fails the initial user lookup (expected with the configuration) and “subtree” and “subtree and below” throw the same errors with the expected change in search scope.

Any suggestions where to go from here?