Do you know if there is a work around to this, or when we could expect a fix? I have some 1200 servers that people are waiting/wanting to be able to do puppet runs on, from Foreman.

Case insensitivity is by design at the moment in fact importers, so I don't think it's trivial to change. I can't predict when somebody will fix it, if it ever is changed, I'm only triaging the bug.

If you want to have a go at changing the behaviour, the downcase statements in Host::Managed's import_host_and_facts method is probably where to begin, however some thought would need to be given to the consequences (case sensitivity versus insensitivity).

Dominic Cleal wrote:

Case insensitivity is by design at the moment in fact importers, so I don't think it's trivial to change. I can't predict when somebody will fix it, if it ever is changed, I'm only triaging the bug.

If you want to have a go at changing the behaviour, the downcase statements in Host::Managed's import_host_and_facts method is probably where to begin, however some thought would need to be given to the consequences (case sensitivity versus insensitivity).

As a QA tester, I would consider this to be a major bug. There is functionality in Foreman that is completely broken and useless. When wanting to push the hostnames from Foreman to other service (mco, ps, etc), it is impossible as the hostname does not come in to Foreman correctly. The main reason we moved to Foreman was to take advantage for individual groups to "Run Puppet" on their own, on multiple machines at once. In some cases we have teams that need to Run Puppet on ~ 350 machines at once. Foreman would have allowed us to do this, but with it receiving incorrect case sensitivity, many of Foremans capabilities are now irrelevant.

Facter pulls the correct case sensitivity. We import them into mco as well, which handles the case sens perfectly. Puppet Enterprise and the deprecated Puppet Dashboard also handle correct case. Foreman is the only one that does not. I will look into repairing the bug myself, but this should really be reconsidered by the Foreman team.

Although I was hoping for a different response about the bug, I do appreciate your reply.

Honestly, I'm not sure if this is necessarily a Foreman Bug or merely an mco bug. DNS by design is not case sensitive, although it is case "aware". So, whereas I sympathize with your issue, it appears that the foreman code takes an elegant approach to merely downcase the hostname to ensure ease of further integration. I would think that mco should likewise take the DNS case insensitive RFC into account when calling commands against hostnames.

Now with that being said... Oddly enough, Foreman DOES NOT take the same practice in dealing with the domain fact. We currently have an issue where we get CAPS.net, caps.NET, caps.net, and CAPS.NET domains popping up in the GUI due to some random machine in our network querying our domain in different cases (very intermittant and frustrating). This causes our recursive dns servers' cache to serve the domain up in the improper case and funneling that down into our hosts' facts and finally impacting foreman's domain list. I haven't decided on whether to open a bug report for this, but it does directly conflict with this bug report to some extent.

I thought the same. So I tested it when I originally found this. I have mco tied in with another service as well, and that records the host name with correct sensitivity. I did open a bug with mco, and they agreed it is not an mco issue, as mco just takes whatever it is given. When you "Run Puppet" in Foreman, with mcollective as the provider, here is what it sends:

JNSEMTEST hostname is in all caps.

From the foreman-proxy/proxy.log
D, [2015-01-08T12:38:51.867799 #6451] DEBUG -- : about to execute: /usr/bin/sudo /usr/bin/mco puppet runonce -I jnsemtest.foundry.test
W, [2015-01-08T12:38:52.363122 #6451] WARN -- : Non-null exit code when executing '/usr/bin/sudo/usr/bin/mcopuppetrunonce-Ijnsemtest.foundry.test'

Where as my other service that push the host name to mco, push it as:
Started POST "/execute/puppet/runonce" for 172.31.100.214 at 2015-01-08 14:24:14 -0600
Processing by ExecuteController#execute as JSON
Parameters: {"{\"filter\":{\"identity\":"=>{"\"JNSEMTEST\""=>{"},\"args\":{\"force\":false,\"server\":\"puppet.foundry.test\",\"noop\":false,\"splay\":false}}"=>nil}}, "agent"=>"puppet", "mcaction"=>"runonce"}

mco will just use whatever its told to use. In the case of Foreman it is being told to use the hostname, but since Foreman always downcase! it will fail forever, on any host that uses anything but lowercase host names. Looking at my DNS, 30-40% of the hosts out there are using CAPS of some sort. There are ~ 5000 hosts.

I should have expanded on the last sentence. DNS Reverse Lookup is not case sensitive, but Forward is. Which, really, is irrelevant. MCO is still going to take whatever Foreman gives it, which will always be lower case. If you run MCO Ping, you will see case sensitivity. The communication between what Foreman is telling MCO, and who MCO actually knows about is where the issue is.

Well, that's not entirely the case. Forward DNS lookups are not case sensitive, although, they are case 'aware'. Meaning, a dig of www.google.com and WWW.GooGLE.com will yield the same result (barring the fact google has multiple ip's of course). A URL/URI is however case sensitive as is a certificate CN, so I'm kind of wondering if that's where the problem is being experienced. I haven't looked into the mco code, but I'm willing to believe it matches against the names which the certificates were generated against rather than a blind case insensitive hostname. In which case, you still have this issue obviously. Maybe the fix for this would be to simply pass @host.certname to your mco command, rather than the hosts name. I'm not entirely sure where that is in the foreman code, but you can easily verify the case sensitivity of your certname in the foreman db via select certname from hosts where name like 'JNSEMTEST%'; Likewise, I think the 'clientcert' fact in the gui represents the same return value. It seems like the most elegant solution to the problem, that is if the certname does in fact reveal the proper case.

Joey D wrote:

Well, that's not entirely the case. Forward DNS lookups are not case sensitive, although, they are case 'aware'. Meaning, a dig of www.google.com and WWW.GooGLE.com will yield the same result (barring the fact google has multiple ip's of course). A URL/URI is however case sensitive as is a certificate CN, so I'm kind of wondering if that's where the problem is being experienced. I haven't looked into the mco code, but I'm willing to believe it matches against the names which the certificates were generated against rather than a blind case insensitive hostname. In which case, you still have this issue obviously. Maybe the fix for this would be to simply pass @host.certname to your mco command, rather than the hosts name. I'm not entirely sure where that is in the foreman code, but you can easily verify the case sensitivity of your certname in the foreman db via select certname from hosts where name like 'JNSEMTEST%'; Likewise, I think the 'clientcert' fact in the gui represents the same return value. It seems like the most elegant solution to the problem, that is if the certname does in fact reveal the proper case.

