Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #174527 > unrolled thread

set domain name in Debian `

Back to article view | Back to linux.debian.user

Contents

  set domain name in Debian ` Glenn English <ghe2001@gmail.com> - 2016-11-11 21:50 +0100
    Re: set domain name in Debian ` Greg Wooledge <wooledg@eeg.ccf.org> - 2016-11-11 22:00 +0100
      Re: set domain name in Debian ` Glenn English <ghe2001@gmail.com> - 2016-11-11 23:10 +0100
        Re: set domain name in Debian ` Greg Wooledge <wooledg@eeg.ccf.org> - 2016-11-11 23:40 +0100
          Re: set domain name in Debian ` Glenn English <ghe2001@gmail.com> - 2016-11-12 04:50 +0100
        Re: set domain name in Debian ` Joe <joe@jretrading.com> - 2016-11-11 23:50 +0100
          Re: set domain name in Debian ` Glenn English <ghe2001@gmail.com> - 2016-11-12 01:40 +0100
    Re: set domain name in Debian ` Andy Smith <andy@strugglers.net> - 2016-11-12 06:00 +0100
      Re: set domain name in Debian ` Glenn English <ghe2001@gmail.com> - 2016-11-12 07:40 +0100
        Re: set domain name in Debian ` Andy Smith <andy@strugglers.net> - 2016-11-12 07:50 +0100
          Re: set domain name in Debian ` Glenn English <ghe2001@gmail.com> - 2016-11-12 10:20 +0100
            Re: set domain name in Debian ` Andy Smith <andy@strugglers.net> - 2016-11-12 11:30 +0100
              Re: set domain name in Debian ` Brian <ad44@cityscape.co.uk> - 2016-11-12 13:40 +0100
              Re: set domain name in Debian ` Glenn English <ghe2001@gmail.com> - 2016-11-12 17:10 +0100
                Re: set domain name in Debian ` sunrise@mailbug.com - 2016-11-12 19:40 +0100
                  Re: set domain name in Debian ` Glenn English <ghe2001@gmail.com> - 2016-11-12 20:30 +0100
                Re: set domain name in Debian ` Greg Wooledge <wooledg@eeg.ccf.org> - 2016-11-14 14:30 +0100
                  Re: set domain name in Debian ` Glenn English <ghe2001@gmail.com> - 2016-11-14 23:00 +0100
                  Re: set domain name in Debian ` David Wright <deblis@lionunicorn.co.uk> - 2016-11-14 23:40 +0100
                    Re: set domain name in Debian ` Greg Wooledge <wooledg@eeg.ccf.org> - 2016-11-15 14:10 +0100
                      Re: set domain name in Debian ` Greg Wooledge <wooledg@eeg.ccf.org> - 2016-11-15 15:20 +0100
                        Re: set domain name in Debian ` Brian <ad44@cityscape.co.uk> - 2016-11-15 16:00 +0100
                          Re: set domain name in Debian ` Greg Wooledge <wooledg@eeg.ccf.org> - 2016-11-15 16:20 +0100
                            Re: set domain name in Debian ` Brian <ad44@cityscape.co.uk> - 2016-11-15 16:40 +0100
                            Re: set domain name in Debian ` David Wright <deblis@lionunicorn.co.uk> - 2016-11-15 17:10 +0100
                      Re: set domain name in Debian ` Brian <ad44@cityscape.co.uk> - 2016-11-15 15:20 +0100
                        Re: set domain name in Debian ` Joe <joe@jretrading.com> - 2016-11-15 16:10 +0100
                          Re: set domain name in Debian ` Brian <ad44@cityscape.co.uk> - 2016-11-15 16:50 +0100
                            Re: set domain name in Debian ` Joe <joe@jretrading.com> - 2016-11-15 17:30 +0100
    Re: set domain name in Debian ` Henrique de Moraes Holschuh <hmh@debian.org> - 2016-11-12 16:50 +0100
      Re: set domain name in Debian ` Glenn English <ghe2001@gmail.com> - 2016-11-12 18:20 +0100
        Re: set domain name in Debian ` Henrique de Moraes Holschuh <hmh@debian.org> - 2016-11-12 19:40 +0100
          Re: set domain name in Debian ` Glenn English <ghe2001@gmail.com> - 2016-11-12 22:40 +0100

