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

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

sudo slow on DNS lookup, with invalid resolv.conf entries

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

Contents

  sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-15 18:10 +0200
    Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-15 19:00 +0200
      Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-15 21:30 +0200
        Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-15 22:00 +0200
          Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-15 23:10 +0200
            Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-15 23:20 +0200
              Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-15 23:40 +0200
                Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-16 00:10 +0200
                  Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-16 01:20 +0200
                    Re: sudo slow on DNS lookup, with invalid resolv.conf entries Gene Heskett <gheskett@shentel.net> - 2017-09-16 02:10 +0200
                      Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-17 22:40 +0200
                        Re: sudo slow on DNS lookup, with invalid resolv.conf entries deloptes <deloptes@gmail.com> - 2017-09-17 23:00 +0200
                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-18 00:10 +0200
                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Gene Heskett <gheskett@shentel.net> - 2017-09-18 00:50 +0200
                            Re: sudo slow on DNS lookup, with invalid resolv.conf entries deloptes <deloptes@gmail.com> - 2017-09-18 01:00 +0200
                              Re: sudo slow on DNS lookup, with invalid resolv.conf entries Gene Heskett <gheskett@shentel.net> - 2017-09-18 01:10 +0200
                                Re: sudo slow on DNS lookup, with invalid resolv.conf entries deloptes <deloptes@gmail.com> - 2017-09-18 09:00 +0200
                                  Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-18 18:40 +0200
                                    Re: sudo slow on DNS lookup, with invalid resolv.conf entries deloptes <deloptes@gmail.com> - 2017-09-18 20:20 +0200
                                      Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-18 20:50 +0200
                                        Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-18 22:50 +0200
                                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-19 00:00 +0200
                                        Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-18 22:50 +0200
                                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-19 00:00 +0200
                                        Re: sudo slow on DNS lookup, with invalid resolv.conf entries deloptes <deloptes@gmail.com> - 2017-09-18 23:00 +0200
                                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-19 00:00 +0200
                                    Re: sudo slow on DNS lookup, with invalid resolv.conf entries Gene Heskett <gheskett@shentel.net> - 2017-09-19 00:10 +0200
                        Re: sudo slow on DNS lookup, with invalid resolv.conf entries Gene Heskett <gheskett@shentel.net> - 2017-09-18 00:50 +0200
                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-18 01:20 +0200
    Re: sudo slow on DNS lookup, with invalid resolv.conf entries Dan Ritter <dsr@randomstring.org> - 2017-09-15 23:10 +0200
      Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-15 23:40 +0200

Page 1 of 2  [1] 2  Next page →

#186861 — sudo slow on DNS lookup, with invalid resolv.conf entries

I was getting > 30sec to complete "sudo su" on a host. This host had
invalid entries in resolv.conf and I realized sudo was doing 5 seconds
lookup on each entry searching for "localhost.localdomain"

sudo is 1.8.19p1 @ stretch.

Believe no DNS lookups should be made... even for localhost


sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\313\265\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=51}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\1\371\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=51}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\313\265\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=51}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\1\371\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=51}], 2, MSG_NOSIGNAL) = 2

[toc] | [next] | [standalone]

#186862

	Hi.

On Fri, Sep 15, 2017 at 12:46:09PM -0300, x9p wrote:
> 
> I was getting > 30sec to complete "sudo su" on a host. This host had
> invalid entries in resolv.conf and I realized sudo was doing 5 seconds
> lookup on each entry searching for "localhost.localdomain"
> 
> sudo is 1.8.19p1 @ stretch.
> 
> Believe no DNS lookups should be made... even for localhost

While DNS lookups for localhost are unusual any reasonable configured
DNS should have no trouble resolving it. Especially since there are OSes
that try to resolve *everything* by default via including localhost (AIX
comes to mind).

While you mentioned misconfigured resolv.conf I believe your problem
lies somewhat deeper than this.

Specifically I'm interested with:

grep hosts /etc/nsswitch.conf

grep localhost /etc/hosts

Reco

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

#186867