Sure. I can probably fix this. But we should also agree that this definitely causes an issue which renders the "Run Puppet" option (a massive feature) in Foreman, useless. I'm going to assume I am not the only person out there that has capitalization in hostnames, so this issue will continue to reproduce itself for others in the future (especially with Puppet /kick now removed for Windows hosts, MCO is the second best way). The fact they are all downcased is the root cause of the actual bug. Whether mco is called in or not. MCO might be part of the issue, but the main cause that affects mco, is how it receives its information from Foreman.

If we look at the facts/facter, we can see that both the hostname and the fqdn come in to Foreman case sensitive. Foreman seems to grab the certname, for its name, correct? Wouldnt it be more viable, to use the full fqdn as the Name column in Foreman?

Any help you could offer on where to begin looking to fix this, would be much appreciated. If i can figure out what the Run Puppet actually triggers, I could probably tell it to use the fqdn instead of the certname. Im sure I can find it, but would rather ask the professionals first, where to begin.

Thanks again.

Any chance you can think of a workaround for this? I am now up to 1300+ servers that can not use the Run Puppet option in Foreman. Which, for our environment, is probably in the top 3 importance using Foreman. Puppet does not run on a short time schedule, so if I push out a fix, it will fix anything that is added in the future, but doesnt fix my problem with the current 1000+ host that can not use this option.

I really need a work around to allow the Run Puppet functionality to work with case sensitivity. Any help or direction at all would be a big help.

Take a look at: models/host/managed.rb
def puppetrun!
...
...
ProxyAPI::Puppet.new({:url => puppet_proxy.url}).run fqdn
...
...
end

maybe try passing certname there rather than fqdn? I've not tested it, nor am I sure it will simply "work" or if that's actually the correct variable name given the particular class (maybe host.certname), but it's something to look at. If it does in fact work, we can create the pull request; although it's a toss up as to whether it's an acceptable change/workaround.

Joey D wrote:

Take a look at: models/host/managed.rb
def puppetrun!
...
...
ProxyAPI::Puppet.new({:url => puppet_proxy.url}).run fqdn
...
...
end

maybe try passing certname there rather than fqdn? I've not tested it, nor am I sure it will simply "work" or if that's actually the correct variable name given the particular class (maybe host.certname), but it's something to look at. If it does in fact work, we can create the pull request; although it's a toss up as to whether it's an acceptable change/workaround.

Thanks for your ideas. I really appreciate them. I tried everything from: hostname, host, name, certname, cert. It doesnt seem to change what is passed. I even used foobar and bob and still nothing changed. Ill keep looking in to this, since mgmt told me I do nothing else until this is fixed. Ill take any other ideas.

I was able to patch this myself. Not on your end though. On mcollectives end. For Linux I just changed:

mcollective/manifests/common/config.pp -

added line:

mcollective::common::setting { 'identity':
value => $mcollective::identity,
}


then put the cooresponding value in init.pp:

$identity = $fqdn,

For windows mcollective I changed config.rb to:

identity = Socket.gethostbyname(Socket.gethostname).first.downcase

You can move this status to Medium, now that there is a confirmed work around.