On Monday 18 September 2017 12:39:12 Reco wrote:
> 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
On Mon 18 Sep 2017 at 22:50:07 +0200, deloptes wrote:
> Brian wrote:
>
> > 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"
>
> He admitted he entered localhost when
On Mon 18 Sep 2017 at 23:47:18 +0300, Reco wrote:
> On Mon, Sep 18, 2017 at 07:48:53PM +0100, Brian wrote:
> > 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
On Mon 18 Sep 2017 at 17:47:18 -0300, x9p wrote:
> > 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
> >
Brian wrote:
> 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"
He admitted he entered localhost when prompted at installation time.
regards
Hi.
On Mon, Sep 18, 2017 at 07:48:53PM +0100, Brian wrote:
> 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?
> >
> >
> 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
>
root@localhost:~# cat /etc/hostname
On Mon 18 Sep 2017 at 15:41:48 -0300, x9p wrote:
>
> >>
> >> I believe topic is closed with this.
> >
> > For the benefit of other users: what does your /etc/hosts look like now?
> >
> > --
> > Brian.
> >
> >
>
> root@localhost:~# cat /proc/sys/kernel/hostname
> localhost.localdomain
>
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
>>
>> I believe topic is closed with this.
>
> For the benefit of other users: what does your /etc/hosts look like now?
>
> --
> Brian.
>
>
root@localhost:~# cat /proc/sys/kernel/hostname
localhost.localdomain
root@localhost:~# grep localhost /etc/hosts
127.0.0.1 localhost
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
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
On Mon 18 Sep 2017 at 12:28:16 -0300, x9p wrote:
> Thanks for the memo. Seems the solution is to not call machine localhost,
> if insist in doing so, be sure it contains a "localhost.localdomain" line
> in /etc/hosts.
>
> I believe topic is closed with this.
For the benefit of other users: what
>>
>> My chosen machine name was "localhost", problem partially lies here.
>
> Yeah, man.
>
> My uncle Harry had a similar problem when it occurred to him that--for
> reasons of simplicity and because of a failing memory--he might christen
> two recently-purchased kittens with identical names.
On 2017-09-18, Greg Wooledge wrote:
> On Mon, Sep 18, 2017 at 11:38:05AM +, Curt wrote:
>> On 2017-09-18, x9p wrote:
>> > My chosen machine name was "localhost", problem partially lies here.
>>
>> Yeah, man.
>>
>> My uncle Harry had a similar
On Mon, Sep 18, 2017 at 11:38:05AM +, Curt wrote:
> On 2017-09-18, x9p wrote:
> > My chosen machine name was "localhost", problem partially lies here.
>
> Yeah, man.
>
> My uncle Harry had a similar problem when it occurred to him that--for
> reasons of simplicity
On Mon 18 Sep 2017 at 06:32:55 -0300, x9p wrote:
(Please watch your attributioms; it confuses matters. x9p did not write
this).
> > This is the default from the last stretch install
> >
> > $ cat /etc/hosts
> > 127.0.0.1 Â Â Â localhost
> > 127.0.1.1    fujitsu.mydomain   fujitsu
> >
On 2017-09-18, x9p wrote:
>>
>> IMO you should look deeper in your use case and see why you get invalid
>> setup. The problem might be somewhere else.
>>
>> regards
>>
>>
>
> My chosen machine name was "localhost", problem partially lies here.
Yeah, man.
My uncle Harry
>
> This is the default from the last stretch install
>
> $ cat /etc/hosts
> 127.0.0.1 Â Â Â localhost
> 127.0.1.1    fujitsu.mydomain   fujitsu
>
> so if mydomain or localdomain is not working it will delay.
>
> 127.0.1.1 fujitsu fujitsu.mydomain
>
> will not delay because
x9p wrote:
> If system hostname should ALWAYS be resolvable, whether there is network
> or no, the change in /etc/hosts
> from (default in stretch):
> 127.0.0.1 localhost
> to (my system):
> 127.0.0.1 localhost localhost.localdomain
>
> is justifiable as it breaks (not literally
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
> The last time I recollect this "someone" sticking his head above the
parapet was in the thread beginning at
> https://lists.debian.org/debian-devel/2013/07/msg00809.html
>From the above URL:
From: Christoph Anton Mitterer
Date: Tue, 30 Jul 2013 22:43:44 +0200
-
-
On Sun 17 Sep 2017 at 18:43:18 -0400, Gene Heskett wrote:
> On Sunday 17 September 2017 16:39:25 x9p wrote:
>
> > > 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
> >
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
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
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
On Sunday 17 September 2017 16:39:25 x9p wrote:
> > 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
>
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
x9p wrote:
> Should be on debian by default in my opinion.
... and truly it is
> 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:
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
> 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:
>
>
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
> You should have a localhost entry in /etc/hosts. If you have
> configured your /etc/sudoers to specify "localhost.localdomain",
> then you should also have a localhost.localdomain entry in
> /etc/hosts, or your should change the sudoers config to just
> reference "localhost".
>
No changes were
> 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
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
> >
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.
>
>
> 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
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
> 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
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 @
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
42 matches
Mail list logo