Page 2 of 2 — ← Prev page 1 [2]

#174746

On Tue, Nov 15, 2016 at 02:10:14PM +0000, Brian wrote:
> With 'dpkg-reconfigure exim4-config' the message
> 
>  "Starting MTA:hostname --fqdn did not return a fully qualified name,
>  dc_minimaldns will not work. Please fix your /etc/hosts setup."
> 
> should appear if "yes" is chosen for the option. 'hostname -f' is useful
> for checking there is a sane hosts configuration for exim to use.

Now you're scaring me.  I'm afraid to run this thing to test your theory,
because it might cause my perfectly working configuration to break.

Well, let's back up /etc/exim4 and try it....

wooledg@wooledg:~$ sudo tar czf /var/tmp/etc-exim4.tar.gz /etc/exim4
[sudo] password for wooledg: 
tar: Removing leading `/' from member names
wooledg@wooledg:~$ sudo dpkg-reconfigure exim4-config
[[ now it goes into dialog ]]

First choice:
  mail sent by smarthost; received via SMTP or fetchmail

Second choice:
  System mail name:
  eeg.ccf.org

Third choice:
  IP-addresses to listen on...:
  127.0.0.1 ; ::1

Fourth choice:
  Other destinations for which mail is accepted:
  wooledg

Fifth choice:
  Machines to relay mail for:
  (blank)

Sixth choice:
  IP address or host name of the outgoing smarthost:
  gateway.eeg.ccf.org

Seventh choice:
  Hide local mail name in outgoing mail?
  No

Eighth choice:
  Keep number of DNS-queries minimal?
  No

Ninth choice:
  Delivery method for local mail:
  Maildir format in home directory

Tenth choice:
  Split configuration into small files?
  No

Voila.  No need for hostname -f to return a string with dots.  Exim
was perfectly content with what I've been doing for years.

[toc] | [prev] | [next] | [standalone]

#174749

On Tue 15 Nov 2016 at 09:18:33 -0500, Greg Wooledge wrote:

> On Tue, Nov 15, 2016 at 02:10:14PM +0000, Brian wrote:
> > With 'dpkg-reconfigure exim4-config' the message
> > 
> >  "Starting MTA:hostname --fqdn did not return a fully qualified name,
> >  dc_minimaldns will not work. Please fix your /etc/hosts setup."
> > 
> > should appear if "yes" is chosen for the option. 'hostname -f' is useful
> > for checking there is a sane hosts configuration for exim to use.
> 
> Now you're scaring me.  I'm afraid to run this thing to test your theory,
> because it might cause my perfectly working configuration to break.
> 
> Well, let's back up /etc/exim4 and try it....

Backing up update-exim4.conf.conf would have been sufficient.
 
> wooledg@wooledg:~$ sudo tar czf /var/tmp/etc-exim4.tar.gz /etc/exim4
> [sudo] password for wooledg: 
> tar: Removing leading `/' from member names
> wooledg@wooledg:~$ sudo dpkg-reconfigure exim4-config
> [[ now it goes into dialog ]]
> 
> First choice:
>   mail sent by smarthost; received via SMTP or fetchmail
> 
> Second choice:
>   System mail name:
>   eeg.ccf.org
> 
> Third choice:
>   IP-addresses to listen on...:
>   127.0.0.1 ; ::1
> 
> Fourth choice:
>   Other destinations for which mail is accepted:
>   wooledg
> 
> Fifth choice:
>   Machines to relay mail for:
>   (blank)
> 
> Sixth choice:
>   IP address or host name of the outgoing smarthost:
>   gateway.eeg.ccf.org
> 
> Seventh choice:
>   Hide local mail name in outgoing mail?
>   No
> 
> Eighth choice:
>   Keep number of DNS-queries minimal?
>   No

You didn't use "yes"?

