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. IMHO, this bug report is akin to "`sudo rm -rf` hosed my system!"Īdam sM, "" member, my first "" posting. ![]() A "blog post" does not a "bug report" make. Freedom means "free to do anything, even if it is destructive."ģ. His system is broken simply because he broke it.Ģ. The original "bug" reporter needs to understand that:ġ. Note that, had I rebooted right after, `sudo` and many other things would'veīeen "broken" again because "/etc/hosts" and "/etc/hostname" do _not_ agree this, too, is _not_ a bug. Observe that `sudo` went from working, to "broken", to working again as I restored the system to a semi-consistent stateīy having `hostname` and "/etc/hosts" agree. # sed -i "s/pickles/ foobar/ g" /etc/hosts The commands are posted in the order I execute them and you can use the leading '$' or '#' to distinguish between the 2 terminals: I, too, use 2 terminals, 1 in a `sudo -s` session as a failsafe and a second to test for breakage of `sudo` in general. _and_ the tool warns you that your system will be in an inconsistent state until the next reboot. If you change the hostname from within the `network-admin` tool, you have no issues with `sudo` The kernel itself and/or "the Environment" "/etc/hostname" which, in turn, sets the precedent for 3. The behavior stems from the fact that the hostname is preset in 3 locations:ġ. I can confirm similar behavior on Hardy Alpha6 to what's shown above, _but_ I say that there is no bug here. Or, asked the other way round, can you please check if it is fixed for you as well on current Hardy? $ sudo grep -v '^#' /etc/sudoers | grep -v '^$' I sanyone actually able to reproduce this? Can you please post a recipe here?įor the record, I'm using the default sudoers: However, some of the recent duplicates (like bug 197494) seem to indicate that it is still a problem in hardy. Now, when I reset the hostname withĮverything works again on both dapper and hardy. it still warns me, but doesn't fail any more. Sudo: unable to lookup foobar via gethostbyname() 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 should still complain, but run the ls command. upgrade sudo to the hardy-proposed version and attempt the same. Hardy final will fail with "unable to resolve host foo" and not run the ls. open another terminal, and try "sudo ls". open a terminal and do "sudo -i" to get a root shell do "hostname foo" ![]() ![]() fails) on a system where /usr/sbin/sendmail does NOT exist (standard Ubuntu installation) Otherwise, just mark it as invalid and forget it. If you consider that this is relevant and worth discussing, we can add Adam Williamson to the conversation. Originally from 2006/02/ 24/how- to-break- ubuntu- in-thirty- seconds/, Not too smart! Surely sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on? The only way out of this that I can see is single-user mode or the recovery console. Only, as you can see, this utterly breaks Ubuntu…all I need to do to fix the sudo problem is edit /etc/hosts so 127.0.0.1 is ‘ubuntu510′ (the name of the VM) rather than ‘zen’ (the name of the real machine), but I can’t do it, because sudo doesn’t work… So now when I set up a new VMware machine I just copy the /etc/hosts from the real machine over to the VM then edit a couple of lines to match the VM, instead of re-editing it all from scratch. I have a bunch of entries in /etc/hosts because of having four local systems plus a bunch of VMware machines etc. ![]() …yeah, sudo, it’s all very clever until someone loses an eye! Sudo: unable to lookup ubuntu510 via gethostbyname() On behalf of Adam Williamson sudo scp 192.168.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |