Aah, I finally found out why I could not reproduce it, and what's wrong.
I have local MTAs on all my boxes. If I install a system without one, I
can replicate the error. It apparently tries to send a mail to the admin
about the error and dies with a SIGPIPE:
Program received signal SIGPIPE,
I've had this problem with both a fresh install and an upgrade to Hardy.
George Durbridge's and Phosgene's experience matches mine - using the
network admin tool, sudo works ok without domain name, but can't sudo
with a domain name.
Unfortunately, my 'workgroup' uses a domain name!
--
sudo
I have to say I agree with SteveR in comment 56. The chicken and egg
problem here is likely a deal breaker for more than a few remote server
administrators.
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug
** Changed in: sudo (Ubuntu Hardy)
Target: None = ubuntu-8.04.1
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
This problem occurred for my friend on his laptop when he upgraded from
Gusty to Hardy. I first tried going into recovery mode and resetting the
hostname, but there was no change. So instead I used the network-admin
to change /etc/hosts; I aliased 127.0.0.1 as the hostname and localhost.
I'll try
I just upgraded from 7.10 to 8.04 with the effect that I could not sudo
any more (unable to resolve host name)
the problem is that my sysadmin had advised me to remove the line
127.0.1.1 myhostname
from /etc/hosts a couple of days before the upgrade. When I put it back
in, sudo worked
What I have to do to get the sudo to work:
127.0.0.1 localhost
#127.0.1.1 Ubuntu-Tower.NTWorkgroup ###commented to see if it will fix
sudo###
127.0.1.1 Ubuntu-Tower
With the .NTWorkgroup, I can 't use Update Manager, Root terminal etc.
etc.
I had to use the normal Terminal followed
Having just installed ubuntu 08.04 on a new server, then putting it in a
datacenter over an hour away, then copying our master hosts file over
and thus loosing the server, I can say that this bug is reason enough
for us to drop the whole idea of moving to ubuntu. I think it needs a
couple of more
** Tags added: gutsy2hardy
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
There is a user in #kubuntu-de at the moment who upgraded from Gutsy to
Hardy and did nothing manually to her /etc/hosts or /etc/hostname. After
the upgrade sudo stopped working for her. The hostname was still maxi as
before the upgrade, but the line in /etc/hosts suddenly said 127.0.0.1
maxl
Martin Pitt wrote:
I just have trouble with reproducing it.
Seriously? Here's one way:
Boot the 8.04 live CD
Open a terminal window
Enter the commands
sudo id
sudo hostname foo
sudo id
Note how the former sudo id command succeeds but the latter one fails with
the error message sudo:
A minor clarification to the above... the exact error message issued
by the sudo id command is actually
sudo: unable to resolve host foo
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you
I encountered this same problem after upgrading from gutsy to hardy.
After trying to resolve connection problems which were messed up after
the upgrade the sudo stopped working. It happened when I disabled my
wireless and lan connection from kde network management tools. Booting
in recovery mode
This is a bug in the network-admin tool. It is not just an upgrade
problem, as I encountered it on a fresh install of Hardy.
The tool saves a hostname to /etc/hosts in the form host.domain, even
if you only enter host. So if you provide for one IP the aliases
host and host.domain, it saves
I think this bug is marked as In progress and Martin Pitt is assigned
to it and from reading the comments (have any of you actually read the
comments?), he said in comment #1:
I agree that sudo doesn't need to look up the hostname IF the relevant
host part in sudoers is ALL anyway.
Any comment
Please refrain from discouraging people to contribute. People are
trying to help by sharing their experiences in hopes that the additional
information will be useful to resolving this bug.
Furthermore, Martin Pitt has also stated that he does not consider this
to be a bug and that does require
Let's please step back a bit. If we look at things from sudo's point of
view, maybe this is just expected behavior and not a bug. But, if you
look at it from the Ubuntu project's point of view, this is a major
problem. There is simply no way on any kind of robust system _I_ want
to be involved
Here's a list of over 20 threads so far on ubuntuforums with posts
describing problems caused by this bug:
http://hightechsorcery.com/2008/04/partial-list-ubuntuforums-threads-
related-sudo-unable-resolve-host-bug
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
I upgraded to 8.04 today and am having the same problem. Whenever I use sudo I
get the error:
sudo: unable to resolve host hostname
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you are a
I upgraded 7.10 to 8.04 today (23-04-2008). sudo was borked due to
unable to resolve host. I removed 127.0.1.1 montreal.ubuntu.com
ubuntu from /etc/hosts file in recovery mode. BAM! It worked perfectly.
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
I confirm this bug in a dist-upgrade from Kubuntu Gutsy to Hardy
(18/04/2008), without touching any config file.
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you are a member of Ubuntu
Bugs,
I ran into this recently. My use case was copying virtual machines and
then changing the hostname by editing the /etc/hostname and running
hostname -F. I was surprised to see sudo stop working following this
and requiring me to boot into single user mode to fix. My surprise was
because there
I fixed my error
sudo: unable to resolve host lian-ubuntu-beta
by making entries in System-Administration-Network
such that afterward the files /etc/hostname and /etc/hosts read:
$ cat /etc/hostname
lian-ubuntu-beta
[EMAIL PROTECTED]:~$ cat /etc/hosts
127.0.0.1 localhost lian-ubuntu-beta
This is a link to the Ubuntu forums that shows how to do what LarryJ
states above.
http://ph.ubuntuforums.com/showthread.php?p=4480244
Quick and very easy fix.
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug
The sudo+hostname bug/inconvenience happened to me. I hosed my hosts
file when upgrading from 7.04 to 8.04. Sudo didn't want to do anything,
but gksudo worked fine. The network-dependent sudo failed, but the
X11-dependent gksudo was OK. Redundancy saves the day.
--
sudo shouldn’t ABSOLUTELY NEED
I was getting the same problem, sudo: unable to resolve host ABIT, where
ABIT is my HOST NAME. I fixed this problem by going to
System==Administration==Network, under the General tab, I put my Domain Name
as home.local
,
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
@asmoore
I am not confused at all.
I actually am certain that raising privileges on the local machine should not
require networking bits at all. There is no real reason why that should be
done. No real dependency of the network, unlike the X system that is actually
meant and thought for
Convenient, no doubt - but I see it as a positive side effect of a
defective behaviour rather than something intentional and positive.
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you are a
I actually am certain that raising privileges on the local machine should not
require networking bits at all.
There is no real reason why that should be done. No real dependency of the
network,
unlike the X system that is actually meant and thought for networking.
In your own terms: The
Sir, I seriously think that sudo is meant to raise/change privileges of the
current user, and this has nothing to do with the network. The manual page
makes this short description: sudo, sudoedit - execute a command as another
user.
But I am certain that you can explain me who says that the
@Dorin
Perhaps sudo should try to use the name from /etc/hostname when gethostbyname
fails?
It looks quite simple to do that, and assume that you'll have there 127:0.0.1
(in both IPv4 and v6)?!?!?!
You seem to be confused.
That's _exactly_ what `sudo` is doing: it's using the known _local_
Of course it is no bug in the sense that it breaks any specified
contract, but ubuntu does not have a password for root and sudo is the
only way to repair a wrong /etc/hosts. On systems with root passwords
this would be a non-issue.
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s
Just because applications like gnome-terminal or mc are broken doesn't mean
that on your local box there should definitely be no resolving done. Or if
there is some kind of resolving done, resolve 127.0.0.1 or localhost (just to
be not so IP-minded)
But I see NO reason for sudo to make any DNS
** Changed in: sudo (Ubuntu Hardy)
Status: Incomplete = In Progress
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
@Martin
$ sudo true
sudo: unable to resolve host pickles
^^ This is where sudo was broken. I can re-run the test using `sudo id` when I
get back to my Hardy box;
But, again, I feel there is no bug here:
Not being able to resolve the local hostname is a broken and unsupportable
state for any
@asmoore82
But, again, I feel there is no bug here:
Maybe you are right if you have a new installation of hardy. But consider there
is a different behavior in hardy compared to previous releases (e.g. gutsy)
where a different hostname in /etc/hostname and /etc/hosts is accepted. If this
is
sudo does not work by default if your network card is only partially
supported, as opposed to logging in with root.
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you are a member of Ubuntu
But consider there is a different behavior in hardy compared to previous
releases (e.g. gutsy)
where a different hostname in /etc/hostname and /etc/hosts is accepted
accepted by `sudo` or accepted in general ??
I can get away with that on my Gutsy box, but it _is_ a misconfiguration and
I can reproduce the bug in Hardy:
barcc:~$ sudo grep -v '^#' /etc/sudoers | grep -v '^$'
Defaults!lecture,tty_tickets,!fqdn,timestamp_timeout = 15
rootALL=(ALL) ALL
%admin ALL=(ALL) ALL
root:~# hostname foobar
barcc:~$ sudo id
sudo: unable to resolve host foobar
It warns and
I can confirm similar behavior on Hardy Alpha6 to what's shown above,
_but_ I say that there is no bug here.
The behavior stems from the fact that the hostname is preset in 3 locations:
1. /etc/hosts 2. /etc/hostname which, in turn, sets the precedent for 3.
The kernel itself and/or the
Sorry for the double-post, but in a more direct response to the YELLING
in the topic:
If sudo behaved differently, it would become vulnerable to some sort of
`HOSTNAME=foobar sudo ...` attack.
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
I tried to change sudoers to Defaults !lecture,tty_tickets,!fqdn and
get the same sudo behavior, i. e. it warns, but does not fail. Thus I
can still not reproduce the bug in Hardy. Can anyone else?
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
I tried to reproduce this. I opened two terminal windows, and did sudo
-i in one of them to get a root shell (#), the other is a normal user
shell ($)
$ sudo id
[sudo] password for martin:
uid=0(root) gid=0(root) Gruppen=0(root)
0 [EMAIL PROTECTED]:~
$ sudo -k
so by default, sudo works. Now
Hi
Yesterday I did a dist-upgrade from gutsy, I haven't touched my sudoers file:
sudo grep -v '^#' /etc/sudoers | grep -v '^$'
Defaults!lecture,tty_tickets,!fqdn
rootALL=(ALL) ALL
%admin ALL=(ALL) ALL
I found the bug and had to add a manual entry in etc/hosts:
127.0.0.1 cube
This
Hi
Changing
Defaults !lecture,tty_tickets,!fqdn
to
Defaults env_reset
and now it works as martin says
thanks
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you are a member of Ubuntu
Bugs,
I have a wirless PCI card that is only partially supported in Ubuntu.
During the installation and trial of drivers for that card, it has
happened several times that sudo just stopped working, in the same
manner as described here. This is highly frustrating. If I could touch
To clarify, the reason that sudo looks up the local hostname is that
/etc/sudoers is designed to be shareable between multiple hosts.
(/etc/hosts is too, but this doesn't work if you share an /etc/hosts
that gives you no way to look up your own hostname.) In order to know
which of the commands in
I don't know how this sharing is supposed to be done, but whatever the
usecase for it, denying user login because the local hostname cannot be
resolved should definitely not be allowed here. The reason that I don't
think you need to lookup the hostname is because the hostname is
specified nowhere
Perhaps sudo should try to use the name from /etc/hostname when
gethostbyname fails? It looks quite simple to do that, and assume that
you'll have there 127:0.0.1 (in both IPv4 and v6)?!?!?!
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
** Changed in: sudo (Ubuntu)
Importance: Low = High
Status: Confirmed = In Progress
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct
@harcesz
The forums are a better place to get help. Launchpad is for reporting
bugs when you find one. Nonetheless, you should be able to boot in
rescue-mode and edit /etc/hostname and /etc/hosts files. If you need
instructions on how to do this, use the forums.
--
sudo shouldn’t ABSOLUTELY
just updated to 8.04 and that either messed up my hostname or it's not
good for sudo anymore, I'm a bit confused at the moment
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you are a member
Yes,I just have experience this problem.And I come here for help,but I
can't get help.If you had a solution,please tell me.Thanks.
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://bugs.launchpad.net/bugs/32906
You received this bug notification because you are a
** Changed in: sudo (Ubuntu)
Assignee: (unassigned) = Martin Pitt
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://launchpad.net/bugs/32906
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
** Bug 62706 has been marked a duplicate of this bug
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://launchpad.net/bugs/32906
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Another related bug: https://launchpad.net/bugs/19775
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://launchpad.net/bugs/32906
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
** Bug 21859 has been marked a duplicate of this bug
--
sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on
https://launchpad.net/bugs/32906
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
57 matches
Mail list logo