> Ninth choice:
>   Delivery method for local mail:
>   Maildir format in home directory
> 
> Tenth choice:
>   Split configuration into small files?
>   No
> 
> Voila.  No need for hostname -f to return a string with dots.  Exim
> was perfectly content with what I've been doing for years.

It would be if "Keep number of DNS-queries minimal?" was "No".                                                          
                                                                                                                        
It would also happily send a string without dots as the HELO.                                                           
Whether the remote server is happy is another matter.

----------------------------------------------------------------------

This reply is the second one I've sent to your mail. The first was sent
after removing canonical_hostname from /etc/hostame. 'hostname -f' said
"desktop". The first mail was rejected by ldo:

  debian-user@lists.debian.org                                                                                          
    SMTP error from remote mail server after RCPT TO:<debian-user@lists.debian.org>:                                    
    host bendel.debian.org [82.195.75.100]: 504 5.5.2 <desktop>:                                                        
    Helo command rejected: need fully-qualified hostname

A quick check with the useful command 'hostname -f' revealed the problem.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#174752

On Tue, Nov 15, 2016 at 02:59:14PM +0000, Brian wrote:
> On Tue 15 Nov 2016 at 09:18:33 -0500, Greg Wooledge wrote:
> > Second choice:
> >   System mail name:
> >   eeg.ccf.org

> > Eighth choice:
> >   Keep number of DNS-queries minimal?
> >   No
> 
> You didn't use "yes"?

Of course not.  Why would I do that?  I'm not on dialup.  I'm on a
corporate LAN where I run my own DNS nameservers.

> It would also happily send a string without dots as the HELO.

Isn't that controlled by the "System mail name" option?  As you can
see, mine is set to eeg.ccf.org.  Whether this is something I typed
into exim config by hand long ago, or something that it picked up
by itself from /etc/resolv.conf, I can no longer remember.

Either way, I would have made sure it was correct.

> Whether the remote server is happy is another matter.

Indeed.  A mail server should be properly configured, not just left as
"best guess from defaults".

[toc] | [prev] | [next] | [standalone]

#174755

On Tue 15 Nov 2016 at 10:10:17 -0500, Greg Wooledge wrote:

> On Tue, Nov 15, 2016 at 02:59:14PM +0000, Brian wrote:
> > On Tue 15 Nov 2016 at 09:18:33 -0500, Greg Wooledge wrote:
> > > Second choice:
> > >   System mail name:
> > >   eeg.ccf.org
> 
> > > Eighth choice:
> > >   Keep number of DNS-queries minimal?
> > >   No
> > 
> > You didn't use "yes"?
> 
> Of course not.  Why would I do that?  I'm not on dialup.  I'm on a
> corporate LAN where I run my own DNS nameservers.

It was the point of David Wright's mail and wouldn't have hurt. Also, it
may have indicated 'hostname -f' is not so "rubbish" after all. 
 
> > It would also happily send a string without dots as the HELO.
> 
> Isn't that controlled by the "System mail name" option?  As you can

A common misconception, no. It is the domain name used to qualify mail
addresses without a domain name. Mail to brian would get sent as
brian@eeg.ccf.org.

> see, mine is set to eeg.ccf.org.  Whether this is something I typed
> into exim config by hand long ago, or something that it picked up
> by itself from /etc/resolv.conf, I can no longer remember.

You typed it in. Unless another program had configured /etc/mailname
already. /etc/resolv.conf doesn't come into it.

> Either way, I would have made sure it was correct.
> 
> > Whether the remote server is happy is another matter.
> 
> Indeed.  A mail server should be properly configured, not just left as
> "best guess from defaults".

A mail server which accepts an EHLO without dots in it *is* properly
configured.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#174758

On Tue 15 Nov 2016 at 10:10:17 (-0500), Greg Wooledge wrote:
> On Tue, Nov 15, 2016 at 02:59:14PM +0000, Brian wrote:
> > On Tue 15 Nov 2016 at 09:18:33 -0500, Greg Wooledge wrote:
> > > Second choice:
> > >   System mail name:
> > >   eeg.ccf.org
> 
> > > Eighth choice:
> > >   Keep number of DNS-queries minimal?
> > >   No
> > 
> > You didn't use "yes"?
> 
> Of course not.  Why would I do that?  I'm not on dialup.  I'm on a
> corporate LAN where I run my own DNS nameservers.

