[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

RE: Permissions problems with conserver 8.11

Phillip Pacheco ppacheco@genesyslab.com
Mon, 19 Sep 2005 15:51:07 -0700 (PDT)

Thank you, Thank you!

Using the -M switch did the trick.  I hadn't noticed this before, but
one of the production "conserver servers" has a CC name of "console".
This is why I was getting the wrong server when I attempted to connect.
It is also why I never noticed this fundamental configuration feature.

I see in the man page of the "console" command that it is necessary to
define the default server name at compile time.  Is there an alternative
to this?  I would like to define the server name in a configuration file
instead.  If this is not possible now, will it be possible in future
releases.  I ask because my boss has a preference for using pre-compiled
programs to ensure uniformity.  I suppose that I can create a shell
alias as a band-aid solution.

Thank you one last time.  I am stoked to have finally solved this
problem.  Now I can move on to tweaking the config to my liking :).

Phillip Pacheco

-----Original Message-----
From: users-bounces@conserver.com [mailto:users-bounces@conserver.com]
On Behalf Of Bryan Stansell
Sent: Monday, September 19, 2005 3:17 PM
To: users@conserver.com
Subject: Re: Permissions problems with conserver 8.11

On Mon, Sep 19, 2005 at 02:30:44PM -0700, Phillip Pacheco wrote:
> I am afraid I don't know what you mean about access.c entries showing
> up.  Where will they show up?  Should I run conserver in daemon mode,
> try to connect with console, then run conserver -D a second time?  I
> tried just that, and found no access.c entries.

you just run it in daemon mode, connect with the client, and you should
see access attempts.  if not, something "bad" is happening and the
client isn't talking to the server (which below seems to confirm).

> {unixlab2}/usr/local/etc> console -D -D -D unixlab2
> console: DEBUG: [console.c:465] GetPort: hostname=XXXXX.genesyslab.com
> (console), ip=199.XX.XXX.XXX, port=782 

ah...right.  i steered you wrong.  it was -D, not -v that was needed.
good catch.  ;-)

> This confirms my initial fears:  We have an extensive pre-existing
> conserver network in our production environment using 7.1.3.  unixlab2
> is not mentioned anywhere in the config of the production network, yet
> somehow it attempts to reference one of the other conserver servers.

if you run 'console -V', you'll see the default server the client tries
to connect to (the master).  that's probably pointing at your production
system.  if you run 'console -M <host> [other options]' you can override
that and point at your test system.  so, probably 'console -M unixlab2
unixlab2' would be a good start.

> This raises new questions:
> 1.  Can I integrate an 8.1.1 server with the pre-existing 7.1.3
> (eventually we will upgrade the whole network)

as long as the 8.x.x client is used to talk to an 8.x.x server and a
7.x.x client is talking to a 7.x.x server, yes.  there are client/server
protocol issues between various revisions which the INSTALL file in the
distribution points out.

> 2.  How can I separate this test environment from the production
> environment?

basically by using the -M flag on the client.  you've already contained
the server (it knows about two consoles, and it manages them) and with
-M, you contain the client.

i hope this helps clear things up for folks (at least a bit), gives
people a view into how things work, and answers the important questions.

users mailing list