>         Hi.

Hi.

>
> While DNS lookups for localhost are unusual any reasonable configured
> DNS should have no trouble resolving it. Especially since there are OSes
> that try to resolve *everything* by default via including localhost (AIX
> comes to mind).
>

Understand, but disagree with sudo doing DNS lookups. Will fill a bug with
them.

> While you mentioned misconfigured resolv.conf I believe your problem
> lies somewhat deeper than this.

Actually it is deeper. I did not pay that much attention to the strace I
did before.

https://pastebin.com/j0rw5Kgn

10.1.2.9 is the DNS of the company I work for, turned out I had not
connected to the VPN yet by the time i issued the sudo command.

---

connect(6, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("10.1.2.9")}, 16) = 0^M
poll([{fd=6, events=POLLOUT}], 1, 0)    = 1 ([{fd=6, revents=POLLOUT}])^M
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2^M
poll([{fd=6, events=POLLIN}], 1, 5000)  = 0 (Timeout)^M

---

resolv.conf is not a symlink to systemd, just a plain file. I explicitly
removed the symlink and created a normal file.

> Specifically I'm interested with:
>
> grep hosts /etc/nsswitch.conf
>
> grep localhost /etc/hosts
>
> Reco
>

Did not touched these, are the default from stretch:

root@localhost:~# grep hosts /etc/nsswitch.conf
hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
root@localhost:~# grep localhost /etc/hosts
127.0.0.1       localhost
127.0.1.1       localhost
::1     localhost ip6-localhost ip6-loopback

x9p

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

#186870

On Fri, Sep 15, 2017 at 04:28:31PM -0300, x9p wrote:
> 
> >         Hi.
> 
> Hi.
> 
> >
> > While DNS lookups for localhost are unusual any reasonable configured
> > DNS should have no trouble resolving it. Especially since there are OSes
> > that try to resolve *everything* by default via including localhost (AIX
> > comes to mind).
> >
> 
> Understand, but disagree with sudo doing DNS lookups. Will fill a bug with
> them.

sudo(8) says:

     sudo supports a plugin architecture for security policies and
input/output logging.  Third parties can develop and distribute their
own policy and I/O logging plugins to work seamlessly with the sudo
front end.  The default security policy is sudoers, which is configured
via the file /etc/sudoers, or via LDAP.

And LDAP means TCP, and TCP usually mean DNS requests.

So it's unusual (sudo does not exhibit such behavior here), but
possible.


> > While you mentioned misconfigured resolv.conf I believe your problem
> > lies somewhat deeper than this.
> 
> Actually it is deeper. I did not pay that much attention to the strace I
> did before.
> 
> https://pastebin.com/j0rw5Kgn
> 
> 10.1.2.9 is the DNS of the company I work for, turned out I had not
> connected to the VPN yet by the time i issued the sudo command.

A stray nameserver in resolv.conf, which can happen if resolvconf is
used carelessly. Even more weird things are always possible with
NetworkManager.

> resolv.conf is not a symlink to systemd, just a plain file. I explicitly
> removed the symlink and created a normal file.

And of course one can never disregard a misconfigured VPN script.



> > Specifically I'm interested with:
> >
> > grep hosts /etc/nsswitch.conf
> >
> > grep localhost /etc/hosts
> >
> > Reco
> >
> 
> Did not touched these, are the default from stretch:
> 
> root@localhost:~# grep hosts /etc/nsswitch.conf
> hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
> root@localhost:~# grep localhost /etc/hosts
> 127.0.0.1       localhost
> 127.0.1.1       localhost
> ::1     localhost ip6-localhost ip6-loopback

Curious. Can you reproduce the behaviour if sudo is run as root?
I propose to simplify things a bit (needs to be run as root):

strace -o /tmp/sudo -econnect,open sudo -i

Reco

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

#186875

