Closed
Bug 891333
Opened 11 years ago
Closed 11 years ago
puppetized hosts send email from foo@$domain
Categories
(Infrastructure & Operations :: RelOps: Puppet, task)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: rail, Assigned: rail)
Details
Attachments
(1 file)
805 bytes,
patch
|
dustin
:
review+
rail
:
checked-in+
|
Details | Diff | Splinter Review |
Right now it looks like 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 It would be great to have FQDN right after 127.0.0.1. I hit some issues with `facter fqdn` without having FQDN as the first entry, so I added a work around for AWS hosts: http://hg.mozilla.org/build/cloud-tools/file/5e627ea3e624/aws/aws_create_instance.py#l78
Comment 1•11 years ago
|
||
I don't think puppetize.sh should do this (it's not really in the business of config mgmt), but it sounds like the file should be managed by puppet. That is, unless the `facter fqdn` problems were during the puppetize run, in which case what were they?
Assignee | ||
Comment 2•11 years ago
|
||
I had issues with `facter fqdn` because it uses `domainname` on Linux to determine the domain part of the host. IIRC, domainname reads the first entry in /etc/hosts and parses it.
Comment 3•11 years ago
|
||
[root@mobile-imaging-009.p9.releng.scl1.mozilla.com ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 [root@mobile-imaging-009.p9.releng.scl1.mozilla.com ~]# facter fqdn mobile-imaging-009.p9.releng.scl1.mozilla.com [root@mobile-imaging-009.p9.releng.scl1.mozilla.com ~]# domainname (none) [root@mobile-imaging-009.p9.releng.scl1.mozilla.com ~]# ..so I'm not sure /etc/hosts is the thing that's wrong here. What error do you get from facter?
Assignee | ||
Comment 4•11 years ago
|
||
Hmmm, maybe that was Ubuntu... I was getting localhost.locadomain as FQDN and localdomain as domainname.
Comment 5•11 years ago
|
||
Ah, indeed: [root@talos-linux64-ix-001.test.releng.scl3.mozilla.com ~]# cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 talos-linux64-ix-001.test.releng.scl3.mozilla.com talos-linux64-ix-001 # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters [root@talos-linux64-ix-001.test.releng.scl3.mozilla.com ~]# facter fqdn talos-linux64-ix-001.test.releng.scl3.mozilla.com [root@talos-linux64-ix-001.test.releng.scl3.mozilla.com ~]# domainname (none) This is apparently something that kickstart takes care of when doing installs. As such, I think the fix in comment 0 is actually the correct approach. Secondarily managing /etc/hosts with puppet wouldn't hurt, although it occurs too late to fix problems in puppetize.sh. Did you have trouble on the 9 on-premisies masters where you just added the fqdn to /etc/hosts? Those are CentOS *and* kickstarted, so I'd be surprised to hear that anything was amiss. If not, do you mind reverting /etc/hosts to avoid surprises?
Assignee | ||
Comment 6•11 years ago
|
||
The only issue I've seen was: From: Builder <cltbld@srv.releng.scl3.mozilla.com> sent from bm81
Comment 7•11 years ago
|
||
That's expected at the moment: postfix uses the host's domain by default. Some postfix config could change that.
Updated•11 years ago
|
Component: Server Operations: RelEng → RelOps: Puppet
Product: mozilla.org → Infrastructure & Operations
QA Contact: arich → dustin
Updated•11 years ago
|
Assignee: server-ops-releng → rail
Summary: puppetize.sh should create proper /etc/hosts file → puppetized hosts send email from foo@$domain
Assignee | ||
Comment 8•11 years ago
|
||
Attachment #775990 -
Flags: review?(dustin)
Updated•11 years ago
|
Attachment #775990 -
Flags: review?(dustin) → review+
Assignee | ||
Comment 9•11 years ago
|
||
Comment on attachment 775990 [details] [diff] [review] use FQDN for myorigin https://hg.mozilla.org/build/puppet/rev/71e7b33d0e3b
Attachment #775990 -
Flags: checked-in+
Assignee | ||
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 10•11 years ago
|
||
I'm not sure if this worked. Release mail still lacks a hostname: Return-Path: release@mozilla.com Received: from zmmta2.mail.corp.phx1.mozilla.com (LHLO zmmta2.mail.corp.phx1.mozilla.com) (10.20.77.30) by zmmbox5.mail.corp.phx1.mozilla.com with LMTP; Fri, 19 Jul 2013 06:11:59 -0700 (PDT) Received: from zmmta2.mail.corp.phx1.mozilla.com (localhost6.localdomain [127.0.0.1]) by zmmta2.mail.corp.phx1.mozilla.com (Postfix) with ESMTP id 66D571021EC; Fri, 19 Jul 2013 06:11:59 -0700 (PDT) Received: from smtp.mozilla.org (zlb1.mail.corp.phx1.mozilla.com [10.20.77.200]) by zmmta2.mail.corp.phx1.mozilla.com (Postfix) with ESMTP id 59E361021EA; Fri, 19 Jul 2013 06:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at mozilla.org Received: from localhost.localdomain (v-1030.fw1.releng.scl3.mozilla.net [63.245.214.82]) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPS id DCB1BF223D; Fri, 19 Jul 2013 06:11:58 -0700 (PDT) Content-Transfer-Encoding: base64 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Fri, 19 Jul 2013 06:11:51 -0700 Subject: [release] Firefox 23.0b7 build1: completed update_verify_1/4 on win32 From: release@mozilla.com References: <bc523d21831e3863da784e9c304b8b2a@mozilla.com> In-Reply-To: <bc523d21831e3863da784e9c304b8b2a@mozilla.com> To: release-mgmt@mozilla.com, release@mozilla.com Message-Id: <20130719131159.59E361021EA@zmmta2.mail.corp.phx1.mozilla.com> update_verify_1/4 complete for Firefox 23.0b7 build1 on win32 -buildbot
You need to log in
before you can comment on or make changes to this bug.
Description
•