From shal_halka@hotmail.com Fri Jan 4 05:37:16 2002 From: shal_halka@hotmail.com (Shal Halka) Date: Fri, 04 Jan 2002 16:37:16 +1100 Subject: Initial installation and configuration Message-ID: Hi, I'm experiencing difficulties in getting Conserver working after the initial installation. I am able to start the conserver daemon, however when I connect using 'console -a serverA', I don't get the serverA's console login. No output appears, other than the ^Ec escape sequence. 'console -u' shows that the port is up, but the communication is still a problem. I've installed a Cyclom Y RISC-Based Multiport Serial Board (16 port, db25 pin) to a standalone p.c running Linux Redhat 7.0 kernel 2.2.16-22 i686. The software provided with the board successfully tested its installation. I then extracted the tarball, and ran the following commands for installation: # ./configure --prefix=/usr/local/conserver \ --with-cffile=/usr/local/conserver/etc/conserver.cf \ --pwdfile=/usr/local/conserver/etc/conserver.passwd # make # make install --- My conserver.cf file contains the following information: LOGDIR=/var/log serverA:/dev/ttyC0:9600:&:15m %% allowed: 127.0.0.1 serverA --- My conserver.passwd file contains: root:*passwd*:any shal:*passwd*:any --- I read elsewhere that mingetty doesn't suffice for serial lines so I installed a mgetty rpm, however it hasn't resolved my problem. My /etc/inittab file is the generic installation file, with this entry for mgetty: s2:12345:respawn:/sbin/mgetty -r -s 9600 /dev/ttyC0 --- I'm a new user, so I'm not sure what else needs to be considered when configuring the setup. The Linux PC's only purpose is to act at the console access server, it's not networked. The intention is to attach the serial consoles of several Sun servers to the serial board. If more information is required, please advise so I can provide these. Any assistance is very much appreciated. Thanks, Shal Halka Unix Systems Administrator _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From shal_halka@hotmail.com Fri Jan 4 06:09:55 2002 From: shal_halka@hotmail.com (Shal Halka) Date: Fri, 04 Jan 2002 17:09:55 +1100 Subject: Initial installation and configuration Message-ID: My apologies, emailing problems, sending again just incase :) From: "Shal Halka" To: users@conserver.com Subject: Initial installation and configuration Date: Fri, 04 Jan 2002 16:37:16 +1100 Hi, I'm experiencing difficulties in getting Conserver working after the initial installation. I am able to start the conserver daemon, however when I connect using 'console -a serverA', I don't get the serverA's console login. No output appears, other than the ^Ec escape sequence. 'console -u' shows that the port is up, but the communication is still a problem. I've installed a Cyclom Y RISC-Based Multiport Serial Board (16 port, db25 pin) to a standalone p.c running Linux Redhat 7.0 kernel 2.2.16-22 i686. The software provided with the board successfully tested its installation. I then extracted the tarball, and ran the following commands for installation: # ./configure --prefix=/usr/local/conserver \ --with-cffile=/usr/local/conserver/etc/conserver.cf \ --pwdfile=/usr/local/conserver/etc/conserver.passwd # make # make install --- My conserver.cf file contains the following information: LOGDIR=/var/log serverA:/dev/ttyC0:9600:&:15m %% allowed: 127.0.0.1 serverA --- My conserver.passwd file contains: root:*passwd*:any shal:*passwd*:any --- I read elsewhere that mingetty doesn't suffice for serial lines so I installed a mgetty rpm, however it hasn't resolved my problem. My /etc/inittab file is the generic installation file, with this entry for mgetty: s2:12345:respawn:/sbin/mgetty -r -s 9600 /dev/ttyC0 --- I'm a new user, so I'm not sure what else needs to be considered when configuring the setup. The Linux PC's only purpose is to act at the console access server, it's not networked. The intention is to attach the serial consoles of several Sun servers to the serial board. If more information is required, please advise so I can provide these. Any assistance is very much appreciated. Thanks, Shal Halka Unix Systems Administrator _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ users mailing list users@conserver.com https://www.conserver.com/mailman/listinfo/users _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From kaming@team.outblaze.com Fri Jan 4 06:16:30 2002 From: kaming@team.outblaze.com (Kaming) Date: 04 Jan 2002 14:16:30 +0800 Subject: Initial installation and configuration In-Reply-To: References: Message-ID: <1010124991.3160.27.camel@kaming.portal2.com> Hi, May be you can try to install getty instead of mgetty. It is not the standard package in linux 7.0, you may need to download it from rpmfind.net. I can connect to the serial console successfully by using getty. Of course, you need to replace mgetty with getty in inittab. Thanks. Kaming. On Fri, 2002-01-04 at 13:37, Shal Halka wrote: > Hi, > > I'm experiencing difficulties in getting Conserver working after the initial > installation. I am able to start the conserver daemon, however when I > connect using 'console -a serverA', I don't get the serverA's console login. > No output appears, other than the ^Ec escape sequence. 'console -u' shows > that the port is up, but the communication is still a problem. > > I've installed a Cyclom Y RISC-Based Multiport Serial Board (16 port, db25 > pin) to a standalone p.c running Linux Redhat 7.0 kernel 2.2.16-22 i686. The > software provided with the board successfully tested its installation. I > then extracted the tarball, and ran the following commands for installation: > > # ./configure --prefix=/usr/local/conserver \ > --with-cffile=/usr/local/conserver/etc/conserver.cf \ > --pwdfile=/usr/local/conserver/etc/conserver.passwd > > # make > # make install > > --- > > My conserver.cf file contains the following information: > > LOGDIR=/var/log > serverA:/dev/ttyC0:9600:&:15m > %% > allowed: 127.0.0.1 serverA > > --- > > My conserver.passwd file contains: > > root:*passwd*:any > shal:*passwd*:any > > --- > > I read elsewhere that mingetty doesn't suffice for serial lines so I > installed a mgetty rpm, however it hasn't resolved my problem. My > /etc/inittab file is the generic installation file, with this entry for > mgetty: > > s2:12345:respawn:/sbin/mgetty -r -s 9600 /dev/ttyC0 > > --- > > I'm a new user, so I'm not sure what else needs to be considered when > configuring the setup. The Linux PC's only purpose is to act at the console > access server, it's not networked. The intention is to attach the serial > consoles of several Sun servers to the serial board. If more information is > required, please advise so I can provide these. Any assistance is very much > appreciated. > > Thanks, > Shal Halka > Unix Systems Administrator > > > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users > From bryan@conserver.com Fri Jan 4 11:34:05 2002 From: bryan@conserver.com (Bryan Stansell) Date: Fri, 4 Jan 2002 03:34:05 -0800 Subject: Initial installation and configuration In-Reply-To: <1010124991.3160.27.camel@kaming.portal2.com>; from kaming@team.outblaze.com on Fri, Jan 04, 2002 at 02:16:30PM +0800 References: <1010124991.3160.27.camel@kaming.portal2.com> Message-ID: <20020104033405.B25044@underdog.stansell.org> Hi Shal, Sounds like things are working ok on the conserver side (well, as far as can be seen). I suggest you use another tool (like minicom) to connect to your serial port and see if you get a login prompt. You may even want to connect a laptop or some other device to the serial port instead of using the linux box. Basically, start working from a "is the host working" question to a "is the serial card working" question to a "is conserver working" question (keep adding the layers). That will help determine if it's a mgetty/getty problem, serial card problem, or conserver problem. If you can see the console using something like minicom and still have problems with conserver, let us know. Hope that helps - a bit, at least. Bryan From zonker@certaintysolutions.com Fri Jan 4 20:41:17 2002 From: zonker@certaintysolutions.com (David Harris) Date: Fri, 4 Jan 2002 12:41:17 -0800 Subject: Initial installation and configuration In-Reply-To: ; from shal_halka@hotmail.com on Fri, Jan 04, 2002 at 05:09:55PM +1100 References: Message-ID: <20020104124117.A19481@tweety.main.gnac.com> Another basic question...are you sure that your serial ports are correctly configured? (Have you used TIP to communicate with the attached host before starting Conserver? Or, with conserver running, if you reset the host, do you see console messages during the boot cycle? (Heck, even with the host running, if you telnet to the host and then SU to root, you should see a "su to root succeeded..." message on the serial console.) In short, you should be sure that the serial connection is working (data leads correctly connected, and port speeds set to match) before spending a lot of time hackiong with Conserver setting. :-) There are some basic serial clues on my Minor Scroll of Serial Knowledge, if you'd care to check there; http://www.conserver.com/consoles/msock.html Regards, -Z- http://www.conserver.com/consoles/breakinfo.html From han@zk3.dec.com Tue Jan 15 13:01:25 2002 From: han@zk3.dec.com (Han Pilmeyer) Date: Tue, 15 Jan 2002 14:01:25 +0100 Subject: Problems with conserver "pid" and "quit" commands Message-ID: Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Hi, I found three problems with conserver. 1) "console -P" displays in incorrect PID. The attached patch fixes this. 2) "console -q" doesn't stop conserver when you're on a "trusted connection". When you're authenticated it does work. The attached PID uses for "trusted" the same call as for "authenticated". 3) When you give the "console -q" command and you're on a "trusted connection", console will ask for the "root" password. However conserver never verifies this password and accepts anything. I'm not sure what would be the appropriate way to fix this. In fact when you are running as root and trusted it would be nice if console wouldn't ask for a password at all, so that it is easier to use "console -q" from a script. What do others think? The attached patch fixes problem 1 and 2 (based on the 7.1.4-beta, which works fine by the way). Can someone apply these to the source? Cheers. -- -- Han Pilmeyer, email: han@uto.dec.com -- Compaq Tru64 UNIX engineering / Customer Care Consulting Group -- Answers are the easy part, questions raise the doubt -JB --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=master.c_diff Content-Description: master.c 7.1.4-beta patch *** master.c Tue Jan 15 13:12:28 2002 --- master.c.org Wed Oct 10 20:53:21 2001 *************** *** 437,443 **** if ('t' == cType) { fileWrite(csocket, "trusted -- terminated\r\n", -1); ! kill(parentpid, SIGTERM); } else if ((char *)0 == pcArgs) { fileWrite(csocket, "must be trusted to terminate\r\n", -1); } else if ((struct passwd *)0 == (pwd = getpwuid(0))) { --- 437,443 ---- if ('t' == cType) { fileWrite(csocket, "trusted -- terminated\r\n", -1); ! fSawQuit = 1; } else if ((char *)0 == pcArgs) { fileWrite(csocket, "must be trusted to terminate\r\n", -1); } else if ((struct passwd *)0 == (pwd = getpwuid(0))) { *************** *** 452,458 **** exit(EX_OK); } if (0 == strcmp(acIn, "pid")) { ! sprintf(acOut, "%d\r\n", parentpid); (void)fileWrite(csocket, acOut, -1); (void)fileClose(csocket); exit(EX_OK); --- 452,458 ---- exit(EX_OK); } if (0 == strcmp(acIn, "pid")) { ! sprintf(acOut, "%d\r\n", (int)getpid()); (void)fileWrite(csocket, acOut, -1); (void)fileClose(csocket); exit(EX_OK); --=-=-=-- From users@conserver.com Tue Jan 15 18:55:52 2002 From: users@conserver.com (Greg A. Woods) Date: Tue, 15 Jan 2002 13:55:52 -0500 (EST) Subject: non-tty use of "console" client. Message-ID: <20020115185552.A1018B5@proven.weird.com> I've recently been trying to solve a dilema with conserver, my terminal server, my BEST UPS's, Cricket, and nut-ups. Ideally I'd like conserver to be in control of the UPS consoles via the terminal server, but in order to use both Cricket and nut-ups with them I need some way to send periodic commands to the UPS from cron. (nut-ups and cricket can both be taught to watch the log file) I thought, oh, this should be easy, I'll just "echo f | console -f ups" using a user-ID that doesn't require a password and be done with it. Unfortunately when I tried that the conserver daemon came crashing down claiming to have suffered an unexpected SIGPIPE. This was not a pleasant experience since it was my main production conserver! :-( I took a brief look through the code to try and understand the signal handling mechanisms, but quickly realised that I'd need a lot more time to understand what was going on, let alone how to fix the problem. I suppose I could try to write a custom "console" client too, but that also seemed like it would take some time I don't seem to have. Ideally I'd like to also have "console" show the resulting output on stdout, say up to the next prompt (it would send a or whatever is specified to determine what the prompt string is), or for some specified number of lines, or up to the end of some specified regular expression, etc. Has anyone else thought of this, or have any suggestions? -- Greg A. Woods +1 416 218-0098; ; ; Planix, Inc. ; VE3TCP; Secrets of the Weird From bryan@conserver.com Thu Jan 17 08:16:15 2002 From: bryan@conserver.com (Bryan Stansell) Date: Thu, 17 Jan 2002 00:16:15 -0800 Subject: Problems with conserver "pid" and "quit" commands In-Reply-To: ; from han@zk3.dec.com on Tue, Jan 15, 2002 at 02:01:25PM +0100 References: Message-ID: <20020117001615.J29365@underdog.stansell.org> On Tue, Jan 15, 2002 at 02:01:25PM +0100, Han Pilmeyer wrote: > Hi, > > I found three problems with conserver. > 1) "console -P" displays in incorrect PID. The attached patch fixes > this. > 2) "console -q" doesn't stop conserver when you're on a "trusted > connection". When you're authenticated it does work. The attached > PID uses for "trusted" the same call as for "authenticated". how embarrassing. i've integrated the patches for these above. they'll be in the next release (7.1.4). > 3) When you give the "console -q" command and you're on a "trusted > connection", console will ask for the "root" password. However > conserver never verifies this password and accepts anything. I'm > not sure what would be the appropriate way to fix this. In fact > when you are running as root and trusted it would be nice if > console wouldn't ask for a password at all, so that it is easier to > use "console -q" from a script. What do others think? this one is kinda tricky. in the simple case, there would be one conserver host and when you asked it to shut down it would prompt for a password only if necessary. the difficulty case is when you have multiple conserver hosts in a distributed setup. if you put the burden on the server to ask for a password (and you weren't coming in from a trusted host) you'd get N password prompts. with the current code, you only get asked once. but, that too could be an issue...if your conserver hosts have different root passwords, only those with the same password would shut down. so, what's the right answer? i'm not sure. i was thinking that a '-n' (picking a random letter) flag or something on the client side might be useful. if you run with '-n', no password queries are done - it just uses an empty string. that way, you could do a 'console -q -n' and it wouldn't hang waiting for input. in a similar way, connecting to a console via 'console -n ' would assume an empty password (if it needed one). hmmm...maybe '-E' for "empty password". any opinions out there? Bryan From bryan@conserver.com Thu Jan 17 08:37:46 2002 From: bryan@conserver.com (Bryan Stansell) Date: Thu, 17 Jan 2002 00:37:46 -0800 Subject: non-tty use of "console" client. In-Reply-To: <20020115185552.A1018B5@proven.weird.com>; from woods@weird.com on Tue, Jan 15, 2002 at 01:55:52PM -0500 References: <20020115185552.A1018B5@proven.weird.com> Message-ID: <20020117003746.K29365@underdog.stansell.org> On Tue, Jan 15, 2002 at 01:55:52PM -0500, Greg A. Woods wrote: > I thought, oh, this should be easy, I'll just "echo f | console -f ups" > using a user-ID that doesn't require a password and be done with it. > > Unfortunately when I tried that the conserver daemon came crashing down > claiming to have suffered an unexpected SIGPIPE. This was not a > pleasant experience since it was my main production conserver! :-( hmm...i just tried that myself (well, 'echo ls | console -f foo4') and it didn't crash (using conserver-7.1.4-beta). the client didn't see the output of ls, but the logfile has it. what version of conserver and what type of host are you using (solaris 7, myself)? > Ideally I'd like to also have "console" show the resulting output on > stdout, say up to the next prompt (it would send a or whatever is > specified to determine what the prompt string is), or for some specified > number of lines, or up to the end of some specified regular expression, > etc. > > Has anyone else thought of this, or have any suggestions? well, assuming we can get the thing from crashing with a SIGPIPE, you could do something like: (echo 'ls'; sleep 5) | console -f ups as long as you don't close stdin of the client you'll be able to see the output (worked for me, anyway). using this as a base, you could write a wrapper that fed data to the console client and read it's output. as long as you kept the feed open and only closed it once you saw the regexp or CR or whatever coming out the other end, you should be able to do just about anything. heck, you could even do a whole expect-like thing and feed more commands based on the output and such. in theory, the perl IPC::Open2 module should provide at least one method of doing this (or the Expect module, or...). Bryan From kjell.andresen@usit.uio.no Fri Jan 18 14:19:09 2002 From: kjell.andresen@usit.uio.no (Kjell Andresen) Date: Fri, 18 Jan 2002 15:19:09 +0100 (CET) Subject: Need to set 38400-8-n-1-xon i conserver.cf In-Reply-To: <200201181407.g0IE7220027714@underdog.stansell.org> Message-ID: Hello! I've been using this excellent program for quite some time, but is all new to this list (unfortunately). I'd like to connect a Nexsan raid-shelf to my conserver, but I do not succeed. Having read http://www.conserver.com/FAQ #7 doesn't help me through. The shelves is easilly connected to a laptop with 38400-8-n-1-xon. I'm afraid I have to check my DB9->rj45 connector (I use EasyConnection XP Panel you see) - but it would be easier to do one thing at a time! These two does not work: tera:/dev/ttyE8:38400:/konsollserver/var/consoles/tera.log: teraplan:/dev/ttyE9:38400p:&: Are you able to help me, please? Regards, Kjell Andresen Systems administrator, University of Oslo, Norway Center for Information Technology Services and Department of Geophysics From zonker@certaintysolutions.com Fri Jan 18 15:53:43 2002 From: zonker@certaintysolutions.com (David Harris) Date: Fri, 18 Jan 2002 07:53:43 -0800 Subject: Need to set 38400-8-n-1-xon i conserver.cf In-Reply-To: ; from kjell.andresen@usit.uio.no on Fri, Jan 18, 2002 at 03:19:09PM +0100 References: <200201181407.g0IE7220027714@underdog.stansell.org> Message-ID: <20020118075343.A12363@tweety.main.gnac.com> Good questions...in return, I have a question for you. ;-) If conserver is not running, can you use TIP or other utility to talk to the host when connected to those ports? (Are you sure the physical connection is correct between the serial port and the console? Some clues about basic serial connection are at http://www.conserver.com/sonsoles/msock.html) Once we rule out serial connection problems, we can look for any issues between conserver and the serial card. :-) -Z- From bryan@conserver.com Mon Jan 21 11:11:32 2002 From: bryan@conserver.com (Bryan Stansell) Date: Mon, 21 Jan 2002 03:11:32 -0800 Subject: conserver 7.1.4 is available Message-ID: <20020121031132.A15438@underdog.stansell.org> It took a while longer than expected to get 7.1.4 together. This was *almost* going to be a release based fully on patches submitted by the user base - something that I thought was very cool. But then I started adding some new features as well (based on suggestions from some of you). Hopefully you think it was worth the wait. The man pages have been updated to explain the new options and config file syntax. Patches for man pages to add details or explain things clearly are always welcome! :-) version 7.1.4 (Jan 21, 2002): - console -[PqQ] didn't work - patch by Han Pilmeyer - maxfiles() didn't check FD_SETSIZE - patch by Justin Grudzien - New -o and -O server flags for automatically reconnecting downed consoles - patch by Benn Oshrin - Automatic reconnection of consoles on read failures, retried every minute - Up to nine break sequences can be defined in the configuration file and assigned to consoles individually, accessed via new ^ecl[?0-9] escape sequences - console logs are marked with "up" and "down" timestamps The following based on code by John R. Jackson - sequential timestamps merged into one range during playback - timestamps done on "nice" boundaries (hour, minute, etc.) - lots of code cleanup, optimizations, etc. Bryan Stansell From kkayast@abcv.com Tue Jan 22 21:03:20 2002 From: kkayast@abcv.com (Kailash Kayastha) Date: Tue, 22 Jan 2002 15:03:20 -0600 Subject: what hardwares does conserver support? Message-ID: Hello: What is the best, cheapest hardware that is compatible with the conserver? Thanks, Kailash From jimmy@nccom.com Tue Jan 22 21:21:29 2002 From: jimmy@nccom.com (Jim Gottlieb) Date: Tue, 22 Jan 2002 13:21:29 -0800 Subject: what hardware does conserver support? In-Reply-To: References: Message-ID: <20020122212129.GC5312@nccom.com> On 2002-01-22 at 15:03, Kailash Kayastha (kkayast@abcv.com) wrote: > What is the best, cheapest hardware that is compatible with the conserver? You don't say how many ports you need. If it's anywhere from 5 up to 30, I'd highly recommend a used Portmaster 2 or 2e. See http://portmasters.com/ You can get a 10-port box for $200 and a 30-port for $350. And they work fine with Sun machines as they don't send spurious BREAK signals. From zonker@certaintysolutions.com Tue Jan 22 23:51:21 2002 From: zonker@certaintysolutions.com (David Harris) Date: Tue, 22 Jan 2002 15:51:21 -0800 Subject: what hardwares does conserver support? In-Reply-To: ; from kkayast@abcv.com on Tue, Jan 22, 2002 at 03:03:20PM -0600 References: Message-ID: <20020122155121.A1923@tweety.main.gnac.com> On Tue, Jan 22, 2002 at 03:03:20PM -0600, Kailash Kayastha wrote: > Hello: > > What is the best, cheapest hardware that is compatible with the conserver? Well, how about a partial answer? :-) I've tested a bunch of terminal/console server devices with Conserver. We've been making an effort to identify those devices which will only send BREAK when you want to send it, and not any other time. (This is important in Sun environments using the serial console for remote console access...) However, you can see what we've found about a number of different console servers on the page http://www.conserver.com/consoles/breakinfo.html Of course, you can also use on-board multi-port cards as well with Conserver, but I haven't done extensive testing with those. Perhaps others on the list can offer their own experiences with various vendors and models. :-) -Z- http://www.conserver.com/consoles/ From doug@gblx.net Tue Jan 22 23:59:10 2002 From: doug@gblx.net (Doug Hughes) Date: Tue, 22 Jan 2002 16:59:10 -0700 (MST) Subject: what hardwares does conserver support? In-Reply-To: <20020122155121.A1923@tweety.main.gnac.com> Message-ID: On Tue, 22 Jan 2002, David Harris wrote: > On Tue, Jan 22, 2002 at 03:03:20PM -0600, Kailash Kayastha wrote: > > Hello: > > > > What is the best, cheapest hardware that is compatible with the conserver? > > Well, how about a partial answer? :-) > > I've tested a bunch of terminal/console server devices with > Conserver. We've been making an effort to identify those > devices which will only send BREAK when you want to send it, > and not any other time. (This is important in Sun environments > using the serial console for remote console access...) > > However, you can see what we've found about a number of > different console servers on the page > > http://www.conserver.com/consoles/breakinfo.html > > Of course, you can also use on-board multi-port cards as > well with Conserver, but I haven't done extensive testing > with those. Perhaps others on the list can offer their own > experiences with various vendors and models. :-) > I have heard anecdotal evidence that the GNP cards 'do the right thing'. I can say that the Aurora sbus cards do send a break to 'most' attached hosts 'most' of the time when the box experiences a power incident. (Generally, I use 4 strand phone cable for console runs as it saves a lot of space, running through the racks, is easier to trim to custom lengths, and for some reason, the capacitance in the parallel strands seems to be just enough to inhibit 'bad breaks' in some cases. It seems the longer the run the better, ironically. ;) Doug From iainr@dcs.ed.ac.uk Wed Jan 23 00:00:00 2002 From: iainr@dcs.ed.ac.uk (Iain Rae) Date: Wed, 23 Jan 2002 00:00:00 +0000 Subject: what hardwares does conserver support? References: <20020122155121.A1923@tweety.main.gnac.com> Message-ID: <3C4DFD00.7030303@dcs.ed.ac.uk> David Harris wrote: > On Tue, Jan 22, 2002 at 03:03:20PM -0600, Kailash Kayastha wrote: > >>Hello: >> >>What is the best, cheapest hardware that is compatible with the conserver? >> > > Well, how about a partial answer? :-) > > I've tested a bunch of terminal/console server devices with > Conserver. We've been making an effort to identify those > devices which will only send BREAK when you want to send it, > and not any other time. (This is important in Sun environments > using the serial console for remote console access...) > > However, you can see what we've found about a number of > different console servers on the page > > http://www.conserver.com/consoles/breakinfo.html > > Of course, you can also use on-board multi-port cards as > well with Conserver, but I haven't done extensive testing > with those. Perhaps others on the list can offer their own > experiences with various vendors and models. :-) We've used cyclades cards (Y series) for coming up on a year now without any problems. The SUN break stuff is a pain but we've been using the alternate break setting and not had any problems with that so far (touch wood). From user@conserver.com Wed Jan 23 04:05:30 2002 From: user@conserver.com (Greg A. Woods) Date: Tue, 22 Jan 2002 23:05:30 -0500 (EST) Subject: what hardwares does conserver support? In-Reply-To: <20020122155121.A1923@tweety.main.gnac.com> References: <20020122155121.A1923@tweety.main.gnac.com> Message-ID: <20020123040530.DAA73B7@proven.weird.com> [ On Tuesday, January 22, 2002 at 15:51:21 (-0800), David Harris wrote: ] > Subject: Re: what hardwares does conserver support? > > I've tested a bunch of terminal/console server devices with > Conserver. We've been making an effort to identify those > devices which will only send BREAK when you want to send it, > and not any other time. (This is important in Sun environments > using the serial console for remote console access...) You are fighting against the laws of physics. You cannot easily avoid having a server detect a break on its console serial port when the attached device is power cycled, at least not without making changes to the default circuitry on the host system side of things. Cables and connectors will inevitably interfere with your results except under "ideal conditions". > However, you can see what we've found about a number of > different console servers on the page > > http://www.conserver.com/consoles/breakinfo.html This is all very interesting, but potentially very misleading. Poor cables, or connectors, could influence the results, as will variations in the components used in the host system's console serial port, and even the jumper settings configuring the port. The only correct and certain solution is hinted to in the last part of this page: http://www.conserver.com/consoles/breaktest.html and also well described in detail on this mostly correct page: http://www.cisco.com/warp/public/770/fn-tsbreak.html The correct solution is to modify the console serial port on the host system such that the system itself will supply a data signal in the absense of a signal from the attached terminal or terminal server, while at the same time not preventing the terminal server from generating a real BREAK signal on demand. One way of doing this is to putting an approximately 4.7K Ohm resistor between pin 3 and pin 25 (which has -5v on most Sun systems) on the host end when connecting to a Sun SPARC host. This should have the effect of stifling any appearance of a BREAK signal when the console server machine is either disconnected or power cycled. However so long as the terminal server can still send data it should also still be able to send an intentional BREAK signal as well. (contrary to the incorrect information on the Cisco page -- obviously if the resistor held the Rx pin at the mark level permanently then no data could be sent at all to the port, and similarly if the terminal server can still toggle the line levels to send data signals then it can equally well hold the line at the space level for the requisite time to generate an intentional BREAK signal). The reason this isn't always reliable for everyone is because depending on the exact design of the host system's serial console port, the voltages may vary. This web page talks about some of the different Sun systems which have jumper options to switch the port from RS-232 (+/-12vdc signalling) to RS-423 (+/-5vdc signalling): http://www.stokely.com/unix.serial.port.resources/A-B-Ycablepinout.html For true RS-232 ports you might sometimes need to hold the Rx pin closer to -12vdc than -5vdc (while at the same time not preventing the terminal server from driving the line to +12vdc to send data or a real BREAK). I have in the past seen a more reliable circuit with a zener diode, but once you get the right values for your equipment all should work fine. The other solution is of course to just use a reliable enough terminal server and never power cycle it, and also of course never disconnect the console cable on a server that's in production (schedule downtime first!). On my home network I use a DECserver on a DEChub500 with redundant power supplies. :-) -- Greg A. Woods +1 416 218-0098; ; ; Planix, Inc. ; VE3TCP; Secrets of the Weird From doug@gblx.net Wed Jan 23 14:40:28 2002 From: doug@gblx.net (Doug Hughes) Date: Wed, 23 Jan 2002 07:40:28 -0700 (MST) Subject: what hardwares does conserver support? In-Reply-To: <20020123040530.DAA73B7@proven.weird.com> Message-ID: On Tue, 22 Jan 2002, Greg A. Woods wrote: > > The correct solution is to modify the console serial port on the host > system such that the system itself will supply a data signal in the > absense of a signal from the attached terminal or terminal server, while > at the same time not preventing the terminal server from generating a > real BREAK signal on demand. One way of doing this is to putting an > approximately 4.7K Ohm resistor between pin 3 and pin 25 (which has -5v > on most Sun systems) on the host end when connecting to a Sun SPARC > host. This should have the effect of stifling any appearance of a BREAK > signal when the console server machine is either disconnected or power > cycled. However so long as the terminal server can still send data it > should also still be able to send an intentional BREAK signal as well. > (contrary to the incorrect information on the Cisco page -- obviously if > the resistor held the Rx pin at the mark level permanently then no data > could be sent at all to the port, and similarly if the terminal server > can still toggle the line levels to send data signals then it can > equally well hold the line at the space level for the requisite time to > generate an intentional BREAK signal). > ... > > > The other solution is of course to just use a reliable enough terminal > server and never power cycle it, and also of course never disconnect the > console cable on a server that's in production (schedule downtime > first!). On my home network I use a DECserver on a DEChub500 with > redundant power supplies. :-) > I would swap these around. I would start with a good terminal server that doesn't send false breaks when power cycled. The cisco 36XX series is one such. You can power cycle the box all you want and it will not send a break during such an event. There are others popping up Perle - http://www.perle.com/products/prod_family/console_server/cs9000.html Digi, Lantronix, Xyplex (see evals: http://www.datacomideas.com/SunSafe.html) If I was going to buy one today (and my company wasn't strongly wedded to Cisco already), I'd get one of these: http://www.lantronix.com/products/cs/scs1600_3200/index.html. They have an optional module that is controlled by a cable from the console server that allows you to power cycle the host as well. Also see NuData's product, which you can plug into the serial port of a Sun to prevent erroneous breaks: http://www.nudata.com/pdf/CUS4324_Sellsheet.pdf I realise the point that Greg is trying to make, but, IMHO, one should try any/all of the above solutions long before taking the possibility warranty voiding and manual act of soldering components onto your serial port hardware. These vendor solutions have been evaluated by third parties and determined to work. PS - not since sparc1 days have I had any trouble disconnecting the serial cable from the Sun side of serial connection. No breaks. Doug From zonker@certaintysolutions.com Wed Jan 23 17:30:11 2002 From: zonker@certaintysolutions.com (David Harris) Date: Wed, 23 Jan 2002 09:30:11 -0800 Subject: Serial BREAK on console servers Message-ID: <20020123093011.A28585@tweety.main.gnac.com> Actually two very important points have been made here; 1) Lots of things can cause BREAK, even when there is nothing plugged into the console port! (And you may be able to build some protecting into the device itself by performing some electrical surgery on your devices serial port.) 2) In most cases (where Conserver is concerned) folks will have something plugged into the serial console all the time, so it would be better to use a device that doesn't send BREAK when the power to the device is removed, or even when the port is reset. (This reduces the chance thatyou will induce a BREAK when changing cables, etc.) I also appreciate that both writers took time to provide additional pointers, and to provide some explanations to help fill out their premises. :-) While I appreciate the input, I wanted to explain a couple of things that have driven my web pages; a) I've been hacking serial for a long while, and I've found a lot of trouble sources while working in all aspects of communications hardware design, repair, and support. While you *could* try to document it all, the audience of folks interested in reading it all would be pretty small. (The reason why you can't find many good, *complete* books on the topic is because the book publishers don't see a market.) b) Most folks searching the web for serial stuff are looking for specific, concise information. I've tried to make my pages fit that criteria. (And the feedback from readers has generally been positive. ;-) c) The vendors of console gear really haven't *used it* in the reverse-TCP mode...tested, yes, but they haven't really deployed it in their own shops, and used it for remotely accessing machines...as a result, they haven't seen some of the problems. With that said, most of the vendors *are* interested in feedback, and improving their products. (Note that I said *"most"*...) d) In most cases, fixing the BREAK-on-power-cycle problem *did* require a hardware redesign...but many vendors have made those changes, because they are hearing back from customers that "there is a problem", but many of those same customers couldn't explain *why* things were bad. (Hardware redesign takes time, and costs money. If the vendor is selling a product to a large market, it will benefit them to make a better product. If a vendor only serves a small market, or they have a lot of the 'bad' product in their inventory, it is harder to convince them to make the investment.) e) The BREAK problem really only affects older SUN boxes, and some SGI models...while it's a big market, it's only a *part* of the total market for this type of device. (If you only have one or two SUN boxes, it may be cheaper to use the NuData adapters (at $100 per port...), but if you have two dozen sun boxes to protect, it's going to be cheaper to get a console server that doen't send BREAK until you want it to. And this can be a dynamic equation, if you are small now, but considering growing in the next year or two. :-) I'm really glad for Celeste Stokley's pages. There is lot's of good information there, including the older, legacy stuff. For those searching for as much knowledge on a topic as they can find, knowing the legacy stuff is also important. (and I'm thrilled that she thinks my pages are useful enough to list there. :-) I don't mean to stifle a detailed discussion of RS-232 and EIA-232 standards and specifics (and normal deviations and etc.), but I don't know how many folks would want to read about it. (And I'm wondering if many others might consider it all just extra noise on the list.) I'm happy to continue the thread in the topic is because the book publishers don't see a market. email if folks want. Of course, post to the list whatever you feel is relavant for the list. :-) Regards, -Z- From users@conserver.com Wed Jan 23 20:37:29 2002 From: users@conserver.com (Greg A. Woods) Date: Wed, 23 Jan 2002 15:37:29 -0500 (EST) Subject: Serial BREAK on console servers In-Reply-To: <20020123093011.A28585@tweety.main.gnac.com> References: <20020123093011.A28585@tweety.main.gnac.com> Message-ID: <20020123203729.9C55CB7@proven.weird.com> [ On Wednesday, January 23, 2002 at 09:30:11 (-0800), David Harris wrote: ] > Subject: Serial BREAK on console servers > > Actually two very important points have been made here; > > 1) Lots of things can cause BREAK, even when there is nothing > plugged into the console port! (And you may be able to > build some protecting into the device itself by performing > some electrical surgery on your devices serial port.) You don't have to perform surgery on your host system console ports -- just construct a custom external connectors you plug into them. If you don't use RJ-45 adapters then you can always use a small connector block (DB-25-male/DB-25-female in the case of most Suns) with the custom wiring inside of it. > 2) In most cases (where Conserver is concerned) folks will > have something plugged into the serial console all the > time, so it would be better to use a device that doesn't > send BREAK when the power to the device is removed, > or even when the port is reset. You cannot always avoid having a BREAK seen by the host system when odd things happen to the console terminal (server). The problem sometimes arises in the cabling and connectors, or even in the signal receivers in the server itself and no amount of magic circuitry in the terminal (server) can do anything about it, especially when that circuitry is turned off or otherwise disconnected from its power source. > (This reduces the chance > thatyou will induce a BREAK when changing cables, etc.) Indeed, which is why I only recommend using a pull-down resistor in a connector at the host end. Furthermore if you ever want to disconnect the line from one of your host system's console ports then you may also want to avoid it seeing an indication of a BREAK signal, and that can only be done reliably if you have the pull-down resistor in a separate connector block (be it inside the RJ-45 adapter, or in a separate adapter block), firmly and properly attached to the host. Then no normal amount of capacitance or inductance in the console cable will be likely to cause an accidental BREAK indication. The only place you can relibably control the affects of an un-powered serial cable are at the end connected to the host system. Finally note that having prepared your hosts with proper custom console port connectors means you won't be surprised should you ever have to swap out your carefully chosen terminal server for one less desirable in the event of some catastrophic failure. This isn't rocket science or heavy-duty particle physics -- just some very simple wiring with a small portion of Ohm's law thrown in. :-) An ideal design for such a BREAK-protector would include opto-isolators and zener diodes and such, and perhaps that's what the expensive commercial NuData solution is (though I suspect it's still over-priced by twice). Indeed if I were marketing such a device I'd want it to work reliably even in adverse and abnormal conditions. However for most people a simple pull-down resistor will suffice, and anyone hooking up serial consoles should be capable enough to go to Radio Shack (or wherever), pick up the parts necessary, and assemble them. > e) The BREAK problem really only affects older SUN boxes, and > some SGI models... That's not quite true at all. Lots of BSD-based i386 servers also use the BREAK-to-kernel debugger mechanism. It's normally a very reliable way to control a console serial port. The software "solution" (so called) is far from ideal. Note that the EIA RS-232C specification requires that a floating input be interpreted as a mark (off) condition, but many systems, including the common IBM PC-style "COM" ports, use cheap signal receivers that cause their ports to violate this part of the specification, and that factor alone may mean that even disconnecting the cable from the host end might result in the host seeing a BREAK indication! Only the use of a pull-down resistor or other suitable circuit will avoid this problem. I don't know what level of EIA compliance common console ports on other types of machines might have, but I will note that if such ports have a hardware jumper or switch to select whether they are RS-232 or RS-423 should definitely be configured for RS-232 -- that alone may eliminate the unwanted BREAK problem. > while it's a big market, it's only a > *part* of the total market for this type of device. > (If you only have one or two SUN boxes, it may be cheaper > to use the NuData adapters (at $100 per port...), but > if you have two dozen sun boxes to protect, it's going > to be cheaper to get a console server that doen't send > BREAK until you want it to. And this can be a dynamic > equation, if you are small now, but considering growing > in the next year or two. :-) If you're already using RJ-45 adapters for your console ports then adding a pull-down resistor to each is a very small investment.... Anyone really paranoid about any kind of wiring might call B & B Electronics (www.bb-elec.com) and see if they might be able to provide a ready-made solution at a decent price. They do have a read-made RS-232 optical isolator in both DB-9 and DB-25 varieties, though they're not all that inexpensive. Many electronics suppliers, including B&B, also sell DB-to-DB jumber boxes ideal for constructing the necessary connector adapter. -- Greg A. Woods +1 416 218-0098; ; ; Planix, Inc. ; VE3TCP; Secrets of the Weird From bryan@stansell.org Tue Jan 29 19:09:09 2002 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g0U399j9019549; Tue, 29 Jan 2002 19:09:09 -0800 (PST) Received: (from bryan@localhost) by underdog.stansell.org (8.12.2/8.12.2/Submit) id g0U399FU019548; Tue, 29 Jan 2002 19:09:09 -0800 (PST) Date: Tue, 29 Jan 2002 19:09:09 -0800 From: Bryan Stansell To: users@conserver.com, announce@conserver.com Subject: conserver-7.2.0-beta1 available Message-ID: <20020129190908.B9719@underdog.stansell.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: In an effort to get more folks to test out some of the development code, I've set up a beta site for distributing pre-release code. http://www.conserver.com/beta/ The code has a little testing under it's belt (at a couple of sites), but it could use a whole lot more. If anyone feels inclined to help out by running the new code, that would be great. So, what's the difference between 7.1.4 and 7.2.0-beta1? Well, the list is below, but the important aspect is that static arrays (strings, internal structures, etc) are becoming dynamic. For instance, strings are no longer 'char str[BUFSIZ];' (or even better yet 'char server[32];' - yikes). Think there were checks everywhere for over-running arrays? Nahhhhh...'cause who would ever need a console name greater than 31 characters?...(have I scared you into trying the new code yet?). And the best part, instead of building conserver with a limited number of console "slots" (it's the old MAXMEMB x MAXGRP limit), it can now grow as long as there's enough memory. MAXMEMB (--with-maxmemb) is still used to limit the number of consoles per process. I believe I have the server code modified to be fully dynamic. The client code still needs a *LOT* of work. Hence the reason for bumping the version to 7.2.0 - everything is getting touched to make this happen (but it's a good thing, really!). version 7.2.0-beta1 (Jan 29, 2002): - static structures and strings are now dynamic in server - MAXGRP (--with-maxgrp) has been removed as it's now dynamic - new -m server option for setting the maximum consoles per process - the default is still set with --with-maxmemb - new -i client option (and ^Eci) that displays console information in a machine-parseable format - two debug levels (second level by using two -D options) - ANSI prototypes and definitions (when available) Bryan From AMorris@providence.org Thu Jan 31 10:24:52 2002 Received: from phsorcon02.phsor.org ([170.220.2.13]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g0VIOqj9025566 for ; Thu, 31 Jan 2002 10:24:52 -0800 (PST) Received: by phsorcon02.phsor.org with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 10:24:47 -0800 Message-ID: From: "Morris, Adam" To: "'users@conserver.com'" Subject: Compilation on HP-UX 11i using GCC 3.02 Date: Thu, 31 Jan 2002 10:24:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: Greetings, I'm currently trying to compile conserver on HP-UX 11i using GCC 3.02. So far I have found :- maxfiles() defined while maxfiles is defined as a constant on the system. I've renamed maxfiles() throughout conserver. TELCMD_OK(), TELCMD(), TELOPT_OK() and TELOPT() used but not defined. I've checked a Linux box and added the equivalents from /usr/include/arpa/telnet.h into a local conserver_telnet.h Differences in locations of the select definition (sys/select.h in conserver and sys/time.h on HP-UX) __builtin_va_start is an "unsatisfied symbol" in group.o. There are also minor differences to types of arguments to various network function calls (socklen_t * compared to int *)... These are only warnings though so we can probably ignore them. I'm currently working on fixing the __builtin_va_start problem, the rest have already been fixed. If I can get it compiled who should I send patches to? bryan@conserver.com? The patches are not likely to be guaranteed to test for hp-ux though, so they will not be perfect. Some of them (maxfiles -> conserver_maxfiles for example) shouldn't be a problem on other systems. Any suggestions/comments from anyone? Thanks, Adam Ignore this signature, the company adds it later... :-( **************************************************************************** This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. From zonker@certaintysolutions.com Thu Jan 31 12:40:02 2002 Received: from yosemite.rwc.gnac.net (yosemite.rwc.gnac.net [198.151.248.221]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g0VKe2j9026735 for ; Thu, 31 Jan 2002 12:40:02 -0800 (PST) Received: by yosemite.rwc.gnac.net; id MAA19649; Thu, 31 Jan 2002 12:40:02 -0800 (PST) Received: from unknown(192.168.1.21) by yosemite.rwc.gnac.net via smap (V5.0) id xma019509; Thu, 31 Jan 02 12:39:48 -0800 Received: from tweety.main.gnac.com (localhost.main.gnac.com [127.0.0.1]) by pepe.corp.gnac.com (8.11.0/8.8.7/GNAC-GW-2.1) with ESMTP id g0VKdgv02521; Thu, 31 Jan 2002 12:39:42 -0800 (PST) Received: (from zonker@localhost) by tweety.main.gnac.com (8.9.3/8.7.3/GNAC-COM-1.1) id MAA01371; Thu, 31 Jan 2002 12:39:47 -0800 (PST) Date: Thu, 31 Jan 2002 12:39:47 -0800 From: David Harris To: "Morris, Adam" , users@conserver.com Subject: Re: Compilation on HP-UX 11i using GCC 3.02 Message-ID: <20020131123947.A3115@tweety.main.gnac.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from AMorris@providence.org on Thu, Jan 31, 2002 at 10:24:24AM -0800 Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: Thanks for the informative message! Since the mailing list is archived, I'm sure it will help someone else trying to compile for HP-UX... :-) Bryan is the correct address for the patch info. :-) If you haven't checked into the BETA version info, you may want to...that variable conflict may be resolved as part of the changes to make Conserver a bit more dynamic. http://www.conserver.vom/beta/ Regards, -Z- http://www.conserver.com/consoles/ From AMorris@providence.org Thu Jan 31 12:49:57 2002 Received: from phsorcon02.phsor.org ([170.220.2.13]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g0VKnuj9026868 for ; Thu, 31 Jan 2002 12:49:56 -0800 (PST) Received: by phsorcon02.phsor.org with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 12:49:51 -0800 Message-ID: From: "Morris, Adam" To: users@conserver.com Subject: RE: Compilation on HP-UX 11i using GCC 3.02 Date: Thu, 31 Jan 2002 12:49:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: Well, I've got 7.1.4 compiling (no indication yet if it will work, but hopefully later today... ) I'll try the beta as well just to make sure that there are no other issues. Some of these problems are a PITA... :-) Adam -----Original Message----- From: David Harris [mailto:zonker@certaintysolutions.com] Sent: Thursday, January 31, 2002 12:40 PM To: Morris, Adam; users@conserver.com Subject: Re: Compilation on HP-UX 11i using GCC 3.02 Thanks for the informative message! Since the mailing list is archived, I'm sure it will help someone else trying to compile for HP-UX... :-) Bryan is the correct address for the patch info. :-) If you haven't checked into the BETA version info, you may want to...that variable conflict may be resolved as part of the changes to make Conserver a bit more dynamic. http://www.conserver.vom/beta/ Regards, -Z- http://www.conserver.com/consoles/ **************************************************************************** This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete the message. Thank you very much. From bryan@stansell.org Thu Jan 31 14:00:50 2002 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g0VM0oj9027482 for ; Thu, 31 Jan 2002 14:00:50 -0800 (PST) Received: (from bryan@localhost) by underdog.stansell.org (8.12.2/8.12.2/Submit) id g0VM0oU5027481 for users@conserver.com; Thu, 31 Jan 2002 14:00:50 -0800 (PST) Date: Thu, 31 Jan 2002 14:00:50 -0800 From: Bryan Stansell To: users@conserver.com Subject: Re: Compilation on HP-UX 11i using GCC 3.02 Message-ID: <20020131140050.N9719@underdog.stansell.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from AMorris@providence.org on Thu, Jan 31, 2002 at 12:49:28PM -0800 Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: On Thu, Jan 31, 2002 at 12:49:28PM -0800, Morris, Adam wrote: > Well, I've got 7.1.4 compiling (no indication yet if it will work, but > hopefully later today... ) I'll try the beta as well just to make sure that > there are no other issues. Some of these problems are a PITA... :-) > > Adam The beta will have the same issues as 7.1.4 (no portability/compatability changes). I'd be very interested in seeing the output of the configure command - as well as a make. And, of course, patches are always good. :-) The code (well, 7.1.0 or thereabouts) was known to build under HP-UX 10.20 with gcc. Sounds like either HP changed a bunch of stuff in 11 or maybe the gcc install isn't quite the same. Either way, it could be great to be able to get this to work. Bryan