> sudo(8) says:
>
>      sudo supports a plugin architecture for security policies and
> input/output logging.  Third parties can develop and distribute their
> own policy and I/O logging plugins to work seamlessly with the sudo
> front end.  The default security policy is sudoers, which is configured
> via the file /etc/sudoers, or via LDAP.
>
> And LDAP means TCP, and TCP usually mean DNS requests.
>
> So it's unusual (sudo does not exhibit such behavior here), but
> possible.
>

Agree there are situations where sudo does TCP. Disagree with that
occurring in my simplistic setup. sudo should not hang for X seconds if my
DNS servers are incorrect.

> A stray nameserver in resolv.conf, which can happen if resolvconf is
> used carelessly. Even more weird things are always possible with
> NetworkManager.

Am too old, I like /etc/resolv.conf being just a file. Am avoiding to turn
this into a systemd talk.

>> resolv.conf is not a symlink to systemd, just a plain file. I explicitly
>> removed the symlink and created a normal file.
>
> And of course one can never disregard a misconfigured VPN script.
>
>
>
>> > Specifically I'm interested with:
>> >
>> > grep hosts /etc/nsswitch.conf
>> >
>> > grep localhost /etc/hosts
>> >
>> > Reco
>> >
>>
>> Did not touched these, are the default from stretch:
>>
>> root@localhost:~# grep hosts /etc/nsswitch.conf
>> hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
>> root@localhost:~# grep localhost /etc/hosts
>> 127.0.0.1       localhost
>> 127.0.1.1       localhost
>> ::1     localhost ip6-localhost ip6-loopback
>
> Curious. Can you reproduce the behaviour if sudo is run as root?
> I propose to simplify things a bit (needs to be run as root):
>

strace was already run as root (did "sudo su" as root to prove the point),
otherwise strace would fail with "effective uid is not 0".

x9p

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

#186876

On Fri, Sep 15, 2017 at 06:06:02PM -0300, x9p wrote:
> 
> > sudo(8) says:
> >
> >      sudo supports a plugin architecture for security policies and
> > input/output logging.  Third parties can develop and distribute their
> > own policy and I/O logging plugins to work seamlessly with the sudo
> > front end.  The default security policy is sudoers, which is configured
> > via the file /etc/sudoers, or via LDAP.
> >
> > And LDAP means TCP, and TCP usually mean DNS requests.
> >
> > So it's unusual (sudo does not exhibit such behavior here), but
> > possible.
> >
> 
> Agree there are situations where sudo does TCP. Disagree with that
> occurring in my simplistic setup. sudo should not hang for X seconds if my
> DNS servers are incorrect.
> 
> > A stray nameserver in resolv.conf, which can happen if resolvconf is
> > used carelessly. Even more weird things are always possible with
> > NetworkManager.
> 
> Am too old, I like /etc/resolv.conf being just a file. Am avoiding to turn
> this into a systemd talk.

Was not my intention. All those things can happen if one's using
sysvinit.


> >> > Specifically I'm interested with:
> >> >
> >> > grep hosts /etc/nsswitch.conf
> >> >
> >> > grep localhost /etc/hosts
> >> >
> >> > Reco
> >> >
> >>
> >> Did not touched these, are the default from stretch:
> >>
> >> root@localhost:~# grep hosts /etc/nsswitch.conf
> >> hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname
> >> root@localhost:~# grep localhost /etc/hosts
> >> 127.0.0.1       localhost
> >> 127.0.1.1       localhost
> >> ::1     localhost ip6-localhost ip6-loopback
> >
> > Curious. Can you reproduce the behaviour if sudo is run as root?
> > I propose to simplify things a bit (needs to be run as root):
> >
> 
> strace was already run as root (did "sudo su" as root to prove the point),
> otherwise strace would fail with "effective uid is not 0".

Your snippet of strace output on pastebin is lacking the beginning.
What I'm currently interested in are:

1) Libraries and configuration files that sudo is opening (hence the
'open' syscall). Thinking about it, make it 'open,stat'.

2) What kind of network sockets (short of kinda obvious UDP) sudo is
opening (hence the 'connect' syscall).

Feel free to edit out all unnecessary details of course.


