Re: Problems with conserver after OS upgrade

On Friday 05 June 2009 13:30:03 Bryan Stansell wrote:
> Well, this could be an interesting failure mode with the SSL code, or
> something changed such that conserver no longer believes it's running on
> the host that's supposed to manage the consoles.  So, it's sending a
> redirect but redirecting to itself (under an alternate identity?).
>
> I'd look at the following output for clues:
>
>   conserver -DS
>   conserver -V
>   console -D <console>

  I think there's something in there.  conserver -DS shows lots of things, including that all of the consoles (of which I only have 6) are remote:

[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:762] Memory Usage (GRPENT objects): 0 (0)
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:817] Memory Usage (CONSENT objects): 0 (0)
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:830] Memory Usage (REMOTE objects): 211 (6)
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:837] Memory Usage (ACCESS objects): 81 (3)
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:844] Memory Usage (STRING objects): 856 (14)
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:852] Memory Usage (userList objects): 46 (4)
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:855] Memory Usage (total): 1194
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:1004] DumpDataStructures(): remote: rserver=cfe-rack, rhost=localhost
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:1004] DumpDataStructures(): remote: rserver=skaro, rhost=localhost
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:1004] DumpDataStructures(): remote: rserver=usparc, rhost=localhost
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:1004] DumpDataStructures(): remote: rserver=harmony, rhost=localhost
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:1004] DumpDataStructures(): remote: rserver=cyteen, rhost=localhost
[Fri Jun  5 15:06:24 2009] conserver (2243): DEBUG: [main.c:1004] DumpDataStructures(): remote: rserver=c3620, rhost=localhost
[Fri Jun  5 15:06:24 2009] conserver (2243): terminated

  One of these is a direct connection, and the other 5 are TCP connections
through a cisco access-server.  But, I think that's not the relevant part.
I think is it a client/server issue.

  When I run console -D foo, I see many "ok -> ok -> ssl_connect ->
ok -> @localhost -> goodbye", followed by another of the same, 
connecting again to localhost, until it eventually fails with "forwarding
level too deep!"

  I've never run this in any way other than as a single console server,
and only being able to connect from itself via localhost (127.0.0.1).

> If it's a name mismatch problem, perhaps just looking at the 'master'
> entries (if there are any) in your conserver.cf file and making sure
> they map to an ip address on your host would be a good first start.
>
> Feel free to send me (directly) any of the info above to help poke
> around and figure this out.  It *seems* like a configuration issue, but
> it's always possible it's something else.

  Okay.  Default * has "master localhost".  That's the only master I have.
localhost does, using IPv4 resolution, resolve to 127.0.0.1.  I don't
know if the default family changed in this rev of the OS, but it seems
that "localhost" resolves only to the IPv4 address.  That appears to be
true on another host still running NetBSD 4.0.

  Thanks.  Let me know if this reveals anything to you...

                              - Chris