Chown error during NetSUS 5.0 install

[jelockwood]

I have installed NetSUS 5.0 over the top of NetSUS 4.1 on an Ubuntu 16.04 virtual machine. It is only being used for the SUS portion but I did notice an error during the install. Here is the relevant part of the output displayed during the install process.

The following will be installed
* Appliance Web Interface
* File Sharing
* Software Update Server
* NetBoot Server
* LDAP Proxy

Proceed?  (y/n): y
Installing...
Starting Web Application Installation
ERROR: Site default-ssl not properly enabled: /etc/apache2/sites-enabled/default-ssl.conf is a real file, not touching it
Restarting apache...
OK
Finished deploying the appliance web application
Starting NetBoot Installation
smbuser already exists
afpuser already exists
OK
Finished deploying NetBoot
Starting SUS Installation
OK
Finished deploying SUS
Starting LDAP Proxy Installation
chown: invalid user: ‘ldap’
chown: invalid user: ‘ldap:ldap’
OK
Finished deploying the LDAP Proxy

The NetSUSLP has been installed.
To complete the installation, open a web browser and navigate to https://sus:443/.
If you are installing NetSUSLP for the first time, please follow the documentation for setup instructions.

As I am only using the SUS module I am not able to test the LDAP Proxy which based on the above might not work properly due to this error. I can confirm that in /etc/passwd there is no user account listed called ldap.

[duncan-mccracken]

Are you able to post the full installation log for this. I've noticed on occasion in an upgrade scenario that slapd wasn't getting installed on certain versions of Ubuntu 16, due to the package list refresh not being successful You can install slaps from the command line using these commands: sudo apt-get update sudo apt-get install slapd Then re-run the NetSUS installer. Note: if slaps was already installed with a customer user account, you would need to download the source and edit the LDAPProxyInstall.sh script with the correct credentials, build your own installer and proceed from there. Even then, there still may be issues as I belief the LDAP user is referenced in other locations in the supporting files, and there is no provisioning in that code for an alternate username. Disclaimer: I didn't do a lot with the LDAP proxy in this version as Jamf's Infrastructure Manager performs the same function, and this is the recommended path for LDAP proxy. The implementation in NetSUS may be deprecated soon.

[jelockwood]

The NetSUS server is not running OpenLDAP so probably does not have slapd installed. If it is a requirement to have OpenLDAP installed so it can run the LDAP proxy this should be listed as a dependency in the NetSUS installer so it automatically installs it as well.

Since I have no plan to use the NetSUS LDAP proxy I will not pursue this further but I thought it might be helpful to let you know.

Note: The same thing would potentially apply to the JAMF Infrastructure Manager, if it requires OpenLDAP aka slapd it should list it as a dependency in its installer so as to automatically install it if needed.

[duncan-mccracken]

The installer does have the slapd installation as part of its routine. Its supposed to abort installation if any of the dependencies fail. Weird. I'd still appreciate the installer log, from: Settings > Logs > /var/appliance/logs/applianceinstaller.log As if the installation failures aren't aborting, this may not be limited to just slapd.

[jelockwood]

Here is the appliance installer.log

applianceinstaller.log

From the first date it seems it covers the original install of NetSUS 4.1 as well as the (several) installs of NetSUS 5.0 I run the 5.0 install multiple times as I manually resolved the location of my existing SSL certs by creating symbolic links in /etc/pki/tls/certs

[duncan-mccracken]

Thanks, I've had a look through this, all appears as you described. I've also cross-referenced to the installer's module which handles the slaps configuration. This is what I've found: The error is generated because of the presence of the /etc/openldap directory (which is the default for CentOS/RHEL, as well as the presence of /etc/ldap (the default for Ubuntu) I may have to update the installer to do a bit deeper checking during the installation than simply the presence of the default os-specific config directories. I assume you are doing a roll-your-own installation, so its possibly caused by an ldap configuration in the base OS you are installing on. That being said, it may pay you to check the contents of /etc/openldap if you have a directory service configuration for shell (or other access) because the installer may have attempted to apply the CentOS / RHEL configuration to the following things: /etc/openldap/slapd.conf /etc/openldap/certs/ Does this shed any light on things?

[jelockwood]

As far as I can tell the standard user/service account for OpenLDAP is called - openldap

Perhaps your install script is using the wrong username. Similarly for the group it is also called openldap

So perhaps the chown should be

chown openldap:openldap

and not

chown ldap:ldap

[duncan-mccracken]

The former (user: openldap) is (and did) happen during the installation process as expected. The installer itself performs these tasks post-installation of slapd. The conditional check for this is the presence of the directory /etc/ldap (Ubuntu's slapd default directory) The latter (user: ldap) tests for the presence of /etc/openldap (default for RHEL/CentOS), then performs the RHEL/CentOS specific tasks. Your system has both of these directories, which is what is generating the error. I will add an additional check to the installer to also test for the default os slapd user in conjunction to the presence of the os-specific default directory. My previous connects were for you to check anything that your environment lays down in /etc/openldap because the installer may have attempted to modify them.