I hadn't appreciated that you're entirely desktop oriented.
As for myself, there's no DNS service here, no dotty addresses
at all as I have no domain name to call my own, here.
Hence also no point in DNS-queries, but I can shut exim up
by letting it make pointless lookups. I don't have a clue whether
my router bothers to ask 8.8.8.8 for dotless requests.

OTOH I own a domain name 3000 miles away which has no ISP-type
connection with me at all; it's the destination for emails bound
for me, so it's kind of important that exim rewrites that my
emails come from its address.

> > It would also happily send a string without dots as the HELO.
> 
> Isn't that controlled by the "System mail name" option?  As you can
> see, mine is set to eeg.ccf.org.  Whether this is something I typed
> into exim config by hand long ago, or something that it picked up
> by itself from /etc/resolv.conf, I can no longer remember.
> 
> Either way, I would have made sure it was correct.

Again, correct for me is no dots. As you can see from my headers, my
email all goes out through alum (unless I'm on the road).

> > Whether the remote server is happy is another matter.
> 
> Indeed.  A mail server should be properly configured, not just left as
> "best guess from defaults".

Well, I don't see how a smarthost can enforce a dotty address unless
they issue you with a valid one. I can't put myself onto .cox.net
unilaterally, so unless I use the nonce domain name that is constructed
from the IP address (which could change at any time), I don't have
a FQDN except alum.

I assume Cox authenticate me by the physical wire I appear on. Maybe
they even check the MAC of the modem, though I'm not forced to use
theirs. When I'm on the road, I obviously use my own domain name for
the smarthost, but then I have to use a different port and a password.
Still no dotty HELO/EHLO though.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#174747

On Tue 15 Nov 2016 at 08:00:31 -0500, Greg Wooledge wrote:

> On Mon, Nov 14, 2016 at 04:29:35PM -0600, David Wright wrote:
> > As your own   hostname -f   produces not dots, what approach do you
> > use to shut exim up, or do you just ignore (or suppress) the message?
> 
> I have (control over) a bunch of computers, and they're not all configured
> the same.  The machine I believe you refer to is this one:
> 
> wooledg@wooledg:~$ hostname
> wooledg
> wooledg@wooledg:~$ hostname -f
> wooledg
> 
> This is a dual-boot Windows/Debian workstation on my desk at work.
> 
> Here's the /etc/hosts:
> 
> wooledg@wooledg:~$ cat /etc/hosts
> 127.0.0.1	localhost
> 127.0.1.1	wooledg

Exim wants to see a fqdn in the 127.0.1.1 line, written as specified in
hosts(5):

 IP_address canonical_hostname [aliases...]

The canonical_hostname is used for the HELO/EHLO. With most large ISPs
it is not taken much notice of but there are servers which (rightly or
wrongly) would do a reverse lookup on wooledg and, getting a negative
response, reject the mail. Basically, you will get away with the line
you have when you use an understanding smarthost. I think Postfix
could behave in the same way.

> # The following lines are desirable for IPv6 capable hosts
> ::1     localhost ip6-localhost ip6-loopback
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
> 
> The hostname is defined in DNS (originally I just let it have a dynamic
> IP address and dealt with that, but later I arranged for it to have
> a non-changing IP address, for reasons beyond the scope of this email;
> but in all cases, DNS always had a working "A" record).
> 
> It looks like this one is running exim:
> 
> wooledg@wooledg:~$ ps -ef | grep exim
> Debian-+   949     1  0 Nov14 ?        00:00:00 /usr/sbin/exim4 -bd -q30m
> wooledg  10865  2007  0 07:53 pts/4    00:00:00 grep exim
> 
> I never saw any errors like the one you showed, perhaps because exim
> used my default search domain (from /etc/resolv.conf) and found a sane
> DNS configuration, or perhaps because this machine is in a very simple
> "send to smarthost only" mode.  I don't really know exim very well.

With 'dpkg-reconfigure exim4-config' the message

 "Starting MTA:hostname --fqdn did not return a fully qualified name,
 dc_minimaldns will not work. Please fix your /etc/hosts setup."

should appear if "yes" is chosen for the option. 'hostname -f' is useful
for checking there is a sane hosts configuration for exim to use.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#174750

On 15/11/2016 14:10, Brian wrote:
> On Tue 15 Nov 2016 at 08:00:31 -0500, Greg Wooledge wrote:
>
>> On Mon, Nov 14, 2016 at 04:29:35PM -0600, David Wright wrote:
>>> As your own   hostname -f   produces not dots, what approach do you
>>> use to shut exim up, or do you just ignore (or suppress) the message?
>>
>> I have (control over) a bunch of computers, and they're not all configured
>> the same.  The machine I believe you refer to is this one:
>>
>> wooledg@wooledg:~$ hostname
>> wooledg
>> wooledg@wooledg:~$ hostname -f
>> wooledg
>>
>> This is a dual-boot Windows/Debian workstation on my desk at work.
>>
>> Here's the /etc/hosts:
>>
>> wooledg@wooledg:~$ cat /etc/hosts
>> 127.0.0.1	localhost
>> 127.0.1.1	wooledg
>
> Exim wants to see a fqdn in the 127.0.1.1 line, written as specified in
> hosts(5):
>
>  IP_address canonical_hostname [aliases...]
>
> The canonical_hostname is used for the HELO/EHLO.

Default, can be overridden by the primary_hostname configuration, which 
can be overridden again by helo_data in individual transports.

My mail server's hostname does not exist in public DNS, like many small 
mail servers it is behind NAT, not directly exposed to the Net. My 
public MX hostname is not the same as the server's hostname.

Also exim4 can handle mail for multiple domains, using a separate HELO 
for each if required, and the per-transport setting allows even finer 
HELO control if you have a use for that.


> With most large ISPs
> it is not taken much notice of but there are servers which (rightly or
> wrongly) would do a reverse lookup on wooledg and, getting a negative
> response, reject the mail. Basically, you will get away with the line
> you have when you use an understanding smarthost. I think Postfix
> could behave in the same way.
>

That's fairly common, the exim4 default if enabled is to check that the 
HELO is resolvable at all, not that it matches anything specific. It's a 
few years since I last did it, but when I used telnet to talk to remote 
mail servers I used a well-known six character domain name as HELO to 
save typing, one to which I had no entitlement, and nothing ever complained.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#174756

On Tue 15 Nov 2016 at 15:02:54 +0000, Joe wrote:

> On 15/11/2016 14:10, Brian wrote:

> >Exim wants to see a fqdn in the 127.0.1.1 line, written as specified in
> >hosts(5):
> >
> > IP_address canonical_hostname [aliases...]
> >
> >The canonical_hostname is used for the HELO/EHLO.
> 
> Default, can be overridden by the primary_hostname configuration, which can
> be overridden again by helo_data in individual transports.
> 
> My mail server's hostname does not exist in public DNS, like many small mail
> servers it is behind NAT, not directly exposed to the Net. My public MX
> hostname is not the same as the server's hostname.
> 
> Also exim4 can handle mail for multiple domains, using a separate HELO for
> each if required, and the per-transport setting allows even finer HELO
> control if you have a use for that.

I'm convinced it can all of these things but my needs are mostly
accomodated by the setups described in the Debian documentation.

> >With most large ISPs
> >it is not taken much notice of but there are servers which (rightly or
> >wrongly) would do a reverse lookup on wooledg and, getting a negative
> >response, reject the mail. Basically, you will get away with the line
> >you have when you use an understanding smarthost. I think Postfix
> >could behave in the same way.
> >
> 
> That's fairly common, the exim4 default if enabled is to check that the HELO
> is resolvable at all, not that it matches anything specific. It's a few
> years since I last did it, but when I used telnet to talk to remote mail
> servers I used a well-known six character domain name as HELO to save
> typing, one to which I had no entitlement, and nothing ever complained.

Are you sure that is the default?

brian@desktop:~$ telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 desktop ESMTP Exim 4.84_2 Tue, 15 Nov 2016 15:38:31 +0000
helo claptrap
250 desktop Hello localhost [::1]
mail from:brian
501 brian: sender address must contain a domain
mail from:brian@localhost
250 OK
rcpt to:brian@desktop
250 Accepted

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#174760

On 15/11/2016 15:45, Brian wrote:
> On Tue 15 Nov 2016 at 15:02:54 +0000, Joe wrote:
>

>>
>> That's fairly common, the exim4 default if enabled is to check that the HELO
>> is resolvable at all, not that it matches anything specific. It's a few
>> years since I last did it, but when I used telnet to talk to remote mail
>> servers I used a well-known six character domain name as HELO to save
>> typing, one to which I had no entitlement, and nothing ever complained.
>
> Are you sure that is the default?
>

Not default, 'default if enabled'. HELO checking is initially turned 
off, if you just turn it on, it doesn't look for a specific match. There 
are systems which do look for a HELO which is related to the email 
itself, which I don't think is a good idea.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#174586

On Fri, 11 Nov 2016, Glenn English wrote:
> /proc/sys/domainname says "(none)". hostname -f gives the old domain

/proc/sys/domainname is the kernel's idea of a domain name, which is
only used by some network filesystems (kernel-based NFS, I think),
AFAIK.

Nothing else needs it.  And if you set up such a filesystem, the
userspace utilities should set the kernel domainname properly by
themselves.

Note that the kernel also needs to know the node name (host name without
a domain)... and _this_ is used everywhere.

> name (where does it get it). grep -ir doesn't find the old name string
> anywhere in /etc or in /lib.

hostname -f does this:

1. Asks glibc for the hostname, using gethostname().

2. Does an IP lookup on the hostname, using getaddrinfo() and the
   hostname it got from gethostname(), and returns the result from
   getaddrinfo().

Since it uses glibc for the host name lookup, it is subject to the glibc
name resolver, which is configured through /etc/nsswitch.conf.

Now, gethostname() works like this [in glibc]: it calls the uname()
syscall, and uses the node name returned.  I.e. it looks up the
*hostname* the kernel was set to.

So, glibc's gethostname() will match the output of "uname -n".  This
information was set on the kernel by either systemd, or by the
initscripts.

Initscripts use /etc/hostname to set this information.  I am not well
versed on how exactly systemd persists this information, but it likely
uses /etc/hostname as well.

> I know it must be simple to do -- the installer does it without
> downloading a C library, but it must be in a secret place I don't know
> about...

1. Set /etc/hostname to the *node name* (i.e. just the host name,
   without the domain)

2. Ensure the *node name* _locally_ resolves to an IPv4/IPv6.  Usually
   this is done by adding it to /etc/hosts, so that things will not
   break when the network is down.

   Do it like this in /etc/hosts:
   <ip> <fully qualified hostname> <nodename>

   For example:

   /etc/hostname:
   examplehost

   /etc/hosts:
   192.0.2.42  examplehost.example.com  examplehost

   Refer to the item (3) below for the reasoning.

   Full answer:  anything that is resolvable locally when piped by
   glibc through the "hosts" nss module pipeline configured in
   /etc/nsswitch.conf will do.  /etc/hosts is a configuration
   file processed for the "files" nss module typically used in
   /etc/nsswitch.conf.

3. Ensure the IPv4/IPv6 you used for the *node name* resolves to
   the full host name (FQDN).

   Now, there is a trick to doing this when using /etc/hosts.  You
   *must* list the FQDN first in /etc/hosts, as it will return just the
   first match when doing a "reverse lookup".

   The complete answer is: ensure the "hosts" nss module pipeline
   configured in /etc/nsswitch.conf will return as the *first* match,
   for the *node name*'s IPv4/IPv6, the FQDN of the host.


There, this is a bit harder to understand than other answers you got,
but it should get the details right and might be helpful in more
convoluted scenarios.

"man nsswitch.conf" for mode details about /etc/nsswitch.conf.
"man hosts" for more details about /etc/hosts

and each libc function I mentioned also has its own manpage.

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#174590

> On Nov 12, 2016, at 8:46 AM, Henrique de Moraes Holschuh <hmh@debian.org> wrote:
> 
> hostname -f does this:
> 
> 1. Asks glibc for the hostname, using gethostname().
> 
> 2. Does an IP lookup on the hostname, using getaddrinfo() and the
>   hostname it got from gethostname(), and returns the result from
>   getaddrinfo().
> 
> Since it uses glibc for the host name lookup, it is subject to the glibc
> name resolver, which is configured through /etc/nsswitch.conf.
> 
> Now, gethostname() works like this [in glibc]: it calls the uname()
> syscall, and uses the node name returned.  I.e. it looks up the
> *hostname* the kernel was set to.
> 
> So, glibc's gethostname() will match the output of "uname -n".  This
> information was set on the kernel by either systemd, or by the
> initscripts.
> 
> Initscripts use /etc/hostname to set this information.  I am not well
> versed on how exactly systemd persists this information, but it likely
> uses /etc/hostname as well.

Bingo! I had a feeling it was convoluted.

> root@srv:~# host srv.slsware.org
> srv.slsware.org has address 216.17.203.66
> root@srv:~# hostname
> srv
> root@srv:~# hostname -f
> srv.slsware.org
> root@srv:~# hostname -d
> slsware.org

I edited /etc/resolv.conf to point the nameserver at the host's IP instead of pointing at localhost (this host is the (temporary) DNS server for the .org domain).

Now all is well. Except for /proc, which I'll ignore in the future.

Just why the IP worked and 'localhost' didn't is another question -- I assume it has something to do with machinations in glibc. I'm not afraid of C, but things are working and I've got more interesting things to do today.

Thanks all. It's been quite a ride. Now everybody write it down: it has nothing to do with what's in /etc/hosts or /etc/resolv.conf. There has to be a live, accessible DNS server for the domain somewhere. At least at slsware.org there does.

What idiot designed that?

It does seem that /etc/hosts should work, though...


No, I take it back. I don't think DNS is the whole story. It worked in this case, but how does the installer get a domainname?

-- 
Glenn English

[toc] | [prev] | [next] | [standalone]

#174597

On Sat, 12 Nov 2016, Glenn English wrote:
> Thanks all. It's been quite a ride. Now everybody write it down: it
> has nothing to do with what's in /etc/hosts or /etc/resolv.conf. There
> has to be a live, accessible DNS server for the domain somewhere. At
> least at slsware.org there does.

Maybe for the install.

But the whole thing really doesn't need any DNS servers *as long as*
everything you need is resolved statically by some module in
/etc/nsswitch.conf... such as the default "files" module, which reads
/etc/hosts.

At which point, it boils down to a complete enough, correct /etc/hosts

> It does seem that /etc/hosts should work, though...

It does work, provided that you have "files" first in the list of NSS
modules, and you have both the nodename and the FQDN in /etc/hosts for
the correct IPs and in the correct order.  Otherwise, it depends.

> No, I take it back. I don't think DNS is the whole story. It worked in
> this case, but how does the installer get a domainname?

The *installer* either asks the user for the FQDN and gets the nodename,
domain name and FQDN from that (and it *should* write them to /etc/hosts
and /etc/hostname appropriately), or gets information from DHCP/DHCPv6
and the DNS while autoconfiguring.

Now, *what* the DHCP/DHCPv6 and DNS will answer, well, that's up to your
local network.

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#174612

> On Nov 12, 2016, at 11:31 AM, Henrique de Moraes Holschuh <hmh@debian.org> wrote:
> 
> But the whole thing really doesn't need any DNS servers *as long as*
> everything you need is resolved statically by some module in
> /etc/nsswitch.conf... such as the default "files" module, which reads
> /etc/hosts.

> root@srv:~# cat /etc/nsswitch.conf 
> # /etc/nsswitch.conf
> #
> # Example configuration of GNU Name Service Switch functionality.
> # If you have the `glibc-doc-reference' and `info' packages installed, try:
> # `info libc "Name Service Switch"' for information about this file.
> 
> passwd:         compat
> group:          compat
> shadow:         compat
> gshadow:        files
> 
> hosts:	files dns
> networks:       files
> 
> protocols:      db files
> services:       db files
> ethers:         db files
> rpc:            db files
> 
> netgroup:       nis

If I understand this, it looks at hosts first.

With bind9 stopped, ping sso works and says it's pinging 216.17.203.66, srv.slsware.org.

> At which point, it boils down to a complete enough, correct /etc/hosts
> 
>> It does seem that /etc/hosts should work, though...
> 
> It does work, provided that you have "files" first in the list of NSS
> modules, and you have both the nodename and the FQDN in /etc/hosts for
> the correct IPs and in the correct order.  Otherwise, it depends.

The nodename is another word for hostname, right? (I'd never heard that word before. Wikipedia said it just meant hostname.)

/etc/hosts, as I said before:

> root@srv:~# cat /etc/hosts
> # /etc/hosts:  This file describes a number of hostname-to-address
> #
> # This is to be sent to all hosts that need a hosts file
> #	(don't really know how yet...)
> #  
> # Host Database
> # localhost is used to configure the loopback interface
> # sudo cp hosts /etc ; dist `pwd`/hosts /etc all hosts
> # The following lines are desirable for IPv6 capable hosts
> # when the system is booting.  Do not change this entry.
> #       
> ::1 		ip6-localhost 			ip6-loopback
> fe00::0		ip6-localnet
> ff00::0 	ip6-mcastprefix
> ff02::1 	ip6-allnodes
> ff02::2 	ip6-allrouters
> ff02::3 	ip6-allhosts
> 
> 127.0.0.1	localhost localhost.localdomain lh lcl
> 
> # pass I slsware.org -- all routable IPs; no NAT
> 216.17.203.64	slsware.org
> 216.17.203.65	out.slsware.org		oso
> 216.17.203.66	srv.slsware.org		sso
> 216.17.203.67	gobook.slsware.org	gso gbo
> 216.17.203.68	unused0.slsware.org	u0so
> 216.17.203.69	unused1.slsware.org	u1so
> 216.17.203.70	printer.slsware.org	pso
> 216.17.203.71	broadcast.slsware.org	bso
> 
> # misc ne'r-do-wells
> 127.0.0.2       ad.doubleclick.net
> 127.0.0.2       mmv.admob.com

Here's the line:

> 216.17.203.66	srv.slsware.org		sso

That's OK, right?

hosts ought to work. But it doesn't -- not on this machine, not today. I've had the FQDN way down in hosts before, and hostname -f found it with no trouble. For many years, I had a CVS playpen to be sure exactly the same hosts file was on all my machines, and as far as I know, there was never a problem.

Many years ago I wrote a big shell script to set up iptables (ipchains back then). It uses hostname -f to find out which machine it's on, and how the filter should be configured -- if that command fails, iptables won't be set up on the machine. It's a very important command here. If it gives the wrong answer, it'll be filter the wrong stuff.

> The *installer* either asks the user for the FQDN and gets the nodename,
> domain name and FQDN from that (and it *should* write them to /etc/hosts
> and /etc/hostname appropriately),

It always has, all of them. I use the curses netinst expert, and it's always worked flawlessly.

This is the first time I've had trouble with the domain. I think I may need to do a little more investigation. Apparently, hosts is supposed to work...

> or gets information from DHCP/DHCPv6
> and the DNS while autoconfiguring.

I don't use DHCP or autoconfig, so that's never come up.


I disabled bind, put the big hosts file (with slsware.org at the top) back, rebooted, and -f said srv.slsware.dmz.

I removed all but one occurrence of 'srv' from the big hosts, rebooted, and -f was correct.

I replaced the big hosts file.

I retyped the srv...org line at the top if the file, rebooted, and -f said srv...dmz.

I moved slsware.org to the bottom of the file, rebooted, and -f said srv...dmz.

I removed the srv.slsware.dmz line, moved the slsware.org collection back to the top, rebooted, and -f said www...dmz.

I give up. This is acting like I've never seen it -- there's never been a problem with hosts before. I have to have those alien FQDNs and aliases and IPs in there so I can SSH to them during the switchover.

-- 
Glenn English

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web