Re: Weird bugs

[Mark Burgess]

As far as I can see, this email patch is exactly the code in 2.1.16

M

On Wed, 2005-09-28 at 23:09 -0400, Jason Kim wrote:
> Ok, I'm going to ramble a bit here, but I've been staring down cfengine code 
> all day, so please forgive me. I've just gone insane trying to figure this 
> out, if anyone actually has the patience to read the whole thing and grok it, 
> please let me know if I'm anywhere near on track (and if you can help me get 
> my sanity back).
> ======
> 
> I had originally setup my systems to use an unqualified hostname. So for 
> example, the output of 'hostname' would be 'testy', and 'hostname -f' would 
> be 'testy.mgmt.advance.net'. This would work without any problems for the 
> majority of things, only a few things would bug me:
> -When cfexecd would send me emails it would send it with a subject of 
> '(testy./10.1.9.9)' and from 'address@hidden'. Note the lack of a domain, and 
> the extra '.' in the subject.
> -The emails would also have a reply-to field set to 'address@hidden', which 
> was the mailto field.
> -I would get an extra runlog in /var/cfengine named 'cfengine..runlog' (the 
> normal runlog would be named 'cfengine.testy.runlog'). The logs in the file 
> are from standalone cfengine scripts, seemed like they couldn't figure out 
> the hostname to generate a proper runlog.
> 
> So, just to see what would happen, I changed my hostname to use a fqdn, ie 
> the 
> output of 'hostname' would be 'testy.mgmt.advance.net'. This seems to have 
> changed the behavior of a couple of things:
> -The emails now come with the subject '(testy.mgmt.advance.net/10.1.9.9)' and 
> from 'address@hidden'.
> -The reply-to field was still set as 'address@hidden'.
> -A new runlog would appear: 'cfengine.testy.mgmt.advance.net.runlog', which 
> came from cfexecd. Cfagent would write to 'cfengine.zerg.runlog', and the 
> standalones would write to 'cfengine..runlog'.
> 
> After hours of poking around I have the following observations and theories 
> (this is the long confusing part and I apologize):
> 
> The emailing section of cfexecd does set a reply-to field (via the 'MAIL 
> FROM:' smtp command) with a) the 'EmailFrom' if it was specified, or b) the 
> address 'address@hidden' where '[domain]' is everything after the '@' in 
> the 'EmailTo' variable, or c) the 'EmailTo' variable itself. I don't set the 
> 'EmailFrom' variable, so I should be getting a reply-to of 
> 'address@hidden', not 'address@hidden'. I believe the problem is a 
> sscanf call which is supposed to grab the domain from the 'EmailTo' variable, 
> attached a simple patch.
> 
> The emailing section is supposed to use the fqdn (the VFQNAME variable) for 
> the subject and from fields, so there apparently is a problem in acquiring 
> the fqdn when the hostname is unqualified. So here what I think is going 
> on... 
> The main() function of cfexecd calls CheckOptsAndInit() which then calls 
> GetNameInfo() which then calls uname() and then calls SetDomainName() with 
> the resulting nodename. Now oddly enough, SetDomainName() then ignores the 
> given name and calls hostname() directly. 
> If a '.' appears in the resulting hostname it's assumed to be fully 
> qualified, 
> VFQNAME is set to it and a domain (VDOMAIN) variable is set on everything 
> after the first '.' (and the emails appear correctly). 
> If there is no '.' and VDOMAIN is not set to 'undefined.domain', VDOMAIN is 
> appended to the hostname to create the VFQNAME. The only problem is that at 
> this point VDOMAIN is empty, so we end up with a VFQNAME of 'testy.'.
> Now it would appear that the fix is to always use a fully qualified hostname, 
> but that brings up the runlog problems...
> 
> From what I can deduce, runlogs are a) created every time something needs a 
> lock, b) are always called with the unqualified name (the VUQNAME variable), 
> and c) are used throughout cfexecd, cfagent, and cfenvd. So theoretically I 
> should always have only one runlog, 'cfengine.testy.runlog', no matter if my 
> hostname is fully qualified or not. Now the problem is that cfexecd assigns 
> the nodename of a machine to VUQNAME flat out, regardless of whether the it 
> is fully qualified or not, resulting in differing runlog names depending on 
> the hostname.
> Cfexecd then spawns cfagent, which _doesn't_ make assumptions about the 
> hostname, it calls the GetNameInfo() as described above. Now regardless of 
> whether the hostname is fully qualified or not, the GetNameInfo() call only 
> sets the VFQNAME and VDOMAIN, cfagent has to parse a 'domain' variable in 
> order to figure out the VUQNAME. As long as that is set, it appears that 
> cfagent's runlogs are always the correct form, however I'm not in the habit 
> of setting the domain var in standalone cfagent scripts, which results in 
> cfagent never setting the VUQNAME and creating 'cfengine..runlog' files.
> Oh, and for the record, it seems that cfenvd always uses the name 'localhost' 
> when acquiring a lock, so it always generates its own file, 
> 'cfengine.localhost.runlog'.
> 
> Sooo...
> The question is, WTF is the correct way to name a host?? The docs seem to 
> disparage using fully qualified names, but also claim that they shouldn't be 
> an issue. I don't think these bugs actually affect the way cfexecd/cfagent 
> run, except perhaps via some odd lock name or class definition mangling... So 
> should I just ignore these problems for the sake of my sanity? I had set out 
> to see if I could squash a couple of simple bugs, but I don't have the 
> slightest idea of where one would even start. I'd venture to say that the 
> whole set of functions that set the qualified/unqualified hostnames and 
> domainname need to be pulled out and made a separate, consistent module for 
> cfexecd, cfagent, and (possibly) cfenvd. But that seems like waaay too much 
> work for what is basically such a small set of problems that no one but me 
> has even cared about it (that I know of anyway).
> 
> Congrats if you got this far. I'm going to go cry now...
> -JayKim
> _______________________________________________
> Bug-cfengine mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-cfengine