[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]
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 Genesys -----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 network? > (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. Bryan _______________________________________________ users mailing list users@conserver.com https://www.conserver.com/mailman/listinfo/users