Puppet: System Administration Automated

Support

Ticket #792 (closed enhancement: invalid)

Opened 1 year ago

Last modified 7 months ago

When using external_nodes with certname identification, domain is tacked onto the end

Reported by: randybias Assigned to: luke
Priority: normal Milestone: unplanned
Component: unknown Version: 0.23.2
Severity: normal Keywords:
Cc: randyb@cloudscale.net Triage Stage: Needs more info
Attached Patches: None Complexity: Unknown

Description

The behavior is that the external_nodes command is called with progressive arguments in this order: 

e633ac9e-ef87-45aa-952c-9c09c319e06e.usma1.compute.amazonaws.com
e633ac9e-ef87-45aa-952c-9c09c319e06e
default

Where e633ac9e-ef87-45aa-952c-9c09c319e06e is the certname I used.

It's hard to say that this is a bug. I can see that for normal operations it might be desirable to map hostname -> fqdn 'smartly', but I'd rather that was the second iteration rather than the first. I would prefer that on the first iteration it's the plain jane certname (CN) as presented by the client's certificate without any frills on it.

Either I would like the behavior changed for external_nodes or possibly in general (although I don't know if this breaks anything??)

I'm willing to write the patch if this sounds like an acceptable fix. Let me know.

Attachments

puppet-nodesearch.patch.txt (0.6 kB) - added by randybias on 09/05/07 03:40:43.
patch to reverse search order, preferring smaller over larger

Change History

09/05/07 00:44:53 changed by michael

  • stage changed from Unreviewed to Accepted.
  • milestone set to unplanned.

As long as there are no complaints, the first iteration will use the CN as presented by the client. As always, patches are welcome.

09/05/07 03:40:43 changed by randybias

  • attachment puppet-nodesearch.patch.txt added.

patch to reverse search order, preferring smaller over larger

09/05/07 03:41:46 changed by randybias

I'm not certain if this is the best solution or not. We haven't had time to really look through that code in detail to determine if this is the cleanest solution, but it does resolve our particular issue as the CN + domain will always be longer.

09/05/07 04:19:40 changed by luke

Hmm, a pretty simple patch. It's against the released code, instead of the current git repo, but I guess it'll be easy enough to switch.

04/24/08 07:55:18 changed by luke

  • component changed from library to unknown.

04/24/08 17:17:31 changed by jamtur01

  • status changed from new to closed.
  • resolution set to invalid.

Closing as superseded. The patch is no longer relevant. If the issue remains please re-open ticket with updated patch.

04/24/08 18:57:26 changed by randybias

I don't think you should close this as 'superseded' and 'invalid' unless you provide the actual version or repo revision with the relevant fixes.

This fix is critical to my use case and infrastructure. We're actively patching 0.23.2 on all new deployments just to get around it. So if it's in 24.4 I need to know that specifically. And if it's not in 0.24.4 I need to know what revision of the repo it's in.

04/24/08 19:16:53 changed by jamtur01

  • stage changed from Accepted to Needs more info.

The patch is no longer relevant - it does not work for 0.24.4 or later.

It is my understanding that barring major bugs there is no remediation being done to 0.23.x releases. I suggest reviewing or testing 0.24.4 to confirm if the issue is resolved or can be patched elsewhere.

The previous patch is also against the installed base and not the source. If you wish to supply an updated patch you should patch against the source tree.

04/25/08 01:34:34 changed by luke

I'll solve this problem as part of #1178, since it's really a question of what the host's name is and how we refer to and look for hosts.