PS Replying to debian-user@lists.debian.org is sufficient. There's no
need to CC me, I'm subscribed to the list.

Reco

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

#186877

> Your snippet of strace output on pastebin is lacking the beginning.
> What I'm currently interested in are:
>
> 1) Libraries and configuration files that sudo is opening (hence the
> 'open' syscall). Thinking about it, make it 'open,stat'.
>
> 2) What kind of network sockets (short of kinda obvious UDP) sudo is
> opening (hence the 'connect' syscall).
>

Sorry for that, pasted the full output here.
https://pastebin.com/0bV7JC1z

> Feel free to edit out all unnecessary details of course.

No need.

>
> PS Replying to debian-user@lists.debian.org is sufficient. There's no
> need to CC me, I'm subscribed to the list.
>

Sorry for that. I just hit "reply all", fixing.

x9p

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

#186879

On Fri, Sep 15, 2017 at 06:32:17PM -0300, x9p wrote:
> 
> > Your snippet of strace output on pastebin is lacking the beginning.
> > What I'm currently interested in are:
> >
> > 1) Libraries and configuration files that sudo is opening (hence the
> > 'open' syscall). Thinking about it, make it 'open,stat'.
> >
> > 2) What kind of network sockets (short of kinda obvious UDP) sudo is
> > opening (hence the 'connect' syscall).
> >
> 
> Sorry for that, pasted the full output here.
> https://pastebin.com/0bV7JC1z
> 
> > Feel free to edit out all unnecessary details of course.
> 
> No need.

Thanks, now I see it.

Your /etc/hosts says:

127.0.0.1       localhost
127.0.1.1       localhost
::1     localhost ip6-localhost ip6-loopback

Note the absence of localhost.localdomain.


Your hostname is "localhost.localdomain", as strace helpfully shows us:

uname({sysname="Linux", nodename="localhost.localdomain", ...})


I won't say that specifying fqdn as nodename is wrong per se, but in
your case you don't have a record for your hostname in /etc/hosts.

This *could* be the case that's nss-myhostname is designed for but …
it's the last in your nsswitch.conf so it cannot come into play.

Therefore libc resolver you're using does exactly the same way it's
supposed to - search for localhost.localdomain in /etc/hosts first,
query DNS next.


Quick and dirty way to fix this is to add a record for
'localhost.localdomain' in your /etc/hosts.

Correct, but painful way (I won't even try to predict what you could
break in your setup) to fix this is to ensure that your hostname is
'localhost' verbatim.

Reco

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

#186880

> Thanks, now I see it.
>
> Your /etc/hosts says:
>
> 127.0.0.1       localhost
> 127.0.1.1       localhost
> ::1     localhost ip6-localhost ip6-loopback
>
> Note the absence of localhost.localdomain.
>
>
> Your hostname is "localhost.localdomain", as strace helpfully shows us:
>
> uname({sysname="Linux", nodename="localhost.localdomain", ...})
>

strangely i do not remember calling it localhost with domain localdomain,
just localhost.

>
> I won't say that specifying fqdn as nodename is wrong per se, but in
> your case you don't have a record for your hostname in /etc/hosts.
>
> This *could* be the case that's nss-myhostname is designed for but …
> it's the last in your nsswitch.conf so it cannot come into play.
>
> Therefore libc resolver you're using does exactly the same way it's
> supposed to - search for localhost.localdomain in /etc/hosts first,
> query DNS next.
>
>
> Quick and dirty way to fix this is to add a record for
> 'localhost.localdomain' in your /etc/hosts.
>

Will do it, thanks

> Correct, but painful way (I won't even try to predict what you could
> break in your setup) to fix this is to ensure that your hostname is
> 'localhost' verbatim.
>

I still think correct way is sudo not try to access network functions in a
setup where it does not need to - waste of time, code, and opens it to
more bugs.

Thanks for the analysis Reco.

x9p

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

#186882

On Friday 15 September 2017 19:17:30 x9p wrote:

> > Thanks, now I see it.
> >
> > Your /etc/hosts says:
> >
> > 127.0.0.1       localhost
> > 127.0.1.1       localhost
> >
> > ::1     localhost ip6-localhost ip6-loopback
> >
> > Note the absence of localhost.localdomain.
> >
> >
> > Your hostname is "localhost.localdomain", as strace helpfully shows
> > us:
> >
> > uname({sysname="Linux", nodename="localhost.localdomain", ...})
>
> strangely i do not remember calling it localhost with domain
> localdomain, just localhost.
>
> > I won't say that specifying fqdn as nodename is wrong per se, but in
> > your case you don't have a record for your hostname in /etc/hosts.
> >
> > This *could* be the case that's nss-myhostname is designed for but
> > … it's the last in your nsswitch.conf so it cannot come into play.
> >
> > Therefore libc resolver you're using does exactly the same way it's
> > supposed to - search for localhost.localdomain in /etc/hosts first,
> > query DNS next.
> >
> >
> > Quick and dirty way to fix this is to add a record for
> > 'localhost.localdomain' in your /etc/hosts.
>
> Will do it, thanks
>
> > Correct, but painful way (I won't even try to predict what you could
> > break in your setup) to fix this is to ensure that your hostname is
> > 'localhost' verbatim.
>
> I still think correct way is sudo not try to access network functions
> in a setup where it does not need to - waste of time, code, and opens
> it to more bugs.
>
> Thanks for the analysis Reco.
>
> x9p

Since the /etc/hosts file can also contain aliases, the ideaL way would 
seem to be to make use of that. Example:
192.168.x.z	localhost.localdomain	localhost

where x.z are the triplets (without the zero leading fill of course) 
corresponding to the class d of your local network.

Then you shouldn't have any dns problems if your resolv.conf is correct.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
++

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

#186916

> Since the /etc/hosts file can also contain aliases, the ideaL way would
> seem to be to make use of that. Example:
> 192.168.x.z	localhost.localdomain	localhost
>

You are right, this solves the problem of the DNS lookup / X seconds delay
to run sudo even with a buggy DNS server:

root@localhost:~# head -1 /etc/hosts
127.0.0.1       localhost localhost.localdomain

Should be on debian by default in my opinion.

x9p

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

#186917

x9p wrote:

> Should be on debian by default in my opinion.

... and truly it is

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

#186921

On Sun 17 Sep 2017 at 22:54:27 +0200, deloptes wrote:

> x9p wrote:
> 
> > Should be on debian by default in my opinion.
> 
> ... and truly it is

Really? Not on any install I have done and not according to the netcfg
source package:

  * Don't make 'localhost.localdomain' the canonical hostname of 127.0.0.1.                                             
    See Oct 2005 debian-devel discussion with Subject: localhost.localdomain,

  * Per Olofsson                                                                                                        
    - Map 127.0.0.1 to localhost in /etc/hosts, make the hostname                                                       
      an alias instead.

-- 
Brian. 

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

#186922

On Sunday 17 September 2017 16:54:27 deloptes wrote:

> x9p wrote:
> > Should be on debian by default in my opinion.
>
> ... and truly it is

Not on the 3 other wheezy's nor on the one jessie machine I can inspect 
in a couple minutes here.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#186924

Gene Heskett wrote:

> On Sunday 17 September 2017 16:54:27 deloptes wrote:
> 
>> x9p wrote:
>> > Should be on debian by default in my opinion.
>>
>> ... and truly it is
> 
> Not on the 3 other wheezy's nor on the one jessie machine I can inspect
> in a couple minutes here.
> 
> Cheers, Gene Heskett

No idea, on any debian I installed local host maps to 127.0.0.1

This is the default from the last stretch install

$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       fujitsu.mydomain    fujitsu

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Interesting to know why.

If it is about localhost.localdomain .... no idea where localdomain is
coming from. Perhaps if you install in a local network without domain, or
if you do not enter any.

The line in stretch

127.0.1.1       fujitsu.mydomain    fujitsu

