Re: panel error *** ORBit patch ***

["Andy Coyne" <andy_coyne modusmedia com>]

FYI: I have had several friends install Linux, esp RH51 (because the RH install is almost trivial
nowadays), who have managed to end up with broken ip. They chose a hostname and domain name and didn't
realize they needed to modify /etc/hosts (or else use a name that resolves correctly on a DNS server they
have access to). By default, when the system starts the first time sendmail just sits there and tries to
resolve their hostname, and in their words "Linux hangs and I have to reboot and it just doesn't work".

Of course, sendmail will error out *eventually* and the system will complete the boot, and the fix is
trivial for a propeller head, but basically ip and networking issues really confuse newbies and frankly
can give Linux a bad name, eg: "What? I'm not on a network. What do you mean? Why doesn't it just work
like Windows does". (Ouch, sorry. But that is the sort of thing I hear sometimes. :)

Let's remember that tons of newbies will try Gnome, and it musn't dissapoint them because of our
assumptions. Perhaps when it executes the first time, the panel could verify the validity of its
assumptions about basic networking (on an otherwise functional Linux install).

-Andy

Elliot Lee wrote:

> <beware, soapbox content included. I've also reordered the chunks of the
> message a bit.>
>
> On Thu, 13 Aug 1998, Frederick I Gleef wrote:
>
> > > I refuse to put broken DNS hacks in in order to cater to broken system
> > > setups. I quite honestly do not care to support broken systems - should I
> > > also check to make sure that you have IPv4 support on your system before
> > > attempting to use it? :)
> >
> > I beg you to reconsider.  Broken DNS is common
>
> If programs encounter a broken runtime environment, they are not required
> to run perfectly. If the environment does not provide the basic
> necessities (which, for a network desktop, includes core network
> services), then it's reasonable to exit
>
> On the flip side, robust error detection (and if possible, recovery) is a
> must, so while your patch didn't quite fit the bill, your message pointed
> out some really broken code of mine :) Thanks once again!
>
> > Some users are beholden on others for DNS services.  For example many
> > people with just a dialup connection only have access to reverse DNS
> > when they are connected (and with some ISP's not even then).  These
> > users often have dynamic IP addresses.  While you and I have the
> > knowledge to write a script to adjust /etc/hosts for a dynamic number,
> > and possibly a dynamic name, many users don't.  We shouldn't require
> > that level of knowledge just to get Panel working.
>
> The default /etc/hosts on most systems (which would produce localhost ->
> 127.0.0.1 -> localhost.localdomain, I think) should work fine. If you
> don't have DNS access, it's when you have '/bin/hostname' print out a
> hostname that is not listed in your /etc/hosts file, and/or you have dns
> listed in /etc/nsswitch.conf before files for the hosts map, that problems
> ensue.
>
> > Remember, DNS is not a requirement for an IPv4 network to work.
>
> No DNS requirement was made. /etc/hosts fits the bill.
>
> > A better (in my mind), but still not perfect solution would be a
> > configure option for localhost-only compilation.
>
> I have no problem telling people that IMHO, their system is broken. They
> can feel free to prove otherwise to me, of course :)
>
> The big problem with putting little hacks like this in is that we wind up
> with a "good enough" mentality similar to the one that Bill "640k will be
> enough" Gates purportedly holds. Yes, we could indeed hard-code
> "localhost" in, but that would defeat the whole point of having a NETWORK
> desktop.
>
> Basic idea is to work with the broadest range of systems possible without
> limiting functionality in any way...
>
> > The best option, in my mind, would be for it to do the DNS and reverse
> > DNS checks.  If the tests succeed, great, if not (i.e. hent==NULL)
> > rather than failing with an error or segfaulting, contunue with
> > server_cnx->hostname = g_strdup("localhost").  This way, machines with
> > proper DNS will have a properly networked ORBit, machines without it
> > will not, but still work locally.
>
> DNS does not have to be involved, /etc/hosts is your friend.
>
> > Should I pass on this offer to any BOOTP / DHCP user having problems
> > with Panel :-).  I think your time would be better spent on coding than
> > tech support.
>
> Here's the premises I'm working under:
>         - 'hostname' should resolve to a valid IP address, loopback or otherwise.
>         - The IP address pointed to by 'hostname' should reverse-resolve
>           to a valid hostname (presumably, but not required to be, the FQDN)
>         - The 'hostname' and/or FQDN retrieved using the above procedure
>           should be valid for the lifetime of a CORBA server (and the
>
> Here's the requirements for a solution to make things work better:
>         - At the time of object reference creation in the server, it must
>           put a valid hostname (Internet-accessable if at all possible)
>           into the IOR.
>         - That hostname needs to continue to work (resolvable to a
>           connectable IP) as long as the IOR is
>           published for use by clients.
> [I think those are the only requirements, I might have missed one]
>
> Stepping down from the soapbox, note that all of the above may be more or
> less rhetorically speaking, because the ORBit in CVS should do something like:
>
>         hostname = gethostname();
>         hostent = gethostbyname(hostname);
>         if(hostent) {
>                 addrent = gethostbyaddr(hostent->host_address);
>                 if(addrent) {
>                         internet_accessable_hostname = addrent->host_fqdn;
>                 } else
>                         internet_accessable_hostname = ip_address_into_string(hostent->host_address);
>         } else
>                 internet_accessable_hostname = hostname;
>
> (And then internet_accessable_hostname is of course what gets encoded into
> theh IOR and advertised as "the host to access this object on").
>
> Does anyone know how X handles this whole conundrum? It has the _exact_
> same problem WRT setting $DISPLAY and all. Even if its solution is not
> "perfect", the solution (a) sets precedent (b) works pretty well most of
> the time (c) even if we get a better solution, the X one is going to limit
> us, because all GNOME programs on a particular desktop session share the
> same display.
>
> (Part of the problem is that CORBA encodes the hostname inside the IOR
> instead of leaving it directly manipulatable like X $DISPLAY's do. Perhaps
> we just need an iiop:// URL parser instead - any volunteers? It shouldn't
> be too hard, since all ORBit object keys are strings... :-)
>
> Hope this helps,
> -- Elliot
> Progress (n.): The process through which Usenet has evolved from smart
> people in front of dumb terminals to dumb people in front of smart
> terminals.  -- obs@burnout.demon.co.uk
>
> --
>          To unsubscribe: mail gnome-list-request@gnome.org with
>                        "unsubscribe" as the Subject.
>