[MODULES-7553] sqlserver module, documentation: Advanced Example using the hostname fact has issues Created: 2018/07/30  Updated: 2019/05/20  Resolved: 2019/05/20

Status: Resolved
Project: Modules
Component/s: sqlserver, windows
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Patrick Grant Assignee: William Hurt
Resolution: Fixed Votes: 0
Labels: Support, maintenance, triage, windows_engineer_triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Epic Link: IAC - Customer Escalations
Team: Windows
Story Points: 1
Sprint: Windows 2019-05-29
QA Risk Assessment: Needs Assessment

 Description   

Ticket raised on behalf of PE customer using our sqlserver module.

The customer had an issue when they followed the modules advanced example: https://forge.puppet.com/puppetlabs/sqlserver#advanced-example

Like the example, the customer tried to use the hostname fact when assigning a user to a role.

However, this didn’t work and the customer had to specifically use the Uppercase domain shortname rather than the hostname fact as below:

 

$short_domain_name = 'MYCOMPANY'
sqlserver::config { $instancename: 
admin_login_type => 'WINDOWS_LOGIN'
sqlserver::login{ "${short_domain_name}\\${puppet_mgt_account}"
instance => $instancename, 
login_type => 'WINDOWS_LOGIN'
require => Sqlserver::Config[$instancename], 
sqlserver::role { 'serveradmin'
ensure => present, 
instance => $instancename, 
type => 'SERVER'
members => ["${short_domain_name}\\${puppet_mgt_account}", $facts['id']], 
require => Sqlserver::Login["${short_domain_name}\\${puppet_mgt_account}"], 
}

 

 

The customer feels that this needs to be documented or there needs to be an engineering effort to account for this.



 Comments   
Comment by Benjamin Ostrowski [ 2018/08/01 ]

FYI, it wasn't the hostname fact I was attempting to use, it was the domain fact that gets resolved to the FQDN of the domain that the server is joined to (e.g. mydomain.com).  It would be my hope that i wouldn't have explicitly define a variable such as 

$::domain = 'MYCOMPANY'

 

but instead use the fact that already exists for "domain" to be able to add these logins and roles.  Such as...

 

sqlserver::config { $instancename: 
admin_login_type => 'WINDOWS_LOGIN', 
} 
sqlserver::login{ "${::domain}\\${puppet_mgt_account}": 
instance => $instancename, 
login_type => 'WINDOWS_LOGIN', 
require => Sqlserver::Config[$instancename], 
} 
sqlserver::role { 'serveradmin': 
ensure => present, 
instance => $instancename, 
type => 'SERVER', 
members => ["${::domain}\\${puppet_mgt_account}", $facts['id']], 
require => Sqlserver::Login["${::domain}\\${puppet_mgt_account}"], 
}

Comment by William Hurt [ 2019/05/10 ]

The documentation should be updated to point out that the `$::domain` facter fact is not suitable for constructing user names.

I have also raised an issue with the vox module windows_env asking for feedback on the idea of adding the NETBIOS domain name to their facts module. This would give users a suitable fact for this purpose without having to hard code strings like this, or attempt to substring them in ways that could be difficult for some users.

Comment by William Hurt [ 2019/05/16 ]

My offer to add NETBIOS name as a fact to the vox windows_env module was not accepted. This ticket will now default to a simple documentation change.

Comment by William Hurt [ 2019/05/20 ]

Merged to master at: https://github.com/puppetlabs/puppetlabs-sqlserver/commit/6f04ba6605b394dae46d7ff8ef6ee19d9ea75344

Generated at Wed Apr 01 14:17:49 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.