is new to me, but computer works with local dhcp/dns, so why bother

regards

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

#186925

On Sunday 17 September 2017 18:58:30 deloptes wrote:

> Gene Heskett wrote:
> > On Sunday 17 September 2017 16:54:27 deloptes wrote:
> >> x9p wrote:
> >> > Should be on debian by default in my opinion.
> >>
> >> ... and truly it is
> >
> > Not on the 3 other wheezy's nor on the one jessie machine I can
> > inspect in a couple minutes here.
> >
> > Cheers, Gene Heskett
>
> No idea, on any debian I installed local host maps to 127.0.0.1
>
> This is the default from the last stretch install
>
> $ cat /etc/hosts
> 127.0.0.1       localhost

The above is precisely my point, there is NOT a 

127.0.0.1 localhost.localdomain localhost 

entry in anyones /etc/hosts file unless THEY PUT IT THERE.

So while I seem to have fixed the OP's problem, the fix is now masking 
the real problem (and I haven't a clue what the heck that actually is)

 
> 127.0.1.1       fujitsu.mydomain    fujitsu
>
> # The following lines are desirable for IPv6 capable hosts
>
> ::1     localhost ip6-localhost ip6-loopback
>
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
>
> Interesting to know why.
>
> If it is about localhost.localdomain .... no idea where localdomain is
> coming from. Perhaps if you install in a local network without domain,
> or if you do not enter any.
>
> The line in stretch
>
> 127.0.1.1       fujitsu.mydomain    fujitsu
>
> is new to me, but computer works with local dhcp/dns, so why bother
>
> regards


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#186929

Gene Heskett wrote:

> 127.0.0.1 localhost.localdomain localhost

Sorry but I did not understand if the problem is there or if the problem is
that it is not there?

I guess this is put there at time of installation. I'll check few virtual
machines later to see how it was written.

IMO if you have working resolver it shouldn't matter much.

regards

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

#186958

	Hi.

On Mon, Sep 18, 2017 at 08:50:36AM +0200, deloptes wrote:
> Gene Heskett wrote:
> 
> > 127.0.0.1 localhost.localdomain localhost
> 
> Sorry but I did not understand if the problem is there or if the problem is
> that it is not there?

Long story short, OP has a misbehaving Debian stretch installation with
the hostname (as in - /proc/sys/kernel/hostname) set to
'localhost.localdomain'.
/etc/hosts lacks such entry.
/etc/resolv.conf points to an absent DNS.

The result is - every execution of sudo has an added 30-second execution
time 'bonus'.
 

> I guess this is put there at time of installation. I'll check few virtual
> machines later to see how it was written.

If the user chooses conventional hostname (even 'debian') during the
installation - sure, they should put a record in /etc/hosts. Unsure
about stretch, but they did so since etch.

The question is - since 'localhost.localdomain' is special, what happens
if such hostname is chosen during the installation?


> IMO if you have working resolver it shouldn't matter much.

Please read this thread's subject one more time. Last three words
especially.

Reco

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

#186962

Reco wrote:

> The question is - since 'localhost.localdomain' is special, what happens
> if such hostname is chosen during the installation?

well, now we all know what happens :)

regards

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

#186964

On Mon 18 Sep 2017 at 20:13:44 +0200, deloptes wrote:

> Reco wrote:
> 
> > The question is - since 'localhost.localdomain' is special, what happens
> > if such hostname is chosen during the installation?
> 
> well, now we all know what happens :)

True, we know the OP has a problem with with sudo. What we do not know
is the hostname he chose during the installation, although it looks like
it was "localhost" from the second line of

  127.0.0.1       localhost                                                                                             
  127.0.1.1       localhost

The installer recommends a single word for the hostname. The "single"
aspect is the result of a number of years of experience and bug reports.
Although "localhost.localdomain" is not an invalid hostname the OP does
not appear to have used it. (We have not been given the contents of his
/etc/hostname explicitly).

What was the problem with his resolv.conf? Have I missed that?

-- 
Brian.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web