From woods@proven.weird.com Wed May 1 20:57:21 2002 Received: from most.weird.com (IDENT:7ZsXxngzn8+NAqLW474h7hihQYRkyQNh6hEANng3HW7V8Ol7dz2Oln9Lo4totAgUWQmHU3Ys+Yc@mail.weird.com [204.92.254.2]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g423vK2S002531 for ; Wed, 1 May 2002 20:57:21 -0700 (PDT) Received: from proven.weird.com([204.92.254.15]) (4624 bytes) by most.weird.com via smail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident <[6ZGryAIG3YwPPwJFcch8COBr8qc2UCu9o99SDIbT2tJUUhDixJEnCSkoTkPvuCs9oogOJ1pb4+A5Y3Pd23dOpg==]> using rfc1413) id for ; Wed, 1 May 2002 23:57:17 -0400 (EDT) (Smail-3.2.0.115-Pre 2001-Aug-6 #2 built 2002-Apr-22) Received: by proven.weird.com (Postfix, from userid 1000) id 212EDAC; Wed, 1 May 2002 23:57:12 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: ;j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz;@-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= References: <20020425014019.398AEAC@proven.weird.com> <200204250646.XAA09745@tweety.main.gnac.com> X-Mailer: VM 7.03 under Emacs 21.2.1 Reply-To: users@conserver.com (ConServer Users Mailing List) Organization: Planix, Inc.; Toronto, Ontario; Canada Message-Id: <20020502035712.212EDAC@proven.weird.com> Date: Wed, 1 May 2002 23:57:12 -0400 (EDT) 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 Wednesday, April 24, 2002 at 23:46:06 (-0700), Dave Stuit wrote: ] > Subject: Re: proposal for remote console specs using the console name, not device name > > On 24 Apr 02 18:41 PDT, Greg A. Woods wrote: > > > > I'd like to propose that remote console specifications (the "@conserver" > > form) should be preceded by the remote conserver's name for the console, > > not it's device name. [and until the next major release both could be > > permitted, with a warning logged for deprecated usage....] > > I can see how that would make things easier for multiple conserver hosts > with separately maintained cf files (although i'm not sure when it would > be desirable for different conservers to refer to a console by different > names ... seems like that would be confusing). My assumption, based on my reading of the documentation and from the various sample configurations, was that the device name was the key used to select the "console" on the remote conserver host. I probably do want to have the same console name, and I don't think I really meant to suggest that different conserver hosts would refer to the same "console" by different names. I just didn't want to have to distribute the device names -- I want the freedom to change them without having to change the console.cf on the master conserver host. I've since come to understand the code a bit better and I've done some more experiments and I've found that indeed the device name is ignored and can be omitted (as can the baud rate): callerid:@very::&: This has much the same effect as I was trying to achieve through my proposal in the first place -- I apologise to all for not trying it before! :-) (my next post will be about why it's now a _lot_ easier for me to try such things on a whim! :-) > However, i know of at least a few sites where a single cf file is > maintained centrally and distributed to all conserver hosts (and we like > it that way :) ). Also, if one of the hosts dies, it's especially easy > to have another one take over if all of the device and port information > is present in everyone's cf file (assuming the devices are terminal > servers that are accessible from the other conserver hosts). In almost all situations I currently envision using conserver its primary reason is for logging -- where possible I always use terminal servers for the actual serial ports, so universal access from any workstation via the 'console' client program is only required because of my use of conserver. I'm only using multiple hosts on my home network and that's only because I don't have the necessary power supply to be able to put a small 8-port termserver in my office! ;-) In the scenarios I manage if the conserver host dies then I just telnet directly to the terminal server, just as I did before using conserver. :-) Unless the conserver host outage is extended I wouldn't want to take over console logging on some other host as dis-joint and distributed console logs are probably not any more useful than no logs at all, especially given that I only really need logging for capturing the cause of hopefully far more rare system crashes. -- Greg A. Woods +1 416 218-0098; ; ; Planix, Inc. ; VE3TCP; Secrets of the Weird From corr0823@yahoo.com Fri May 3 06:09:57 2002 Received: from web20404.mail.yahoo.com (web20404.mail.yahoo.com [216.136.226.123]) by underdog.stansell.org (8.12.2/8.12.2) with SMTP id g43D9v2S024585 for ; Fri, 3 May 2002 06:09:57 -0700 (PDT) Message-ID: <20020503130956.42692.qmail@web20404.mail.yahoo.com> Received: from [65.199.229.162] by web20404.mail.yahoo.com via HTTP; Fri, 03 May 2002 06:09:56 PDT Date: Fri, 3 May 2002 06:09:56 -0700 (PDT) From: Jim Corrigan Subject: Fwd: Why not down load CLIM, it does all of what you are doing and more To: users@conserver.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-2095219833-1020431396=:34408" 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: --0-2095219833-1020431396=:34408 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com --0-2095219833-1020431396=:34408 Content-Type: message/rfc822 X-Apparently-To: corr0823@yahoo.com via web20402.mail.yahoo.com; 02 May 2002 04:28:57 -0700 (PDT) X-Track: 1: 40 Return-Path: Received: from 65.199.229.162 (HELO interlock.KiNETWORKS.com) (65.199.229.162) by mta613.mail.yahoo.com with SMTP; 02 May 2002 04:28:56 -0700 (PDT) Received: from fileserver.rtp.KiNETWORKS.com by interlock.KiNETWORKS.com via smtpd (for mta-v12.level3.mail.yahoo.com [64.157.4.82]) with SMTP; 2 May 2002 11:28:56 UT Received: from e5a.rtp.KiNETWORKS.com (e5a.rtp.KiNETWORKS.com [172.16.16.8]) by KiNETWORKS.com (8.11.2/8.11.1) with ESMTP id g42BStk25784 for ; Thu, 2 May 2002 07:28:55 -0400 (EDT) Received: from e5a (e5a [172.16.16.8]) by e5a.rtp.KiNETWORKS.com (8.9.3+Sun/8.9.3) with SMTP id HAA08710 for ; Thu, 2 May 2002 07:28:55 -0400 (EDT) Date: Thu, 2 May 2002 07:28:55 -0400 (EDT) From: Jim Corrigan Reply-To: Jim Corrigan Subject: Why not down load CLIM, it does all of what you are doing and more To: corr0823@yahoo.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cGPF5p3iMTDIxrGapTBiBQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Content-Length: 3759 Greg Pardon the intrusion, if it is viewed as such. We have offered conserver users access to CLIM at no charge in exchange for comments on how to make CLIM better. CLIM allows you from multiple hosts to access multiple systems by the other hosts using the primary as a provider. We have autofailover built into the product as well. So two CLIM servers or actually upto three can handle failover in unison, i.e., primary fails, secondary takes over, secondary fails, tertiary takes over, primary comes back and tertiary gives control back to primary. Further by making all systems providers to otehr, one system maintains control of the consoles while the others can access the consoles. we monitor the terminal server and port on server as well We have a highly distributed product that lets users gain access via command line or gui and soon browser. We have soft consoles that support ssh2 and clim supports and maintains links to ssh2 terminal servers most notably cyclades. We support logging on tty device attached lines as well. we support all types of UNIX systems, windows NT and win2k as well OpenVMS. 1. Need System ID for License: (see instructions below) 2. Need Hostname: 3. Need Interface Name: Instructions to get System ID: ? NT use: ipconfig -all OR ipconfig /all , send ouptut ? Tru64/ Digital UNIX use: netstat -i send MAC address (will need to remove DECnet or untar our files and run kinet/bin/setia) ? AIX use: uname -m output ? Solaris use: hostid output ? HPUX use: /etc/lanscan send Output ? OVMS use: mcr lancp sho config output ? NT use: ipconfig /all output ? IRIX use: sysinfo -s output ? Linux use: ifconfig output - CLIM is a commercial product that provides extensive management facilities including console management easy to install and deploy dynamically add consoles w/o having to cycle Service daemons mulitple read/write access exclusive access that makes all read/write access readonly, connect to all consoles with a single window ( gang connect ) mulitple access methods that are all logged to unique log files including telnet and ssh sessions ( 2nd QTR 2002 ) and operator console ( need to load KOP Service on remote system ) auto-archiving of unique console logs support for ssh v2 and access to terminal servers that have ssh v2 deployed, i.e., cyclades, lantronix and cisco ( v1 - version 1 support by 2nd QTR 2002) vnc access to windows from UNIX using vnctight and UNIX Window manager and connection via Browser using port 5801 and above. CPU Efficient console log scanning auto configures terminal server ports and locks them down. Supports three power managers that have serial lines including APC and Server Technology Console inputs and outputs can be scan for up to five patterns as they occur as well as boot prompts are reported imeediately when found Terminal/Access Server Management Monitors, Maintains and Manages Terminal/Access Servers' configuration of their serial ports. Monitors, Maintains and Manages Terminal/Access Servers' configuration of console ports controlled by CLIM. This capability means that if the terminal server port goes unavailable then you willknow prior to accessing the port. Log File Monitoring a highly CPU efficient, beats Perle Scripts scanning, and scan of console logs. Pattern recognition is specified by regular expressions. If you distribute CLIM's NodeMonitor Services to each system under Console Management any log file on that system can be monitored including UNIX messages file or any NT event file or OpenVMS Operator Log file. Any log files patterns found are forwarded to our Event manager or as an snmp trap or to BMC Software Tivoli or OpenView event managers. As many lines before and after a found pattern can be specified by the user to be forwarded with the found pattern. The log file contents can be filtered as it is viewed by patterns or time intervals. The filtered log file can be printed or emailed or displayed via web. Event Manager Pattern finds, System Resource and Application Availability Monitoring or realtime high priority console scans are received by the Event Manager. The events found can be reported as they are found or an event can be generated after a number of events come in within a specified period of time. Actions assoicated with an event can be generated depending on the time of day. UP to 5 times of days can be specified Actions can be limited to occur a specified number of times with a given duration of time, e.g. one action per 1 hour or 30 minutes. System Resource, Application Availability Monitoring and Operations Console Those systems connected to CLIM via an access server can easily and quickly deploy system resource and application monitoring. NODEMONITOR Services include Log File Manager, Event Manager, KIOperations ( KOP ) Services and our directory server KiDS. CPU, Memory, Disk and Page/Swap file are monitored. Resource utilization that exceeds the thresholds set automatically or specified by the user has an event generated. If a monitored application executable ( multiple instances are found of same process name ) exits user can stipulate restart script. An event is generated and a popup is sent to any CLIM Ki Works. OpenVMS applications PID is reported in HEX. A script is run to set up a CLIM UNIX server as a Distribuiton Server. The Distribution Server is populated from our ftp site with the required binaries. The systems connected to and under control of CLIM will be updated with the NODEMONITOR Services via another script. From CLIM the user will be able to gain access to a UNIX X server via X display or WebBrowser port 5801. The browser must support Java. NODEMONITOR Services will need to be installed on the UNIX system. Access to NT and Win2k WinVNC servers will also be allowed via X and broswer and will be more efficent under tightvnc binaries. AutoFailover to upto Three Redundant Systems A CLIM BFD Service named for the buford ( Backup failover daemon ) allows for upto two other CLIM Servers to be specified as backup systems. In the USA South buford is a good ole boy who is someone you can count on. If the primary system exits the first backup system takes over, if the first backup system fails the second backup system takes over.The BFD Services coordinate the failover sequeunce between three CLIM servers. If at any time the first backup or primary system come back online the first or second backup system will relinquish control to the primary. Detected failures include Service Daemon failure, network failure, power failure or system crash. Failover can also be initiated via the command line using bfdcp command fail init and terminated via the fail term commands. Setup is as simple as bfdcp add backup node All redundancy is automatically setup. The event, log file and console databases are propagated. If a chenge occurs in any of the primary system's Services the backup systems are automatically updated as well. Jim Corrigan President/CEO voice: +919 481 2111 x 22 fax: +919 468 5797 mobile: +919 349-8767 URL: http://www.KiNETWORKS.com email: Jim.Corrigan@KiNETWORKS.com SnailMail: Ki NETWORKS, Inc 102 New Edition Court Cary, NC 27511 ------------------------------------ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, notify the sender immediately and destroy this e-mail. Any unauthorized duplication, disclosure or distribution of the material in this e-mail is forbidden. ------------- End Forwarded Message ------------- Jim Corrigan President/CEO voice: +919 481 2111 x 22 fax: +919 468 5797 mobile: +919 349-8767 URL: http://www.KiNETWORKS.com email: Jim.Corrigan@KiNETWORKS.com SnailMail: Ki NETWORKS, Inc 102 New Edition Court Cary, NC 27511 ------------------------------------ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, notify the sender immediately and destroy this e-mail. Any unauthorized duplication, disclosure or distribution of the material in this e-mail is forbidden. --0-2095219833-1020431396=:34408-- From lepera@us.ibm.com Fri May 3 06:34:31 2002 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g43DYT2S024789 for ; Fri, 3 May 2002 06:34:30 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g43DYN6r067780 for ; Fri, 3 May 2002 09:34:23 -0400 Received: from d01ml251.pok.ibm.com (d01ml251.pok.ibm.com [9.56.224.79]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g43DYLb71548 for ; Fri, 3 May 2002 09:34:21 -0400 Subject: Console commands on AIX To: users@conserver.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "William P LePera" Date: Fri, 3 May 2002 09:34:19 -0400 X-MIMETrack: Serialize by Router on D01ML251/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/03/2002 09:34:21 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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: Hello, Don't know if anyone has experience with conserver and AIX 5.1, but I'm seeing a weird problem and I hope someone can help... I compiled conserver 7.2.1 conserver and console apps with the AIX C compiler. As an initial test, I set it up using a terminal server, with an entry in conserver.cf as follows: c5bn15:!123.45.67.89:3002:& This worked fine. I was able to run the console app and connect to the target node without a problem. So far so good. The problem came when I tried to change the config file to invoke a command (with the pipe "|" character). For a follow-up test, I changed the config file to use the same terminal server, except now I explicitly telnet to the terminal server and port using the pipe character and the telnet command as follows: c5bn15:|/bin/telnet 123.45.67.89 3002::& This did not work as well. I got a message "Failed to allocate pseudo-tty: No such file or directory". See below: conserver-7.2.1 -Dv -p 782 conserver-7.2.1 (18998): conserver.com version 7.2.1 conserver-7.2.1 (18998): Started as `root' by `root' at Fri May 3 08:27:18 2002 conserver-7.2.1 (18998): DEBUG: Bind address set to `0.0.0.0' conserver-7.2.1 (18998): DEBUG: readLine: returning conserver-7.2.1 (18998): DEBUG: readLine: returning conserver-7.2.1 (18998): c5bn15 with command `/bin/telnet 123.45.67.89 3002' logged to /var/log/consoles/c5bn15 conserver-7.2.1 (18998): DEBUG: readLine: returning <%%> conserver-7.2.1 (18998): DEBUG: readLine: returning conserver-7.2.1 (18998): DEBUG: readLine: returning <> conserver-7.2.1 (4772): DEBUG: File I/O: Encapsulated fd 4 type 1 conserver-7.2.1 (4772): DEBUG: maxfiles=32766 conserver-7.2.1 (4772): DEBUG: File I/O: Opened `/var/log/consoles/c5bn15' as fd 5 conserver-7.2.1 (4772): DEBUG: File I/O: Wrote 18 bytes to fd 5 conserver-7.2.1 (4772): DEBUG: File I/O: Wrote 24 bytes to fd 5 conserver-7.2.1 (4772): DEBUG: File I/O: Wrote 3 bytes to fd 5 conserver-7.2.1 (4772): Failed to allocate pseudo-tty: No such file or directory conserver-7.2.1 (4772): DEBUG: File I/O: Wrote 20 bytes to fd 5 conserver-7.2.1 (4772): DEBUG: File I/O: Wrote 24 bytes to fd 5 conserver-7.2.1 (4772): DEBUG: File I/O: Wrote 3 bytes to fd 5 conserver-7.2.1 (4772): DEBUG: File I/O: Closed fd 5 conserver-7.2.1 (18998): group #0 pid 4772 on port 33211 conserver-7.2.1 (18998): access type 'a' for "pok.ibm.com" ^Cconserver-7.2.1 (18998): DEBUG: Sending pid 4772 signal 15 conserver-7.2.1 (18998): DEBUG: Group: id=0 pid=33211, port=4772, imembers=1 conserver-7.2.1 (18998): DEBUG: server=c5bn15, dfile=/dev/null, lfile=/var/log/consoles/c5bn15 conserver-7.2.1 (18998): DEBUG: mark=0, nextMark=0, breakType=1 conserver-7.2.1 (18998): DEBUG: isNetworkConsole=0, networkConsoleHost = conserver-7.2.1 (18998): DEBUG: networkConsolePort=0, telnetState=0, autoReup=0 conserver-7.2.1 (18998): DEBUG: baud=Local, parity= conserver-7.2.1 (18998): DEBUG: fvirtual=1, acslave=/dev/null, pccmd=/bin/telnet 123.45.67.89 3002, ipid=-1 conserver-7.2.1 (18998): DEBUG: nolog=0, fdtty=-1, activitylog=0, breaklog=0 conserver-7.2.1 (18998): DEBUG: fup=0, fronly=0 conserver-7.2.1 (18998): DEBUG: ------ conserver-7.2.1 (18998): Stopped at Fri May 3 08:27:24 2002 conserver-7.2.1 (4772): DEBUG: Group: id=0 pid=33211, port=4772, imembers=1 conserver-7.2.1 (4772): DEBUG: server=c5bn15, dfile=/dev/null, lfile=/var/log/consoles/c5bn15 conserver-7.2.1 (4772): DEBUG: mark=0, nextMark=0, breakType=1 conserver-7.2.1 (4772): DEBUG: isNetworkConsole=0, networkConsoleHost = conserver-7.2.1 (4772): DEBUG: networkConsolePort=0, telnetState=0, autoReup=0 conserver-7.2.1 (4772): DEBUG: baud=Local, parity= conserver-7.2.1 (4772): DEBUG: fvirtual=1, acslave=/dev/null, pccmd=/bin/telnet 123.45.67.89 3002, ipid=-1 conserver-7.2.1 (4772): DEBUG: nolog=0, fdtty=-1, activitylog=0, breaklog=0 conserver-7.2.1 (4772): DEBUG: fup=0, fronly=0 conserver-7.2.1 (4772): DEBUG: ------ At this point I recompiled a debug version and started poking around. The file it's choking on is "/dev/ptmx", it isn't present on the system, although the flags in config.h seem to indicate it should be (AIX does not currently support this pty flavor). At this point, I edited config.h and commented out the definition of HAVE_PTSNAME, simply to have the code bypass the ptmx portion and use another method of allocating a pty. This worked a little better, but when I run console, the app doesn't appear to connect to the terminal server. If I hit return, I just get linfeeds on the screen. Checking the process list, it doesn't look like the telnet session is ever started. Here's the conserver output during initialization, the connect attempt, and after killing it with ctrl-C: conserver-7.2.1.dbg -Dv -p 782 conserver-7.2.1.dbg (4770): conserver.com version 7.2.1 conserver-7.2.1.dbg (4770): Started as `root' by `root' at Fri May 3 08:17:53 2002 conserver-7.2.1.dbg (4770): DEBUG: Bind address set to `0.0.0.0' conserver-7.2.1.dbg (4770): DEBUG: readLine: returning conserver-7.2.1.dbg (4770): DEBUG: readLine: returning conserver-7.2.1.dbg (4770): c5bn15 with command `/bin/telnet 123.45.67.89 3002' logged to /var/log/consoles/c5bn15 conserver-7.2.1.dbg (4770): DEBUG: readLine: returning <%%> conserver-7.2.1.dbg (4770): DEBUG: readLine: returning conserver-7.2.1.dbg (4770): DEBUG: readLine: returning <> conserver-7.2.1.dbg (18666): DEBUG: File I/O: Encapsulated fd 4 type 1 conserver-7.2.1.dbg (18666): DEBUG: maxfiles=32766 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Opened `/var/log/consoles/c5bn15' as fd 5 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 18 bytes to fd 5 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 24 bytes to fd 5 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 3 bytes to fd 5 conserver-7.2.1.dbg (5206): DEBUG: maxfiles=32766 conserver-7.2.1.dbg (18666): c5bn15 has pid 5206 on /dev/pts/1 conserver-7.2.1.dbg (4770): group #0 pid 18666 on port 33208 conserver-7.2.1.dbg (4770): access type 'a' for "pok.ibm.com" conserver-7.2.1.dbg (4770): DEBUG: File I/O: Encapsulated fd 5 type 1 conserver-7.2.1.dbg (4770): DEBUG: Access check: hostname=c5aix03.ppd.pok.ibm.com, ip=123.45.67.2 conserver-7.2.1.dbg (4770): DEBUG: Access check: who=pok.ibm.com, trust=a conserver-7.2.1.dbg (4770): DEBUG: Access check: name=c5aix03.ppd.pok.ibm.com conserver-7.2.1.dbg (4770): DEBUG: Access check: name=ppd.pok.ibm.com conserver-7.2.1.dbg (4770): DEBUG: Access check: name=pok.ibm.com conserver-7.2.1.dbg (19424): DEBUG: File I/O: Wrote 4 bytes to fd 5 conserver-7.2.1.dbg (4770): DEBUG: File I/O: Closed fd 5 conserver-7.2.1.dbg (19424): DEBUG: File I/O: Read 13 bytes from fd 5 conserver-7.2.1.dbg (19424): DEBUG: File I/O: Wrote 5 bytes to fd 5 conserver-7.2.1.dbg (19424): DEBUG: File I/O: Wrote 2 bytes to fd 5 conserver-7.2.1.dbg (19424): DEBUG: File I/O: Closed fd 5 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Encapsulated fd 7 type 1 conserver-7.2.1.dbg (18666): DEBUG: Access check: hostname=c5aix03.ppd.pok.ibm.com, ip=123.45.67.2 conserver-7.2.1.dbg (18666): DEBUG: Access check: who=pok.ibm.com, trust=a conserver-7.2.1.dbg (18666): DEBUG: Access check: name=c5aix03.ppd.pok.ibm.com conserver-7.2.1.dbg (18666): DEBUG: Access check: name=ppd.pok.ibm.com conserver-7.2.1.dbg (18666): DEBUG: Access check: name=pok.ibm.com conserver-7.2.1.dbg (18666): DEBUG: Client acid initialized to ` @c5aix03.ppd.pok.ibm.com' conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 4 bytes to fd 7 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Read 3 bytes from fd 7 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 1 byte to fd 7 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 8 bytes to fd 7 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Read 6 bytes from fd 7 conserver-7.2.1.dbg (18666): DEBUG: Client acid reinitialized to `root@c5aix03.ppd.pok.ibm.com' conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 7 bytes to fd 7 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Read 8 bytes from fd 7 conserver-7.2.1.dbg (18666): DEBUG: readLine: returning <*any*::any> conserver-7.2.1.dbg (18666): User root@c5aix03.ppd.pok.ibm.com logging into server c5bn15 conserver-7.2.1.dbg (18666): c5bn15: login root@c5aix03.ppd.pok.ibm.com [Fri May 3 08:18:53 2002] conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 11 bytes to fd 7 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Read 1 byte from fd 7 conserver-7.2.1.dbg (18666): DEBUG: Read 2 bytes from fd 6 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 2 bytes to fd 5 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 2 bytes to fd 7 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Read 1 byte from fd 7 conserver-7.2.1.dbg (18666): DEBUG: Read 2 bytes from fd 6 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 2 bytes to fd 5 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 2 bytes to fd 7 ^Cconserver-7.2.1.dbg (4770): DEBUG: Sending pid 18666 signal 15 conserver-7.2.1.dbg (4770): DEBUG: Group: id=0 pid=33208, port=18666, imembers=1 conserver-7.2.1.dbg (4770): DEBUG: server=c5bn15, dfile=/dev/null, lfile=/var/log/consoles/c5bn15 conserver-7.2.1.dbg (4770): DEBUG: mark=0, nextMark=0, breakType=1 conserver-7.2.1.dbg (4770): DEBUG: isNetworkConsole=0, networkConsoleHost = conserver-7.2.1.dbg (4770): DEBUG: networkConsolePort=0, telnetState=0, autoReup=0 conserver-7.2.1.dbg (4770): DEBUG: baud=Local, parity= conserver-7.2.1.dbg (4770): DEBUG: fvirtual=1, acslave=/dev/null, pccmd=/bin/telnet 123.45.67.89 3002, ipid=-1 conserver-7.2.1.dbg (4770): DEBUG: nolog=0, fdtty=-1, activitylog=0, breaklog=0 conserver-7.2.1.dbg (4770): DEBUG: fup=0, fronly=0 conserver-7.2.1.dbg (4770): DEBUG: ------ conserver-7.2.1.dbg (4770): Stopped at Fri May 3 08:21:49 2002 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 38 bytes to fd 7 conserver-7.2.1.dbg (18666): DEBUG: Sending pid 5206 signal 1 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 20 bytes to fd 5 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 24 bytes to fd 5 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Wrote 3 bytes to fd 5 conserver-7.2.1.dbg (18666): DEBUG: File I/O: Closed fd 5 conserver-7.2.1.dbg (18666): DEBUG: Group: id=0 pid=33208, port=18666, imembers=1 conserver-7.2.1.dbg (18666): DEBUG: server=c5bn15, dfile=/dev/ptc/1, lfile=/var/log/consoles/c5bn15 conserver-7.2.1.dbg (18666): DEBUG: mark=0, nextMark=0, breakType=1 conserver-7.2.1.dbg (18666): DEBUG: isNetworkConsole=0, networkConsoleHost= conserver-7.2.1.dbg (18666): DEBUG: networkConsolePort=0, telnetState=0, autoReup=0 conserver-7.2.1.dbg (18666): DEBUG: baud=Local, parity= conserver-7.2.1.dbg (18666): DEBUG: fvirtual=1, acslave=/dev/pts/1, pccmd=/bin/telnet 123.45.67.89 3002, ipid=-1 conserver-7.2.1.dbg (18666): DEBUG: nolog=0, fdtty=-1, activitylog=0, breaklog=0 conserver-7.2.1.dbg (18666): DEBUG: fup=0, fronly=0 conserver-7.2.1.dbg (18666): DEBUG: ------ Should I have changed a different env variable to work around the ptmx problem? Could there be a problem with the "configure" utility, which seemed to configure the compile environment to think that ptmx was present? Any help or debug tips appreciated! Thanks, Bill LePera IBM Server Group, Poughkeepsie, NY From corr0823@yahoo.com Fri May 3 06:36:58 2002 Received: from web20405.mail.yahoo.com (web20405.mail.yahoo.com [216.136.226.124]) by underdog.stansell.org (8.12.2/8.12.2) with SMTP id g43Daw2S024831 for ; Fri, 3 May 2002 06:36:58 -0700 (PDT) Message-ID: <20020503133658.62676.qmail@web20405.mail.yahoo.com> Received: from [65.199.229.162] by web20405.mail.yahoo.com via HTTP; Fri, 03 May 2002 06:36:58 PDT Date: Fri, 3 May 2002 06:36:58 -0700 (PDT) From: Jim Corrigan Subject: Fwd: Why not down load CLIM, it does all of what you are doing and more To: users@conserver.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1989001798-1020433018=:62322" 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: --0-1989001798-1020433018=:62322 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com --0-1989001798-1020433018=:62322 Content-Type: message/rfc822 X-Apparently-To: corr0823@yahoo.com via web20402.mail.yahoo.com; 02 May 2002 04:28:57 -0700 (PDT) X-Track: 1: 40 Return-Path: Received: from 65.199.229.162 (HELO interlock.KiNETWORKS.com) (65.199.229.162) by mta613.mail.yahoo.com with SMTP; 02 May 2002 04:28:56 -0700 (PDT) Received: from fileserver.rtp.KiNETWORKS.com by interlock.KiNETWORKS.com via smtpd (for mta-v12.level3.mail.yahoo.com [64.157.4.82]) with SMTP; 2 May 2002 11:28:56 UT Received: from e5a.rtp.KiNETWORKS.com (e5a.rtp.KiNETWORKS.com [172.16.16.8]) by KiNETWORKS.com (8.11.2/8.11.1) with ESMTP id g42BStk25784 for ; Thu, 2 May 2002 07:28:55 -0400 (EDT) Received: from e5a (e5a [172.16.16.8]) by e5a.rtp.KiNETWORKS.com (8.9.3+Sun/8.9.3) with SMTP id HAA08710 for ; Thu, 2 May 2002 07:28:55 -0400 (EDT) Date: Thu, 2 May 2002 07:28:55 -0400 (EDT) From: Jim Corrigan Reply-To: Jim Corrigan Subject: Why not down load CLIM, it does all of what you are doing and more To: corr0823@yahoo.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cGPF5p3iMTDIxrGapTBiBQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Content-Length: 3759 Greg Pardon the intrusion, if it is viewed as such. We have offered conserver users access to CLIM at no charge in exchange for comments on how to make CLIM better. CLIM allows you from multiple hosts to access multiple systems by the other hosts using the primary as a provider. We have autofailover built into the product as well. So two CLIM servers or actually upto three can handle failover in unison, i.e., primary fails, secondary takes over, secondary fails, tertiary takes over, primary comes back and tertiary gives control back to primary. Further by making all systems providers to otehr, one system maintains control of the consoles while the others can access the consoles. we monitor the terminal server and port on server as well We have a highly distributed product that lets users gain access via command line or gui and soon browser. We have soft consoles that support ssh2 and clim supports and maintains links to ssh2 terminal servers most notably cyclades. We support logging on tty device attached lines as well. we support all types of UNIX systems, windows NT and win2k as well OpenVMS. 1. Need System ID for License: (see instructions below) 2. Need Hostname: 3. Need Interface Name: Instructions to get System ID: ? NT use: ipconfig -all OR ipconfig /all , send ouptut ? Tru64/ Digital UNIX use: netstat -i send MAC address (will need to remove DECnet or untar our files and run kinet/bin/setia) ? AIX use: uname -m output ? Solaris use: hostid output ? HPUX use: /etc/lanscan send Output ? OVMS use: mcr lancp sho config output ? NT use: ipconfig /all output ? IRIX use: sysinfo -s output ? Linux use: ifconfig output - CLIM is a commercial product that provides extensive management facilities including console management easy to install and deploy dynamically add consoles w/o having to cycle Service daemons mulitple read/write access exclusive access that makes all read/write access readonly, connect to all consoles with a single window ( gang connect ) mulitple access methods that are all logged to unique log files including telnet and ssh sessions ( 2nd QTR 2002 ) and operator console ( need to load KOP Service on remote system ) auto-archiving of unique console logs support for ssh v2 and access to terminal servers that have ssh v2 deployed, i.e., cyclades, lantronix and cisco ( v1 - version 1 support by 2nd QTR 2002) vnc access to windows from UNIX using vnctight and UNIX Window manager and connection via Browser using port 5801 and above. CPU Efficient console log scanning auto configures terminal server ports and locks them down. Supports three power managers that have serial lines including APC and Server Technology Console inputs and outputs can be scan for up to five patterns as they occur as well as boot prompts are reported imeediately when found Terminal/Access Server Management Monitors, Maintains and Manages Terminal/Access Servers' configuration of their serial ports. Monitors, Maintains and Manages Terminal/Access Servers' configuration of console ports controlled by CLIM. This capability means that if the terminal server port goes unavailable then you willknow prior to accessing the port. Log File Monitoring a highly CPU efficient, beats Perle Scripts scanning, and scan of console logs. Pattern recognition is specified by regular expressions. If you distribute CLIM's NodeMonitor Services to each system under Console Management any log file on that system can be monitored including UNIX messages file or any NT event file or OpenVMS Operator Log file. Any log files patterns found are forwarded to our Event manager or as an snmp trap or to BMC Software Tivoli or OpenView event managers. As many lines before and after a found pattern can be specified by the user to be forwarded with the found pattern. The log file contents can be filtered as it is viewed by patterns or time intervals. The filtered log file can be printed or emailed or displayed via web. Event Manager Pattern finds, System Resource and Application Availability Monitoring or realtime high priority console scans are received by the Event Manager. The events found can be reported as they are found or an event can be generated after a number of events come in within a specified period of time. Actions assoicated with an event can be generated depending on the time of day. UP to 5 times of days can be specified Actions can be limited to occur a specified number of times with a given duration of time, e.g. one action per 1 hour or 30 minutes. System Resource, Application Availability Monitoring and Operations Console Those systems connected to CLIM via an access server can easily and quickly deploy system resource and application monitoring. NODEMONITOR Services include Log File Manager, Event Manager, KIOperations ( KOP ) Services and our directory server KiDS. CPU, Memory, Disk and Page/Swap file are monitored. Resource utilization that exceeds the thresholds set automatically or specified by the user has an event generated. If a monitored application executable ( multiple instances are found of same process name ) exits user can stipulate restart script. An event is generated and a popup is sent to any CLIM Ki Works. OpenVMS applications PID is reported in HEX. A script is run to set up a CLIM UNIX server as a Distribuiton Server. The Distribution Server is populated from our ftp site with the required binaries. The systems connected to and under control of CLIM will be updated with the NODEMONITOR Services via another script. From CLIM the user will be able to gain access to a UNIX X server via X display or WebBrowser port 5801. The browser must support Java. NODEMONITOR Services will need to be installed on the UNIX system. Access to NT and Win2k WinVNC servers will also be allowed via X and broswer and will be more efficent under tightvnc binaries. AutoFailover to upto Three Redundant Systems A CLIM BFD Service named for the buford ( Backup failover daemon ) allows for upto two other CLIM Servers to be specified as backup systems. In the USA South buford is a good ole boy who is someone you can count on. If the primary system exits the first backup system takes over, if the first backup system fails the second backup system takes over.The BFD Services coordinate the failover sequeunce between three CLIM servers. If at any time the first backup or primary system come back online the first or second backup system will relinquish control to the primary. Detected failures include Service Daemon failure, network failure, power failure or system crash. Failover can also be initiated via the command line using bfdcp command fail init and terminated via the fail term commands. Setup is as simple as bfdcp add backup node All redundancy is automatically setup. The event, log file and console databases are propagated. If a chenge occurs in any of the primary system's Services the backup systems are automatically updated as well. Jim Corrigan President/CEO voice: +919 481 2111 x 22 fax: +919 468 5797 mobile: +919 349-8767 URL: http://www.KiNETWORKS.com email: Jim.Corrigan@KiNETWORKS.com SnailMail: Ki NETWORKS, Inc 102 New Edition Court Cary, NC 27511 ------------------------------------ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, notify the sender immediately and destroy this e-mail. Any unauthorized duplication, disclosure or distribution of the material in this e-mail is forbidden. ------------- End Forwarded Message ------------- Jim Corrigan President/CEO voice: +919 481 2111 x 22 fax: +919 468 5797 mobile: +919 349-8767 URL: http://www.KiNETWORKS.com email: Jim.Corrigan@KiNETWORKS.com SnailMail: Ki NETWORKS, Inc 102 New Edition Court Cary, NC 27511 ------------------------------------ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, notify the sender immediately and destroy this e-mail. Any unauthorized duplication, disclosure or distribution of the material in this e-mail is forbidden. --0-1989001798-1020433018=:62322-- From iainr@dcs.ed.ac.uk Fri May 3 06:53:27 2002 Received: from muck.dcs.ed.ac.uk (muck.dcs.ed.ac.uk [129.215.216.15]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g43DrP2S024992 for ; Fri, 3 May 2002 06:53:26 -0700 (PDT) Received: from dcs.ed.ac.uk (testnode2.inf.ed.ac.uk [129.215.212.124]) by muck.dcs.ed.ac.uk with ESMTP id OAA08247 for ; Fri, 3 May 2002 14:53:20 +0100 (BST) Message-ID: <3CD29652.6090404@dcs.ed.ac.uk> Date: Fri, 03 May 2002 14:53:22 +0100 From: Iain Rae User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020420 X-Accept-Language: en-us, en MIME-Version: 1.0 To: users@conserver.com Subject: client enhancement request X-Enigmail-Version: 0.49.2.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: We had a power outage yesterday and one thing we decided would be useful would be to have some way of identifying the console that console is connected to. Say by having something like [hostname] [console server] [device] on the top line of the console. and have it togglable for people that don't want it. Of course at this point someone mails me and tells me that you can do something like this already. The other Idle thought I've just had, was if we allowed a comment field on the end of the conserver.cf console entry i.e. scar:/dev/cub23:9600p:&:1h:"Patch panel 7 port 6648" you could have something like client:server:dev/cub23:Patch panel 7 port 6648 on the top line. Silly idea? -- Iain Rae Tel:01316505202 Computing Officer JCMB:2148 Division of Informatics The University of Edinburgh From woods@proven.weird.com Wed May 1 22:29:54 2002 Received: from most.weird.com (IDENT:8pu6cScd2yuckCfqDwbNpg/2NTgHbw1Wv/MZz+csBzG59GlJOd7vdsOFidk3voopUD/HplaF9mc@most.weird.com [204.92.254.2]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g425Tp2S003207 for ; Wed, 1 May 2002 22:29:52 -0700 (PDT) Received: from proven.weird.com([204.92.254.15]) (114475 bytes) by most.weird.com via smail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident <[1WWa6CDqzRtdY6EoFr8N2AxDHgh8VwebGnIatuTFHg+nDu7tHkZxR6XvJXYrbySNCbeWz+1oI50tSlD0Je1ZmQ==]> using rfc1413) id for ; Thu, 2 May 2002 01:29:48 -0400 (EDT) (Smail-3.2.0.115-Pre 2001-Aug-6 #2 built 2002-Apr-22) Received: by proven.weird.com (Postfix, from userid 1000) id 964B3AC; Thu, 2 May 2002 01:29:47 -0400 (EDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="gRHcdVS1Np" Content-Transfer-Encoding: 7bit X-Face: ;j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz;@-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= Date: Thu, 2 May 2002 01:29:47 -0400 (EDT) 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: --gRHcdVS1Np Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Attached is a patch to integrate hooks to call the public domain 'chat' program (often supplied with pppd, but also included in this patch) with an optional per-console chat script each time the console is initialised (i.e. after carrier or DTR returns, or after a telnet connection is re-established). A separate conserver.chat file is provided for, both to simplify the configuration and to allow the chat script to be protected from prying eyes (since its most common application might well be to login to a terminal server and thus it will contain at least an access password -- that's what I use it for anyway, and the examples are real! :-). The chat-script is run after the first read for a network console port (in order to allow telent negotiation to proceed first even though nothing is really done yet). This means a chat to a really raw socket connection might fail unless something can be read before the chat is attempted. I apologise for the rather extensive unrelated changes -- I found it necessary to hack around quite a bit before I got all the right things in the right places and I'm too lazy to try to undo the stylistic changes (I find some aspects of the current coding style almost unreadable, and some of the utility functions are quite bizzare). The portability of this code isn't guaranteed, though it shouldn't be too bad, at least for any half-way modern system (not that the code will even begin to compile on a pre-ANSI machine anyway!). It's been tested on NetBSD/sparc-1.3.2 and lightly on NetBSD/{i386,sparc}-1.5W. Note the version of the 'chat' program included in this patch is a slightly modified version of the one from NetBSD-current (1.25). I've added a new flag, '-I', which causes it to not try to modify the TTY settings (which fails on a direct socket); and I've fixed up the manual page a bit. The hooks in conserver will use this option if the console is a network port, so you'll definitely need this customised version! (Note I've not really tested it against a serial TTY, but it should work fine given that the chat program works fine when tested by hand on the command-line via a real serial port.) I've not done any autoconf- iscation on chat either. It may compile by default though on many modern systems since it seems to expects only TERMIOS and other basic POSIX functionality. It certainly works fine on NetBSD from whence it was taken, and no doubt will work equally well on any recent *BSD and maybe even MacOS-X. Note too that some, though perhaps not all, of the suggested improvements in the last patch I posted are included in this one too (they were too hard for me to separate :-). (apologies also for the size of this message -- but it appears it will just under 128kb on the wire and it seems best to post it as one than to expect y'all to put together a MIME message/partial multi-message post ;-) -- Greg A. Woods +1 416 218-0098; ; ; Planix, Inc. ; VE3TCP; Secrets of the Weird --gRHcdVS1Np Content-Type: text/plain Content-Description: conserver patches to add chat hooks Content-Disposition: inline; filename="chat.patch" Content-Transfer-Encoding: 7bit Index: conserver/readcfg.h =================================================================== RCS file: /cvs/misc/conserver/conserver/readcfg.h,v retrieving revision 1.1.1.2 diff -c -r1.1.1.2 readcfg.h *** conserver/readcfg.h 16 Mar 2002 22:24:02 -0000 1.1.1.2 --- conserver/readcfg.h 1 May 2002 22:54:27 -0000 *************** *** 48,55 **** --- 48,59 ---- extern void ReadCfg(char *, FILE *); extern char *pruneSpace(char *); extern void ReReadCfg(); + extern void ReadChat(char *, FILE *); + extern CONSENT *FindCE(char *); #else extern void ReadCfg(); extern char *pruneSpace(); extern void ReReadCfg(); + extern void ReadChat(); + extern CONSENT *FindCE(); #endif Index: conserver/readcfg.c =================================================================== RCS file: /cvs/misc/conserver/conserver/readcfg.c,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 readcfg.c *** conserver/readcfg.c 24 Apr 2002 21:42:00 -0000 1.1.1.3 --- conserver/readcfg.c 2 May 2002 02:25:49 -0000 *************** *** 246,252 **** #if USE_ANSI_PROTO ReadCfg(char *pcFile, FILE * fp) #else ! ReadCfg(pcFile, fp, master) char *pcFile; FILE *fp; #endif --- 246,252 ---- #if USE_ANSI_PROTO ReadCfg(char *pcFile, FILE * fp) #else ! ReadCfg(pcFile, fp) char *pcFile; FILE *fp; #endif *************** *** 595,600 **** --- 595,602 ---- pCE->fup = pCE->autoReUp = 0; pCE->pCLon = pCE->pCLwr = (CONSCLIENT *) 0; pCE->fdlog = (CONSFILE *) 0; + buildMyString((char *)0, &pCE->consoleChat); /* see ReadChat() */ + pCE->doneChat = 0; if (pcLine[0] == '!') { char acOut[100]; *************** *** 1046,1051 **** --- 1048,1054 ---- #endif { FILE *fpConfig; + FILE *fpChat; if ((FILE *) 0 == (fpConfig = fopen(pcConfig, "r"))) { Error("fopen: %s: %s", pcConfig, strerror(errno)); *************** *** 1056,1061 **** --- 1059,1069 ---- fclose(fpConfig); + if ((fpChat = fopen(pcChat, "r"))) { + ReadChat(pcChat, fpChat); + fclose(fpChat); + } + if (pGroups == (GRPENT *) 0 && pRCList == (REMOTE *) 0) { if (isMaster) { Error("No consoles found in configuration file"); *************** *** 1115,1118 **** --- 1123,1195 ---- } } } + } + + /* + * read in the optional chat file.... + */ + CONSENT * + FindCE(ConsName) + char *ConsName; + { + GRPENT *pGE; + CONSENT *pCE; + + for (pGE = pGroups; pGE; pGE = pGE->pGEnext) { + if (pGE->imembers == 0) { + continue; + } + for (pCE = pGE->pCElist; pCE; pCE = pCE->pCEnext) { + if (strcmp(pCE->server.string, ConsName) == 0) { + return pCE; + } + } + } + + return NULL; + } + + /* + * read in the optional chat file.... + */ + void + ReadChat(pcFile, fp) + char *pcFile; + FILE *fp; + { + int iLine; + unsigned char *acIn; + STRING acInSave = { (char *) 0, 0, 0 }; + + buildMyString((char *) 0, &acInSave); + + iLine = 0; + while ((acIn = readLine(fp, &acInSave, &iLine))) { + char *acStart, *pcChat, *pcMark, *pcCN; + CONSENT *pCE; + + acStart = pruneSpace(acIn); + + if ((pcMark = strchr(acStart, ':'))) { + *pcMark++ = '\000'; + pcCN = pruneSpace(acStart); + pcChat = pruneSpace(pcMark); + } else { + Error("%s(%d) bad config line `%s'", + pcFile, iLine, acIn); + continue; + } + if (strchr(pcChat, '\'')) { + Error("%s(%d) chat script must not contain any single quotes: %s", + pcFile, iLine, acIn); + continue; + } + if ((pCE = FindCE(pcCN))) { + buildMyString(pcChat, &pCE->consoleChat); + } else { + Error("%s(%d) unknown console: %s", + pcFile, iLine, pcCN); + continue; + } + } } Index: conserver/master.c =================================================================== RCS file: /cvs/misc/conserver/conserver/master.c,v retrieving revision 1.1.1.2 diff -c -r1.1.1.2 master.c *** conserver/master.c 16 Mar 2002 22:24:01 -0000 1.1.1.2 --- conserver/master.c 2 May 2002 02:32:20 -0000 *************** *** 104,110 **** continue; } ! for (pGE = pGroups; pGE != (GRPENT *) 0; pGE = pGE->pGEnext) { if (0 == pGE->imembers) continue; if (pid != pGE->pid) --- 104,110 ---- continue; } ! for (pGE = pGroups; pGE; pGE = pGE->pGEnext) { if (0 == pGE->imembers) continue; if (pid != pGE->pid) *************** *** 223,229 **** { GRPENT *pGE; ! for (pGE = pGroups; pGE != (GRPENT *) 0; pGE = pGE->pGEnext) { if (0 == pGE->imembers || -1 == pGE->pid) continue; Debug(1, "Sending pid %d signal %d", pGE->pid, arg); --- 223,229 ---- { GRPENT *pGE; ! for (pGE = pGroups; pGE; pGE = pGE->pGEnext) { if (0 == pGE->imembers || -1 == pGE->pid) continue; Debug(1, "Sending pid %d signal %d", pGE->pid, arg); *************** *** 462,468 **** (char *)0 }; char **ppc; ! for (ppc = apcHelp; (char *)0 != *ppc; ++ppc) { (void)fileWrite(csocket, *ppc, -1); } fileClose(&csocket); --- 462,468 ---- (char *)0 }; char **ppc; ! for (ppc = apcHelp; *ppc; ++ppc) { (void)fileWrite(csocket, *ppc, -1); } fileClose(&csocket); *************** *** 495,501 **** if (0 == strcmp(acIn, "groups")) { int iSep = 1; ! for (pGE = pGroups; pGE != (GRPENT *) 0; pGE = pGE->pGEnext) { if (0 == pGE->imembers) continue; filePrint(csocket, ":%u" + iSep, ntohs(pGE->port)); --- 495,501 ---- if (0 == strcmp(acIn, "groups")) { int iSep = 1; ! for (pGE = pGroups; pGE; pGE = pGE->pGEnext) { if (0 == pGE->imembers) continue; filePrint(csocket, ":%u" + iSep, ntohs(pGE->port)); *************** *** 523,529 **** filePrint(csocket, "@%s", inet_ntoa(lcl.sin_addr)); iSep = 0; } ! for (pRC = pRCUniq; (REMOTE *) 0 != pRC; pRC = pRC->pRCuniq) { filePrint(csocket, ":@%s" + iSep, pRC->rhost.string); iSep = 0; } --- 523,529 ---- filePrint(csocket, "@%s", inet_ntoa(lcl.sin_addr)); iSep = 0; } ! for (pRC = pRCUniq; pRC; pRC = pRC->pRCuniq) { filePrint(csocket, ":@%s" + iSep, pRC->rhost.string); iSep = 0; } *************** *** 553,563 **** found = 0; pRCFound = (REMOTE *) 0; /* look for a local machine */ ! for (pGE = pGroups; pGE != (GRPENT *) 0; pGE = pGE->pGEnext) { if (0 == pGE->imembers) continue; ! for (pCE = pGE->pCElist; pCE != (CONSENT *) 0; ! pCE = pCE->pCEnext) { if (0 != strcmp(pcArgs, pCE->server.string)) { continue; } --- 553,562 ---- found = 0; pRCFound = (REMOTE *) 0; /* look for a local machine */ ! for (pGE = pGroups; pGE; pGE = pGE->pGEnext) { if (0 == pGE->imembers) continue; ! for (pCE = pGE->pCElist; pCE; pCE = pCE->pCEnext) { if (0 != strcmp(pcArgs, pCE->server.string)) { continue; } *************** *** 571,577 **** * duplicates - a bad state to be in. * Does the readcfg.c code even check for dups? */ ! for (pRC = pRCList; (REMOTE *) 0 != pRC; pRC = pRC->pRCnext) { if (0 != strcmp(pcArgs, pRC->rserver.string)) { continue; } --- 570,576 ---- * duplicates - a bad state to be in. * Does the readcfg.c code even check for dups? */ ! for (pRC = pRCList; pRC; pRC = pRC->pRCnext) { if (0 != strcmp(pcArgs, pRC->rserver.string)) { continue; } *************** *** 581,591 **** pRCFound = pRC; } if (found == 0) { /* Then look for substring matches */ ! for (pGE = pGroups; pGE != (GRPENT *) 0; pGE = pGE->pGEnext) { if (0 == pGE->imembers) continue; ! for (pCE = pGE->pCElist; pCE != (CONSENT *) 0; ! pCE = pCE->pCEnext) { if (0 != strncmp(pcArgs, pCE->server.string, strlen(pcArgs))) { --- 580,590 ---- pRCFound = pRC; } if (found == 0) { /* Then look for substring matches */ ! Debug(1, "client wants server '%s', looking for substrings", pcArgs); ! for (pGE = pGroups; pGE; pGE = pGE->pGEnext) { if (0 == pGE->imembers) continue; ! for (pCE = pGE->pCElist; pCE; pCE = pCE->pCEnext) { if (0 != strncmp(pcArgs, pCE->server.string, strlen(pcArgs))) { *************** *** 599,605 **** } /* look for a remote server */ /* again, looks for dups with local consoles */ ! for (pRC = pRCList; (REMOTE *) 0 != pRC; pRC = pRC->pRCnext) { if (0 != strncmp(pcArgs, pRC->rserver.string, strlen(pcArgs))) { continue; --- 598,604 ---- } /* look for a remote server */ /* again, looks for dups with local consoles */ ! for (pRC = pRCList; pRC; pRC = pRC->pRCnext) { if (0 != strncmp(pcArgs, pRC->rserver.string, strlen(pcArgs))) { continue; Index: conserver/main.h =================================================================== RCS file: /cvs/misc/conserver/conserver/main.h,v retrieving revision 1.1.1.2 diff -c -r1.1.1.2 main.h *** conserver/main.h 16 Mar 2002 22:24:01 -0000 1.1.1.2 --- conserver/main.h 2 May 2002 02:10:30 -0000 *************** *** 44,49 **** --- 44,50 ---- extern unsigned int bindPort, bindBasePort; extern char *pcLogfile; extern char *pcConfig; + extern char *pcChat; extern char *pcPasswd; extern int cMaxMemb; extern struct sockaddr_in in_port; Index: conserver/main.c =================================================================== RCS file: /cvs/misc/conserver/conserver/main.c,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 main.c *** conserver/main.c 24 Apr 2002 21:42:00 -0000 1.1.1.3 --- conserver/main.c 2 May 2002 03:37:39 -0000 *************** *** 54,70 **** #include #include ! int fAll = 0, fVerbose = 0, fSoftcar = 0, fNoinit = 0, fVersion = ! 0, fStrip = 0, fDaemon = 0, fUseLogfile = 0, fReopen = 0, fReopenall = ! 0; char chDefAcc = 'r'; ! #define FULLCFPATH SYSCONFDIR "/" CONFIGFILE ! #define FULLPDPATH SYSCONFDIR "/" PASSWDFILE char *pcLogfile = LOGFILEPATH; char *pcConfig = FULLCFPATH; char *pcPasswd = FULLPDPATH; char *pcPort = DEFPORT; char *pcBasePort = DEFBASEPORT; --- 54,84 ---- #include #include ! int fAll = 0; ! int fDaemon = 0; ! int fDoNotRun = 0; ! int fNoinit = 0; ! int fReopen = 0; ! int fReopenall = 0; ! int fSoftcar = 0; ! int fStrip = 0; ! int fUseLogfile = 0; ! int fVerbose = 0; ! int fVersion = 0; char chDefAcc = 'r'; ! #ifdef __STDC__ ! # define FULLCFPATH SYSCONFDIR "/" CONFIGFILE ! # define FULLCHATPATH SYSCONFDIR "/" CHATFILE ! # define FULLPDPATH SYSCONFDIR "/" PASSWDFILE ! #else ! # include "ERROR: this code assumes ISO/STD C ability to concatenate strings." ! #endif char *pcLogfile = LOGFILEPATH; char *pcConfig = FULLCFPATH; + char *pcChat = FULLCHATPATH; char *pcPasswd = FULLPDPATH; char *pcPort = DEFPORT; char *pcBasePort = DEFBASEPORT; *************** *** 109,115 **** */ static void #if USE_ANSI_PROTO ! daemonize() #else daemonize() #endif --- 123,129 ---- */ static void #if USE_ANSI_PROTO ! daemonize(void) #else daemonize() #endif *************** *** 173,184 **** static char u_terse[] = ! " [-7dDhinouvV] [-a type] [-m max] [-M addr] [-p port] [-b port] [-C config] [-P passwd] [-L logfile] [-O min]"; static char *apcLong[] = { "7 strip the high bit of all console data", "a type set the default access type", "b port base port for secondary channel (any by default)", ! "C config give a new config file to the server process", "d become a daemon, redirecting stdout/stderr to logfile", "D enable debug output, sent to stderr", "h output this message", --- 187,199 ---- static char u_terse[] = ! " [-7dDhinouvV] [-a type] [-m max] [-M addr] [-p port] [-b port] [-c config] [-C chat] [-P passwd] [-L logfile] [-O min]"; static char *apcLong[] = { "7 strip the high bit of all console data", "a type set the default access type", "b port base port for secondary channel (any by default)", ! "c config specify custom config file", ! "C chat specify chat-script file", "d become a daemon, redirecting stdout/stderr to logfile", "D enable debug output, sent to stderr", "h output this message", *************** *** 187,192 **** --- 202,208 ---- "m max maximum consoles managed per process", "M addr address to listen on (all addresses by default)", "n obsolete - see -u", + "N don't start any master process (use with -v)", "o reopen downed console on client connect", "O min reopen all downed consoles every minutes", "p port port to listen on", *************** *** 301,322 **** if (!fDebug) return; ! for (pGE = pGroups; pGE != (GRPENT *) 0; pGE = pGE->pGEnext) { Debug(1, "Group: id=%u pid=%d, port=%d, imembers=%d", pGE->id, pGE->port, pGE->pid, pGE->imembers); ! for (pCE = pGE->pCElist; pCE != (CONSENT *) 0; pCE = pCE->pCEnext) { ! if (pCE->pccmd.string == (char *)0) pCE->pccmd.string = empty; ! if (pCE->server.string == (char *)0) pCE->server.string = empty; ! if (pCE->dfile.string == (char *)0) pCE->dfile.string = empty; ! if (pCE->lfile.string == (char *)0) pCE->lfile.string = empty; ! if (pCE->networkConsoleHost.string == (char *)0) pCE->networkConsoleHost.string = empty; ! if (pCE->acslave.string == (char *)0) pCE->acslave.string = empty; Debug(1, " server=%s, dfile=%s, lfile=%s", pCE->server.string, --- 317,340 ---- if (!fDebug) return; ! for (pGE = pGroups; pGE; pGE = pGE->pGEnext) { Debug(1, "Group: id=%u pid=%d, port=%d, imembers=%d", pGE->id, pGE->port, pGE->pid, pGE->imembers); ! for (pCE = pGE->pCElist; pCE; pCE = pCE->pCEnext) { ! if (!pCE->pccmd.string) pCE->pccmd.string = empty; ! if (!pCE->server.string) pCE->server.string = empty; ! if (!pCE->dfile.string) pCE->dfile.string = empty; ! if (!pCE->lfile.string) pCE->lfile.string = empty; ! if (!pCE->networkConsoleHost.string) pCE->networkConsoleHost.string = empty; ! if (!pCE->consoleChat.string) ! pCE->consoleChat.string = empty; ! if (!pCE->acslave.string) pCE->acslave.string = empty; Debug(1, " server=%s, dfile=%s, lfile=%s", pCE->server.string, *************** *** 326,337 **** Debug(1, " isNetworkConsole=%d, networkConsoleHost=%s", pCE->isNetworkConsole, pCE->networkConsoleHost.string); ! Debug(1, ! " networkConsolePort=%d, telnetState=%d, autoReup=%d", ! pCE->networkConsolePort, pCE->telnetState, ! pCE->autoReUp); ! Debug(1, " baud=%s, parity=%c", pCE->pbaud->acrate, pCE->pparity->ckey); Debug(1, " fvirtual=%d, acslave=%s, pccmd=%s, ipid=%d", --- 344,356 ---- Debug(1, " isNetworkConsole=%d, networkConsoleHost=%s", pCE->isNetworkConsole, pCE->networkConsoleHost.string); ! Debug(1, " networkConsolePort=%d, telnetState=%d, autoReup=%d", ! pCE->networkConsolePort, pCE->telnetState, pCE->autoReUp); ! Debug(1, " consoleChat='%s'", pCE->consoleChat.string); ! Debug(1, " doneChat=%d, baud=%s, parity=%c", ! pCE->doneChat, ! pCE->pbaud->acrate, pCE->pparity->ckey); Debug(1, " fvirtual=%d, acslave=%s, pccmd=%s, ipid=%d", *************** *** 344,355 **** Debug(1, " ------"); } } ! for (pRC = pRCList; (REMOTE *) 0 != pRC; pRC = pRC->pRCnext) { ! if (pRC->rserver.string == (char *)0) pRC->rserver.string = empty; ! if (pRC->rhost.string == (char *)0) pRC->rhost.string = empty; ! Debug(1, "Remote: rserver=%s, rhost =%s", pRC->rserver.string, pRC->rhost.string); } } --- 363,374 ---- Debug(1, " ------"); } } ! for (pRC = pRCList; pRC; pRC = pRC->pRCnext) { ! if (!pRC->rserver.string) pRC->rserver.string = empty; ! if (!pRC->rhost.string) pRC->rhost.string = empty; ! Debug(1, "Remote: rserver=%s, rhost=%s", pRC->rserver.string, pRC->rhost.string); } } *************** *** 373,380 **** { int i; FILE *fpConfig; struct hostent *hpMe; ! static char acOpts[] = "7a:b:C:dDhiL:m:M:noO:p:P:suVv"; extern int optopt; extern char *optarg; struct passwd *pwd; --- 392,400 ---- { int i; FILE *fpConfig; + FILE *fpChat; struct hostent *hpMe; ! static char acOpts[] = "7a:b:C:dDhiL:m:M:nNoO:p:P:suvV"; extern int optopt; extern char *optarg; struct passwd *pwd; *************** *** 444,452 **** case 'b': pcBasePort = optarg; break; ! case 'C': pcConfig = optarg; break; case 'd': fDaemon = 1; fUseLogfile = 1; --- 464,475 ---- case 'b': pcBasePort = optarg; break; ! case 'c': pcConfig = optarg; break; + case 'C': + pcChat = optarg; + break; case 'd': fDaemon = 1; fUseLogfile = 1; *************** *** 473,478 **** --- 496,504 ---- case 'n': /* noop now */ break; + case 'N': + fDoNotRun = 1; + break; case 'o': /* try reopening downed consoles on connect */ fReopen = 1; *************** *** 624,646 **** Error("fopen: %s: %s", pcConfig, strerror(errno)); exit(EX_UNAVAILABLE); } ! #if HAVE_FLOCK ! /* we lock the configuration file so that two identical ! * conservers will not be running together (but two with ! * different configurations can run on the same host). ! */ ! if (-1 == flock(fileno(fpConfig), LOCK_NB | LOCK_EX)) { ! Error("%s is locked, won\'t run more than one conserver?", ! pcConfig); ! exit(EX_UNAVAILABLE); } #endif ReadCfg(pcConfig, fpConfig); if (pGroups == (GRPENT *) 0 && pRCList == (REMOTE *) 0) { Error("No consoles found in configuration file"); ! } else { /* if no one can use us we need to come up with a default */ if (pACList == (ACCESS *) 0) { --- 650,680 ---- Error("fopen: %s: %s", pcConfig, strerror(errno)); exit(EX_UNAVAILABLE); } ! #if HAVE_FLOCK /* XXX fcntl() is infinitely more portable! */ ! if (!fDoNotRun) { ! /* we lock the configuration file so that two identical ! * conservers will not be running together (but two with ! * different configurations can run on the same host). ! */ ! if (-1 == flock(fileno(fpConfig), LOCK_NB | LOCK_EX)) { ! Error("%s is locked -- conserver already running, or is file being edited?", ! pcConfig); ! exit(EX_UNAVAILABLE); ! } } #endif ReadCfg(pcConfig, fpConfig); + /* Note: don't close fpConfig until we exit in order to keep lock... */ + + if ((fpChat = fopen(pcChat, "r"))) { + ReadChat(pcChat, fpChat); + fclose(fpChat); + } if (pGroups == (GRPENT *) 0 && pRCList == (REMOTE *) 0) { Error("No consoles found in configuration file"); ! } else if (!fDoNotRun) { /* if no one can use us we need to come up with a default */ if (pACList == (ACCESS *) 0) { Index: conserver/group.c =================================================================== RCS file: /cvs/misc/conserver/conserver/group.c,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 group.c *** conserver/group.c 24 Apr 2002 21:42:00 -0000 1.1.1.3 --- conserver/group.c 2 May 2002 02:45:09 -0000 *************** *** 65,70 **** --- 65,72 ---- #include #include #include + #include + #include #include #if USE_ANSI_PROTO #include *************** *** 98,103 **** --- 100,108 ---- static sig_atomic_t fSawReOpen = 0, fSawReUp = 0, fSawMark = 0, fSawGoAway = 0, fSawReapVirt = 0; + static int DoTelnet __P((CONSENT *, int, unsigned char *, unsigned char *)); + static int ConsChat __P((CONSENT *)); + void #if USE_ANSI_PROTO SendClientsMsg(CONSENT * pCE, char *message) *************** *** 1313,1322 **** /* open all the files we need for the consoles in our group * if we can't get one (bitch and) flag as down */ ! if (!fNoinit) for (pCE = pGE->pCElist; pCE != (CONSENT *) 0; pCE = pCE->pCEnext) { ConsInit(pCE, &pGE->rinit, 1); } /* set up the list of free connection slots */ --- 1318,1328 ---- /* open all the files we need for the consoles in our group * if we can't get one (bitch and) flag as down */ ! if (!fNoinit) { for (pCE = pGE->pCElist; pCE != (CONSENT *) 0; pCE = pCE->pCEnext) { ConsInit(pCE, &pGE->rinit, 1); } + } /* set up the list of free connection slots */ *************** *** 1401,1406 **** --- 1407,1417 ---- if (!pCEServing->fup || !FD_ISSET(pCEServing->fdtty, &rmask)) { continue; } + if (!pCEServing->isNetworkConsole && !pCEServing->doneChat) { + if (pCEServing->consoleChat.string && pCEServing->consoleChat.used) { + pCEServing->doneChat = ConsChat(pCEServing); + } + } /* read terminal line */ if ((nr = read(pCEServing->fdtty, acInOrig, *************** *** 1433,1484 **** Debug(1, "Read %d bytes from fd %d", nr, pCEServing->fdtty); if (pCEServing->isNetworkConsole) { ! /* Do a little Telnet Protocol interpretation ! * state = 0: normal ! * = 1: Saw a IAC char ! * = 2: Saw a DONT/DO/WONT/WILL command ! * = 5: Saw a \r ! */ ! int new = 0, state; ! state = pCEServing->telnetState; ! for (i = 0; i < nr; ++i) { ! if (state == 0 && acInOrig[i] == IAC) { ! Debug(1, "%s: Got telnet `IAC'", ! pCEServing->server.string); ! state = 1; ! } else if (state == 1 && acInOrig[i] != IAC) { ! Debug(1, "%s: Got telnet cmd `%u'", ! pCEServing->server.string, acInOrig[i]); ! if (acInOrig[i] == DONT || acInOrig[i] == DO || ! acInOrig[i] == WILL || acInOrig[i] == WONT) ! state = 2; ! else ! state = 0; ! } else if (state == 2) { ! Debug(1, "%s: Got telnet option `%u'", ! pCEServing->server.string, acInOrig[i]); ! state = 0; ! } else { ! if (state == 5) { ! state = 0; ! if (acInOrig[i] == '\000') ! continue; ! } ! if (acInOrig[i] == IAC) ! Debug(1, "%s: Quoted `IAC'", ! pCEServing->server.string); ! if (fStrip) ! acIn[new++] = acInOrig[i] & 127; ! else ! acIn[new++] = acInOrig[i]; ! if (acInOrig[i] == '\r') ! state = 5; ! else ! state = 0; ! } ! } ! pCEServing->telnetState = state; ! nr = new; } else { for (i = 0; i < nr; ++i) { if (fStrip) --- 1444,1450 ---- Debug(1, "Read %d bytes from fd %d", nr, pCEServing->fdtty); if (pCEServing->isNetworkConsole) { ! nr = DoTelnet(pCEServing, nr, acInOrig, acIn); } else { for (i = 0; i < nr; ++i) { if (fStrip) *************** *** 1487,1492 **** --- 1453,1463 ---- acIn[i] = acInOrig[i]; } } + if (pCEServing->isNetworkConsole && !pCEServing->doneChat) { + if (pCEServing->consoleChat.string && pCEServing->consoleChat.used) { + pCEServing->doneChat = ConsChat(pCEServing); + } + } if (nr == 0) continue; *************** *** 1834,1841 **** /* try to reopen line if specified at server startup */ ! if ((fNoinit || fReopen) && !pCEServing->fup) ConsInit(pCEServing, &pGE->rinit, 0); /* try for attach on new console */ --- 1805,1813 ---- /* try to reopen line if specified at server startup */ ! if ((fNoinit || fReopen) && !pCEServing->fup) { ConsInit(pCEServing, &pGE->rinit, 0); + } /* try for attach on new console */ *************** *** 2939,2942 **** --- 2911,3100 ---- fileClose(&ssocket); Error("internal flow error"); exit(EX_UNAVAILABLE); + } + + + /* Do a little Telnet Protocol interpretation + * state = 0: normal + * = 1: Saw a IAC char + * = 2: Saw a DONT/DO/WONT/WILL command + * = 5: Saw a \r + */ + static int + DoTelnet(pCEServing, nr, acInOrig, acIn) + CONSENT *pCEServing; + int nr; + unsigned char acInOrig[]; + unsigned char acIn[]; + { + int i; + int new = 0; + int state; + + state = pCEServing->telnetState; + for (i = 0; i < nr; ++i) { + if (state == 0 && acInOrig[i] == IAC) { + Debug(1, "%s: Got telnet `IAC'", + pCEServing->server.string); + state = 1; + } else if (state == 1 && acInOrig[i] != IAC) { + Debug(1, "%s: Got telnet cmd `%u'", + pCEServing->server.string, acInOrig[i]); + if (acInOrig[i] == DONT || acInOrig[i] == DO || + acInOrig[i] == WILL || acInOrig[i] == WONT) { + state = 2; + } else { + state = 0; + } + } else if (state == 2) { + Debug(1, "%s: Got telnet option `%u'", + pCEServing->server.string, acInOrig[i]); + state = 0; + } else { + if (state == 5) { + state = 0; + if (acInOrig[i] == '\000') { + continue; + } + } + if (acInOrig[i] == IAC) { + Debug(1, "%s: Quoted `IAC'", + pCEServing->server.string); + } + if (fStrip) { + acIn[new++] = acInOrig[i] & 127; + } else { + acIn[new++] = acInOrig[i]; + } + if (acInOrig[i] == '\r') { + state = 5; + } else { + state = 0; + } + } + } + pCEServing->telnetState = state; + + return new; + } + + /* + * ConsChat() - run the chat program with ChatString + * + * returns true if the script succeeded (chat exit status of 0) + */ + static int + ConsChat(pCE) + CONSENT *pCE; + { + int ConsTTY = pCE->fdtty; + int isNetworkConsole = pCE->isNetworkConsole; + char *ChatString = pCE->consoleChat.string; + int retries = 5; /* try hard to fork() */ + int cstatus; + int pid; + int fd; + char *ChatCommand; + + (void) fflush(stdout); + (void) fflush(stderr); + + /* + * WARNING: we cannot use vfork() due to the file descriptor tricks we + * have to play in the child.... + */ + while ((pid = fork()) < 0 && errno == EAGAIN && --retries >= 0) { + Debug(1, "ConsChat: fork() said EAGAIN!"); + (void) sleep(2); /* sleep a bit between retries */ + } + switch (pid) { + case -1: + Error("ConsChat(): fork(): %s", strerror(errno)); + break; + default: /* PARENT */ + re_wait: + while (waitpid(pid, &cstatus, 0) < 0) { + if (errno == EINTR) { + continue; + } + Error("ConsChat: error waiting for chat process: %s", + strerror(errno)); + } + if (WIFEXITED(cstatus)) { + Debug((WEXITSTATUS(cstatus) == 0) ? 2 : 1, + "ConsChat: chat exited on fd %d with status %d", + ConsTTY, WEXITSTATUS(cstatus)); + } else if (WIFSIGNALED(cstatus)) { + Error("ConsChat: chat died on fd %s with signal %d", + ConsTTY, WTERMSIG(cstatus)); + } else if (WIFSTOPPED(cstatus)) { + Error("ConsChat: chat stopped on fd %s with signal %d", + ConsTTY, WSTOPSIG(cstatus)); + kill(pid, SIGCONT); + goto re_wait; + } else { + Error("ConsChat: bad status from chat process: \\0%o", cstatus); + } + break; + case 0: /* CHILD */ + /* + * This is rather sleazy, but is also what pppd does -- we use + * the shell to break the chat string down into its separate + * arguments.... (or a chat file could be specified) + * + * Note we do the malloc() in the child so we don't have to + * worry about any memory leak.... :-) + */ + ChatCommand = malloc(strlen(PATH_CHAT) + sizeof(" -I -sSvV ") + strlen(ChatString)); + if (!ChatCommand) { + Error("ConsChat: malloc() failed: %s", strerror(errno)); + exit(1); + } + strcpy(ChatCommand, PATH_CHAT); + strcat(ChatCommand, isNetworkConsole ? " -I" : ""); + strcat(ChatCommand, fVerbose ? " -sSvV " : " -sS "); + strcat(ChatCommand, ChatString); + + Debug(2, "ConsChat: starting: /bin/sh -c '%s' on fd %d", ChatCommand, ConsTTY); + /* + * if we want this to work properly with a real TTY then we + * want the child process to become a session leader and to + * establish the console tty as its controlling terminal.... + * + * XXX is dup2() sufficient to trigger allocation of a + * controlling terminal? + */ + setsid(); + if (dup2(ConsTTY, STDIN_FILENO) != STDIN_FILENO) { + Error("ConsChat(): dup2(stdin): %s", strerror(errno)); + exit(1); + } + if (dup2(ConsTTY, STDOUT_FILENO) != STDOUT_FILENO) { + Error("ConsChat(): dup2(stdout): %s", strerror(errno)); + exit(1); + } + close(ConsTTY); /* pedantic... */ + + #if 0 && defined(_POSIX_JOB_CONTROL) /* XXX we may need to call tcsetpgrp()? */ + if (tcsetpgrp(0, getpid()) == -1) { + Error("ConsChat(): tcsetpgrp(stdin, getpid()): %s", strerror(errno)); + exit(1); + } + #endif + /* close all fds > STDERR_FILENO */ + for (fd = (STDERR_FILENO + 1); fd < getdtablesize(); fd++) { + (void) close(fd); + } + /* leave stderr alone -- it will be open to the log file */ + + execl("/bin/sh", "sh", "-c", ChatCommand, (char *) NULL); + + Error("ConsChat(): execl(%s): %s", PATH_CHAT, strerror(errno)); + exit(1); + } + if (WIFEXITED(cstatus)) { + return (WEXITSTATUS(cstatus) == 0); + } + + return 0; } Index: conserver/consent.h =================================================================== RCS file: /cvs/misc/conserver/conserver/consent.h,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 consent.h *** conserver/consent.h 24 Apr 2002 21:42:00 -0000 1.1.1.3 --- conserver/consent.h 1 May 2002 23:22:55 -0000 *************** *** 62,74 **** int mark; /* Mark (chime) interval */ long nextMark; /* Next mark (chime) time */ short int breakType; /* break type [1-9] */ ! int autoReUp; /* Used if network console */ ! int isNetworkConsole; ! STRING networkConsoleHost; ! int networkConsolePort; ! int telnetState; /* used if virtual console */ STRING acslave; /* pseudo-device slave side */ --- 62,76 ---- int mark; /* Mark (chime) interval */ long nextMark; /* Next mark (chime) time */ short int breakType; /* break type [1-9] */ ! int autoReUp; /* ???? */ ! STRING consoleChat; /* chat script to run on Init */ ! int doneChat; /* have we run the chat script? */ /* Used if network console */ ! int isNetworkConsole; /* flag identifying this as a network connected console */ ! STRING networkConsoleHost; /* hostname where network connection is made */ ! int networkConsolePort; /* TCP port number to connect to on host */ ! int telnetState; /* telnet protocol state machinery state */ /* used if virtual console */ STRING acslave; /* pseudo-device slave side */ *************** *** 103,109 **** extern void ConsDown(CONSENT *, fd_set *); extern int CheckHostCache(const char *); extern void AddHostCache(const char *); ! extern void ClearHostCache(); #else extern PARITY *FindParity(); extern BAUD *FindBaud(); --- 105,111 ---- extern void ConsDown(CONSENT *, fd_set *); extern int CheckHostCache(const char *); extern void AddHostCache(const char *); ! extern void ClearHostCache(void); #else extern PARITY *FindParity(); extern BAUD *FindBaud(); Index: conserver/consent.c =================================================================== RCS file: /cvs/misc/conserver/conserver/consent.c,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 consent.c *** conserver/consent.c 24 Apr 2002 21:42:00 -0000 1.1.1.3 --- conserver/consent.c 1 May 2002 23:30:13 -0000 *************** *** 48,53 **** --- 48,54 ---- #include #include #include + #include #include #include #include *************** *** 124,133 **** , /* even */ {'m', PARENB | CS7 | PARODD | PAREXT, 0} , /* mark */ {'o', PARENB | CS7 | PARODD, 0} , /* odd */ {'p', CS8, 0} ! , /* pass 8 bits, no parity */ {'s', PARENB | CS7 | PAREXT, 0} , /* space */ #else /* ! HAVE_TERMIOS_H */ --- 125,136 ---- , /* even */ {'m', PARENB | CS7 | PARODD | PAREXT, 0} , /* mark */ + {'n', CS8, 0} + , /* pass 8 bits, no parity */ {'o', PARENB | CS7 | PARODD, 0} , /* odd */ {'p', CS8, 0} ! , /* pass 8 bits, no parity, old form */ {'s', PARENB | CS7 | PAREXT, 0} , /* space */ #else /* ! HAVE_TERMIOS_H */ *************** *** 139,144 **** --- 142,149 ---- , /* odd */ # if defined(PASS8) {'p', PASS8, EVENP | ODDP} + , /* pass 8 bits, no parity, old form */ + {'n', PASS8, EVENP | ODDP} , /* pass 8 bits, no parity */ # endif {'s', 0, EVENP | ODDP} /* space */ *************** *** 649,655 **** void #if USE_ANSI_PROTO ! ClearHostCache() #else ClearHostCache() #endif --- 654,660 ---- void #if USE_ANSI_PROTO ! ClearHostCache(void) #else ClearHostCache() #endif *************** *** 832,845 **** return; } } - - # if POKE_ANNEX - /* - * Poke the connection to get the annex to wake up and - * register this connection. - */ - write(pCE->fdtty, "\r\n", 2); - # endif } else if (-1 == (pCE->fdtty = open(pCE->dfile.string, O_RDWR | O_NDELAY, 0600))) { --- 837,842 ---- *************** *** 848,853 **** --- 845,853 ---- return; } FD_SET(pCE->fdtty, pfdSet); + + /* we'll need to re-run the chat script.... */ + pCE->doneChat = 0; /* ok, now setup the device */ Index: configure.in =================================================================== RCS file: /cvs/misc/conserver/configure.in,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 configure.in *** configure.in 24 Apr 2002 21:41:59 -0000 1.1.1.3 --- configure.in 2 May 2002 01:22:42 -0000 *************** *** 75,80 **** --- 75,93 ---- [AC_DEFINE_UNQUOTED(CONFIGFILE, "conserver.cf") AC_MSG_RESULT('$sysconfdir/conserver.cf')]) + AC_MSG_CHECKING(for chat-script filename) + AC_ARG_WITH(chatfile, + AC_HELP_STRING([--with-chatfile=CHATFILE],[Specify chat-script filename @<:@conserver.chat@:>@]), + [if test "$withval" != yes; then + AC_DEFINE_UNQUOTED(CHATFILE, "$withval") + AC_MSG_RESULT('$sysconfdir/$withval') + else + AC_DEFINE_UNQUOTED(CHATFILE, "conserver.chat") + AC_MSG_RESULT('$sysconfdir/conserver.chat') + fi], + [AC_DEFINE_UNQUOTED(CHATFILE, "conserver.chat") + AC_MSG_RESULT('$sysconfdir/conserver.chat')]) + AC_MSG_CHECKING(for password filename) AC_ARG_WITH(pwdfile, AC_HELP_STRING([--with-pwdfile=PWDFILE],[Specify password filename @<:@conserver.passwd@:>@]), *************** *** 140,145 **** --- 153,171 ---- [AC_DEFINE_UNQUOTED(CONNECTTIMEOUT, 10) AC_MSG_RESULT(10)]) + AC_MSG_CHECKING(for chat program) + AC_ARG_WITH(chat, + AC_HELP_STRING([--with-chat=/path/to/chat],[Specify pathname to chat program @<:@chat@:>@]), + [if test "$withval" != yes; then + AC_DEFINE_UNQUOTED(PATH_CHAT, "$withval") + AC_MSG_RESULT('$withval') + else + AC_DEFINE_UNQUOTED(PATH_CHAT, "chat") + AC_MSG_RESULT('chat') + fi], + [AC_DEFINE_UNQUOTED(PATH_CHAT, "chat") + AC_MSG_RESULT('chat')]) + dnl ### Check for compiler et al. ################################### AC_PROG_CC AC_PROG_INSTALL *************** *** 294,298 **** dnl ### Create output files. ####################################### AC_SUBST(LIBOBJS) ! AC_CONFIG_FILES([Makefile conserver/Makefile conserver.cf/Makefile console/Makefile autologin/Makefile]) AC_OUTPUT --- 320,324 ---- dnl ### Create output files. ####################################### AC_SUBST(LIBOBJS) ! AC_CONFIG_FILES([Makefile chat/Makefile conserver/Makefile conserver.cf/Makefile console/Makefile autologin/Makefile]) AC_OUTPUT Index: acconfig.h =================================================================== RCS file: /cvs/misc/conserver/acconfig.h,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 acconfig.h *** acconfig.h 24 Apr 2002 21:41:58 -0000 1.1.1.3 --- acconfig.h 1 May 2002 19:38:59 -0000 *************** *** 24,29 **** --- 24,34 ---- #undef CONFIGFILE /* + * Config file path + */ + #undef CHATFILE + + /* * Password file path */ #undef PASSWDFILE *************** *** 32,37 **** --- 37,47 ---- * Logfile path */ #undef LOGFILEPATH + + /* + * path to chat program + */ + #undef PATH_CHAT /* * Number of consoles per child process Index: Makefile.in =================================================================== RCS file: /cvs/misc/conserver/Makefile.in,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 Makefile.in *** Makefile.in 5 Dec 2001 20:36:45 -0000 1.1.1.1 --- Makefile.in 2 May 2002 01:22:25 -0000 *************** *** 12,18 **** ### Makefile rules - no user-servicable parts below ! SUBDIRS = conserver console conserver.cf all: for n in $(SUBDIRS); do \ --- 12,18 ---- ### Makefile rules - no user-servicable parts below ! SUBDIRS = chat conserver console conserver.cf all: for n in $(SUBDIRS); do \ cvs diff: Diffing chat Index: chat/Makefile.in =================================================================== RCS file: chat/Makefile.in diff -N chat/Makefile.in *** /dev/null 1 Jan 1970 00:00:00 -0000 --- chat/Makefile.in 2 May 2002 01:21:07 -0000 *************** *** 0 **** --- 1,52 ---- + ### Path settings + srcdir = @srcdir@ + top_srcdir = @top_srcdir@ + prefix = @prefix@ + exec_prefix = @exec_prefix@ + bindir = @bindir@ + sysconfdir = @sysconfdir@ + mandir = @mandir@ + + ### Installation programs and flags + INSTALL = @INSTALL@ + INSTALL_PROGRAM = @INSTALL_PROGRAM@ -s + LN_S = @LN_S@ + MKDIR = @MKDIR@ + + ### Compiler and link options + CC = @CC@ + CFLAGS = @CFLAGS@ + DEFS = @DEFS@ + CPPFLAGS = -I$(top_srcdir) -I$(srcdir) $(DEFS) @CPPFLAGS@ + LDFLAGS = @LDFLAGS@ + LIBS = @LIBS@ + @SET_MAKE@ + + + ### Makefile rules - no user-servicable parts below + + CHAT_OBJS = chat.o + CHAT_HDRS = ../config.h + ALL = chat + + all: $(ALL) + + chat: $(CHAT_OBJS) + $(CC) $(CFLAGS) $(LDFLAGS) -o chat $(CHAT_OBJS) $(LIBS) + + .c.o: + $(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $< + + clean: + rm -f *~ *.o $(ALL) core + + distclean: clean + rm -f Makefile + + install: chat + $(MKDIR) $(DESTDIR)$(bindir) + $(INSTALL_PROGRAM) chat $(DESTDIR)$(bindir) + $(MKDIR) $(DESTDIR)$(mandir)/man1 + $(INSTALL) chat.man $(DESTDIR)$(mandir)/man1/chat.1 + + .PHONY: clean distclean install Index: chat/chat.c =================================================================== RCS file: chat/chat.c diff -N chat/chat.c *** /dev/null 1 Jan 1970 00:00:00 -0000 --- chat/chat.c 2 May 2002 01:16:33 -0000 *************** *** 0 **** --- 1,1754 ---- + /* + * Chat -- a program for automatic session establishment (i.e. dial + * the phone and log in). + * + * Standard termination codes: + * 0 - successful completion of the script + * 1 - invalid argument, expect string too large, etc. + * 2 - error on an I/O operation or fatal error condition. + * 3 - timeout waiting for a simple string. + * 4 - the first string declared as "ABORT" + * 5 - the second string declared as "ABORT" + * 6 - ... and so on for successive ABORT strings. + * + * This software is in the public domain. + * + * ----------------- + * 22-May-99 added environment substitutuion, enabled with -E switch. + * Andreas Arens . + * + * 12-May-99 added a feature to read data to be sent from a file, + * if the send string starts with @. Idea from gpk . + * + * added -T and -U option and \T and \U substitution to pass a phone + * number into chat script. Two are needed for some ISDN TA applications. + * Keith Dart + * + * + * Added SAY keyword to send output to stderr. + * This allows to turn ECHO OFF and to output specific, user selected, + * text to give progress messages. This best works when stderr + * exists (i.e.: pppd in nodetach mode). + * + * Added HANGUP directives to allow for us to be called + * back. When HANGUP is set to NO, chat will not hangup at HUP signal. + * We rely on timeouts in that case. + * + * Added CLR_ABORT to clear previously set ABORT string. This has been + * dictated by the HANGUP above as "NO CARRIER" (for example) must be + * an ABORT condition until we know the other host is going to close + * the connection for call back. As soon as we have completed the + * first stage of the call back sequence, "NO CARRIER" is a valid, non + * fatal string. As soon as we got called back (probably get "CONNECT"), + * we should re-arm the ABORT "NO CARRIER". Hence the CLR_ABORT command. + * Note that CLR_ABORT packs the abort_strings[] array so that we do not + * have unused entries not being reclaimed. + * + * In the same vein as above, added CLR_REPORT keyword. + * + * Allow for comments. Line starting with '#' are comments and are + * ignored. If a '#' is to be expected as the first character, the + * expect string must be quoted. + * + * + * Francis Demierre + * Thu May 15 17:15:40 MET DST 1997 + * + * + * Added -r "report file" switch & REPORT keyword. + * Robert Geer + * + * Added -s "use stderr" and -S "don't use syslog" switches. + * June 18, 1997 + * Karl O. Pinc + * + * + * Added -e "echo" switch & ECHO keyword + * Dick Streefland + * + * + * Considerable updates and modifications by + * Al Longyear + * Paul Mackerras + * + * + * The original author is: + * + * Karl Fox + * Morning Star Technologies, Inc. + * 1760 Zollinger Road + * Columbus, OH 43221 + * (614)451-1883 + * + */ + + #ifndef __STDC__ + #define const + #endif + + #include + #ifndef lint + static const char rcsid[] = "Id: chat.c,v 1.26 1999/12/23 01:39:54 paulus Exp "; + #endif + + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + #include + + #ifndef TERMIO + #undef TERMIOS + #define TERMIOS + #endif + + #ifdef TERMIO + #include + #endif + #ifdef TERMIOS + #include + #endif + + #define STR_LEN 1024 + + #ifndef SIGTYPE + #define SIGTYPE void + #endif + + #undef __P + #undef __V + + #ifdef __STDC__ + #include + #define __V(x) x + #define __P(x) x + #else + #include + #define __V(x) (va_alist) va_dcl + #define __P(x) () + #define const + #endif + + #ifndef O_NONBLOCK + #define O_NONBLOCK O_NDELAY + #endif + + #ifdef SUNOS + extern int sys_nerr; + extern char *sys_errlist[]; + #define memmove(to, from, n) bcopy(from, to, n) + #define strerror(n) ((unsigned)(n) < sys_nerr? sys_errlist[(n)] :\ + "unknown error") + #endif + + char *program_name; + + #define MAX_ABORTS 50 + #define MAX_REPORTS 50 + #define DEFAULT_CHAT_TIMEOUT 45 + + int echo = 0; + int verbose = 0; + int to_log = 1; + int to_stderr = 0; + int Verbose = 0; + int quiet = 0; + int report = 0; + int use_env = 0; + int exit_code = 0; + int do_set_tty = 1; + FILE* report_fp = (FILE *) 0; + char *report_file = (char *) 0; + char *chat_file = (char *) 0; + char *phone_num = (char *) 0; + char *phone_num2 = (char *) 0; + int timeout = DEFAULT_CHAT_TIMEOUT; + + int have_tty_parameters = 0; + + #ifdef TERMIO + #define term_parms struct termio + #define get_term_param(param) ioctl(0, TCGETA, param) + #define set_term_param(param) ioctl(0, TCSETA, param) + struct termio saved_tty_parameters; + #endif + + #ifdef TERMIOS + #define term_parms struct termios + #define get_term_param(param) tcgetattr(0, param) + #define set_term_param(param) tcsetattr(0, TCSANOW, param) + struct termios saved_tty_parameters; + #endif + + char *abort_string[MAX_ABORTS], *fail_reason = (char *)0, + fail_buffer[50]; + int n_aborts = 0, abort_next = 0, timeout_next = 0, echo_next = 0; + int clear_abort_next = 0; + + char *report_string[MAX_REPORTS] ; + char report_buffer[50] ; + int n_reports = 0, report_next = 0, report_gathering = 0 ; + int clear_report_next = 0; + + int say_next = 0, hup_next = 0; + + void *dup_mem __P((void *b, size_t c)); + void *copy_of __P((char *s)); + void usage __P((void)); + void logf __P((const char *fmt, ...)); + void fatal __P((int code, const char *fmt, ...)); + SIGTYPE sigalrm __P((int signo)); + SIGTYPE sigint __P((int signo)); + SIGTYPE sigterm __P((int signo)); + SIGTYPE sighup __P((int signo)); + void unalarm __P((void)); + void init __P((void)); + void set_tty_parameters __P((void)); + void echo_stderr __P((int)); + void break_sequence __P((void)); + void terminate __P((int status)); + void do_file __P((char *chat_file)); + int get_string __P((register char *string)); + int put_string __P((register char *s)); + int write_char __P((int c)); + int put_char __P((int c)); + int get_char __P((void)); + void chat_send __P((register char *s)); + char *character __P((int c)); + void chat_expect __P((register char *s)); + char *clean __P((register char *s, int sending)); + void break_sequence __P((void)); + void pack_array __P((char **array, int end)); + char *expect_strtok __P((char *, char *)); + int vfmtmsg __P((char *, int, const char *, va_list)); /* vsprintf++ */ + + int main __P((int, char *[])); + + void *dup_mem(b, c) + void *b; + size_t c; + { + void *ans = malloc (c); + if (!ans) + fatal(2, "memory error!"); + + memcpy (ans, b, c); + return ans; + } + + void *copy_of (s) + char *s; + { + return dup_mem (s, strlen (s) + 1); + } + + /* + * chat [ -eEIsSvV ] [ -T number ] [ -U number ] [ -t timeout ] [ -f chat-file ] \ + * [ -r report-file ] \ + * [...[[expect[-say[-expect...]] say expect[-say[-expect]] ...]]] + * + * Perform a UUCP-dialer-like chat script on stdin and stdout. + */ + int + main(argc, argv) + int argc; + char **argv; + { + int option; + int i; + + program_name = *argv; + tzset(); + + while ((option = getopt(argc, argv, ":eEf:Ir:sSt:T:U:vV")) != -1) { + switch (option) { + case 'e': + ++echo; + break; + + case 'E': + ++use_env; + break; + + case 'v': + ++verbose; + break; + + case 'V': + ++Verbose; + break; + + case 's': + ++to_stderr; + break; + + case 'S': + to_log = 0; + break; + + case 'f': + if (optarg != NULL) + chat_file = copy_of(optarg); + else + usage(); + break; + + case 't': + if (optarg != NULL) + timeout = atoi(optarg); + else + usage(); + break; + + case 'I': + do_set_tty = 0; + break; + + case 'r': + if (optarg) { + if (report_fp != NULL) + fclose (report_fp); + report_file = copy_of (optarg); + report_fp = fopen (report_file, "a"); + if (report_fp != NULL) { + if (verbose) + fprintf (report_fp, "Opening \"%s\"...\n", + report_file); + report = 1; + } + } + break; + + case 'T': + if (optarg != NULL) + phone_num = copy_of(optarg); + else + usage(); + break; + + case 'U': + if (optarg != NULL) + phone_num2 = copy_of(optarg); + else + usage(); + break; + + default: + usage(); + break; + } + } + argc -= optind; + argv += optind; + /* + * Default the report file to the stderr location + */ + if (report_fp == NULL) + report_fp = stderr; + + if (to_log) { + #ifdef ultrix + openlog("chat", LOG_PID); + #else + openlog("chat", LOG_PID | LOG_NDELAY, LOG_LOCAL2); + + if (verbose) + setlogmask(LOG_UPTO(LOG_INFO)); + else + setlogmask(LOG_UPTO(LOG_WARNING)); + #endif + } + + init(); + + if (chat_file != NULL) { + if (argc) + usage(); + else + do_file (chat_file); + } else { + for (i = 0; i < argc; i++) { + chat_expect(argv[i]); + if (++i < argc) + chat_send(argv[i]); + } + } + + terminate(0); + return 0; + } + + /* + * Process a chat script when read from a file. + */ + + void do_file (chat_file) + char *chat_file; + { + int linect, sendflg; + char *sp, *arg, quote; + char buf [STR_LEN]; + FILE *cfp; + + cfp = fopen (chat_file, "r"); + if (cfp == NULL) + fatal(1, "%s -- open failed: %m", chat_file); + + linect = 0; + sendflg = 0; + + while (fgets(buf, STR_LEN, cfp) != NULL) { + sp = strchr (buf, '\n'); + if (sp) + *sp = '\0'; + + linect++; + sp = buf; + + /* lines starting with '#' are comments. If a real '#' + is to be expected, it should be quoted .... */ + if ( *sp == '#' ) + continue; + + while (*sp != '\0') { + if (*sp == ' ' || *sp == '\t') { + ++sp; + continue; + } + + if (*sp == '"' || *sp == '\'') { + quote = *sp++; + arg = sp; + while (*sp != quote) { + if (*sp == '\0') + fatal(1, "unterminated quote (line %d)", linect); + + if (*sp++ == '\\') { + if (*sp != '\0') + ++sp; + } + } + } + else { + arg = sp; + while (*sp != '\0' && *sp != ' ' && *sp != '\t') + ++sp; + } + + if (*sp != '\0') + *sp++ = '\0'; + + if (sendflg) + chat_send (arg); + else + chat_expect (arg); + sendflg = !sendflg; + } + } + fclose (cfp); + } + + /* + * We got an error parsing the command line. + */ + void usage() + { + fprintf(stderr, "\ + Usage: %s [-eEIsSvV] [-t timeout] [-r report-file]\n\ + [-T phone-number] [-U phone-number2]\n\ + {-f chat-file | chat-script}\n\ + Chat-Script: [...[[expect[-say[-expect...]] say expect[-say[-expect]] ...]]]\n", + program_name); + exit(1); + } + + char line[1024]; + + /* + * Send a message to syslog and/or stderr. + */ + void logf __V((const char *fmt, ...)) + { + va_list args; + + #ifdef __STDC__ + va_start(args, fmt); + #else + char *fmt; + va_start(args); + fmt = va_arg(args, char *); + #endif + + vfmtmsg(line, sizeof(line), fmt, args); + if (to_log) + syslog(LOG_INFO, "%s", line); + if (to_stderr) + fprintf(stderr, "%s\n", line); + } + + /* + * Print an error message and terminate. + */ + + void fatal __V((int code, const char *fmt, ...)) + { + va_list args; + + #ifdef __STDC__ + va_start(args, fmt); + #else + int code; + char *fmt; + va_start(args); + code = va_arg(args, int); + fmt = va_arg(args, char *); + #endif + + vfmtmsg(line, sizeof(line), fmt, args); + if (to_log) + syslog(LOG_ERR, "%s", line); + if (to_stderr) + fprintf(stderr, "%s\n", line); + terminate(code); + } + + int alarmed = 0; + + SIGTYPE sigalrm(signo) + int signo; + { + int flags; + + alarm(1); + alarmed = 1; /* Reset alarm to avoid race window */ + signal(SIGALRM, sigalrm); /* that can cause hanging in read() */ + + if ((flags = fcntl(0, F_GETFL, 0)) == -1) + fatal(2, "Can't get file mode flags on stdin: %m"); + + if (fcntl(0, F_SETFL, flags | O_NONBLOCK) == -1) + fatal(2, "Can't set file mode flags on stdin: %m"); + + if (verbose) + logf("alarm"); + } + + void unalarm() + { + int flags; + + if ((flags = fcntl(0, F_GETFL, 0)) == -1) + fatal(2, "Can't get file mode flags on stdin: %m"); + + if (fcntl(0, F_SETFL, flags & ~O_NONBLOCK) == -1) + fatal(2, "Can't set file mode flags on stdin: %m"); + } + + SIGTYPE sigint(signo) + int signo; + { + fatal(2, "SIGINT"); + } + + SIGTYPE sigterm(signo) + int signo; + { + fatal(2, "SIGTERM"); + } + + SIGTYPE sighup(signo) + int signo; + { + fatal(2, "SIGHUP"); + } + + void init() + { + signal(SIGINT, sigint); + signal(SIGTERM, sigterm); + signal(SIGHUP, sighup); + + set_tty_parameters(); + signal(SIGALRM, sigalrm); + alarm(0); + alarmed = 0; + } + + void set_tty_parameters() + { + term_parms t; + + if (!do_set_tty) + return; + + #if defined(get_term_param) + if (get_term_param (&t) < 0) + fatal(2, "Can't get terminal parameters: %m"); + + saved_tty_parameters = t; + have_tty_parameters = 1; + + t.c_iflag |= IGNBRK | ISTRIP | IGNPAR; + t.c_oflag |= OPOST | ONLCR; + t.c_lflag = 0; + t.c_cc[VERASE] = + t.c_cc[VKILL] = 0; + t.c_cc[VMIN] = 1; + t.c_cc[VTIME] = 0; + + if (set_term_param (&t) < 0) + fatal(2, "Can't set terminal parameters: %m"); + #endif + } + + void break_sequence() + { + #ifdef TERMIOS + tcsendbreak (0, 0); + #endif + } + + void terminate(status) + int status; + { + static int terminating = 0; + + if (terminating) + exit(status); + terminating = 1; + echo_stderr(-1); + /* + * Allow the last of the report string to be gathered before we terminate. + */ + if (report_gathering) { + int c, rep_len; + + rep_len = strlen(report_buffer); + while (rep_len + 1 <= sizeof(report_buffer)) { + alarm(1); + c = get_char(); + alarm(0); + if (c < 0 || iscntrl(c)) + break; + report_buffer[rep_len] = c; + ++rep_len; + } + report_buffer[rep_len] = 0; + fprintf (report_fp, "chat: %s\n", report_buffer); + } + if (report_file != (char *) 0 && report_fp != (FILE *) NULL) { + if (verbose) + fprintf (report_fp, "Closing \"%s\".\n", report_file); + fclose (report_fp); + report_fp = (FILE *) NULL; + } + + #if defined(get_term_param) + if (have_tty_parameters) { + if (set_term_param (&saved_tty_parameters) < 0) + fatal(2, "Can't restore terminal parameters: %m"); + } + #endif + + exit(status); + } + + /* + * 'Clean up' this string. + */ + char *clean(s, sending) + register char *s; + int sending; /* set to 1 when sending (putting) this string. */ + { + char temp[STR_LEN], env_str[STR_LEN], cur_chr; + register char *s1, *phchar; + int add_return = sending; + #define isoctal(chr) (((chr) >= '0') && ((chr) <= '7')) + #define isalnumx(chr) ((((chr) >= '0') && ((chr) <= '9')) \ + || (((chr) >= 'a') && ((chr) <= 'z')) \ + || (((chr) >= 'A') && ((chr) <= 'Z')) \ + || (chr) == '_') + + s1 = temp; + while (*s) { + cur_chr = *s++; + if (cur_chr == '^') { + cur_chr = *s++; + if (cur_chr == '\0') { + *s1++ = '^'; + break; + } + cur_chr &= 0x1F; + if (cur_chr != 0) { + *s1++ = cur_chr; + } + continue; + } + + if (use_env && cur_chr == '$') { /* ARI */ + phchar = env_str; + while (isalnumx(*s)) + *phchar++ = *s++; + *phchar = '\0'; + phchar = getenv(env_str); + if (phchar) + while (*phchar) + *s1++ = *phchar++; + continue; + } + + if (cur_chr != '\\') { + *s1++ = cur_chr; + continue; + } + + cur_chr = *s++; + if (cur_chr == '\0') { + if (sending) { + *s1++ = '\\'; + *s1++ = '\\'; + } + break; + } + + switch (cur_chr) { + case 'b': + *s1++ = '\b'; + break; + + case 'c': + if (sending && *s == '\0') + add_return = 0; + else + *s1++ = cur_chr; + break; + + case '\\': + case 'K': + case 'p': + case 'd': + if (sending) + *s1++ = '\\'; + *s1++ = cur_chr; + break; + + case 'T': + if (sending && phone_num) { + for (phchar = phone_num; *phchar != '\0'; phchar++) + *s1++ = *phchar; + } + else { + *s1++ = '\\'; + *s1++ = 'T'; + } + break; + + case 'U': + if (sending && phone_num2) { + for (phchar = phone_num2; *phchar != '\0'; phchar++) + *s1++ = *phchar; + } + else { + *s1++ = '\\'; + *s1++ = 'U'; + } + break; + + case 'q': + quiet = 1; + break; + + case 'r': + *s1++ = '\r'; + break; + + case 'n': + *s1++ = '\n'; + break; + + case 's': + *s1++ = ' '; + break; + + case 't': + *s1++ = '\t'; + break; + + case 'N': + if (sending) { + *s1++ = '\\'; + *s1++ = '\0'; + } + else + *s1++ = 'N'; + break; + + case '$': /* ARI */ + if (use_env) { + *s1++ = cur_chr; + break; + } + /* FALL THROUGH */ + + default: + if (isoctal (cur_chr)) { + cur_chr &= 0x07; + if (isoctal (*s)) { + cur_chr <<= 3; + cur_chr |= *s++ - '0'; + if (isoctal (*s)) { + cur_chr <<= 3; + cur_chr |= *s++ - '0'; + } + } + + if (cur_chr != 0 || sending) { + if (sending && (cur_chr == '\\' || cur_chr == 0)) + *s1++ = '\\'; + *s1++ = cur_chr; + } + break; + } + + if (sending) + *s1++ = '\\'; + *s1++ = cur_chr; + break; + } + } + + if (add_return) + *s1++ = '\r'; + + *s1++ = '\0'; /* guarantee closure */ + *s1++ = '\0'; /* terminate the string */ + return dup_mem (temp, (size_t) (s1 - temp)); /* may have embedded nuls */ + } + + /* + * A modified version of 'strtok'. This version skips \ sequences. + */ + + char *expect_strtok (s, term) + char *s, *term; + { + static char *str = ""; + int escape_flag = 0; + char *result; + + /* + * If a string was specified then do initial processing. + */ + if (s) + str = s; + + /* + * If this is the escape flag then reset it and ignore the character. + */ + if (*str) + result = str; + else + result = (char *) 0; + + while (*str) { + if (escape_flag) { + escape_flag = 0; + ++str; + continue; + } + + if (*str == '\\') { + ++str; + escape_flag = 1; + continue; + } + + /* + * If this is not in the termination string, continue. + */ + if (strchr (term, *str) == (char *) 0) { + ++str; + continue; + } + + /* + * This is the terminator. Mark the end of the string and stop. + */ + *str++ = '\0'; + break; + } + return (result); + } + + /* + * Process the expect string + */ + + void chat_expect (s) + char *s; + { + char *expect; + char *reply; + + if (strcmp(s, "HANGUP") == 0) { + ++hup_next; + return; + } + + if (strcmp(s, "ABORT") == 0) { + ++abort_next; + return; + } + + if (strcmp(s, "CLR_ABORT") == 0) { + ++clear_abort_next; + return; + } + + if (strcmp(s, "REPORT") == 0) { + ++report_next; + return; + } + + if (strcmp(s, "CLR_REPORT") == 0) { + ++clear_report_next; + return; + } + + if (strcmp(s, "TIMEOUT") == 0) { + ++timeout_next; + return; + } + + if (strcmp(s, "ECHO") == 0) { + ++echo_next; + return; + } + + if (strcmp(s, "SAY") == 0) { + ++say_next; + return; + } + + /* + * Fetch the expect and reply string. + */ + for (;;) { + expect = expect_strtok (s, "-"); + s = (char *) 0; + + if (expect == (char *) 0) + return; + + reply = expect_strtok (s, "-"); + + /* + * Handle the expect string. If successful then exit. + */ + if (get_string (expect)) + return; + + /* + * If there is a sub-reply string then send it. Otherwise any condition + * is terminal. + */ + if (reply == (char *) 0 || exit_code != 3) + break; + + chat_send (reply); + } + + /* + * The expectation did not occur. This is terminal. + */ + if (fail_reason) + logf("Failed (%s)", fail_reason); + else + logf("Failed"); + terminate(exit_code); + } + + /* + * Translate the input character to the appropriate string for printing + * the data. + */ + + char *character(c) + int c; + { + static char string[10]; + char *meta; + + meta = (c & 0x80) ? "M-" : ""; + c &= 0x7F; + + if (c < 32) + sprintf(string, "%s^%c", meta, (int)c + '@'); + else if (c == 127) + sprintf(string, "%s^?", meta); + else + sprintf(string, "%s%c", meta, c); + + return (string); + } + + /* + * process the reply string + */ + void chat_send (s) + register char *s; + { + char file_data[STR_LEN]; + + if (say_next) { + say_next = 0; + s = clean(s, 1); + write(2, s, strlen(s)); + free(s); + return; + } + + if (hup_next) { + hup_next = 0; + if (strcmp(s, "OFF") == 0) + signal(SIGHUP, SIG_IGN); + else + signal(SIGHUP, sighup); + return; + } + + if (echo_next) { + echo_next = 0; + echo = (strcmp(s, "ON") == 0); + return; + } + + if (abort_next) { + char *s1; + + abort_next = 0; + + if (n_aborts >= MAX_ABORTS) + fatal(2, "Too many ABORT strings"); + + s1 = clean(s, 0); + + if (strlen(s1) > strlen(s) + || strlen(s1) + 1 > sizeof(fail_buffer)) + fatal(1, "Illegal or too-long ABORT string ('%v')", s); + + abort_string[n_aborts++] = s1; + + if (verbose) + logf("abort on (%v)", s); + return; + } + + if (clear_abort_next) { + char *s1; + int i; + int old_max; + int pack = 0; + + clear_abort_next = 0; + + s1 = clean(s, 0); + + if (strlen(s1) > strlen(s) + || strlen(s1) + 1 > sizeof(fail_buffer)) + fatal(1, "Illegal or too-long CLR_ABORT string ('%v')", s); + + old_max = n_aborts; + for (i=0; i < n_aborts; i++) { + if ( strcmp(s1,abort_string[i]) == 0 ) { + free(abort_string[i]); + abort_string[i] = NULL; + pack++; + n_aborts--; + if (verbose) + logf("clear abort on (%v)", s); + } + } + free(s1); + if (pack) + pack_array(abort_string,old_max); + return; + } + + if (report_next) { + char *s1; + + report_next = 0; + if (n_reports >= MAX_REPORTS) + fatal(2, "Too many REPORT strings"); + + s1 = clean(s, 0); + + if (strlen(s1) > strlen(s) || strlen(s1) > sizeof fail_buffer - 1) + fatal(1, "Illegal or too-long REPORT string ('%v')", s); + + report_string[n_reports++] = s1; + + if (verbose) + logf("report (%v)", s); + return; + } + + if (clear_report_next) { + char *s1; + int i; + int old_max; + int pack = 0; + + clear_report_next = 0; + + s1 = clean(s, 0); + + if (strlen(s1) > strlen(s) || strlen(s1) > sizeof fail_buffer - 1) + fatal(1, "Illegal or too-long REPORT string ('%v')", s); + + old_max = n_reports; + for (i=0; i < n_reports; i++) { + if ( strcmp(s1,report_string[i]) == 0 ) { + free(report_string[i]); + report_string[i] = NULL; + pack++; + n_reports--; + if (verbose) + logf("clear report (%v)", s); + } + } + free(s1); + if (pack) + pack_array(report_string,old_max); + + return; + } + + if (timeout_next) { + timeout_next = 0; + timeout = atoi(s); + + if (timeout <= 0) + timeout = DEFAULT_CHAT_TIMEOUT; + + if (verbose) + logf("timeout set to %d seconds", timeout); + + return; + } + + /* + * The syntax @filename means read the string to send from the + * file `filename'. + */ + if (s[0] == '@') { + /* skip the @ and any following white-space */ + char *fn = s; + while (*++fn == ' ' || *fn == '\t') + ; + + if (*fn != 0) { + FILE *f; + int n = 0; + + /* open the file and read until STR_LEN-1 bytes or end-of-file */ + f = fopen(fn, "r"); + if (f == NULL) + fatal(1, "%s -- open failed: %m", fn); + while (n < STR_LEN - 1) { + int nr = fread(&file_data[n], 1, STR_LEN - 1 - n, f); + if (nr < 0) + fatal(1, "%s -- read error", fn); + if (nr == 0) + break; + n += nr; + } + fclose(f); + + /* use the string we got as the string to send, + but trim off the final newline if any. */ + if (n > 0 && file_data[n-1] == '\n') + --n; + file_data[n] = 0; + s = file_data; + } + } + + if (strcmp(s, "EOT") == 0) + s = "^D\\c"; + else if (strcmp(s, "BREAK") == 0) + s = "\\K\\c"; + + if (!put_string(s)) + fatal(1, "Failed"); + } + + int get_char() + { + int status; + char c; + + status = read(0, &c, 1); + + switch (status) { + case 1: + return ((int)c & 0x7F); + + default: + logf("warning: read() on stdin returned %d", status); + + case -1: + if ((status = fcntl(0, F_GETFL, 0)) == -1) + fatal(2, "Can't get file mode flags on stdin: %m"); + + if (fcntl(0, F_SETFL, status & ~O_NONBLOCK) == -1) + fatal(2, "Can't set file mode flags on stdin: %m"); + + return (-1); + } + } + + int put_char(c) + int c; + { + int status; + char ch = c; + + usleep(10000); /* inter-character typing delay (?) */ + + status = write(1, &ch, 1); + + switch (status) { + case 1: + return (0); + + default: + logf("warning: write() on stdout returned %d", status); + + case -1: + if ((status = fcntl(0, F_GETFL, 0)) == -1) + fatal(2, "Can't get file mode flags on stdin, %m"); + + if (fcntl(0, F_SETFL, status & ~O_NONBLOCK) == -1) + fatal(2, "Can't set file mode flags on stdin: %m"); + + return (-1); + } + } + + int write_char (c) + int c; + { + if (alarmed || put_char(c) < 0) { + alarm(0); + alarmed = 0; + + if (verbose) { + if (errno == EINTR || errno == EWOULDBLOCK) + logf(" -- write timed out"); + else + logf(" -- write failed: %m"); + } + return (0); + } + return (1); + } + + int put_string (s) + register char *s; + { + quiet = 0; + s = clean(s, 1); + + if (verbose) { + if (quiet) + logf("send (?????\?)"); /* backslash to avoid trigraph ??) */ + else + logf("send (%v)", s); + } + + alarm(timeout); alarmed = 0; + + while (*s) { + register char c = *s++; + + if (c != '\\') { + if (!write_char (c)) + return 0; + continue; + } + + c = *s++; + switch (c) { + case 'd': + sleep(1); + break; + + case 'K': + break_sequence(); + break; + + case 'p': + usleep(10000); /* 1/100th of a second (arg is microseconds) */ + break; + + default: + if (!write_char (c)) + return 0; + break; + } + } + + alarm(0); + alarmed = 0; + return (1); + } + + /* + * Echo a character to stderr. + * When called with -1, a '\n' character is generated when + * the cursor is not at the beginning of a line. + */ + void echo_stderr(n) + int n; + { + static int need_lf; + char *s; + + switch (n) { + case '\r': /* ignore '\r' */ + break; + case -1: + if (need_lf == 0) + break; + /* fall through */ + case '\n': + write(2, "\n", 1); + need_lf = 0; + break; + default: + s = character(n); + write(2, s, strlen(s)); + need_lf = 1; + break; + } + } + + /* + * 'Wait for' this string to appear on this file descriptor. + */ + int get_string(string) + register char *string; + { + char temp[STR_LEN]; + int c, printed = 0, len, minlen; + register char *s = temp, *end = s + STR_LEN; + char *logged = temp; + + fail_reason = (char *)0; + string = clean(string, 0); + len = strlen(string); + minlen = (len > sizeof(fail_buffer)? len: sizeof(fail_buffer)) - 1; + + if (verbose) + logf("expect (%v)", string); + + if (len > STR_LEN) { + logf("expect string is too long"); + exit_code = 1; + return 0; + } + + if (len == 0) { + if (verbose) + logf("got it"); + return (1); + } + + alarm(timeout); + alarmed = 0; + + while ( ! alarmed && (c = get_char()) >= 0) { + int n, abort_len, report_len; + + if (echo) + echo_stderr(c); + if (verbose && c == '\n') { + if (s == logged) + logf(""); /* blank line */ + else + logf("%0.*v", s - logged, logged); + logged = s + 1; + } + + *s++ = c; + + if (verbose && s >= logged + 80) { + logf("%0.*v", s - logged, logged); + logged = s; + } + + if (Verbose) { + if (c == '\n') + fputc( '\n', stderr ); + else if (c != '\r') + fprintf( stderr, "%s", character(c) ); + } + + if (!report_gathering) { + for (n = 0; n < n_reports; ++n) { + if ((report_string[n] != (char*) NULL) && + s - temp >= (report_len = strlen(report_string[n])) && + strncmp(s - report_len, report_string[n], report_len) == 0) { + time_t time_now = time ((time_t*) NULL); + struct tm* tm_now = localtime (&time_now); + + strftime (report_buffer, 20, "%b %d %H:%M:%S ", tm_now); + strcat (report_buffer, report_string[n]); + + report_string[n] = (char *) NULL; + report_gathering = 1; + break; + } + } + } + else { + if (!iscntrl (c)) { + int rep_len = strlen (report_buffer); + report_buffer[rep_len] = c; + report_buffer[rep_len + 1] = '\0'; + } + else { + report_gathering = 0; + fprintf (report_fp, "chat: %s\n", report_buffer); + } + } + + if (s - temp >= len && + c == string[len - 1] && + strncmp(s - len, string, len) == 0) { + if (verbose) { + if (s > logged) + logf("%0.*v", s - logged, logged); + logf(" -- got it\n"); + } + + alarm(0); + alarmed = 0; + return (1); + } + + for (n = 0; n < n_aborts; ++n) { + if (s - temp >= (abort_len = strlen(abort_string[n])) && + strncmp(s - abort_len, abort_string[n], abort_len) == 0) { + if (verbose) { + if (s > logged) + logf("%0.*v", s - logged, logged); + logf(" -- failed"); + } + + alarm(0); + alarmed = 0; + exit_code = n + 4; + strcpy(fail_reason = fail_buffer, abort_string[n]); + return (0); + } + } + + if (s >= end) { + if (logged < s - minlen) { + if (verbose) + logf("%0.*v", s - logged, logged); + logged = s; + } + s -= minlen; + memmove(temp, s, minlen); + logged = temp + (logged - s); + s = temp + minlen; + } + + if (alarmed && verbose) + logf("warning: alarm synchronization problem"); + } + + alarm(0); + + if (verbose && printed) { + if (alarmed) + logf(" -- read timed out"); + else + logf(" -- read failed: %m"); + } + + exit_code = 3; + alarmed = 0; + return (0); + } + + /* + * Gross kludge to handle Solaris versions >= 2.6 having usleep. + */ + #ifdef SOL2 + #include + #if MAXUID > 65536 /* then this is Solaris 2.6 or later */ + #undef NO_USLEEP + #endif + #endif /* SOL2 */ + + #ifdef NO_USLEEP + #include + #include + + /* + usleep -- support routine for 4.2BSD system call emulations + last edit: 29-Oct-1984 D A Gwyn + */ + + extern int select(); + + int + usleep( usec ) /* returns 0 if ok, else -1 */ + long usec; /* delay in microseconds */ + { + static struct { /* `timeval' */ + long tv_sec; /* seconds */ + long tv_usec; /* microsecs */ + } delay; /* _select() timeout */ + + delay.tv_sec = usec / 1000000L; + delay.tv_usec = usec % 1000000L; + + return select(0, (long *)0, (long *)0, (long *)0, &delay); + } + #endif + + void + pack_array (array, end) + char **array; /* The address of the array of string pointers */ + int end; /* The index of the next free entry before CLR_ */ + { + int i, j; + + for (i = 0; i < end; i++) { + if (array[i] == NULL) { + for (j = i+1; j < end; ++j) + if (array[j] != NULL) + array[i++] = array[j]; + for (; i < end; ++i) + array[i] = NULL; + break; + } + } + } + + /* + * vfmtmsg - format a message into a buffer. Like vsprintf except we + * also specify the length of the output buffer, and we handle the + * %m (error message) format. + * Doesn't do floating-point formats. + * Returns the number of chars put into buf. + */ + #define OUTCHAR(c) (buflen > 0? (--buflen, *buf++ = (c)): 0) + + int + vfmtmsg(buf, buflen, fmt, args) + char *buf; + int buflen; + const char *fmt; + va_list args; + { + int c, i, n; + int width, prec, fillch; + int base, len, neg, quoted; + unsigned long val = 0; + char *str, *buf0; + const char *f; + unsigned char *p; + char num[32]; + static char hexchars[] = "0123456789abcdef"; + + buf0 = buf; + --buflen; + while (buflen > 0) { + for (f = fmt; *f != '%' && *f != 0; ++f) + ; + if (f > fmt) { + len = f - fmt; + if (len > buflen) + len = buflen; + memcpy(buf, fmt, len); + buf += len; + buflen -= len; + fmt = f; + } + if (*fmt == 0) + break; + c = *++fmt; + width = prec = 0; + fillch = ' '; + if (c == '0') { + fillch = '0'; + c = *++fmt; + } + if (c == '*') { + width = va_arg(args, int); + c = *++fmt; + } else { + while (isdigit(c)) { + width = width * 10 + c - '0'; + c = *++fmt; + } + } + if (c == '.') { + c = *++fmt; + if (c == '*') { + prec = va_arg(args, int); + c = *++fmt; + } else { + while (isdigit(c)) { + prec = prec * 10 + c - '0'; + c = *++fmt; + } + } + } + str = 0; + base = 0; + neg = 0; + ++fmt; + switch (c) { + case 'd': + i = va_arg(args, int); + if (i < 0) { + neg = 1; + val = -i; + } else + val = i; + base = 10; + break; + case 'o': + val = va_arg(args, unsigned int); + base = 8; + break; + case 'x': + val = va_arg(args, unsigned int); + base = 16; + break; + case 'p': + val = (unsigned long) va_arg(args, void *); + base = 16; + neg = 2; + break; + case 's': + str = va_arg(args, char *); + break; + case 'c': + num[0] = va_arg(args, int); + num[1] = 0; + str = num; + break; + case 'm': + str = strerror(errno); + break; + case 'v': /* "visible" string */ + case 'q': /* quoted string */ + quoted = c == 'q'; + p = va_arg(args, unsigned char *); + if (fillch == '0' && prec > 0) { + n = prec; + } else { + n = strlen((char *)p); + if (prec > 0 && prec < n) + n = prec; + } + while (n > 0 && buflen > 0) { + c = *p++; + --n; + if (!quoted && c >= 0x80) { + OUTCHAR('M'); + OUTCHAR('-'); + c -= 0x80; + } + if (quoted && (c == '"' || c == '\\')) + OUTCHAR('\\'); + if (c < 0x20 || (0x7f <= c && c < 0xa0)) { + if (quoted) { + OUTCHAR('\\'); + switch (c) { + case '\t': OUTCHAR('t'); break; + case '\n': OUTCHAR('n'); break; + case '\b': OUTCHAR('b'); break; + case '\f': OUTCHAR('f'); break; + default: + OUTCHAR('x'); + OUTCHAR(hexchars[c >> 4]); + OUTCHAR(hexchars[c & 0xf]); + } + } else { + if (c == '\t') + OUTCHAR(c); + else { + OUTCHAR('^'); + OUTCHAR(c ^ 0x40); + } + } + } else + OUTCHAR(c); + } + continue; + default: + *buf++ = '%'; + if (c != '%') + --fmt; /* so %z outputs %z etc. */ + --buflen; + continue; + } + if (base != 0) { + str = num + sizeof(num); + *--str = 0; + while (str > num + neg) { + *--str = hexchars[val % base]; + val = val / base; + if (--prec <= 0 && val == 0) + break; + } + switch (neg) { + case 1: + *--str = '-'; + break; + case 2: + *--str = 'x'; + *--str = '0'; + break; + } + len = num + sizeof(num) - 1 - str; + } else { + len = strlen(str); + if (prec > 0 && len > prec) + len = prec; + } + if (width > 0) { + if (width > buflen) + width = buflen; + if ((n = width - len) > 0) { + buflen -= n; + for (; n > 0; --n) + *buf++ = fillch; + } + } + if (len > buflen) + len = buflen; + memcpy(buf, str, len); + buf += len; + buflen -= len; + } + *buf = 0; + return buf - buf0; + } Index: chat/chat.man =================================================================== RCS file: chat/chat.man diff -N chat/chat.man *** /dev/null 1 Jan 1970 00:00:00 -0000 --- chat/chat.man 2 May 2002 05:13:37 -0000 *************** *** 0 **** --- 1,511 ---- + .\" -*- nroff -*- + .\" manual page [] for chat 1.8 + .\" Id: chat.8,v 1.9 1999/09/06 05:10:23 paulus Exp + .\" SH section heading + .\" SS subsection heading + .\" LP paragraph + .\" IP indented paragraph + .\" TP hanging label + .TH CHAT 8 "22 May 1999" "Chat Version 1.22" + .SH "NAME" + chat \- Automated conversational script with a modem + .SH "SYNOPSIS" + .B chat + [ + .I options + ] + .I script + .SH "DESCRIPTION" + .LP + The \fIchat\fR program defines a conversational exchange between the + computer and the modem. Its primary purpose is to establish the + connection between the Point-to-Point Protocol Daemon (\fIpppd\fR) and + the remote's \fIpppd\fR process. + .SH "OPTIONS" + .TP + .B -f \fI + Read the chat script from the chat \fIfile\fR. The use of this option + is mutually exclusive with the chat script parameters. The user must + have read access to the file. Multiple lines are permitted in the + file. Space or horizontal tab characters should be used to separate + the strings. + .TP + .B -t \fI + Set the timeout for the expected string to be received. If the string + is not received within the time limit then the reply string is not + sent. An alternate reply may be sent or the script will fail if there + is no alternate reply string. A failed script will cause the + \fIchat\fR program to terminate with a non-zero error code. + .TP + .B -r \fI + Set the file for output of the report strings. If you use the keyword + \fIREPORT\fR, the resulting strings are written to this file. If this + option is not used and you still use \fIREPORT\fR keywords, the + \fIstderr\fR file is used for the report strings. + .TP + .B -e + Start with the echo option turned on. Echoing may also be turned on + or off at specific points in the chat script by using the \fIECHO\fR + keyword. When echoing is enabled, all output from the modem is echoed + to \fIstderr\fR. + .TP + .B -E + Enables environment variable substituion within chat scripts using the + standard \fI$xxx\fR syntax. + .TP + .B -v + Request that the \fIchat\fR script be executed in a verbose mode. The + \fIchat\fR program will then log the execution state of the chat + script as well as all text received from the modem and the output + strings sent to the modem. The default is to log through the SYSLOG; + the logging method may be altered with the -S and -s flags. SYSLOGs + are logged to facility LOG_LOCAL2. + .TP + .B -V + Request that the \fIchat\fR script be executed in a stderr verbose + mode. The \fIchat\fR program will then log all text received from the + modem and the output strings sent to the modem to the stderr device. This + device is usually the local console at the station running the chat or + pppd program. + .TP + .B -s + Use stderr. All log messages from '-v' and all error messages will be + sent to stderr. + .TP + .B -S + Do not use the SYSLOG. By default, error messages are sent to the + SYSLOG. The use of -S will prevent both log messages from '-v' and + error messages from being sent to the SYSLOG (to facility LOG_LOCAL2). + .TP + .B -T \fI + Pass in an arbitary string, usually a phone number, that will be + substituted for the \eT substitution metacharacter in a send string. + .TP + .B -U \fI + Pass in a second string, usually a phone number, that will be + substituted for the \eU substitution metacharacter in a send string. + This is useful when dialing an ISDN terminal adapter that requires two + numbers. + .TP + .B script + If the script is not specified in a file with the \fI-f\fR option then + the script is included as parameters to the \fIchat\fR program. + .SH "CHAT SCRIPT" + .LP + The \fIchat\fR script defines the communications. + .LP + A script consists of one or more "expect-send" pairs of strings, + separated by spaces, with an optional "subexpect-subsend" string pair, + separated by a dash as in the following example: + .IP + ogin:-BREAK-ogin: ppp ssword: hello2u2 + .LP + This line indicates that the \fIchat\fR program should expect the string + "ogin:". If it fails to receive a login prompt within the time interval + allotted, it is to send a break sequence to the remote and then expect the + string "ogin:". If the first "ogin:" is received then the break sequence is + not generated. + .LP + Once it received the login prompt the \fIchat\fR program will send the + string ppp and then expect the prompt "ssword:". When it receives the + prompt for the password, it will send the password hello2u2. + .LP + A carriage return is normally sent following the reply string. It is not + expected in the "expect" string unless it is specifically requested by using + the \er character sequence. + .LP + The expect sequence should contain only what is needed to identify the + string. Since it is normally stored on a disk file, it should not contain + variable information. It is generally not acceptable to look for time + strings, network identification strings, or other variable pieces of data as + an expect string. + .LP + To help correct for characters which may be corrupted during the initial + sequence, look for the string "ogin:" rather than "login:". It is possible + that the leading "l" character may be received in error and you may never + find the string even though it was sent by the system. For this reason, + scripts look for "ogin:" rather than "login:" and "ssword:" rather than + "password:". + .LP + A very simple script might look like this: + .IP + ogin: ppp ssword: hello2u2 + .LP + In other words, expect ....ogin:, send ppp, expect ...ssword:, send hello2u2. + .LP + In actual practice, simple scripts are rare. At the vary least, you + should include sub-expect sequences should the original string not be + received. For example, consider the following script: + .IP + ogin:--ogin: ppp ssword: hello2u2 + .LP + This would be a better script than the simple one used earlier. This would look + for the same login: prompt, however, if one was not received, a single + return sequence is sent and then it will look for login: again. Should line + noise obscure the first login prompt then sending the empty line will + usually generate a login prompt again. + .SH "COMMENTS" + Comments can be embedded in the chat script. A comment is a line which + starts with the \fB#\fR (hash) character in column 1. Such comment + lines are just ignored by the chat program. If a '#' character is to + be expected as the first character of the expect sequence, you should + quote the expect string, or give its octal value, `\e043'. + In a script file if you want to wait for a prompt that starts with a '#' + character, you would have to write something like this: + .IP + # Now wait for the prompt and send logout string + .br + \'# ' logout + .SH "SENDING DATA FROM A FILE" + If the string to send starts with an at sign (@), the rest of the + string is taken to be the name of a file to read to get the string to + send. If the last character of the data read is a newline, it is + removed. The file can be a named pipe (or fifo) instead of a regular + file. This provides a way for \fBchat\fR to communicate with another + program, for example, a program to prompt the user and receive a + password typed in. + .SH "ABORT STRINGS" + Many modems will report the status of the call as a string. These + strings may be \fBCONNECTED\fR or \fBNO CARRIER\fR or \fBBUSY\fR. It + is often desirable to terminate the script should the modem fail to + connect to the remote. The difficulty is that a script would not know + exactly which modem string it may receive. On one attempt, it may + receive \fBBUSY\fR while the next time it may receive \fBNO CARRIER\fR. + .LP + These "abort" strings may be specified in the script using the \fIABORT\fR + sequence. It is written in the script as in the following example: + .IP + ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ATDT5551212 CONNECT + .LP + This sequence will expect nothing; and then send the string ATZ. The + expected response to this is the string \fIOK\fR. When it receives \fIOK\fR, + the string ATDT5551212 to dial the telephone. The expected string is + \fICONNECT\fR. If the string \fICONNECT\fR is received the remainder of the + script is executed. However, should the modem find a busy telephone, it will + send the string \fIBUSY\fR. This will cause the string to match the abort + character sequence. The script will then fail because it found a match to + the abort string. If it received the string \fINO CARRIER\fR, it will abort + for the same reason. Either string may be received. Either string will + terminate the \fIchat\fR script. + .SH "CLR_ABORT STRINGS" + This sequence allows for clearing previously set \fBABORT\fR strings. + \fBABORT\fR strings are kept in an array of a pre-determined size (at + compilation time); \fBCLR_ABORT\fR will reclaim the space for cleared + entries so that new strings can use that space. + .SH "SAY STRINGS" + The \fBSAY\fR directive allows the script to send strings to the user + at the terminal via standard error. If \fBchat\fR is being run by + pppd, and pppd is running as a daemon (detached from its controlling + terminal), standard error will normally be redirected to the file + /etc/ppp/connect-errors. + .LP + \fBSAY\fR strings must be enclosed in single or double quotes. If + carriage return and line feed are needed in the string to be output, + you must explicitely add them to your string. + .LP + The SAY strings could be used to give progress messages in sections of + the script where you want to have 'ECHO OFF' but still let the user + know what is happening. An example is: + .IP + ABORT BUSY + .br + ECHO OFF + .br + SAY "Dialling your ISP...\en" + .br + \'' ATDT5551212 + .br + TIMEOUT 120 + .br + SAY "Waiting up to 2 minutes for connection ... " + .br + CONNECT '' + .br + SAY "Connected, now logging in ...\n" + .br + ogin: account + .br + ssword: pass + .br + $ \c + SAY "Logged in OK ...\n" + \fIetc ...\fR + .LP + This sequence will only present the SAY strings to the user and all + the details of the script will remain hidden. For example, if the + above script works, the user will see: + .IP + Dialling your ISP... + .br + Waiting up to 2 minutes for connection ... Connected, now logging in ... + .br + Logged in OK ... + .LP + .SH "REPORT STRINGS" + A \fBreport\fR string is similar to the ABORT string. The difference + is that the strings, and all characters to the next control character + such as a carriage return, are written to the report file. + .LP + The report strings may be used to isolate the transmission rate of the + modem's connect string and return the value to the chat user. The + analysis of the report string logic occurs in conjunction with the + other string processing such as looking for the expect string. The use + of the same string for a report and abort sequence is probably not + very useful, however, it is possible. + .LP + The report strings to no change the completion code of the program. + .LP + These "report" strings may be specified in the script using the \fIREPORT\fR + sequence. It is written in the script as in the following example: + .IP + REPORT CONNECT ABORT BUSY '' ATDT5551212 CONNECT '' ogin: account + .LP + This sequence will expect nothing; and then send the string + ATDT5551212 to dial the telephone. The expected string is + \fICONNECT\fR. If the string \fICONNECT\fR is received the remainder + of the script is executed. In addition the program will write to the + expect-file the string "CONNECT" plus any characters which follow it + such as the connection rate. + .SH "CLR_REPORT STRINGS" + This sequence allows for clearing previously set \fBREPORT\fR strings. + \fBREPORT\fR strings are kept in an array of a pre-determined size (at + compilation time); \fBCLR_REPORT\fR will reclaim the space for cleared + entries so that new strings can use that space. + .SH "ECHO" + The echo options controls whether the output from the modem is echoed + to \fIstderr\fR. This option may be set with the \fI-e\fR option, but + it can also be controlled by the \fIECHO\fR keyword. The "expect-send" + pair \fIECHO\fR \fION\fR enables echoing, and \fIECHO\fR \fIOFF\fR + disables it. With this keyword you can select which parts of the + conversation should be visible. For instance, with the following + script: + .IP + ABORT 'BUSY' + .br + ABORT 'NO CARRIER' + .br + '' ATZ + .br + OK\er\en ATD1234567 + .br + \er\en \ec + .br + ECHO ON + .br + CONNECT \ec + .br + ogin: account + .LP + all output resulting from modem configuration and dialing is not visible, + but starting with the \fICONNECT\fR (or \fIBUSY\fR) message, everything + will be echoed. + .SH "HANGUP" + The HANGUP options control whether a modem hangup should be considered + as an error or not. This option is useful in scripts for dialling + systems which will hang up and call your system back. The HANGUP + options can be \fBON\fR or \fBOFF\fR. + .br + When HANGUP is set OFF and the modem hangs up (e.g., after the first + stage of logging in to a callback system), \fBchat\fR will continue + running the script (e.g., waiting for the incoming call and second + stage login prompt). As soon as the incoming call is connected, you + should use the \fBHANGUP ON\fR directive to reinstall normal hang up + signal behavior. Here is an (simple) example script: + .IP + ABORT 'BUSY' + .br + '' ATZ + .br + OK\er\en ATD1234567 + .br + \er\en \ec + .br + CONNECT \ec + .br + \'Callback login:' call_back_ID + .br + HANGUP OFF + .br + ABORT "Bad Login" + .br + \'Callback Password:' Call_back_password + .br + TIMEOUT 120 + .br + CONNECT \ec + .br + HANGUP ON + .br + ABORT "NO CARRIER" + .br + ogin:--BREAK--ogin: real_account + .br + \fIetc ...\fR + .LP + .SH "TIMEOUT" + The initial timeout value is 45 seconds. This may be changed using the \fB-t\fR + parameter. + .LP + To change the timeout value for the next expect string, the following + example may be used: + .IP + ATZ OK ATDT5551212 CONNECT TIMEOUT 10 ogin:--ogin: TIMEOUT 5 assword: hello2u2 + .LP + This will change the timeout to 10 seconds when it expects the login: + prompt. The timeout is then changed to 5 seconds when it looks for the + password prompt. + .LP + The timeout, once changed, remains in effect until it is changed again. + .SH "SENDING EOT" + The special reply string of \fIEOT\fR indicates that the chat program + should send an EOT character to the remote. This is normally the + End-of-file character sequence. A return character is not sent + following the EOT. + .PR + The EOT sequence may be embedded into the send string using the + sequence \fI^D\fR. + .SH "GENERATING BREAK" + The special reply string of \fIBREAK\fR will cause a break condition + to be sent. The break is a special signal on the transmitter. The + normal processing on the receiver is to change the transmission rate. + It may be used to cycle through the available transmission rates on + the remote until you are able to receive a valid login prompt. + .PR + The break sequence may be embedded into the send string using the + \fI\eK\fR sequence. + .SH "ESCAPE SEQUENCES" + The expect and reply strings may contain escape sequences. All of the + sequences are legal in the reply string. Many are legal in the expect. + Those which are not valid in the expect sequence are so indicated. + .TP + .B '' + Expects or sends a null string. If you send a null string then it will still + send the return character. This sequence may either be a pair of apostrophe + or quote characters. + .TP + .B \eb + represents a backspace character. + .TP + .B \ec + Suppresses the newline at the end of the reply string. This is the only + method to send a string without a trailing return character. It must + be at the end of the send string. For example, + the sequence hello\ec will simply send the characters h, e, l, l, o. + .I (not valid in expect.) + .TP + .B \ed + Delay for one second. The program uses sleep(1) which will delay to a + maximum of one second. + .I (not valid in expect.) + .TP + .B \eK + Insert a BREAK + .I (not valid in expect.) + .TP + .B \en + Send a newline or linefeed character. + .TP + .B \eN + Send a null character. The same sequence may be represented by \e0. + .I (not valid in expect.) + .TP + .B \ep + Pause for a fraction of a second. The delay is 1/10th of a second. + .I (not valid in expect.) + .TP + .B \eq + Suppress writing the string to the SYSLOG. The string ?????? is + written to the log in its place. + .I (not valid in expect.) + .TP + .B \er + Send or expect a carriage return. + .TP + .B \es + Represents a space character in the string. This may be used when it + is not desirable to quote the strings which contains spaces. The + sequence 'HI\ TIM' and HI\esTIM are the same. + .TP + .B \et + Send or expect a tab character. + .TP + .B \eT + Send the phone number string as specified with the \fI-T\fR option + .I (not valid in expect.) + .TP + .B \eU + Send the phone number 2 string as specified with the \fI-U\fR option + .I (not valid in expect.) + .TP + .B \e\e + Send or expect a backslash character. + .TP + .B \eddd + Collapse the octal digits (ddd) into a single ASCII character and send that + character. + .I (some characters are not valid in expect.) + .TP + .B \^^C + Substitute the sequence with the control character represented by C. + For example, the character DC1 (17) is shown as \^^Q. + .I (some characters are not valid in expect.) + .SH "ENVIRONMENT VARIABLES" + Environment variables are available within chat scripts, if the \fI-E\fR + option was specified in the command line. The metacharacter \fI$\fR is used + to introduce the name of the environment variable to substitute. If the + substition fails, because the requested environment variable is not set, + \fInothing\fR is replaced for the variable. + .SH "TERMINATION CODES" + The \fIchat\fR program will terminate with the following completion + codes. + .TP + .B 0 + The normal termination of the program. This indicates that the script + was executed without error to the normal conclusion. + .TP + .B 1 + One or more of the parameters are invalid or an expect string was too + large for the internal buffers. This indicates that the program as not + properly executed. + .TP + .B 2 + An error occurred during the execution of the program. This may be due + to a read or write operation failing for some reason or chat receiving + a signal such as SIGINT. + .TP + .B 3 + A timeout event occurred when there was an \fIexpect\fR string without + having a "-subsend" string. This may mean that you did not program the + script correctly for the condition or that some unexpected event has + occurred and the expected string could not be found. + .TP + .B 4 + The first string marked as an \fIABORT\fR condition occurred. + .TP + .B 5 + The second string marked as an \fIABORT\fR condition occurred. + .TP + .B 6 + The third string marked as an \fIABORT\fR condition occurred. + .TP + .B 7 + The fourth string marked as an \fIABORT\fR condition occurred. + .TP + .B ... + The other termination codes are also strings marked as an \fIABORT\fR + condition. + .LP + Using the termination code, it is possible to determine which event + terminated the script. It is possible to decide if the string "BUSY" + was received from the modem as opposed to "NO DIAL TONE". While the + first event may be retried, the second will probably have little + chance of succeeding during a retry. + .SH "SEE ALSO" + Additional information about \fIchat\fR scripts may be found with UUCP + documentation. The \fIchat\fR script was taken from the ideas proposed + by the scripts used by the \fIuucico\fR program. + .LP + uucp(1), uucico(8) + .SH "COPYRIGHT" + The \fIchat\fR program is in public domain. This is not the GNU public + license. If it breaks then you get to keep both pieces. Index: conserver.cf/Makefile.in =================================================================== RCS file: /cvs/misc/conserver/conserver.cf/Makefile.in,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 Makefile.in *** conserver.cf/Makefile.in 5 Dec 2001 20:36:45 -0000 1.1.1.1 --- conserver.cf/Makefile.in 2 May 2002 04:31:04 -0000 *************** *** 23,28 **** --- 23,29 ---- install: $(MKDIR) $(DESTDIR)$(mandir)/man5 $(INSTALL) conserver.cf.man $(DESTDIR)$(mandir)/man5/conserver.cf.5 + $(INSTALL) conserver.chat.man $(DESTDIR)$(mandir)/man5/conserver.chat.5 $(INSTALL) conserver.passwd.man $(DESTDIR)$(mandir)/man5/conserver.passwd.5 .PHONY: clean distclean install Index: conserver.cf/conserver.cf.man =================================================================== RCS file: /cvs/misc/conserver/conserver.cf/conserver.cf.man,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 conserver.cf.man *** conserver.cf/conserver.cf.man 24 Apr 2002 21:41:59 -0000 1.1.1.3 --- conserver.cf/conserver.cf.man 2 May 2002 04:44:01 -0000 *************** *** 4,53 **** .SH NAME conserver.cf \- console configuration file for conserver(8) .SH SYNOPSIS - .br .BI \s-1LOGDIR\s0= logdirectory ! .br .BI \s-1TIMESTAMP\s0= timestamp-spec ! .br .BI \s-1BREAK\s0\fIn\fP= break-spec ! .br ! \fIname\fP:\fIdevice\fP[@\fIconserver\fP]:\fIbaud\fP:\fIlogfile\fP:\fItimestamp-spec\fP:\fIbreak\fP ! .br ! \fIname\fP:!\fItermserver\fP[@\fIconserver\fP]:\fIport\fP:\fIlogfile\fP:\fItimestamp-spec\fP:\fIbreak\fP ! .br ! \fIname\fP:|\fIcommand\fP[@\fIconserver\fP]::\fIlogfile\fP:\fItimestamp-spec\fP:\fIbreak\fP ! .br \fB%%\fP ! .br \fIaccess\fP: \fIhosts\fP .SH DESCRIPTION .B Conserver.cf is the configuration file for .BR conserver (8). - It is read once upon startup; - modifications to the file take effect only upon restarting \fBconserver\fP. .PP Blank lines and comment lines (those beginning with a ``#'' and optional leading whitespace) are ignored. Non-ignored lines beginning with whitespace are considered continuations of the previous line. This allows you to span one logical line over many physical lines and insert comments wherever appropriate. .PP ! The first section of the file has logical lines that are separated into ! five colon-separated fields. Leading and trailing white space in each ! field is ignored. .TP .I name the unique name by which this connection is referred to when using the \fBconsole\fP program. This is typically the name of the host whose console is being monitored. .TP .I device ! the full path name of the device for this line. ! The \fIbaud\fP rate is the speed and parity for this console. ! Speed may be given as an integer, ! parity only requires the first letter of any of: even, odd, mark, space. ! For no parity, use the character `p'. .TP .BI ! termserver the hostname of the terminal server to connect to. --- 4,53 ---- .SH NAME conserver.cf \- console configuration file for conserver(8) .SH SYNOPSIS .BI \s-1LOGDIR\s0= logdirectory ! .PP .BI \s-1TIMESTAMP\s0= timestamp-spec ! .PP .BI \s-1BREAK\s0\fIn\fP= break-spec ! .PP ! \fIname\fP:\fIdevice\fP[@\fIconserver\fP]:\fIbaud\fP:\fIlogfile\fP:[\fItimestamp-spec\fP][:\fIbreak\fP] ! .PP ! \fIname\fP:@\fIconserver\fP:[\fIbaud\fP]:[\fIlogfile\fP]:[\fItimestamp-spec\fP][:\fIbreak\fP] ! .PP ! \fIname\fP:!\fItermserver\fP[@\fIconserver\fP]:\fIport\fP:\fIlogfile\fP:[\fItimestamp-spec\fP][:\fIbreak\fP] ! .PP ! \fIname\fP:|\fIcommand\fP[@\fIconserver\fP]::\fIlogfile\fP:[\fItimestamp-spec\fP][:\fIbreak\fP] ! .PP \fB%%\fP ! .PP \fIaccess\fP: \fIhosts\fP .SH DESCRIPTION .B Conserver.cf is the configuration file for .BR conserver (8). .PP Blank lines and comment lines (those beginning with a ``#'' and optional leading whitespace) are ignored. Non-ignored lines beginning with whitespace are considered continuations of the previous line. This allows you to span one logical line over many physical lines and insert comments wherever appropriate. + .SS "Console Specifications" + The first section of the file consists of lines either specifying the + details for a given console, or giving default setting for the following + group of console specifications. .PP ! Console specification lines are separated into five colon-separated ! fields. Leading and trailing white space in each field is ignored. .TP .I name the unique name by which this connection is referred to when using the \fBconsole\fP program. This is typically the name of the host whose console is being monitored. + .PP + The next field has one of three alternate forms: .TP .I device ! the full pathname of the device for this line. .TP .BI ! termserver the hostname of the terminal server to connect to. *************** *** 56,65 **** --- 56,83 ---- .BI | command the command to invoke on the console server. .PP + The interpretation of the third field depends on the form of the second + field: + .TP + .I baud + When the second field is a full pathname to a device, the second field + is the speed and parity for this device. The speed may be given as an + integer in bits per second. The desired parity setting for this device + is specified by the first letter of any of: even, odd, mark, space, or + none, given immediately after the speed number. + .TP + .I port + When the second field is the hostname of a terminal server (i.e. begins + with a `!' character), the second field is the TCP port number to + connect to on that host. + .PP \fIdevice\fP, !\fItermserver\fP, and |\fIcommand\fP may be followed by a remote console server name in the form ``\fB@\fP\fIconserver\fP'', in which case the conserver daemon will send connections for \fIname\fP to the conserver running on the host named \fIconserver\fP. + The device, termserver, or command name are ignored and can be omitted, + as may other fields only necessary on the master conserver host. + .PP When the ``\fB@\fP\fIconserver\fP'' notation is used, \fBconserver\fP recognizes consoles it should manage locally by comparing the IP address of \fIconserver\fP *************** *** 91,104 **** specifies `lines' and will cause timestamps of the form `[Mon Jan 25 14:46:56 PST 1999]' to be placed every \fImark-interval\fP lines (a newline character signifies ! a new line). So, `5h' specifies every five hours and `2l' specifies every ! two lines. ! An `\fBa\fP' can be specified to add logs of `attached', `detached', and `bumped' actions, including the user's name and the host from which the \fBconsole\fP connection was made, to the logfile. ! A `\fBb\fP' can be specified to add logging of break sequences sent to the console. .IP A default \fItimestamp-spec\fP can be specified by using the --- 109,121 ---- specifies `lines' and will cause timestamps of the form `[Mon Jan 25 14:46:56 PST 1999]' to be placed every \fImark-interval\fP lines (a newline character signifies ! a new line). ! An `\fBa\fP' flag can be specified to add logs of `attached', `detached', and `bumped' actions, including the user's name and the host from which the \fBconsole\fP connection was made, to the logfile. ! A `\fBb\fP' flag can be specified to add logging of break sequences sent to the console. .IP A default \fItimestamp-spec\fP can be specified by using the *************** *** 118,155 **** The \fIbreak-spec\fP sequences are defined using the \fB\s-1BREAK\s0\fIn\fB=\fR syntax where \fIn\fP is a number from 1 to 9. ! There are three builtin defaults: ``\s-1BREAK1\s0=\\z'', ! ``\s-1BREAK2\s0=\\r~^b'', ! and ``\s-1BREAK3\s0=#.reset -x\\r''. The values of the \fB\s-1BREAK\s0\fIn\fR ! sequences are simple characters strings with the exception of `\\' and `^': .sp .PD 0 ! .IP \\\\a alert ! .IP \\\\b backspace ! .IP \\\\f form-feed ! .IP \\\\n newline ! .IP \\\\r carriage-return ! .IP \\\\t tab ! .IP \\\\v vertical-tab ! .IP \\\\z serial break ! .IP \\\\\\\\ backslash ! .IP \\\\^ circumflex ! .IP \\\\\fIooo\fP octal representation of a character (where \fIooo\fP is one to three octal digits) ! .IP \\\\\fIc\fP character \fIc\fP .IP ^? delete --- 135,172 ---- The \fIbreak-spec\fP sequences are defined using the \fB\s-1BREAK\s0\fIn\fB=\fR syntax where \fIn\fP is a number from 1 to 9. ! There are three builtin defaults: ``\s-1BREAK1\s0=\ez'', ! ``\s-1BREAK2\s0=\er~^b'', ! and ``\s-1BREAK3\s0=#.reset -x\er''. The values of the \fB\s-1BREAK\s0\fIn\fR ! sequences are simple characters strings with the exception of `\e' and `^': .sp .PD 0 ! .IP \ea alert ! .IP \eb backspace ! .IP \ef form-feed ! .IP \en newline ! .IP \er carriage-return ! .IP \et tab ! .IP \ev vertical-tab ! .IP \ez serial break ! .IP \e\e backslash ! .IP \e^ circumflex ! .IP \e\fIooo\fP octal representation of a character (where \fIooo\fP is one to three octal digits) ! .IP \e\fIc\fP character \fIc\fP .IP ^? delete *************** *** 158,164 **** .PD .PP This section is terminated with a `\fB%%\fP' token on a line by itself. ! .PP The next section of the file contains a list of hosts and addresses which are allowed to connect to the console server. .B Conserver --- 175,181 ---- .PD .PP This section is terminated with a `\fB%%\fP' token on a line by itself. ! .SS "Access Specifications" The next section of the file contains a list of hosts and addresses which are allowed to connect to the console server. .B Conserver Index: conserver.cf/conserver.chat.man =================================================================== RCS file: conserver.cf/conserver.chat.man diff -N conserver.cf/conserver.chat.man *** /dev/null 1 Jan 1970 00:00:00 -0000 --- conserver.cf/conserver.chat.man 2 May 2002 05:19:22 -0000 *************** *** 0 **** --- 1,94 ---- + .\" $Id$ + .\" @(#)constab.5 01/06/91 OSU CIS; Thomas A. Fine + .de Vb + .ft CW + .nf + .ne \\$1 + .. + .de Ve + .ft R + + .fi + .. + .if n .na + .if n .nh + .TH CONSERVER.CHAT 5 "Local" + .SH NAME + conserver.chat \- console chat-script file for conserver(8) + .SH SYNOPSIS + \fIname\fP:\fIchat-script\fP + .\" XXX this optional feature is not yet available -- more parsing is + .\" required to handle it properly as currently the second field is + .\" simply passed in nearly verbatim form (leading and trailing + .\" whitespace is stripped) as part of a single-quoted argument to + .\" /bin/sh. + .\".PP + .\"\fIname\fP:-f \fIchat-script-filename\fP + .SH DESCRIPTION + .B Conservrer.chat + is an optional configuration file for + .BR conserver (8) + that specifies chat scripts for consoles. These scripts are handed off + to the + .BR chat (1) + program for execution whenever the console is (re)initialised. + .PP + Blank lines and comment lines (those beginning with a ``#'' and + optional leading whitespace) are ignored. Non-ignored lines + beginning with whitespace are considered continuations of the + previous line. This allows you to span one logical line over + many physical lines and insert comments wherever appropriate. + .PP + Chat-script specification lines are separated into two colon-separated + fields. Leading and trailing white space in each field is ignored. + .TP + .I name + the unique name by which this console is referred to. This name must + match the name of a console connection defined in the + .B Conserver.cf + file. + .TP + .I chat-script + A chat script specification that will be given on the + .BR chat (1) + command line. This field must not contain any single quotes as it will + itself be concatentated to the chat command and the whole will be passed + as a single-quoted operand to + .B "/bin/sh -c" + and the shell will then again break this string up into separate + parameters which will be given on the + .B chat + program command-line. As such any special characters must be quoted + with double-quotes as must empty parameters. The + .BR chat (1) + manual explains the script syntax and how characters are given. + .PP + Note that for network connected console ports (i.e. those on a terminal + server which are connected to via telnet), it is not currently possible + to cause the terminal server to generate a serial BREAK. Modifications + would be necessary to the + .B chat + program to allow it to send a telnet ``send brk'' command. + .SH EXAMPLE + Many terminal servers have an access password on their reverse telnet + ports. A chat script can be used to login past this password. Here we + assume access via the + .BR console (1) + client is controlled to prevent unauthorised connections and that the + .B conserver.chat + file itself is readable (and writable) only by the + .I root + user (which is of course the ID used to start + .BR conserver ). + .PP + .Vb 3 + # These consoles are on a terminal server with an access password + best-1.4 : "" "\er\en" "\e043--\e043" access + exb210 : "" "\er\en" "\e043--\e043" access + hubly : "" "\er\en" "\e043--\e043" BellSux + .Ve + .SH "SEE ALSO" + .BR chat (1), + .BR console (1), + .BR conserver.cf (5), + .BR conserver (8) --gRHcdVS1Np-- From bryan@stansell.org Fri May 3 20:00:24 2002 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4430O2S001388 for ; Fri, 3 May 2002 20:00:24 -0700 (PDT) Received: (from bryan@localhost) by underdog.stansell.org (8.12.2/8.12.2/Submit) id g4430ORD001387 for users@conserver.com; Fri, 3 May 2002 20:00:24 -0700 (PDT) Date: Fri, 3 May 2002 20:00:24 -0700 From: Bryan Stansell To: users@conserver.com Subject: Re: Console commands on AIX Message-ID: <20020503200024.I14786@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 lepera@us.ibm.com on Fri, May 03, 2002 at 09:34:19AM -0400 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 Fri, May 03, 2002 at 09:34:19AM -0400, William P LePera wrote: > Hello, > > Don't know if anyone has experience with conserver and AIX 5.1, but I'm > seeing a weird problem and I hope someone can help... i haven't...but i have a guess as to something to try. instead of changing the HAVE_PTSNAME config.h option, edit conserver/fallback.c and change the /dev/ptmx references to /dev/ptc (there should be two). i'm not sure if this will work, but it looks like the right thing for aix 5 (looks like aix 3, 4 and 5 all have different methods of allocating ptys). all this is loosely based on docs i found on http://publibn.boulder.ibm.com...so, hopefully i read them right. > Should I have changed a different env variable to work around the ptmx > problem? Could there be a problem with the "configure" utility, which > seemed to configure the compile environment to think that ptmx was present? if the change above works, it'll be an easy fix to check for /dev/ptc and use that instead of /dev/ptmx (seems safer than hardcoding in another _AIX check in the code). > Any help or debug tips appreciated! hope that helps! let me know how it goes... Bryan From bernard.dugas@is-production.com Wed May 8 08:03:25 2002 Received: from mail.petrel.ch (mail.petrel.ch [144.85.10.35]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g48F3O2S011728 for ; Wed, 8 May 2002 08:03:25 -0700 (PDT) Received: from tnp-rt-010.is-production.com ([144.85.4.122] helo=is-production.com) by mail.petrel.ch with esmtp (Exim 3.35 #2) id 175SyS-0005UO-00 for users@conserver.com; Wed, 08 May 2002 17:03:24 +0200 Message-ID: <3CD93D41.7E3A242C@is-production.com> Date: Wed, 08 May 2002 16:59:13 +0200 From: Bernard Dugas Organization: ISProduction X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr,en MIME-Version: 1.0 To: users@conserver.com Subject: COM port for voltage command/measurement ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Hi, I did some search on your archives and others, and found no info on that : I need to use a com port to command voltage on com port pins, to be able to drive external relays. Would anybody have any hint/example for that function ? Best regards, -- __________ Bernard DUGAS ________________________________________ From Ernie.Oporto@viragelogic.com Wed May 8 08:41:29 2002 Received: from viragelogic.com ([63.150.53.109]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g48FfS2S012067 for ; Wed, 8 May 2002 08:41:28 -0700 (PDT) Received: by viragelogic.com; id LAA02086; Wed, 8 May 2002 11:43:40 -0400 (EDT) Received: from nodnsquery(129.200.11.40) by webshield.viragelogic.com via smap (V1.0) id xma002079; Wed, 8 May 02 11:43:33 -0400 From: "Ernie Oporto" To: "Bernard Dugas" Cc: Subject: RE: COM port for voltage command/measurement ? Date: Wed, 8 May 2002 11:41:07 -0400 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002A_01C1F685.3CFC3750" In-Reply-To: <3CD93D41.7E3A242C@is-production.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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: This is a multi-part message in MIME format. ------=_NextPart_000_002A_01C1F685.3CFC3750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit http://www.weedtech.com/ has info on controlling relays with a COM port. See this also... http://www.velleman.be/Product.asp?lan=1&id=9358 > -----Original Message----- > From: users-admin@conserver.com [mailto:users-admin@conserver.com]On > Behalf Of Bernard Dugas > Sent: Wednesday, May 08, 2002 10:59 AM > To: users@conserver.com > Subject: COM port for voltage command/measurement ? > > > Hi, > > I did some search on your archives and others, and found no info on that > : > > I need to use a com port to command voltage on com port pins, to be able > to drive external relays. > > Would anybody have any hint/example for that function ? > > Best regards, > -- > > __________ Bernard DUGAS ________________________________________ > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users > ------=_NextPart_000_002A_01C1F685.3CFC3750 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9DCCApIw ggH7oAMCAQICAwUTKzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYyMTEzMTUxM1oXDTAyMDYyMTEzMTUxM1owTjEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjErMCkGCSqGSIb3DQEJARYcZXJuaWUub3BvcnRvQHZpcmFnZWxvZ2lj LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA8wJMTF41OXQe5rxW6BROWjGrj9iGlCMn lZvumu950DX7TI8nJOUB3ZeMs01WNkKeuxK7nE3RGwGt2NjeDrYDqBqG1ScNkMpkxuZLhq2IhxUo rjfjmzgE1ln7MD+NvejFENaI4PA5n5x/zJLmZyCqs9oBLjeqtkmhlmX4n5srFP8CAwEAAaM5MDcw JwYDVR0RBCAwHoEcZXJuaWUub3BvcnRvQHZpcmFnZWxvZ2ljLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBAgUAA4GBAB+KS7IJsyS0Wn61PPM8G9Ke9VA5dwyu3c0si+RnCKNDjvtKuO/8aD8b 8Q18MBU9SrbjJzq0B6yBBSjwj665rE7jCCUR8pMM9uJwQSxUiQfQWWmuV7qr1wknfGcCzXcz3GeG TfygeRqhh7WonJ+H9hUog4f5mvU2RsKVCsK5GkQrMIIDKTCCApKgAwIBAgIBDDANBgkqhkiG9w0B AQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAw MDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tew kd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWom KmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMIIDLTCCApagAwIB AgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt ZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx 6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hN D3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb 5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1 lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzc eePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr 5PjRzneigTGCAqowggKmAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlm aWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAC AwUTKzAJBgUrDgMCGgUAoIIBZTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wMjA1MDgxNTQxMDVaMCMGCSqGSIb3DQEJBDEWBBS/veeymsP9GOwoCbvDOUGrtKnBlDBY BgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGSMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzAN BgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1Bl cnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwUTKzANBgkqhkiG9w0BAQEFAASBgFk5G1GC XY+HL3UK+OMnfiFCO6HTpW673kCbtbV4l8DxqliNnwWhC1PQLGNIDzc6i0rzY3vnnxUi+3yn1wRi sA3oxkxUsY2JnWG0S8PsfTSD5ILSg6GhrS4s0fd02A/1fpruYRcxevZSledYfQ6d/rDaUHU6810C TWaEt3ELGLd+AAAAAAAA ------=_NextPart_000_002A_01C1F685.3CFC3750-- From brandon.a.saunders.1@ohio.edu Wed May 8 13:40:07 2002 Received: from oak.cats.ohiou.edu (oak.cats.ohiou.edu [132.235.8.44]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g48Ke72S014538 for ; Wed, 8 May 2002 13:40:07 -0700 (PDT) Received: from legos.cns.ohiou.edu (legos.cns.ohiou.edu [132.235.197.118]) by oak.cats.ohiou.edu (8.12.0.Beta19/8.12.0.Beta19) with ESMTP id g48KalVG373587; Wed, 8 May 2002 16:36:47 -0400 (EDT) Date: Wed, 08 May 2002 16:33:50 -0400 From: Brandon Saunders To: Bernard Dugas , users@conserver.com Subject: Re: COM port for voltage command/measurement ? Message-ID: <25320000.1020890030@legos.cns.ohiou.edu> In-Reply-To: <3CD93D41.7E3A242C@is-production.com> References: <3CD93D41.7E3A242C@is-production.com> X-Mailer: Mulberry/2.2.0 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========1740116916==========" 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: --==========1740116916========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I have seen this done with Paralelle ports more often than serial ports. Brandon Saunders Senior Network Engineer Ohio University Communication Network Services Email: brandon.a.saunders.1@ohiou.edu Phone: (740)593-9835 Cell: (740)707-4945 Pager: (740)592-7828 Fax: (740)593-1944 --On Wednesday, May 08, 2002 04:59:13 PM +0200 Bernard Dugas=20 wrote: > Hi, > > I did some search on your archives and others, and found no info on that > : > > I need to use a com port to command voltage on com port pins, to be able > to drive external relays. > > Would anybody have any hint/example for that function ? > > Best regards, > -- > > __________ Bernard DUGAS ________________________________________ > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users --==========1740116916========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE82Yuu/JU6IoYGTd0RAt5kAJ0b1PfvkJLqIWUofAf9EhQmwxQWzgCgiPAQ VtJoRrEMV2smEIwCKD8aC6E= =3sGs -----END PGP SIGNATURE----- --==========1740116916==========-- From aaron@osdl.org Mon May 13 13:19:38 2002 Received: from mail.osdl.org (air-2.osdl.org [65.201.151.6]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4DKJc2S005472 for ; Mon, 13 May 2002 13:19:38 -0700 (PDT) Received: from osdlab.pdx.osdl.net (osdlab.pdx.osdl.net [172.20.1.28]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id g4DKJWR16597 for ; Mon, 13 May 2002 13:19:32 -0700 Date: Mon, 13 May 2002 13:19:32 -0700 (PDT) From: Aaron Burt X-X-Sender: To: Subject: Break sequence problem with RAS2000 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Howdy. Run into a bit of a problem. I have two Computone RAS2000 64-port terminal servers providing console and EMP power control to a mess of Linux boxen. Both terminal servers can send a serial break from a Telnet session with a ^] and send brk. One of 'em will send a break from a Console session with ^ecl1, but the other just sends garbage. ^ecl2 and ^ecl3 don't work either. Any ideas? Also, anyone been able to make break work on a Perle CS9024? From glenn.grimes@eircom.net Wed May 15 07:43:29 2002 Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by underdog.stansell.org (8.12.2/8.12.2) with SMTP id g4FEhR2S001729 for ; Wed, 15 May 2002 07:43:28 -0700 (PDT) Received: (qmail 28903 messnum 1207998 invoked from network[159.134.242.248/glennfreebsd.eng.eircom.net]); 15 May 2002 14:37:56 -0000 Received: from glennfreebsd.eng.eircom.net (HELO eircom.net) (159.134.242.248) by mail04.svc.cra.dublin.eircom.net (qp 28903) with SMTP; 15 May 2002 14:37:56 -0000 Message-ID: <3CE2711E.4E820508@eircom.net> Date: Wed, 15 May 2002 15:30:54 +0100 From: Glenn Grimes X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.2-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: users@conserver.com Subject: Conserver 7.1.3 & Netapp Filers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Hi all, Is anyone out there using conserver to connect to a netapp filer. I have tried all variations of cabling, straight/rolled/crossover, with different DB9 connectors, (the conserver server & the filer are a few meters apart, set up is Conserver_PC -> Cisco 2620 -> Patch Panel -> Patch Panel -> Filer). Netapp filers in general use a normal DB9 male connector and a rolled cable. I have tried making new DB9 connectors with Pins 2 & 3 swapped etc but also with no luck. I have tried connecting my patching into a PC and it is working fine with conserver, I am receiving a signal light on the 2620, but when I connect to the filer I do not receive a signal back at the Cisco 2620. Any help would be greatly appreciated. Rgds, Glenn -- System & Network Operations eircom net From mgx@ornl.gov Wed May 15 07:52:02 2002 Received: from sif.lsd.ornl.gov (sif.lsd.ornl.gov [160.91.102.97]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4FEq12S001819 for ; Wed, 15 May 2002 07:52:01 -0700 (PDT) Received: by sif.lsd.ornl.gov (Postfix on SuSE Linux 7.3 (i386), from userid 15083) id B6A9C1A6C2; Wed, 15 May 2002 10:51:56 -0400 (EDT) Date: Wed, 15 May 2002 10:51:56 -0400 From: Michael Galloway To: Glenn Grimes Cc: users@conserver.com Subject: Re: Conserver 7.1.3 & Netapp Filers Message-ID: <20020515105156.F7058@sif.lsd.ornl.gov> References: <3CE2711E.4E820508@eircom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <3CE2711E.4E820508@eircom.net> User-Agent: Mutt/1.3.22.1i 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: Hi Glenn! yup, using cyclades TS2000 to get to my netapp consoles. i just made up some DB-9 to RJ45 cables per the doc's here: http://www.cyclades.com/solutions/techtalk/techtalk15.php and they worked fine for me. maybe cisco would have some help on cabling for you.... -- michael ps: i'm connecting to F520s and F760's. On Wed, 15 May 2002, Glenn Grimes wrote: > Hi all, > > Is anyone out there using conserver to connect to a netapp filer. I > have tried all variations of cabling, straight/rolled/crossover, with > different DB9 connectors, (the conserver server & the filer are a few > meters apart, set up is Conserver_PC -> Cisco 2620 -> Patch Panel -> > Patch Panel -> Filer). > > Netapp filers in general use a normal DB9 male connector and a rolled > cable. I have tried making new DB9 connectors with Pins 2 & 3 swapped > etc but also with no luck. I have tried connecting my patching into a > PC and it is working fine with conserver, I am receiving a signal light > on the 2620, but when I connect to the filer I do not receive a signal > back at the Cisco 2620. > > Any help would be greatly appreciated. > > Rgds, > > Glenn > -- > System & Network Operations > eircom net > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users > From Ernie.Oporto@viragelogic.com Wed May 15 08:12:46 2002 Received: from viragelogic.com ([63.150.53.109]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4FFCk2S002019 for ; Wed, 15 May 2002 08:12:46 -0700 (PDT) Received: by viragelogic.com; id LAA17866; Wed, 15 May 2002 11:15:13 -0400 (EDT) Received: from nodnsquery(129.200.11.40) by webshield.viragelogic.com via smap (V1.0) id xma017856; Wed, 15 May 02 11:14:51 -0400 From: "Ernie Oporto" To: "Glenn Grimes" , Subject: RE: Conserver 7.1.3 & Netapp Filers Date: Wed, 15 May 2002 11:12:23 -0400 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0178_01C1FC01.61D6D2C0" Importance: Normal In-Reply-To: <3CE2711E.4E820508@eircom.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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: This is a multi-part message in MIME format. ------=_NextPart_000_0178_01C1FC01.61D6D2C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have a Digi Portserver II connected to my F840. Stock serial cabling I had on hand worked for me. Ernie > -----Original Message----- > From: users-admin@conserver.com [mailto:users-admin@conserver.com]On > Behalf Of Glenn Grimes > Sent: Wednesday, May 15, 2002 10:31 AM > To: users@conserver.com > Subject: Conserver 7.1.3 & Netapp Filers > > > Hi all, > > Is anyone out there using conserver to connect to a netapp filer. I > have tried all variations of cabling, straight/rolled/crossover, with > different DB9 connectors, (the conserver server & the filer are a few > meters apart, set up is Conserver_PC -> Cisco 2620 -> Patch Panel -> > Patch Panel -> Filer). > > Netapp filers in general use a normal DB9 male connector and a rolled > cable. I have tried making new DB9 connectors with Pins 2 & 3 swapped > etc but also with no luck. I have tried connecting my patching into a > PC and it is working fine with conserver, I am receiving a signal light > on the 2620, but when I connect to the filer I do not receive a signal > back at the Cisco 2620. > > Any help would be greatly appreciated. > > Rgds, > > Glenn > -- > System & Network Operations > eircom net > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users > ------=_NextPart_000_0178_01C1FC01.61D6D2C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9DCCApIw ggH7oAMCAQICAwUTKzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYyMTEzMTUxM1oXDTAyMDYyMTEzMTUxM1owTjEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjErMCkGCSqGSIb3DQEJARYcZXJuaWUub3BvcnRvQHZpcmFnZWxvZ2lj LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA8wJMTF41OXQe5rxW6BROWjGrj9iGlCMn lZvumu950DX7TI8nJOUB3ZeMs01WNkKeuxK7nE3RGwGt2NjeDrYDqBqG1ScNkMpkxuZLhq2IhxUo rjfjmzgE1ln7MD+NvejFENaI4PA5n5x/zJLmZyCqs9oBLjeqtkmhlmX4n5srFP8CAwEAAaM5MDcw JwYDVR0RBCAwHoEcZXJuaWUub3BvcnRvQHZpcmFnZWxvZ2ljLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBAgUAA4GBAB+KS7IJsyS0Wn61PPM8G9Ke9VA5dwyu3c0si+RnCKNDjvtKuO/8aD8b 8Q18MBU9SrbjJzq0B6yBBSjwj665rE7jCCUR8pMM9uJwQSxUiQfQWWmuV7qr1wknfGcCzXcz3GeG TfygeRqhh7WonJ+H9hUog4f5mvU2RsKVCsK5GkQrMIIDKTCCApKgAwIBAgIBDDANBgkqhkiG9w0B AQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAw MDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tew kd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWom KmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMIIDLTCCApagAwIB AgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt ZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx 6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hN D3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb 5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1 lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzc eePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr 5PjRzneigTGCAqowggKmAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlm aWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAC AwUTKzAJBgUrDgMCGgUAoIIBZTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wMjA1MTUxNTEyMjBaMCMGCSqGSIb3DQEJBDEWBBRbD5EZU6Q00URu3O/bL2Qb0/8irTBY BgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGSMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzAN BgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1Bl cnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwUTKzANBgkqhkiG9w0BAQEFAASBgO1uZwp4 a4SD6qNIs0eno9aDb4fUST1IHYyNjkceMBZWVbv4kKB3kj5EDMwC/94sGI2EYt5V24zGYEHsmEt9 PqGB8LeMR4r59zB7zXSwEiW8GUDGmtdcDccNA8hT6JWXWUQMn2xMKYw0FIjDUFPLxHn31zUyc74e G58/nsBDlNZdAAAAAAAA ------=_NextPart_000_0178_01C1FC01.61D6D2C0-- From zonker@certaintysolutions.com Wed May 15 09:39:52 2002 Received: from yosemite.main.gnac.com (yosemite.rwc.gnac.net [198.151.248.221]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4FGdq2S002762 for ; Wed, 15 May 2002 09:39:52 -0700 (PDT) Received: (from uucp@localhost) by yosemite.main.gnac.com (8.11.6+Sun/8.11.6) id g4FGdq000131; Wed, 15 May 2002 09:39:52 -0700 (PDT) Received: from pepe.main.gnac.com(192.168.1.21) by yosemite.main.gnac.com via csmap (V6.0) id srcEAAfMayma; Wed, 15 May 02 09:39:51 -0700 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 g4FGZ5410579; Wed, 15 May 2002 09:35:05 -0700 (PDT) Received: (from zonker@localhost) by tweety.main.gnac.com (8.9.3/8.7.3/GNAC-COM-1.1) id JAA19254; Wed, 15 May 2002 09:36:03 -0700 (PDT) Date: Wed, 15 May 2002 09:36:03 -0700 From: David Harris To: Glenn Grimes , users@conserver.com Subject: Re: Conserver 7.1.3 & Netapp Filers Message-ID: <20020515093603.H27149@tweety.main.gnac.com> References: <3CE2711E.4E820508@eircom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3CE2711E.4E820508@eircom.net>; from glenn.grimes@eircom.net on Wed, May 15, 2002 at 03:30:54PM +0100 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: We've got NetApp filers connected at a number of sites, to a few brands of console servers (including the Cisco devices). You probably already know the Cisco pinouts, but you can find them at http://www.conserver.com/consoles/ciscocons.html (Note that the Cisco adapters tie the center two RJ-45 leads together, which tells the Cisco port it's in RS-232 mode...this may be important if you're using a conscole or aux port.) You can also get adapter reference info on the host-to-adapter guide (http://www.conserver.com/consoles/cisco-hosts.html), and info on adapters from Americable is there as well (follow links to the cisco adapter kit). The main page (http://www.conserver.com/consoles/) has pointers to guides for Xylogics/Bay/Nortel Annex servers, Chase IOLAN, and Xylogics/iTouch servers as well, in case anyone is interested. -Z- (http://www.conserver.com/consoles/breakoff.html) From lepera@us.ibm.com Thu May 16 15:03:47 2002 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4GM3l2S020157 for ; Thu, 16 May 2002 15:03:47 -0700 (PDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4GM3fg5213972 for ; Thu, 16 May 2002 18:03:41 -0400 Received: from d01ml251.pok.ibm.com (d01ml251.pok.ibm.com [9.56.224.79]) by northrelay02.pok.ibm.com (8.11.1m3/8.11.2) with ESMTP id g4GM3cf31496 for ; Thu, 16 May 2002 18:03:38 -0400 Subject: Dynamic Reconfiguration To: users@conserver.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "William P LePera" Date: Thu, 16 May 2002 18:03:34 -0400 X-MIMETrack: Serialize by Router on D01ML251/01/M/IBM(Release 5.0.10 |March 22, 2002) at 05/16/2002 06:03:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii 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: Hello. I am seeing a strange behavior with dynamic reconfiguration, and am curious if anyone else has seen it or knows a way around it. conserver is compiled with the default of 16 consoles per process. If I start conserver when configured for 8 consoles, I'll end up with two conserver processes, one master process and another for the consoles, which I expect. If I change the config to add another console, then send SIGHUP to the master process, another conserver process is spawned, for a total of three. I would have expected the new console to be added to the existing child process, but that does not appear to be the case. At this point, if conserver is brought down and back up again, I get two process, and the child process has all 9 consoles on it. Is this the way it's supposed to work? If I add consoles in batches and send SIGHUP after each batch, will I always get a new conserver process for each SIGHUP? Is there a way around this which doesn't involve killing conserver and restarting it? Thanks, Bill LePera IBM Server Group Poughkeepsie, NY From bryan@stansell.org Thu May 16 17:41:03 2002 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4H0f32S021453 for ; Thu, 16 May 2002 17:41:03 -0700 (PDT) Received: (from bryan@localhost) by underdog.stansell.org (8.12.2/8.12.2/Submit) id g4H0f3K0021452 for users@conserver.com; Thu, 16 May 2002 17:41:03 -0700 (PDT) Date: Thu, 16 May 2002 17:41:03 -0700 From: Bryan Stansell To: users@conserver.com Subject: Re: Dynamic Reconfiguration Message-ID: <20020516174103.C14786@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 lepera@us.ibm.com on Thu, May 16, 2002 at 06:03:34PM -0400 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, May 16, 2002 at 06:03:34PM -0400, William P LePera wrote: > I am seeing a strange behavior with dynamic reconfiguration, and am curious > if anyone else has seen it or knows a way around it. heh, unfortunately, it isn't strange. > If I change the config to add another console, then send SIGHUP to the > master process, another conserver process is spawned, for a total of three. > I would have expected the new console to be added to the existing child > process, but that does not appear to be the case. At this point, if > conserver is brought down and back up again, I get two process, and the > child process has all 9 consoles on it. yep. > Is this the way it's supposed to work? If I add consoles in batches and > send SIGHUP after each batch, will I always get a new conserver process for > each SIGHUP? Is there a way around this which doesn't involve killing > conserver and restarting it? nope. it's the way it was designed. conserver will fork off as many processes as necessary to handle the new consoles, so if you add 1-16, you get one new process, 17-32, you get two, etc (with the default 16 per process). if you've been adding them slowly over time and have a lot of processes and want the consoles managed by less processes, you're only choice is to do a full restart. the reason for designing it to work this way is simple: there is no communication between the conserver processes. there is just the forking of sub-processes and relaying of the clients. because of this, each sub-process ends up rereading the config file and operating independently of the master process. since the master needs to know which sub-process is managing which consoles, having an existing process use one of it's free slots to manage a console is troublesome. and, if you delete a console, which gives a semi-random sub-process a free slot, you end up with multiple sub-processes with free slots and no way of coordinating which processes control the new consoles. yikes...the more i go on the uglier it gets, but you get the idea. yes, if there was some sort of communication between the processes, this could all be avoided and the master process could reread the config file, figure out the new consoles, send messages instructing sub-processes to add the console definitions to a free slots, and new processes wouldn't have to be spawned. it was a tradeoff between implementing an array of message passing (uni-directional, at least) or just using the already-existing forking code. i took the easy way out and just extended the existing philosophy in the code. so, yes, it's not ideal to add just one or two consoles at a time (and it would be nice if it was handled better)...but at least you can! Bryan From aaron@osdl.org Tue May 21 10:55:37 2002 Received: from mail.osdl.org (air-2.osdl.org [65.201.151.6]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4LHtbjq006385 for ; Tue, 21 May 2002 10:55:37 -0700 (PDT) Received: from osdlab.pdx.osdl.net (osdlab.pdx.osdl.net [172.20.1.28]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id g4LHtWR12756 for ; Tue, 21 May 2002 10:55:32 -0700 Date: Tue, 21 May 2002 10:55:32 -0700 (PDT) From: Aaron Burt X-X-Sender: To: Subject: Further break-sequence weirdness Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: So I've got a couple Computone RAS2000 terminal servers (Term00, Term01) connecting Conserver to a bunch'a Linux boxen. I have Conserver v7.2.1 installed on the server (Build) and on another box (Octopus). Both boxes run Red Hat Linux 7.1 and Conserver was installed from the same RPM. When I run the console client on Build, I can use ^Ecl1 to send a break to boxes on Term00, but not Term01. When I run the console client on Octopus, connecting to Build, I can use ^Ecl1 to send a break to boxes on Term01, but not Term00. Weird, huh? From bryan@stansell.org Tue May 21 12:42:07 2002 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4LJg7jq007356 for ; Tue, 21 May 2002 12:42:07 -0700 (PDT) Received: (from bryan@localhost) by underdog.stansell.org (8.12.2/8.12.2/Submit) id g4LJg75L007355 for users@conserver.com; Tue, 21 May 2002 12:42:07 -0700 (PDT) Date: Tue, 21 May 2002 12:42:07 -0700 From: Bryan Stansell To: users@conserver.com Subject: Re: Further break-sequence weirdness Message-ID: <20020521124207.X14786@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 aaron@osdl.org on Tue, May 21, 2002 at 10:55:32AM -0700 Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: hi aaron, On Tue, May 21, 2002 at 10:55:32AM -0700, Aaron Burt wrote: > When I run the console client on Build, I can use ^Ecl1 to send a break to > boxes on Term00, but not Term01. your first post about this made me think there might have been a configuration issue on Term01...but considering the following: > When I run the console client on Octopus, connecting to Build, I can use > ^Ecl1 to send a break to boxes on Term01, but not Term00. i kinda doubt it. > Weird, huh? more like impossible, actually (my immediate reaction), but who knows. so, the assumption i'm reading in this is that Build is the only host actually running the conserver binary, right? it's making the tcp connections to both Term00 and Term01. the only role in this that Octopus plays is running the client (and as you said, connecting to Build). if this is true, then maybe you just "got lucky" and saw a pattern where there really isn't one? i say that because all the logic, all the break sending, all the "everything important" is happening inside the conserver binary - the client is just triggering events inside it. so, regardless of where the client lives, if the break sequence is triggered in a particular conserver binary, it *should* behave the same every time (hence my immediate "impossible" reaction). but something is obviously wrong, and it's weird enough that i'll need a detailed explaination of the setup (or a confirmation that my assumptions above are correct - that's probably enough detail - and maybe a copy of the conserver.cf file would help too) and serious amount of debug output. if you run both conserver and the console client with -DD (yep, two D's) on all the hosts and redo your tests, maybe i'll be able to see something. it *will* be a lot of output. and you may want to connect multiple times from Octopus or Build and see if that changes the behavior - or even open another window and bump yourself off from the same client host and see. basically, i'm wondering if another pattern can be found. you know where to find me if you're able to put together all that info. :-) Bryan From cheek@mars-systems.com Wed May 22 10:06:29 2002 Received: from nova01.mars-systems.com (nova01-e.mars-systems.com [150.212.252.5]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4MH6Sjq021032 for ; Wed, 22 May 2002 10:06:29 -0700 (PDT) Received: from exchange-02.mars-systems.com (exchange-02.mars-systems.com [150.212.17.103]) by nova01.mars-systems.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MH6MK00621 for ; Wed, 22 May 2002 13:06:22 -0400 (EDT) Received: by exchange-02.mars-systems.com with Internet Mail Service (5.5.2653.19) id <29TCADG6>; Wed, 22 May 2002 12:57:28 -0400 Message-ID: From: Matt Cheek To: "'users@conserver.com'" Subject: Ki Networks CLIM experiences Date: Wed, 22 May 2002 12:57:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201B1.BE910750" Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C201B1.BE910750 Content-Type: text/plain; charset="iso-8859-1" All, This is simply an overview of my experiences with the CLIM console management product from Ki Networks (http://www.kinetworks.com). These are only my observations and opinions. Your mileage may vary. Matt -- Matthew Cheek | Medical Archival Systems, Inc. (a.k.a. MARS) Systems Analyst IV | 1370 Beulah Road | Pittsburgh, PA 15235-5084 cheek@mars-systems.com | v: 412-473-6565 | f: 412-473-6538 Background: I joined Medical Archival Systems, Inc. (part of University of Pittsburgh Medical Center) in early 2000. At that time, MARS had approximately 75 consoles (mostly UNIX systems and network gear such as Cisco routers and switches) with about 60 of these consoles connected to a couple of Xylogics Annex3 terminal servers. There was no console management solution in place at the time and staff would simply telnet directly to the terminal server port in order to connect to particular consoles. Obviously this was an unworkable solution and I set out to find and deploy a true console management solution. (I had used DEC's Polycenter Console Manager (PCM) at two previous employers.) At the same time, I continued to add console connections to existing and new terminal servers. Before beginning my search, I identified and ranked the desired attributes: 1) Console Management - The console manager "manages" which terminal server port is which console - no remembering which port is which 2) Console Control - Easily manage the console (e.g. review the last N lines, send a "break" character, etc.) 3) Console Logging - Useful for diagnosing system crashes or for auditing console access 4) Read-Only Console Connection - Provides the ability to watch over another user's shoulder 5) Security Mechanism - Only permit authorized users to connect to a console 6) Event Notification - Provide notification (e.g. email, pager) of specific console text My initial research focused on commercial console management solutions including CLIM (Command Line Interface Manager) from Ki Networks and ControlTower from Aurora Technologies. Unfortunately, while these commercial products provided rich and robust console management features, they were also prohibitively expensive for my environment which had grown to 178 managed consoles. In Aug 2000, I discovered Conserver via a mention on the Sun Managers mailing list. Conserver, being an open source product, certainly met my unstated requirement of low- or no-cost. In addition, Conserver appeared to meet the first five requirements (i.e. Console Management, Control, Logging plus Read-Only Connections and a rudimentary Security Mechanism). After downloading, building, and installing the product, I was pleased to discovered that Conserver did in fact meet my immediate needs. Additionally, since the Conserver product does not currently provide any sort of event notification, I deployed SWATCH (the Simple WATCHer, http://www.oit.ucsb.edu/~eta/swatch/) to address the Event Notification requirement. SWATCH is an open source utility that watches log files in real time for specific text matches and notifies you in a pre-determined manner when a match is found. I continued to use the combination of Conserver and SWATCH as my Console Management Solution until the middle of May 2002. In early May 2002, Ki Networks made an extraordinary offer to any active Conserver user. They offered a complimentary, permanent license to deploy their CLIM and NodeMonitor products in exchange for feedback on how to improve CLIM. In addition, Ki Networks agreed to provide ongoing support for these products. Since CLIM was one of the commercial products I had evaluated in 2000, I jumped at the offer and worked with Ki Networks to download and install CLIM on an evaluation basis. Since I consider Console Management a critical production facility, one of my minor concerns was understanding the terms of use of this permanent license and the support options. Happily, Ki Networks provided formal license and support documents that were quickly approved by my management. Once the red tape was worked out, I began planning the deployment of CLIM across my enterprise. CLIM Deployment: My current environment is four terminal servers with 178 managed consoles. The CLIM installation was nearly trouble free and within 15 minutes I was able to start the Ki Works GUI to start adding consoles. It quickly became apparent that CLIM is more that just a simple console manager. CLIM is a comprehensive system management product that provides log file management, event management and notification, and terminal server management. Along with this comprehensiveness comes complexity. While Conserver is driven by a fairly simple configuration file, CLIM is best configured via the Ki Works GUI. (There is a CLI configuration utility, but I've not explored its capabilities yet.) Since my primary goal is console management, I started by creating several console connections. The main interface to CLIM is a graphical application (i.e. X. I believe there is also a Windows version if that is your wont.) called "Ki Works". This is a very intuitive GUI for all aspects of configuration and console management. The first step is to define the terminal server(s). This is a simple task that is made easy by predefined configurations for most popular terminal servers (e.g. Xylogics, Cyclades, Lantronix, Cisco, etc). Once a terminal server is defined, adding a console is just as simple. Simply name the console, select the terminal server it is connected to, specify the port number on the terminal server, and select the console's hardware and operating system type. (The last two options instruct CLIM how to interact with the console. For instance, how to send a break, what the boot prompt is, etc.) After creating a console, double clicking on the resulting console icon pops up a console window and off you go. There are actually several methods of connecting to a console: a) Simple Text Connection in a window (i.e. xterm, dtterm) b) GUI connection in a small graphical app with drop-down menus for issuing common commands such as sending a break, powering off a system, etc. c) Read-Only Connection in a window d) Command Line from a shell prompt and, most intriguing: e) Gang Connect which lets you connect to multiple consoles at once and type the same commands into all connections. Very handy! After running several weeks with just a handful of non-production consoles to explore the product, I have scheduled the production cutover for early June. At that time, I will shutdown Conserver and add all my remaining consoles into the CLIM environment. Before that time, I will explore the CLIM command line configuration program (climcp) which will be necessary to quickly and accurately batch add 150+ consoles to the CLIM configuration. I continue to discover features and benefits of CLIM as I use the product. For instance, the CLIM Event Management module (EVM) includes a large set of preprogrammed console event types. For instance there are over a hundred UNIX-specific events. Some examples include system panic, file system full, etc. At the very least, these preprogrammed event types provide an example of how to create custom, application/environment specific event types. ------_=_NextPart_001_01C201B1.BE910750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ki Networks CLIM experiences

All,

This is simply an overview of my experiences with the = CLIM console management product from Ki Networks (http://www.kinetworks.com). These are only my = observations and opinions. Your mileage may vary.

Matt
--
Matthew = Cheek          | Medical = Archival Systems, Inc. (a.k.a. MARS)
Systems Analyst IV     | 1370 = Beulah Road | Pittsburgh, PA 15235-5084
cheek@mars-systems.com | v:  412-473-6565 | = f:  412-473-6538



Background:
I joined Medical Archival Systems, Inc. (part of = University of Pittsburgh Medical Center) in early 2000. At that time, = MARS had approximately 75 consoles (mostly UNIX systems and network = gear such as Cisco routers and switches) with about 60 of these = consoles connected to a couple of Xylogics Annex3 terminal servers. = There was no console management solution in place at the time and staff = would simply telnet directly to the terminal server port in order to = connect to particular consoles. Obviously this was an unworkable = solution and I set out to find and deploy a true console management = solution. (I had used DEC's Polycenter Console Manager (PCM) at two = previous employers.) At the same time, I continued to add console = connections to existing and new terminal servers.

Before beginning my search, I identified and ranked = the desired attributes:

1) Console Management - The console manager = "manages" which terminal server port is which console - no = remembering which port is which

2) Console Control - Easily manage the console (e.g. = review the last N lines, send a "break" character, = etc.)
3) Console Logging - Useful for diagnosing system = crashes or for auditing console access
4) Read-Only Console Connection - Provides the = ability to watch over another user's shoulder
5) Security Mechanism - Only permit authorized users = to connect to a console
6) Event Notification - Provide notification (e.g. = email, pager) of specific console text

My initial research focused on commercial console = management solutions including CLIM (Command Line Interface Manager) = from Ki Networks and ControlTower from Aurora Technologies. = Unfortunately, while these commercial products provided rich and robust = console management features, they were also prohibitively expensive for = my environment which had grown to 178 managed consoles. In Aug 2000, I = discovered Conserver via a mention on the Sun Managers mailing = list.

Conserver, being an open source product, certainly = met my unstated requirement of low- or no-cost. In addition, Conserver = appeared to meet the first five requirements (i.e. Console Management, = Control, Logging plus Read-Only Connections and a rudimentary Security = Mechanism). After downloading, building, and installing the product, I = was pleased to discovered that Conserver did in fact meet my immediate = needs.

Additionally, since the Conserver product does not = currently provide any sort of event notification, I deployed SWATCH = (the Simple WATCHer, http://www.oit.ucsb.edu/~eta/swatch/) to address = the Event Notification requirement. SWATCH is an open source utility = that watches log files in real time for specific text matches and = notifies you in a pre-determined manner when a match is = found.

I continued to use the combination of Conserver and = SWATCH as my Console Management Solution until the middle of May = 2002.

In early May 2002, Ki Networks made an extraordinary = offer to any active Conserver user. They offered a complimentary, = permanent license to deploy their CLIM and NodeMonitor products in = exchange for feedback on how to improve CLIM. In addition, Ki Networks = agreed to provide ongoing support for these products.

Since CLIM was one of the commercial products I had = evaluated in 2000, I jumped at the offer and worked with Ki Networks to = download and install CLIM on an evaluation basis. Since I consider = Console Management a critical production facility, one of my minor = concerns was understanding the terms of use of this permanent license = and the support options. Happily, Ki Networks provided formal license = and support documents that were quickly approved by my management. Once = the red tape was worked out, I began planning the deployment of CLIM = across my enterprise.

CLIM Deployment:
My current environment is four terminal servers with = 178 managed consoles.

The CLIM installation was nearly trouble free and = within 15 minutes I was able to start the Ki Works GUI to start adding = consoles. It quickly became apparent that CLIM is more that just a = simple console manager. CLIM is a comprehensive system management = product that provides log file management, event management and = notification, and terminal server management. Along with this = comprehensiveness comes complexity. While Conserver is driven by a = fairly simple configuration file, CLIM is best configured via the Ki = Works GUI. (There is a CLI configuration utility, but I've not explored = its capabilities yet.)

Since my primary goal is console management, I = started by creating several console connections. The main interface to = CLIM is a graphical application (i.e. X. I believe there is also a = Windows version if that is your wont.) called "Ki Works". = This is a very intuitive GUI for all aspects of configuration and = console management. The first step is to define the terminal server(s). = This is a simple task that is made easy by predefined configurations = for most popular terminal servers (e.g. Xylogics, Cyclades, Lantronix, = Cisco, etc). Once a terminal server is defined, adding a console is = just as simple. Simply name the console, select the terminal server it = is connected to, specify the port number on the terminal server, and = select the console's hardware and operating system type. (The last two = options instruct CLIM how to interact with the console. For instance, = how to send a break, what the boot prompt is, etc.) After creating a = console, double clicking on the resulting console icon pops up a = console window and off you go. There are actually several methods of = connecting to a console:

a)  Simple Text Connection in a window (i.e. = xterm, dtterm)
b)  GUI connection in a small graphical app = with drop-down menus for issuing common commands such as sending a = break, powering off a system, etc.

c)  Read-Only Connection in a window
d)  Command Line from a shell prompt

and, most intriguing:

e)  Gang Connect which lets you connect to = multiple consoles at once and type the same commands into all = connections. Very handy!

After running several weeks with just a handful of = non-production consoles to explore the product, I have scheduled the = production cutover for early June. At that time, I will shutdown = Conserver and add all my remaining consoles into the CLIM environment. = Before that time, I will explore the CLIM command line configuration = program (climcp) which will be necessary to quickly and accurately = batch add 150+ consoles to the CLIM configuration.

I continue to discover features and benefits of CLIM = as I use the product. For instance, the CLIM Event Management module = (EVM) includes a large set of preprogrammed console event types. For = instance there are over a hundred UNIX-specific events. Some examples = include system panic, file system full, etc. At the very least, these = preprogrammed event types provide an example of how to create custom, = application/environment specific event types.

------_=_NextPart_001_01C201B1.BE910750-- From Ernie.Oporto@viragelogic.com Wed May 22 11:27:29 2002 Received: from viragelogic.com ([209.172.126.250]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4MIRTjq021709 for ; Wed, 22 May 2002 11:27:29 -0700 (PDT) Received: by viragelogic.com; id OAA07844; Wed, 22 May 2002 14:29:57 -0400 (EDT) Received: from nodnsquery(129.200.11.40) by webshield.viragelogic.com via smap (V1.0) id xma007830; Wed, 22 May 02 14:29:14 -0400 From: "Ernie Oporto" To: Subject: RE: Ki Networks CLIM experiences Date: Wed, 22 May 2002 14:26:45 -0400 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_005F_01C2019C.B1993910" Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C2019C.B1993910 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0060_01C2019C.B1993910" ------=_NextPart_001_0060_01C2019C.B1993910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ki Networks CLIM experiencesMy main concern in a console system is being able to control my target servers in an extreme emergency where I most likely won't have access to any GUI, but only to manage a server through the rawest of interfaces: some commandline SSH backdoor? That is where clicking on icons and setting up interfaces through GUIs hits a brick wall, and conserver comes through to save the day. For the longest time, we were using an older piece of software called "console" and when I changed companies, I could not find that software anywhere until conserver popped back into the scene. Products like the digital KVM Kaveman from www.digitalv6.com that use an open protocol like VNC are where it's at because of how simple they make the product; I've found VNC works nicely through SSH pipes to control Win2k servers in an emergency, so we plan on adding that product to our network to manage our servers. Like VNC it can also be managed through a web browser. I'm not interested in proprietary interfaces like those used by Avocent, because if I am on the road and am nowhere near one of my systems, I know I can pick up any machine and have access to my network tools from almost any machine with Internet access. If only Linux PCs had some sort of way to interface a serial port like a Sun sparc system to be able to use conserver. I know they have console echoing on a serial port, but it's not the same as doing a break sequence to drop to the EEPROM. Digital KVMs come close, though. Ernie -----Original Message----- From: users-admin@conserver.com [mailto:users-admin@conserver.com]On Behalf Of Matt Cheek Sent: Wednesday, May 22, 2002 12:57 PM To: 'users@conserver.com' Subject: Ki Networks CLIM experiences All, This is simply an overview of my experiences with the CLIM console management product from Ki Networks (http://www.kinetworks.com). These are only my observations and opinions. Your mileage may vary. Matt -- Matthew Cheek | Medical Archival Systems, Inc. (a.k.a. MARS) Systems Analyst IV | 1370 Beulah Road | Pittsburgh, PA 15235-5084 cheek@mars-systems.com | v: 412-473-6565 | f: 412-473-6538 Background: I joined Medical Archival Systems, Inc. (part of University of Pittsburgh Medical Center) in early 2000. At that time, MARS had approximately 75 consoles (mostly UNIX systems and network gear such as Cisco routers and switches) with about 60 of these consoles connected to a couple of Xylogics Annex3 terminal servers. There was no console management solution in place at the time and staff would simply telnet directly to the terminal server port in order to connect to particular consoles. Obviously this was an unworkable solution and I set out to find and deploy a true console management solution. (I had used DEC's Polycenter Console Manager (PCM) at two previous employers.) At the same time, I continued to add console connections to existing and new terminal servers. Before beginning my search, I identified and ranked the desired attributes: 1) Console Management - The console manager "manages" which terminal server port is which console - no remembering which port is which 2) Console Control - Easily manage the console (e.g. review the last N lines, send a "break" character, etc.) 3) Console Logging - Useful for diagnosing system crashes or for auditing console access 4) Read-Only Console Connection - Provides the ability to watch over another user's shoulder 5) Security Mechanism - Only permit authorized users to connect to a console 6) Event Notification - Provide notification (e.g. email, pager) of specific console text My initial research focused on commercial console management solutions including CLIM (Command Line Interface Manager) from Ki Networks and ControlTower from Aurora Technologies. Unfortunately, while these commercial products provided rich and robust console management features, they were also prohibitively expensive for my environment which had grown to 178 managed consoles. In Aug 2000, I discovered Conserver via a mention on the Sun Managers mailing list. Conserver, being an open source product, certainly met my unstated requirement of low- or no-cost. In addition, Conserver appeared to meet the first five requirements (i.e. Console Management, Control, Logging plus Read-Only Connections and a rudimentary Security Mechanism). After downloading, building, and installing the product, I was pleased to discovered that Conserver did in fact meet my immediate needs. Additionally, since the Conserver product does not currently provide any sort of event notification, I deployed SWATCH (the Simple WATCHer, http://www.oit.ucsb.edu/~eta/swatch/) to address the Event Notification requirement. SWATCH is an open source utility that watches log files in real time for specific text matches and notifies you in a pre-determined manner when a match is found. I continued to use the combination of Conserver and SWATCH as my Console Management Solution until the middle of May 2002. In early May 2002, Ki Networks made an extraordinary offer to any active Conserver user. They offered a complimentary, permanent license to deploy their CLIM and NodeMonitor products in exchange for feedback on how to improve CLIM. In addition, Ki Networks agreed to provide ongoing support for these products. Since CLIM was one of the commercial products I had evaluated in 2000, I jumped at the offer and worked with Ki Networks to download and install CLIM on an evaluation basis. Since I consider Console Management a critical production facility, one of my minor concerns was understanding the terms of use of this permanent license and the support options. Happily, Ki Networks provided formal license and support documents that were quickly approved by my management. Once the red tape was worked out, I began planning the deployment of CLIM across my enterprise. CLIM Deployment: My current environment is four terminal servers with 178 managed consoles. The CLIM installation was nearly trouble free and within 15 minutes I was able to start the Ki Works GUI to start adding consoles. It quickly became apparent that CLIM is more that just a simple console manager. CLIM is a comprehensive system management product that provides log file management, event management and notification, and terminal server management. Along with this comprehensiveness comes complexity. While Conserver is driven by a fairly simple configuration file, CLIM is best configured via the Ki Works GUI. (There is a CLI configuration utility, but I've not explored its capabilities yet.) Since my primary goal is console management, I started by creating several console connections. The main interface to CLIM is a graphical application (i.e. X. I believe there is also a Windows version if that is your wont.) called "Ki Works". This is a very intuitive GUI for all aspects of configuration and console management. The first step is to define the terminal server(s). This is a simple task that is made easy by predefined configurations for most popular terminal servers (e.g. Xylogics, Cyclades, Lantronix, Cisco, etc). Once a terminal server is defined, adding a console is just as simple. Simply name the console, select the terminal server it is connected to, specify the port number on the terminal server, and select the console's hardware and operating system type. (The last two options instruct CLIM how to interact with the console. For instance, how to send a break, what the boot prompt is, etc.) After creating a console, double clicking on the resulting console icon pops up a console window and off you go. There are actually several methods of connecting to a console: a) Simple Text Connection in a window (i.e. xterm, dtterm) b) GUI connection in a small graphical app with drop-down menus for issuing common commands such as sending a break, powering off a system, etc. c) Read-Only Connection in a window d) Command Line from a shell prompt and, most intriguing: e) Gang Connect which lets you connect to multiple consoles at once and type the same commands into all connections. Very handy! After running several weeks with just a handful of non-production consoles to explore the product, I have scheduled the production cutover for early June. At that time, I will shutdown Conserver and add all my remaining consoles into the CLIM environment. Before that time, I will explore the CLIM command line configuration program (climcp) which will be necessary to quickly and accurately batch add 150+ consoles to the CLIM configuration. I continue to discover features and benefits of CLIM as I use the product. For instance, the CLIM Event Management module (EVM) includes a large set of preprogrammed console event types. For instance there are over a hundred UNIX-specific events. Some examples include system panic, file system full, etc. At the very least, these preprogrammed event types provide an example of how to create custom, application/environment specific event types. ------=_NextPart_001_0060_01C2019C.B1993910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ki Networks CLIM experiences
My=20 main concern in a console system is being able to control my target = servers=20 in an extreme emergency where I most likely won't have access to any = GUI, but=20 only to manage a server through the rawest of interfaces:  some = commandline=20 SSH backdoor?  That is where clicking on icons and setting up = interfaces=20 through GUIs hits a brick wall, and conserver comes through to save the=20 day.  For the longest time, we were using an older piece of = software called=20 "console" and when I changed companies, I could not find that software = anywhere=20 until conserver popped back into the scene.
 
Products like the digital KVM Kaveman from www.digitalv6.com that use an open = protocol=20 like VNC are where it's at because of how simple they make the product; = I've=20 found VNC works nicely through SSH pipes to control Win2k servers in an=20 emergency, so we plan on adding that product to our network to manage = our=20 servers.  Like VNC it can also be managed through a web = browser.  I'm=20 not interested in proprietary interfaces like those used by Avocent, = because if=20 I am on the road and am nowhere near one of my systems, I know I can = pick up any=20 machine and have access to my network tools from almost any machine with = Internet access.  If only Linux PCs had some sort of way to = interface a=20 serial port like a Sun sparc system to be able to use conserver.  I = know=20 they have console echoing on a serial port, but it's not the same as = doing a=20 break sequence to drop to the EEPROM.  Digital KVMs come close,=20 though.
 
Ernie
 
 
-----Original Message-----
From: = users-admin@conserver.com=20 [mailto:users-admin@conserver.com]On Behalf Of Matt=20 Cheek
Sent: Wednesday, May 22, 2002 12:57 PM
To:=20 'users@conserver.com'
Subject: Ki Networks CLIM=20 experiences


All,

This is simply an overview of my experiences with = the CLIM=20 console management product from Ki Networks (http://www.kinetworks.com).=20 These are only my observations and opinions. Your mileage may = vary.

Matt
--
Matthew = Cheek          |=20 Medical Archival Systems, Inc. (a.k.a. MARS)
Systems=20 Analyst IV     | 1370 Beulah Road | Pittsburgh, PA = 15235-5084
cheek@mars-systems.com | v:  = 412-473-6565 | f:  412-473-6538



Background:
I joined = Medical Archival=20 Systems, Inc. (part of University of Pittsburgh Medical Center) in = early 2000.=20 At that time, MARS had approximately 75 consoles (mostly UNIX systems = and=20 network gear such as Cisco routers and switches) with about 60 of = these=20 consoles connected to a couple of Xylogics Annex3 terminal servers. = There was=20 no console management solution in place at the time and staff would = simply=20 telnet directly to the terminal server port in order to connect to = particular=20 consoles. Obviously this was an unworkable solution and I set out to = find and=20 deploy a true console management solution. (I had used DEC's = Polycenter=20 Console Manager (PCM) at two previous employers.) At the same time, I=20 continued to add console connections to existing and new terminal=20 servers.

Before beginning my search, I identified and ranked = the=20 desired attributes:

1) Console Management - The console manager = "manages" which=20 terminal server port is which console - no remembering which port is=20 which

2) Console Control - Easily manage the console (e.g. = review=20 the last N lines, send a "break" character, etc.)
3)=20 Console Logging - Useful for diagnosing system crashes or for auditing = console=20 access
4) Read-Only Console Connection - = Provides the=20 ability to watch over another user's shoulder
5)=20 Security Mechanism - Only permit authorized users to connect to a=20 console
6) Event Notification - Provide = notification=20 (e.g. email, pager) of specific console text

My initial research focused on commercial console = management=20 solutions including CLIM (Command Line Interface Manager) from Ki = Networks and=20 ControlTower from Aurora Technologies. Unfortunately, while these = commercial=20 products provided rich and robust console management features, they = were also=20 prohibitively expensive for my environment which had grown to 178 = managed=20 consoles. In Aug 2000, I discovered Conserver via a mention on the Sun = Managers mailing list.

Conserver, being an open source product, certainly = met my=20 unstated requirement of low- or no-cost. In addition, Conserver = appeared to=20 meet the first five requirements (i.e. Console Management, Control, = Logging=20 plus Read-Only Connections and a rudimentary Security Mechanism). = After=20 downloading, building, and installing the product, I was pleased to = discovered=20 that Conserver did in fact meet my immediate needs.

Additionally, since the Conserver product does not = currently=20 provide any sort of event notification, I deployed SWATCH (the Simple = WATCHer,=20 http://www.oit.ucsb.edu/~eta/swatch/) to address = the Event=20 Notification requirement. SWATCH is an open source utility that = watches log=20 files in real time for specific text matches and notifies you in a=20 pre-determined manner when a match is found.

I continued to use the combination of Conserver and = SWATCH as=20 my Console Management Solution until the middle of May = 2002.

In early May 2002, Ki Networks made an extraordinary = offer to=20 any active Conserver user. They offered a complimentary, permanent = license to=20 deploy their CLIM and NodeMonitor products in exchange for feedback on = how to=20 improve CLIM. In addition, Ki Networks agreed to provide ongoing = support for=20 these products.

Since CLIM was one of the commercial products I had = evaluated=20 in 2000, I jumped at the offer and worked with Ki Networks to download = and=20 install CLIM on an evaluation basis. Since I consider Console = Management a=20 critical production facility, one of my minor concerns was = understanding the=20 terms of use of this permanent license and the support options. = Happily, Ki=20 Networks provided formal license and support documents that were = quickly=20 approved by my management. Once the red tape was worked out, I began = planning=20 the deployment of CLIM across my enterprise.

CLIM Deployment:
My = current=20 environment is four terminal servers with 178 managed consoles. =

The CLIM installation was nearly trouble free and = within 15=20 minutes I was able to start the Ki Works GUI to start adding consoles. = It=20 quickly became apparent that CLIM is more that just a simple console = manager.=20 CLIM is a comprehensive system management product that provides log = file=20 management, event management and notification, and terminal server = management.=20 Along with this comprehensiveness comes complexity. While Conserver is = driven=20 by a fairly simple configuration file, CLIM is best configured via the = Ki=20 Works GUI. (There is a CLI configuration utility, but I've not = explored its=20 capabilities yet.)

Since my primary goal is console management, I = started by=20 creating several console connections. The main interface to CLIM is a=20 graphical application (i.e. X. I believe there is also a Windows = version if=20 that is your wont.) called "Ki Works". This is a very intuitive GUI = for all=20 aspects of configuration and console management. The first step is to = define=20 the terminal server(s). This is a simple task that is made easy by = predefined=20 configurations for most popular terminal servers (e.g. Xylogics, = Cyclades,=20 Lantronix, Cisco, etc). Once a terminal server is defined, adding a = console is=20 just as simple. Simply name the console, select the terminal server it = is=20 connected to, specify the port number on the terminal server, and = select the=20 console's hardware and operating system type. (The last two options = instruct=20 CLIM how to interact with the console. For instance, how to send a = break, what=20 the boot prompt is, etc.) After creating a console, double clicking on = the=20 resulting console icon pops up a console window and off you go. There = are=20 actually several methods of connecting to a console:

a)  Simple Text Connection in a window (i.e. = xterm,=20 dtterm)
b)  GUI connection in a small = graphical=20 app with drop-down menus for issuing common commands such as sending a = break,=20 powering off a system, etc.

c)  Read-Only Connection in a window =
d)  Command Line from a shell prompt

and, most intriguing:

e)  Gang Connect which lets you connect to = multiple=20 consoles at once and type the same commands into all connections. Very = handy!

After running several weeks with just a handful of=20 non-production consoles to explore the product, I have scheduled the=20 production cutover for early June. At that time, I will shutdown = Conserver and=20 add all my remaining consoles into the CLIM environment. Before that = time, I=20 will explore the CLIM command line configuration program (climcp) = which will=20 be necessary to quickly and accurately batch add 150+ consoles to the = CLIM=20 configuration.

I continue to discover features and benefits of CLIM = as I use=20 the product. For instance, the CLIM Event Management module (EVM) = includes a=20 large set of preprogrammed console event types. For instance there are = over a=20 hundred UNIX-specific events. Some examples include system panic, file = system=20 full, etc. At the very least, these preprogrammed event types provide = an=20 example of how to create custom, application/environment specific = event=20 types.

------=_NextPart_001_0060_01C2019C.B1993910-- ------=_NextPart_000_005F_01C2019C.B1993910 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII9DCCApIw ggH7oAMCAQICAwUTKzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDYyMTEzMTUxM1oXDTAyMDYyMTEzMTUxM1owTjEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjErMCkGCSqGSIb3DQEJARYcZXJuaWUub3BvcnRvQHZpcmFnZWxvZ2lj LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA8wJMTF41OXQe5rxW6BROWjGrj9iGlCMn lZvumu950DX7TI8nJOUB3ZeMs01WNkKeuxK7nE3RGwGt2NjeDrYDqBqG1ScNkMpkxuZLhq2IhxUo rjfjmzgE1ln7MD+NvejFENaI4PA5n5x/zJLmZyCqs9oBLjeqtkmhlmX4n5srFP8CAwEAAaM5MDcw JwYDVR0RBCAwHoEcZXJuaWUub3BvcnRvQHZpcmFnZWxvZ2ljLmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBAgUAA4GBAB+KS7IJsyS0Wn61PPM8G9Ke9VA5dwyu3c0si+RnCKNDjvtKuO/8aD8b 8Q18MBU9SrbjJzq0B6yBBSjwj665rE7jCCUR8pMM9uJwQSxUiQfQWWmuV7qr1wknfGcCzXcz3GeG TfygeRqhh7WonJ+H9hUog4f5mvU2RsKVCsK5GkQrMIIDKTCCApKgAwIBAgIBDDANBgkqhkiG9w0B AQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAw MDAwMFoXDTAyMDgyOTIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tew kd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0R BCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5Jx+gNu4+5DWom KmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0GZ/VQby5YuLYLwVBX tewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3pYgNIMIIDLTCCApagAwIB AgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUu Y29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYD VQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwt ZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx 6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hN D3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb 5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1 lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzc eePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr 5PjRzneigTGCAqowggKmAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlm aWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAC AwUTKzAJBgUrDgMCGgUAoIIBZTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wMjA1MjIxODI2NDJaMCMGCSqGSIb3DQEJBDEWBBRb0InR/xFi5G0izYQ03tuSlIggBjBY BgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGSMQsw CQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzAN BgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1Bl cnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwUTKzANBgkqhkiG9w0BAQEFAASBgKu0wV+m l7+XAYHsTOW9+jjs2++Bu6ssQeQGx06Ak8UD765Ny7ue8KWi6O9WClL8NTe8chYMygj/KXA0bkqQ S5l1nmw1NA/JlMFBvrrcpFGknCsGLHGdEq2ByFLUVk7+ipWE8kG2WsRJiH63Sgc89056dV0L5AhW /SpGBsEg3JrzAAAAAAAA ------=_NextPart_000_005F_01C2019C.B1993910-- From cheek@mars-systems.com Wed May 22 12:03:10 2002 Received: from nova01.mars-systems.com (nova01-e.mars-systems.com [150.212.252.5]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4MJ39jq022098 for ; Wed, 22 May 2002 12:03:09 -0700 (PDT) Received: from exchange-02.mars-systems.com (exchange-02.mars-systems.com [150.212.17.103]) by nova01.mars-systems.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MJ34K01459 for ; Wed, 22 May 2002 15:03:04 -0400 (EDT) Received: by exchange-02.mars-systems.com with Internet Mail Service (5.5.2653.19) id <29TCADP2>; Wed, 22 May 2002 14:54:09 -0400 Message-ID: From: Matt Cheek To: "'users@conserver.com '" Subject: RE: Ki Networks CLIM experiences Date: Wed, 22 May 2002 14:53:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201C2.07B99040" Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C201C2.07B99040 Content-Type: text/plain; charset="iso-8859-1" I could not agree with you more, Ernie. I am a CLI guy through and through. CLIM provides both CLI console access -and- CLI configuration utilities in addition to the pretty GUIs. In fact, I use the CLIM CLI tool (clif) 95% of the time. (clif(1) is equivalent to Conserver's console(1) command.) CLIM provides both GUI and CLI access. The GUI is pretty much icing on the cake for me. Also, while I don't use it, CLIM comes with (and installs) TightVNC. I imagine this is a very useful feature to those who like VNC. And, just as an aside, there IS a product that will provide a serial console for Intel systems. It is the PC Weasel (http://www.realweasel.com/). Take a look. Matt -----Original Message----- From: Ernie Oporto To: users@conserver.com Sent: 5/22/2002 2:26 PM Subject: RE: Ki Networks CLIM experiences My main concern in a console system is being able to control my target servers in an extreme emergency where I most likely won't have access to any GUI, but only to manage a server through the rawest of interfaces: some commandline SSH backdoor? That is where clicking on icons and setting up interfaces through GUIs hits a brick wall, and conserver comes through to save the day. For the longest time, we were using an older piece of software called "console" and when I changed companies, I could not find that software anywhere until conserver popped back into the scene. Products like the digital KVM Kaveman from www.digitalv6.com that use an open protocol like VNC are where it's at because of how simple they make the product; I've found VNC works nicely through SSH pipes to control Win2k servers in an emergency, so we plan on adding that product to our network to manage our servers. Like VNC it can also be managed through a web browser. I'm not interested in proprietary interfaces like those used by Avocent, because if I am on the road and am nowhere near one of my systems, I know I can pick up any machine and have access to my network tools from almost any machine with Internet access. If only Linux PCs had some sort of way to interface a serial port like a Sun sparc system to be able to use conserver. I know they have console echoing on a serial port, but it's not the same as doing a break sequence to drop to the EEPROM. Digital KVMs come close, though. Ernie -----Original Message----- From: users-admin@conserver.com [mailto:users-admin@conserver.com]On Behalf Of Matt Cheek Sent: Wednesday, May 22, 2002 12:57 PM To: 'users@conserver.com' Subject: Ki Networks CLIM experiences All, This is simply an overview of my experiences with the CLIM console management product from Ki Networks ( http://www.kinetworks.com ). These are only my observations and opinions. Your mileage may vary. Matt -- Matthew Cheek | Medical Archival Systems, Inc. (a.k.a. MARS) Systems Analyst IV | 1370 Beulah Road | Pittsburgh, PA 15235-5084 cheek@mars-systems.com | v: 412-473-6565 | f: 412-473-6538 Background: I joined Medical Archival Systems, Inc. (part of University of Pittsburgh Medical Center) in early 2000. At that time, MARS had approximately 75 consoles (mostly UNIX systems and network gear such as Cisco routers and switches) with about 60 of these consoles connected to a couple of Xylogics Annex3 terminal servers. There was no console management solution in place at the time and staff would simply telnet directly to the terminal server port in order to connect to particular consoles. Obviously this was an unworkable solution and I set out to find and deploy a true console management solution. (I had used DEC's Polycenter Console Manager (PCM) at two previous employers.) At the same time, I continued to add console connections to existing and new terminal servers. Before beginning my search, I identified and ranked the desired attributes: 1) Console Management - The console manager "manages" which terminal server port is which console - no remembering which port is which 2) Console Control - Easily manage the console (e.g. review the last N lines, send a "break" character, etc.) 3) Console Logging - Useful for diagnosing system crashes or for auditing console access 4) Read-Only Console Connection - Provides the ability to watch over another user's shoulder 5) Security Mechanism - Only permit authorized users to connect to a console 6) Event Notification - Provide notification (e.g. email, pager) of specific console text My initial research focused on commercial console management solutions including CLIM (Command Line Interface Manager) from Ki Networks and ControlTower from Aurora Technologies. Unfortunately, while these commercial products provided rich and robust console management features, they were also prohibitively expensive for my environment which had grown to 178 managed consoles. In Aug 2000, I discovered Conserver via a mention on the Sun Managers mailing list. Conserver, being an open source product, certainly met my unstated requirement of low- or no-cost. In addition, Conserver appeared to meet the first five requirements (i.e. Console Management, Control, Logging plus Read-Only Connections and a rudimentary Security Mechanism). After downloading, building, and installing the product, I was pleased to discovered that Conserver did in fact meet my immediate needs. Additionally, since the Conserver product does not currently provide any sort of event notification, I deployed SWATCH (the Simple WATCHer, http://www.oit.ucsb.edu/~eta/swatch/ ) to address the Event Notification requirement. SWATCH is an open source utility that watches log files in real time for specific text matches and notifies you in a pre-determined manner when a match is found. I continued to use the combination of Conserver and SWATCH as my Console Management Solution until the middle of May 2002. In early May 2002, Ki Networks made an extraordinary offer to any active Conserver user. They offered a complimentary, permanent license to deploy their CLIM and NodeMonitor products in exchange for feedback on how to improve CLIM. In addition, Ki Networks agreed to provide ongoing support for these products. Since CLIM was one of the commercial products I had evaluated in 2000, I jumped at the offer and worked with Ki Networks to download and install CLIM on an evaluation basis. Since I consider Console Management a critical production facility, one of my minor concerns was understanding the terms of use of this permanent license and the support options. Happily, Ki Networks provided formal license and support documents that were quickly approved by my management. Once the red tape was worked out, I began planning the deployment of CLIM across my enterprise. CLIM Deployment: My current environment is four terminal servers with 178 managed consoles. The CLIM installation was nearly trouble free and within 15 minutes I was able to start the Ki Works GUI to start adding consoles. It quickly became apparent that CLIM is more that just a simple console manager. CLIM is a comprehensive system management product that provides log file management, event management and notification, and terminal server management. Along with this comprehensiveness comes complexity. While Conserver is driven by a fairly simple configuration file, CLIM is best configured via the Ki Works GUI. (There is a CLI configuration utility, but I've not explored its capabilities yet.) Since my primary goal is console management, I started by creating several console connections. The main interface to CLIM is a graphical application (i.e. X. I believe there is also a Windows version if that is your wont.) called "Ki Works". This is a very intuitive GUI for all aspects of configuration and console management. The first step is to define the terminal server(s). This is a simple task that is made easy by predefined configurations for most popular terminal servers (e.g. Xylogics, Cyclades, Lantronix, Cisco, etc). Once a terminal server is defined, adding a console is just as simple. Simply name the console, select the terminal server it is connected to, specify the port number on the terminal server, and select the console's hardware and operating system type. (The last two options instruct CLIM how to interact with the console. For instance, how to send a break, what the boot prompt is, etc.) After creating a console, double clicking on the resulting console icon pops up a console window and off you go. There are actually several methods of connecting to a console: a) Simple Text Connection in a window (i.e. xterm, dtterm) b) GUI connection in a small graphical app with drop-down menus for issuing common commands such as sending a break, powering off a system, etc. c) Read-Only Connection in a window d) Command Line from a shell prompt and, most intriguing: e) Gang Connect which lets you connect to multiple consoles at once and type the same commands into all connections. Very handy! After running several weeks with just a handful of non-production consoles to explore the product, I have scheduled the production cutover for early June. At that time, I will shutdown Conserver and add all my remaining consoles into the CLIM environment. Before that time, I will explore the CLIM command line configuration program (climcp) which will be necessary to quickly and accurately batch add 150+ consoles to the CLIM configuration. I continue to discover features and benefits of CLIM as I use the product. For instance, the CLIM Event Management module (EVM) includes a large set of preprogrammed console event types. For instance there are over a hundred UNIX-specific events. Some examples include system panic, file system full, etc. At the very least, these preprogrammed event types provide an example of how to create custom, application/environment specific event types. ------_=_NextPart_001_01C201C2.07B99040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Ki Networks CLIM experiences

I could not agree with you more, Ernie. I am a CLI = guy through and through. CLIM provides both CLI console access -and- = CLI configuration utilities in addition to the pretty GUIs. In fact, I = use the CLIM CLI tool (clif) 95% of the time. (clif(1) is equivalent to = Conserver's console(1) command.) CLIM provides both GUI and CLI access. = The GUI is pretty much icing on the cake for me.

Also, while I don't use it, CLIM comes with (and = installs) TightVNC. I imagine this is a very useful feature to those = who like VNC.

And, just as an aside, there IS a product that will = provide a serial console for Intel systems. It is the PC Weasel (http://www.realweasel.com/). Take a = look.

Matt

-----Original Message-----
From: Ernie Oporto
To: users@conserver.com
Sent: 5/22/2002 2:26 PM
Subject: RE: Ki Networks CLIM experiences

My main concern in a console system is being able to = control my target
servers in an extreme emergency where I most likely = won't have access to
any GUI, but only to manage a server through the = rawest of interfaces:
some commandline SSH backdoor?  That is where = clicking on icons and
setting up interfaces through GUIs hits a brick = wall, and conserver
comes through to save the day.  For the longest = time, we were using an
older piece of software called "console" = and when I changed companies, I
could not find that software anywhere until = conserver popped back into
the scene.
 
Products like the digital KVM Kaveman from = www.digitalv6.com
<http://www.digitalv6.com>  that use an = open protocol like VNC are where
it's at because of how simple they make the product; = I've found VNC
works nicely through SSH pipes to control Win2k = servers in an emergency,
so we plan on adding that product to our network to = manage our servers.
Like VNC it can also be managed through a web = browser.  I'm not
interested in proprietary interfaces like those used = by Avocent, because
if I am on the road and am nowhere near one of my = systems, I know I can
pick up any machine and have access to my network = tools from almost any
machine with Internet access.  If only Linux = PCs had some sort of way to
interface a serial port like a Sun sparc system to = be able to use
conserver.  I know they have console echoing on = a serial port, but it's
not the same as doing a break sequence to drop to = the EEPROM.  Digital
KVMs come close, though.
 
Ernie
 
 

-----Original Message-----
From: users-admin@conserver.com [mailto:users-admin@conserver.c= om]On
Behalf Of Matt Cheek
Sent: Wednesday, May 22, 2002 12:57 PM
To: 'users@conserver.com'
Subject: Ki Networks CLIM experiences




All,

This is simply an overview of my experiences with the = CLIM console
management product from Ki Networks ( http://www.kinetworks.com
<http://www.kinetworks.com> ). These are only = my observations and
opinions. Your mileage may vary.

Matt
--
Matthew = Cheek          | Medical = Archival Systems, Inc. (a.k.a. MARS)
Systems Analyst IV     | 1370 = Beulah Road | Pittsburgh, PA 15235-5084
cheek@mars-systems.com | v:  412-473-6565 | = f:  412-473-6538



Background:
I joined Medical Archival Systems, Inc. (part of = University of
Pittsburgh Medical Center) in early 2000. At that = time, MARS had
approximately 75 consoles (mostly UNIX systems and = network gear such as
Cisco routers and switches) with about 60 of these = consoles connected to
a couple of Xylogics Annex3 terminal servers. There = was no console
management solution in place at the time and staff = would simply telnet
directly to the terminal server port in order to = connect to particular
consoles. Obviously this was an unworkable solution = and I set out to
find and deploy a true console management solution. = (I had used DEC's
Polycenter Console Manager (PCM) at two previous = employers.) At the same
time, I continued to add console connections to = existing and new
terminal servers.

Before beginning my search, I identified and ranked = the desired
attributes:

1) Console Management - The console manager = "manages" which terminal
server port is which console - no remembering which = port is which

2) Console Control - Easily manage the console (e.g. = review the last N
lines, send a "break" character, etc.) =
3) Console Logging - Useful for diagnosing system = crashes or for
auditing console access
4) Read-Only Console Connection - Provides the = ability to watch over
another user's shoulder
5) Security Mechanism - Only permit authorized users = to connect to a
console
6) Event Notification - Provide notification (e.g. = email, pager) of
specific console text

My initial research focused on commercial console = management solutions
including CLIM (Command Line Interface Manager) from = Ki Networks and
ControlTower from Aurora Technologies. = Unfortunately, while these
commercial products provided rich and robust console = management
features, they were also prohibitively expensive for = my environment
which had grown to 178 managed consoles. In Aug = 2000, I discovered
Conserver via a mention on the Sun Managers mailing = list.

Conserver, being an open source product, certainly = met my unstated
requirement of low- or no-cost. In addition, = Conserver appeared to meet
the first five requirements (i.e. Console = Management, Control, Logging
plus Read-Only Connections and a rudimentary = Security Mechanism). After
downloading, building, and installing the product, I = was pleased to
discovered that Conserver did in fact meet my = immediate needs.

Additionally, since the Conserver product does not = currently provide any
sort of event notification, I deployed SWATCH (the = Simple WATCHer,
http://www.oit.ucsb.edu/~eta/swatch/
<http://www.oit.ucsb.edu/~eta/swatch/> ) to = address the Event
Notification requirement. SWATCH is an open source = utility that watches
log files in real time for specific text matches and = notifies you in a
pre-determined manner when a match is found.

I continued to use the combination of Conserver and = SWATCH as my Console
Management Solution until the middle of May = 2002.

In early May 2002, Ki Networks made an extraordinary = offer to any active
Conserver user. They offered a complimentary, = permanent license to
deploy their CLIM and NodeMonitor products in = exchange for feedback on
how to improve CLIM. In addition, Ki Networks agreed = to provide ongoing
support for these products.

Since CLIM was one of the commercial products I had = evaluated in 2000, I
jumped at the offer and worked with Ki Networks to = download and install
CLIM on an evaluation basis. Since I consider = Console Management a
critical production facility, one of my minor = concerns was understanding
the terms of use of this permanent license and the = support options.
Happily, Ki Networks provided formal license and = support documents that
were quickly approved by my management. Once the red = tape was worked
out, I began planning the deployment of CLIM across = my enterprise.

CLIM Deployment:
My current environment is four terminal servers with = 178 managed
consoles.

The CLIM installation was nearly trouble free and = within 15 minutes I
was able to start the Ki Works GUI to start adding = consoles. It quickly
became apparent that CLIM is more that just a simple = console manager.
CLIM is a comprehensive system management product = that provides log file
management, event management and notification, and = terminal server
management. Along with this comprehensiveness comes = complexity. While
Conserver is driven by a fairly simple configuration = file, CLIM is best
configured via the Ki Works GUI. (There is a CLI = configuration utility,
but I've not explored its capabilities yet.)

Since my primary goal is console management, I = started by creating
several console connections. The main interface to = CLIM is a graphical
application (i.e. X. I believe there is also a = Windows version if that
is your wont.) called "Ki Works". This is = a very intuitive GUI for all
aspects of configuration and console management. The = first step is to
define the terminal server(s). This is a simple task = that is made easy
by predefined configurations for most popular = terminal servers (e.g.
Xylogics, Cyclades, Lantronix, Cisco, etc). Once a = terminal server is
defined, adding a console is just as simple. Simply = name the console,
select the terminal server it is connected to, = specify the port number
on the terminal server, and select the console's = hardware and operating
system type. (The last two options instruct CLIM how = to interact with
the console. For instance, how to send a break, what = the boot prompt is,
etc.) After creating a console, double clicking on = the resulting console
icon pops up a console window and off you go. There = are actually several
methods of connecting to a console:

a)  Simple Text Connection in a window (i.e. = xterm, dtterm)
b)  GUI connection in a small graphical app = with drop-down menus for
issuing common commands such as sending a break, = powering off a system,
etc.

c)  Read-Only Connection in a window
d)  Command Line from a shell prompt

and, most intriguing:

e)  Gang Connect which lets you connect to = multiple consoles at once and
type the same commands into all connections. Very = handy!

After running several weeks with just a handful of = non-production
consoles to explore the product, I have scheduled = the production cutover
for early June. At that time, I will shutdown = Conserver and add all my
remaining consoles into the CLIM environment. Before = that time, I will
explore the CLIM command line configuration program = (climcp) which will
be necessary to quickly and accurately batch add = 150+ consoles to the
CLIM configuration.

I continue to discover features and benefits of CLIM = as I use the
product. For instance, the CLIM Event Management = module (EVM) includes a
large set of preprogrammed console event types. For = instance there are
over a hundred UNIX-specific events. Some examples = include system panic,
file system full, etc. At the very least, these = preprogrammed event
types provide an example of how to create = custom,
application/environment specific event types.

------_=_NextPart_001_01C201C2.07B99040-- From zonker@certaintysolutions.com Wed May 22 12:03:22 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 g4MJ3Mjq022102 for ; Wed, 22 May 2002 12:03:22 -0700 (PDT) Received: by yosemite.rwc.gnac.net; id MAA20593; Wed, 22 May 2002 12:03:34 -0700 (PDT) Received: from unknown(192.168.1.21) by yosemite.rwc.gnac.net via smap (V5.0) id xma020575; Wed, 22 May 02 12:03:08 -0700 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 g4MJ1mT26364; Wed, 22 May 2002 12:01:48 -0700 (PDT) Received: (from zonker@localhost) by tweety.main.gnac.com (8.9.3/8.7.3/GNAC-COM-1.1) id MAA09677; Wed, 22 May 2002 12:02:52 -0700 (PDT) Date: Wed, 22 May 2002 12:02:52 -0700 From: David Harris To: Ernie Oporto , users@conserver.com Subject: Consoles on PCs... Message-ID: <20020522120252.F11989@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 Ernie.Oporto@viragelogic.com on Wed, May 22, 2002 at 02:26:45PM -0400 Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: On Wed, May 22, 2002 at 02:26:45PM -0400, Ernie Oporto wrote: > . . . . If only Linux PCs had > some sort of way to interface a serial port like a Sun sparc system to be > able to use conserver. I know they have console echoing on a serial port, > but it's not the same as doing a break sequence to drop to the EEPROM. Some of you probably already know about the PC Weasel products, but I'm betting it's still one of Canada's best kept secrets. ;-) http://www.realweasel.com/ The idea is an add-in card, which appears to the system as a simple video card, but the output is really to a DB-9 serial port. As the system boots, and sends data to the (vidoe) 'console', the text is captured, and redirected to the serial port on the Weasel card. Once the OS starts up, if it wants to take over a serial port as a serial console, the Weasel card binds the port on the card to that interface...so, one serial port on the PC (on the Weasel card) provides both P.O.S.T. data, as well as providing a serial console to the O.S. But wait, there's more! (Now how much would you pay? ;-) You also have an ability to send a control sequence to the Weasel card, and control things like momentarily triggering the reset line on the CPU, and even controlling the 'soft-power' control lines to 'bounce' (off-and-on) the power suppply, or to simply shut it down. AND, you have an option to connect a short cable from the Weasel card to the keyboard jack on the CPU, so you can access the ROMs at start-up, respond to key-presses during start-up, or perform other interactions (recovering from a HALT, etc.) I like these things a lot! The PCI version has been available for about a year. If you have PC servers that don't have console redirection (or they have limited redirection), try a Weasel card, and see what you think. If you have 'smart' NICs and Drive controllers (which write directly to the video screen, versus reporting to the BIOS for redirection), the Weasel card is a win! -Z- http://www.conserver.com/consoles/ From ernie.oporto@viragelogic.com Wed May 22 13:17:13 2002 Received: from mail.viragelogic.com ([209.172.126.250]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4MKHDjq022740 for ; Wed, 22 May 2002 13:17:13 -0700 (PDT) Received: from viragelogic.com ([127.0.0.1]) by mail.viragelogic.com (Netscape Messaging Server 4.15) with ESMTP id GWJ4BZ00.85T; Wed, 22 May 2002 13:16:47 -0700 From: "Ernie Oporto" To: David Harris Cc: Ernie Oporto , users@conserver.com Message-ID: <9a0ef0b6.f0b69a0e@viragelogic.com> Date: Wed, 22 May 2002 16:16:47 -0400 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: Consoles on PCs... X-Accept-Language: en Content-Type: multipart/mixed; boundary="--316b6d924d063c9c" Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ----316b6d924d063c9c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Wooo! Looks like a great product! The only question I have about it is whether or not you can continue to use a regular video card in the machine and just add this. Their answer in the FAQ was kind of vague with "possibly" as the answer. I've got an order in mind for a few of the PCI versions if it's easily possible. -- Ernest A. Oporto, Systems Administrator Virage Logic Corporation http://www.viragelogic.com Perryville Corporate Park, Bldg 3, Clinton, NJ 08809 Phone:(908)735-1932 Fax:(908)735-1999 mailto:Ernie.Oporto@viragelogic.com ----- Original Message ----- From: David Harris Date: Wednesday, May 22, 2002 3:02 pm Subject: Consoles on PCs... > On Wed, May 22, 2002 at 02:26:45PM -0400, Ernie Oporto wrote: > > . . . . If only Linux PCs had > > some sort of way to interface a serial port like a Sun sparc > system to be > > able to use conserver. I know they have console echoing on a > serial port, > > but it's not the same as doing a break sequence to drop to the > EEPROM. > Some of you probably already know about the PC Weasel products, > but I'm betting it's still one of Canada's best kept secrets. ;-) > > http://www.realweasel.com/ > > The idea is an add-in card, which appears to the system as a simple > video card, but the output is really to a DB-9 serial port. As the > system boots, and sends data to the (vidoe) 'console', the text is > captured, and redirected to the serial port on the Weasel card. > Once the OS starts up, if it wants to take over a serial port as > a serial console, the Weasel card binds the port on the card to > that interface...so, one serial port on the PC (on the Weasel > card) provides both P.O.S.T. data, as well as providing a serial > console to the O.S. > > But wait, there's more! (Now how much would you pay? ;-) > > You also have an ability to send a control sequence to the > Weasel card, and control things like momentarily triggering the > reset line on the CPU, and even controlling the 'soft-power' > control lines to 'bounce' (off-and-on) the power suppply, or > to simply shut it down. > > AND, you have an option to connect a short cable from the > Weasel card to the keyboard jack on the CPU, so you can access > the ROMs at start-up, respond to key-presses during start-up, > or perform other interactions (recovering from a HALT, etc.) > > I like these things a lot! The PCI version has been available > for about a year. If you have PC servers that don't have console > redirection (or they have limited redirection), try a Weasel > card, and see what you think. If you have 'smart' NICs and Drive > controllers (which write directly to the video screen, versus > reporting to the BIOS for redirection), the Weasel card is a win! > > -Z- http://www.conserver.com/consoles/ > > > ----316b6d924d063c9c Content-Type: text/x-vcard; name="eoporto.vcf"; charset="iso-8859-1" Content-Disposition: attachment; filename="eoporto.vcf" Content-Description: Card for Ernie Oporto Content-Transfer-Encoding: quoted-printable begin=3Avcard n=3AOporto=3BErnie fn=3AErnie Oporto org=3AVirage Logic Corporation=3B=3BPerryville Corporate Park=2C Bldg 3=3B= Clinton=3BNJ=3B08809=3BUSA adr=3A=3B=3BPerryville Corporate Park=2C Bldg 3=3BClinton=3BNJ=3B08809=3B= USA version=3A2=2E1 email=3Binternet=3Aernie=2Eoporto=40viragelogic=2Ecom title=3ASystems Administrator end=3Avcard ----316b6d924d063c9c-- From woods@proven.weird.com Thu May 23 13:45:51 2002 Received: from most.weird.com (IDENT:LpUFrlVbMGdfs+7ZtE0p/rleptZkc9PElY/GrRFpYIbRZkKZQ3x2S4lsfGeM7bh+XNlmvkqUah4@mail.weird.com [204.92.254.2]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4NKjojq007219 for ; Thu, 23 May 2002 13:45:51 -0700 (PDT) Received: from proven.weird.com([204.92.254.15]) (8331 bytes) by most.weird.com via smail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident <[oseZa8ST8rDuGOL5M1wkFfMbqX7kwIQkArdX5ArR7PDJBtlQb/0Ha1ISPF1Q2f4viLSk2skl+hS34ezY6ry2rQ==]> using rfc1413) id for ; Thu, 23 May 2002 16:45:48 -0400 (EDT) (Smail-3.2.0.115-Pre 2001-Aug-6 #8 built 2002-May-21) Received: by proven.weird.com (Postfix, from userid 1000) id 34C49AC; Thu, 23 May 2002 16:45:42 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: ;j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz;@-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= Date: Thu, 23 May 2002 16:45:42 -0400 (EDT) Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: conserver eventually seems to go catatonic after SIGPIPE (on NetBSD) I think this is the same problem as what I reported some time ago with a somewhat older release, but now with 7.2.1 it's just far less common. (note the code I'm running includes the patches I sent to the list, though I don't see how any of those changes could affect any signal processing....) I suspect the SIGPIPE is triggered by an attempt to write to a socket that's been closed (TCP RST) by the client. The server should just close the socket and do any per-client cleanup necessary, but I don't see a signal handler for SIGPIPE anywhere.... Eventually I notice this when any long-running 'console' client dies, or when I start getting warning e-mails from Cricket about some delay in processing one of its collectors, which in this case usually turns out to be the little script I use to ask each UPS what it's status is.... No new 'console' connections work right either, which is why the Cricket collector "fails". Somtimes if I leave "console -u" or "console -x" running long enough when it's in this state then I get a response, but it takes many minutes.... I don't think I've ever managed to get a successful connection to an actual console, though I may not have waited long enough. I can kill one of the 'conserver' processes with SIGTERM (I'm currently assuming this is the parent, though I've not been careful enough to look yet), and the other needs SIGQUIT or similar (something it's not caught that will force it to exit). Twice now I've forced it to dump core, but unfortunately I've not been smart enough yet to realize that the binaries I've been building and using were not compiled with '-g'. I'm recompiling now..... Hmm.... seems it was waiting for a PID that didn't exist: $ gdb ./conserver conserver-forced-2.sparc.core GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (sparc-netbsd), Copyright 1996 Free Software Foundation, Inc... warning: exec file is newer than core file. Core was generated by `conserver'. Program terminated with signal 6, Abort trap. Reading symbols from /usr/libexec/ld.so...done. Reading symbols from /usr/lib/libcrypt.so.0.0...done. Reading symbols from /usr/lib/libwrap.so.0.0...done. Reading symbols from /usr/lib/libc.so.12.20...done. #0 0x100b7e5c in wait4 () (gdb) where #0 0x100b7e5c in wait4 () #1 0x100b4e88 in waitpid () #2 0xa6cc in ConsChat (pCE=0x15400) at group.c:3016 #3 0x7a9c in Kiddie (pGE=0x47180, sfd=0x6c010) at group.c:1458 #4 0xa20c in Spawn (pGE=0x47180) at group.c:2907 #5 0xcad0 in FixKids () at master.c:143 #6 0xd2f4 in Master () at master.c:313 #7 0xc874 in main (argc=269482840, argv=0x14400) at main.c:724 (gdb) up #1 0x100b4e88 in waitpid () (gdb) up #2 0xa6cc in ConsChat (pCE=0x15400) at group.c:3016 3016 while (waitpid(pid, &cstatus, 0) < 0) { (gdb) print pid $1 = 21006 (gdb) I'm fairly certain there was no PID 21006 at the time I killed it... This has happened at least twice and I have two forced core dumps of the stuck process. The conserver log file contains entries that suggest it might be one of my Cricket collector scripts causing the SIGPIPE as the failure occurs in the middle of one of the runs (which happen every minute, with a login and logout for each of my three UPS units). From there on things go really wonky until I stop it. PID 14846 is the one that stopped on its own with SIGTERM, and PID 15629 is the one that produced the above core dump. There is no record of PID 21006 in any of the log files produced by this instantiation of conserver, and given the PIDs around the time I killed it that must have been a very recently started process (the new daemon after restarting was 21022). conserver (14847): best-1.4: login cricket@becoming.weird.com [Thu May 23 06:21:20 2002] conserver (14847): best-1.4: logout cricket@becoming.weird.com [Thu May 23 06:21:22 2002] conserver (14847): best-3.1-0: login cricket@becoming.weird.com [Thu May 23 06:21:22 2002] conserver (14847): best-3.1-0: logout cricket@becoming.weird.com [Thu May 23 06:21:24 2002] conserver (14847): best-3.1-1: login cricket@becoming.weird.com [Thu May 23 06:21:24 2002] conserver (14847): best-3.1-1: logout cricket@becoming.weird.com [Thu May 23 06:21:26 2002] conserver (14847): best-1.4: login cricket@becoming.weird.com [Thu May 23 06:22:17 2002] conserver (14847): best-1.4: logout cricket@becoming.weird.com [Thu May 23 06:22:19 2002] conserver (14847): best-3.1-0: login cricket@becoming.weird.com [Thu May 23 06:22:20 2002] conserver (14846): conserver(14847): signal(13), restarted [Thu May 23 06:22:22 2002] Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed warning: read() on stdin returned 0 Failed conserver (15629): lost carrier on once (tserv/2012)! [Thu May 23 06:37:33 2002] conserver (15629): once: automatic reinitialization [Thu May 23 06:37:33 2002] Failed Failed Failed conserver (15629): lost carrier on proven (tserv/2006)! [Thu May 23 06:42:05 2002] conserver (15629): proven: automatic reinitialization [Thu May 23 06:42:05 2002] Failed conserver (15629): lost carrier on raid-00 (tserv/2004)! [Thu May 23 06:43:37 2002] conserver (15629): raid-00: automatic reinitialization [Thu May 23 06:43:37 2002] Failed conserver (15629): lost carrier on hubly (constantly/2001)! [Thu May 23 06:45:08 2002] conserver (15629): hubly: automatic reinitialization [Thu May 23 06:45:08 2002] Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed conserver (15629): lost carrier on hubly (constantly/2001)! [Thu May 23 07:00:15 2002] conserver (15629): hubly: automatic reinitialization [Thu May 23 07:00:15 2002] Failed Failed Failed Failed Failed conserver (15629): best-1.4: login cricket@becoming.weird.com [Thu May 23 07:07:48 2002] Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed Failed conserver (15629): lost carrier on hubly (constantly/2001)! [Thu May 23 07:22:52 2002] conserver (15629): hubly: automatic reinitialization [Thu May 23 07:22:52 2002] conserver (15629): best-1.4: logout cricket@becoming.weird.com [Thu May 23 07:22:53 2002] Failed Failed Failed Failed Failed Failed Failed warning: read() on stdin returned 0 Failed Failed Failed Failed Failed Failed Failed conserver (15629): lost carrier on hubly (constantly/2001)! [Thu May 23 07:42:28 2002] conserver (15629): hubly: automatic reinitialization [Thu May 23 07:42:28 2002] Failed Failed Failed Failed Failed Failed warning: read() on stdin returned 0 Failed conserver (15629): best-3.1-0: login cricket@becoming.weird.com [Thu May 23 07:51:32 2002] Failed Failed Failed Failed [[ .... blah, blah, blah .... ]] conserver (14846): Stopped at Thu May 23 10:25:27 2002 -- Greg A. Woods +1 416 218-0098; ; ; Planix, Inc. ; VE3TCP; Secrets of the Weird From bryan@stansell.org Sun May 26 00:10:07 2002 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4Q7A6jq015445 for ; Sun, 26 May 2002 00:10:06 -0700 (PDT) Received: (from bryan@localhost) by underdog.stansell.org (8.12.2/8.12.2/Submit) id g4Q7A67q015444 for users@conserver.com; Sun, 26 May 2002 00:10:06 -0700 (PDT) Date: Sun, 26 May 2002 00:10:06 -0700 From: Bryan Stansell To: users@conserver.com Subject: Re: conserver eventually goes catatonic after SIGPIPE (on NetBSD) Message-ID: <20020526001006.A10610@underdog.stansell.org> References: <20020523204542.34C49AC@proven.weird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020523204542.34C49AC@proven.weird.com>; from woods@weird.com on Thu, May 23, 2002 at 04:45:42PM -0400 Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: On Thu, May 23, 2002 at 04:45:42PM -0400, Greg A. Woods wrote: > conserver eventually seems to go catatonic after SIGPIPE (on NetBSD) > > I think this is the same problem as what I reported some time ago with > a somewhat older release, but now with 7.2.1 it's just far less common. > (note the code I'm running includes the patches I sent to the list, > though I don't see how any of those changes could affect any signal > processing....) ugh...well, i'll address this at the stack trace... > I suspect the SIGPIPE is triggered by an attempt to write to a socket > that's been closed (TCP RST) by the client. The server should just > close the socket and do any per-client cleanup necessary, but I don't > see a signal handler for SIGPIPE anywhere.... right...no SIGPIPE handler. but, there is a SIGCHLD handler, which gets called when forked processes die. i don't think this is a problem (yet, at least). > I'm recompiling now..... Hmm.... seems it was waiting for a PID that > didn't exist: > [chopped gdb header] > (gdb) where > #0 0x100b7e5c in wait4 () > #1 0x100b4e88 in waitpid () > #2 0xa6cc in ConsChat (pCE=0x15400) at group.c:3016 > #3 0x7a9c in Kiddie (pGE=0x47180, sfd=0x6c010) at group.c:1458 > #4 0xa20c in Spawn (pGE=0x47180) at group.c:2907 > #5 0xcad0 in FixKids () at master.c:143 > #6 0xd2f4 in Master () at master.c:313 > #7 0xc874 in main (argc=269482840, argv=0x14400) at main.c:724 > (gdb) up > #1 0x100b4e88 in waitpid () > (gdb) up > #2 0xa6cc in ConsChat (pCE=0x15400) at group.c:3016 > 3016 while (waitpid(pid, &cstatus, 0) < 0) { > (gdb) print pid > $1 = 21006 > (gdb) looking at #2, you see it's calling waitpid() from ConsChat(). ConsChat() is part of your patch. the problem, i'm guessing, is that the waitpid() inside the while loop has a little bad logic. specifically, what happens when the waitpid() returns an error that isn't EINTR? it'll come around for another waitpid() and, i suppose, lock up like this. at least, that's my guess - i haven't done any real testing - just scanned the code quickly. so, unfortunately, it looks like the patch you've put together might need a little work. i don't think folks using the base 7.2.1 will see this type of problem. i'd love to get the whole chat-based thing integrated in...hopefully this stuff can be worked out. anyway, there's my two cents. Bryan From Malcolm.Gibbs005@msd.govt.nz Mon May 27 17:20:10 2002 Received: from cfwcs010.dsw.govt.nz (inetgate.dsw.govt.nz [202.27.54.3]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4S0K9jq007750 for ; Mon, 27 May 2002 17:20:10 -0700 (PDT) Received: from cfwss004.ssi.govt.nz (cfwss004 [10.177.133.23]) by cfwcs010.dsw.govt.nz (8.11.6/8.11.6) with ESMTP id g4S0K3a18303; Tue, 28 May 2002 12:20:03 +1200 (NZST) Received: from conversion-daemon.cfwss004.ssi.govt.nz by cfwss004.ssi.govt.nz (iPlanet Messaging Server 5.1 (built May 7 2001)) id <0GWS00H01OCHZW@cfwss004.ssi.govt.nz>; Tue, 28 May 2002 12:20:03 +1200 (NZST) Received: from ccwcs001.ssi.govt.nz (ccwcs001.ssi.govt.nz [10.132.6.20]) by cfwss004.ssi.govt.nz (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GWS00L9OOXF56@cfwss004.ssi.govt.nz>; Tue, 28 May 2002 12:20:03 +1200 (NZST) Received: from msd.govt.nz (cfwtw087.mosp.govt.nz [10.177.135.137]) by ccwcs001.ssi.govt.nz (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GWS0057AOXFV3@ccwcs001.ssi.govt.nz>; Tue, 28 May 2002 12:20:03 +1200 (NZST) Date: Tue, 28 May 2002 12:20:07 +1200 From: Malcolm Gibbs Subject: Automatic Reinitialization of connections To: users@conserver.com Cc: malcolm.gibbs@sun.com Message-id: <3CF2CD37.AEAEF5DF@msd.govt.nz> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: Hi, I am about to deploy conserver to manage about 300 consoles and need advice on how to control the automatic re-initialisation of connections. Without any arguments to conserver it appears to go into a very tight loop retrying console connections that are not currently available. This can consume a large amount of resource (CPU and disk log files). I did notice a discussion thread about this in Dec 2001 but the code appears to have changed significantly since, potentially making the advice out-of-date (see https://www.conserver.com/pipermail/users/2001-December/msg00003.html). My preference would be to have failed console connections stay in a down state to be rectified and manually restarted at a later date. Does conserver support this scenario by default? Can somebody advise code changes for conserver 7.2.1 to turn off the automatic reinitialisation? Much appreciated. -- Malcolm Gibbs From bryan@stansell.org Mon May 27 19:37:08 2002 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4S2b8jq008902 for ; Mon, 27 May 2002 19:37:08 -0700 (PDT) Received: (from bryan@localhost) by underdog.stansell.org (8.12.2/8.12.2/Submit) id g4S2b8bN008901 for users@conserver.com; Mon, 27 May 2002 19:37:08 -0700 (PDT) Date: Mon, 27 May 2002 19:37:08 -0700 From: Bryan Stansell To: users@conserver.com Subject: Re: Automatic Reinitialization of connections Message-ID: <20020527193708.M10610@underdog.stansell.org> References: <3CF2CD37.AEAEF5DF@msd.govt.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CF2CD37.AEAEF5DF@msd.govt.nz>; from Malcolm.Gibbs005@msd.govt.nz on Tue, May 28, 2002 at 12:20:07PM +1200 Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: On Tue, May 28, 2002 at 12:20:07PM +1200, Malcolm Gibbs wrote: > Without any arguments to conserver it appears to go into a very tight > loop retrying console connections that are not currently available. This > can consume a large amount of resource (CPU and disk log files). hmmm..."that shouldn't happen". :-/ > I did notice a discussion thread about this in Dec 2001 but the code > appears to have changed significantly since, potentially making the > advice out-of-date (see > https://www.conserver.com/pipermail/users/2001-December/msg00003.html). yep, that's out of date. > My preference would be to have failed console connections stay in a down > state to be rectified and manually restarted at a later date. > > Does conserver support this scenario by default? it should, kinda. actually, it's supposed to retry the connection, and if that fails, it will keep the console down. if you use the -o or -O flags, then that changes. now, if the connection goes up, however briefly, and then goes away, you can get a fairly tight loop as it appears to bring up the console, then loses it, then brings it up, etc... > Can somebody advise code changes for conserver 7.2.1 to turn off the > automatic reinitialisation? well, there are multiple points now. line 1378 of conserver/group.c has 'ReUp(pGe, 1)' - that's where it retries consoles every minute (those that went down hard) - you'll want to comment that out. there's also stuff around line 1429 - 'ConsInit(pCEServing, &pGE->rinit, 0);'. you'll want to comment that out and the following if, replacing it with 'ConsDown(pCEServing, &pGE->rinit);'. i'm pretty sure that'll cover the bases. but, more interesting to me is why this is happening. it really shouldn't if those consoles are really down. would you be willing to send me the log output of conserver so i can see how it's looping? to really tell what's going on we may need to run with the debug flag as well. if this isn't a bug (which it may be, but i'm hoping it isn't), this may be a configuration issue with the consoles, or even another setup situation that the conserver code should be aware of (assumptions that it shouldn't be making, for example). i hope this helps, and i would love to know why it's in such a tight loop...it really shouldn't be. Bryan From Malcolm.Gibbs005@msd.govt.nz Mon May 27 21:09:58 2002 Received: from cfwcs010.dsw.govt.nz (inetgate.dsw.govt.nz [202.27.54.3]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4S49ujq009571; Mon, 27 May 2002 21:09:57 -0700 (PDT) Received: from cfwss004.ssi.govt.nz (cfwss004 [10.177.133.23]) by cfwcs010.dsw.govt.nz (8.11.6/8.11.6) with ESMTP id g4S49na27874; Tue, 28 May 2002 16:09:50 +1200 (NZST) Received: from conversion-daemon.cfwss004.ssi.govt.nz by cfwss004.ssi.govt.nz (iPlanet Messaging Server 5.1 (built May 7 2001)) id <0GWS00A01Z12LC@cfwss004.ssi.govt.nz>; Tue, 28 May 2002 16:09:49 +1200 (NZST) Received: from ccwcs001.ssi.govt.nz (ccwcs001.ssi.govt.nz [10.132.6.20]) by cfwss004.ssi.govt.nz (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GWS00H4DZKDQI@cfwss004.ssi.govt.nz>; Tue, 28 May 2002 16:09:49 +1200 (NZST) Received: from msd.govt.nz (cfwtw087.mosp.govt.nz [10.177.135.137]) by ccwcs001.ssi.govt.nz (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GWS00J3JZKDB3@ccwcs001.ssi.govt.nz>; Tue, 28 May 2002 16:09:49 +1200 (NZST) Date: Tue, 28 May 2002 16:09:49 +1200 From: Malcolm Gibbs Subject: Re: Automatic Reinitialization of connections To: Bryan Stansell Cc: users@conserver.com Message-id: <3CF3030D.65581779@msd.govt.nz> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (WinNT; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <3CF2CD37.AEAEF5DF@msd.govt.nz> <20020527193708.M10610@underdog.stansell.org> Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: Bryan, Thanks for the quick response. Here is the conserver output for the behaviour I am experiencing (I will send a debug file directly to your address). In the following example I have intentionally created a problem in the custom expect script that performs the console connection (automated telnet and login into a Sun RSC card). You notice it automatically retries immediately. The small delay between each try is the expect script attempting the connection (intentional problem was failed login into RSC). conserver.cf line: 'rschost:|/opt/conserver/bin/rsclogin arg1 arg2::&::' conserver (17341): conserver.com version 7.2.1 conserver (17341): Started as `root' by `auser' at Tue May 28 16:06:03 2002 conserver (17342): lost carrier on rschost (/dev/pts/4)! [Tue May 28 16:06:07 2002] conserver (17342): rschost: automatic reinitialization [Tue May 28 16:06:07 2002] conserver (17342): lost carrier on rschost (/dev/pts/4)! [Tue May 28 16:06:12 2002] conserver (17342): rschost: automatic reinitialization [Tue May 28 16:06:12 2002] conserver (17342): lost carrier on rschost (/dev/pts/4)! [Tue May 28 16:06:16 2002] conserver (17342): rschost: automatic reinitialization [Tue May 28 16:06:16 2002] conserver (17342): lost carrier on rschost (/dev/pts/4)! [Tue May 28 16:06:21 2002] conserver (17342): rschost: automatic reinitialization [Tue May 28 16:06:21 2002] conserver (17341): Stopped at Tue May 28 16:06:22 2002 Another example I have experienced is to have a console connection to a host that does not exist conserver (17254): conserver.com version 7.2.1 conserver (17254): Started as `root' by `auser' at Tue May 28 16:03:11 2002 conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28 16:03:11 2002] conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:11 2002] conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28 16:03:11 2002] conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:11 2002] conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28 16:03:12 2002] conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12 2002] conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28 16:03:12 2002] conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12 2002] conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28 16:03:12 2002] conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12 2002] conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28 16:03:12 2002] conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12 2002] conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28 16:03:12 2002] conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12 2002] conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28 16:03:12 2002] conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12 2002] conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28 16:03:12 2002] conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:12 2002] conserver (17255): lost carrier on blah (/dev/pts/4)! [Tue May 28 16:03:13 2002] conserver (17255): blah: automatic reinitialization [Tue May 28 16:03:13 2002] conserver (17254): Stopped at Tue May 28 16:03:13 2002 I hope this helps Malcolm Bryan Stansell wrote: > > On Tue, May 28, 2002 at 12:20:07PM +1200, Malcolm Gibbs wrote: > > Without any arguments to conserver it appears to go into a very tight > > loop retrying console connections that are not currently available. This > > can consume a large amount of resource (CPU and disk log files). > > hmmm..."that shouldn't happen". :-/ > > > I did notice a discussion thread about this in Dec 2001 but the code > > appears to have changed significantly since, potentially making the > > advice out-of-date (see > > https://www.conserver.com/pipermail/users/2001-December/msg00003.html). > > yep, that's out of date. > > > My preference would be to have failed console connections stay in a down > > state to be rectified and manually restarted at a later date. > > > > Does conserver support this scenario by default? > > it should, kinda. actually, it's supposed to retry the connection, and > if that fails, it will keep the console down. if you use the -o or -O > flags, then that changes. now, if the connection goes up, however > briefly, and then goes away, you can get a fairly tight loop as it > appears to bring up the console, then loses it, then brings it up, > etc... > > > Can somebody advise code changes for conserver 7.2.1 to turn off the > > automatic reinitialisation? > > well, there are multiple points now. line 1378 of conserver/group.c > has 'ReUp(pGe, 1)' - that's where it retries consoles every minute > (those that went down hard) - you'll want to comment that out. there's > also stuff around line 1429 - 'ConsInit(pCEServing, &pGE->rinit, 0);'. > you'll want to comment that out and the following if, replacing it with > 'ConsDown(pCEServing, &pGE->rinit);'. i'm pretty sure that'll cover > the bases. > > but, more interesting to me is why this is happening. it really > shouldn't if those consoles are really down. would you be willing to > send me the log output of conserver so i can see how it's looping? to > really tell what's going on we may need to run with the debug flag as > well. if this isn't a bug (which it may be, but i'm hoping it isn't), > this may be a configuration issue with the consoles, or even another > setup situation that the conserver code should be aware of (assumptions > that it shouldn't be making, for example). > > i hope this helps, and i would love to know why it's in such a tight > loop...it really shouldn't be. > > Bryan > _______________________________________________ > users mailing list > users@conserver.com > https://www.conserver.com/mailman/listinfo/users -- Malcolm Gibbs Sun Microsystems (NZ) Ltd mobile (021) 285 9196 From woods@proven.weird.com Tue May 28 09:28:30 2002 Received: from most.weird.com (IDENT:1rB0avPO3Hzzr8aGrZBf30rZ/K52Kpr20+PLP1dz151AlllZYuS8iSUSMKmlsLpdpojpHvhn03g@mail.weird.com [204.92.254.2]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4SGSTjq019512 for ; Tue, 28 May 2002 09:28:29 -0700 (PDT) Received: from proven.weird.com([204.92.254.15]) (3215 bytes) by most.weird.com via smail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident <[xW7+lOJA0WPEH0nayccJf0DJPxPCXtNC9LrqfX2zMAQrKtKYPisUwHPbpNr0GeEZT7c1eyEssIqFOuS0KTvIhA==]> using rfc1413) id for ; Tue, 28 May 2002 12:28:27 -0400 (EDT) (Smail-3.2.0.115-Pre 2001-Aug-6 #9 built 2002-May-28) Received: by proven.weird.com (Postfix, from userid 1000) id 38251AC; Tue, 28 May 2002 12:28:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: ;j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz;@-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= Cc: users@conserver.com, malcolm.gibbs@sun.com Subject: Re: Automatic Reinitialization of connections In-Reply-To: <3CF2CD37.AEAEF5DF@msd.govt.nz> References: <3CF2CD37.AEAEF5DF@msd.govt.nz> X-Mailer: VM 7.03 under Emacs 21.2.1 Reply-To: users@conserver.com (ConServer Users Mailing List) Organization: Planix, Inc.; Toronto, Ontario; Canada Message-Id: <20020528162810.38251AC@proven.weird.com> Date: Tue, 28 May 2002 12:28:10 -0400 (EDT) Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: [ On Tuesday, May 28, 2002 at 12:20:07 (+1200), Malcolm Gibbs wrote: ] > Subject: Automatic Reinitialization of connections > > My preference would be to have failed console connections stay in a down > state to be rectified and manually restarted at a later date. If you're talking about telnet connections to terminal servers then I should warn you that it's quite possible the terminal server will freeze console output if there is no telnet client connected to accept its output. Often this effect can be avoided by careful configuration of both the terminal server and the server's console port. However even with the most careful control of these configurations the very cause of the disconnect may result in an inability to restore the proper configuration parameters at the most critical time. For example if you have a catastrophic power failure on a Friday night and both your terminal server and the servers it manages consoles for are reset, the terminal server may send an XOFF character to the booting servers. This might prevent them from completing their boot procedures, or it might cause kernel output to be permanently frozen while syslog output isn't which will lead to the impression that everything's OK until suddenly your server freezes entirely when the kernel gets stuck at some later date as it trys to print a message on the console. This is in fact one of the reasons I've been working on the chat solution (since my terminal servers require an access password to be sent before they'll complete the connection). I.e. You really do want automatic re-initialisation of telnet connections. Appropriately placed pauses can alleviate resource starvation caused by failed retries. -- Greg A. Woods +1 416 218-0098; ; ; Planix, Inc. ; VE3TCP; Secrets of the Weird From bryan@stansell.org Tue May 28 10:57:55 2002 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4SHvtjq020913 for ; Tue, 28 May 2002 10:57:55 -0700 (PDT) Received: (from bryan@localhost) by underdog.stansell.org (8.12.2/8.12.2/Submit) id g4SHvtKL020912 for users@conserver.com; Tue, 28 May 2002 10:57:55 -0700 (PDT) Date: Tue, 28 May 2002 10:57:55 -0700 From: Bryan Stansell To: users@conserver.com Subject: Re: Automatic Reinitialization of connections Message-ID: <20020528105755.S10610@underdog.stansell.org> References: <3CF2CD37.AEAEF5DF@msd.govt.nz> <20020527193708.M10610@underdog.stansell.org> <3CF3030D.65581779@msd.govt.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CF3030D.65581779@msd.govt.nz>; from Malcolm.Gibbs005@msd.govt.nz on Tue, May 28, 2002 at 04:09:49PM +1200 Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: On Tue, May 28, 2002 at 04:09:49PM +1200, Malcolm Gibbs wrote: > RSC card). You notice it automatically retries immediately. The small > delay between each try is the expect script attempting the connection > (intentional problem was failed login into RSC). > > conserver.cf line: 'rschost:|/opt/conserver/bin/rsclogin arg1 arg2::&::' yep, that explains things. the problem here is that, as far as conserver is concerned, everything is ok - for a total of 5 seconds. then the program exits (which means the console is down), and conserver respawns it. the unfortunate part here is that there's no way of knowing if the program exited because it was having trouble, or of it exited because it finished normally. ideally, a "normal exit" would trigger a respawn and an "abnormal exit" would not - well, maybe. i've been thinking that if we look at the exit code of the program and either auto-respawn that it might be a good compromise. but i'm not sure about that either. why? 'cause i would assume that if something bad happened to a console (say the rsc unit resets), the program would exit with an error code reflecting that. and you'd want conserver to respawn the thing, cause, in theory, the rsc unit would be back and available "real soon". with examples like this, you could argue that the return codes of the programs are irrelevant. which brings us back to our original problem - do you respawn these things or not? for tcp connections and local serial ports, the current logic is probably correct (or real close). for programs, i really don't know what to do. i'd think it's safer to error on the side of respawning. but, maybe we just need another flag that says "don't ever automatically reconnect on failure" (the -o/-O flags would still take effect - it would just turn off the initial retry on failure). if anyone has an opinion on this, let me know (send me private email, please - i'd rather not spam the list). if there's a lot of activity, i'll post a summary. but, i'm thinking the flag would be the right thing for the immediate future. probably only useful for folks who are using programs as consoles (and, as i said, respawning is probably a good thing - even for programs) but i can see the need for it not to respawn too. (yeah, a mixed console set - some programs, some tcp or devices - probably won't find this useful as it would turn them all off, but you could use the -O option. hmm...) Bryan From woods@proven.weird.com Tue May 28 15:10:59 2002 Received: from most.weird.com (IDENT:TmL7uT8xjZEDAY5HyAIN9NPmCNeF8rTCjL+7nkUWewb49eyzCuaXEKbeohWCiSNMdosZxCCs+FI@most.weird.com [204.92.254.2]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4SMAxjq022954 for ; Tue, 28 May 2002 15:10:59 -0700 (PDT) Received: from proven.weird.com([204.92.254.15]) (3307 bytes) by most.weird.com via smail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident <[cTJ84p1Jf2x4xOnzpWOTX3vvEeal1LJ5cc2C0srpCs4GLNMmzXzjv69RkH7P9T6WiqV9xWaWe2KlwsCjqI6p3w==]> using rfc1413) id for ; Tue, 28 May 2002 18:10:57 -0400 (EDT) (Smail-3.2.0.115-Pre 2001-Aug-6 #9 built 2002-May-28) Received: by proven.weird.com (Postfix, from userid 1000) id 73984AC; Tue, 28 May 2002 18:10:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: ;j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz;@-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= References: <20020523204542.34C49AC@proven.weird.com> <20020526001006.A10610@underdog.stansell.org> X-Mailer: VM 7.03 under Emacs 21.2.1 Reply-To: users@conserver.com (ConServer Users Mailing List) Organization: Planix, Inc.; Toronto, Ontario; Canada Message-Id: <20020528221056.73984AC@proven.weird.com> Date: Tue, 28 May 2002 18:10:56 -0400 (EDT) Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: [ On Sunday, May 26, 2002 at 00:10:06 (-0700), Bryan Stansell wrote: ] > Subject: Re: conserver eventually goes catatonic after SIGPIPE (on NetBSD) > > right...no SIGPIPE handler. but, there is a SIGCHLD handler, which > gets called when forked processes die. i don't think this is a problem > (yet, at least). Conserver definitely needs a SIGPIPE handler -- unless it wants to die unexpectedly every time it writes to a client that has disconnected abnormally. The kernel sends SIGPIPE to processes writing to closed sockets just as it does to processes writing to closed pipes.... > looking at #2, you see it's calling waitpid() from ConsChat(). > ConsChat() is part of your patch. the problem, i'm guessing, is that > the waitpid() inside the while loop has a little bad logic. Bummer. I completely missed/ignored the SIGCHLD handler and its call to waitpid() when I added mine, and then when I read the stack backtrace I completely forgot about mine -- or rather I think I assumed that since it waited explicitly for the just-forked chat pid there could be no confusion. I've been looking at some way to fix this. The ideal fix would be to block SIGCHLD during the execution of the chat program. However the code currently supports systems without sigaction(2). Is that important? I'll bet conserver won't even compile on systems without sigaction() despite the fact that API alone is handled portably.... The alternative is to keep a list of chat child PIDs and walk through them after SIGCHLD is caught too.... That's a bit more work, but still easily doable (I've got similar code already tested and working for some other applications). It seems a little messier since it introduces concurrency in the error handling for chat processes where they're currently really more synchronous.... -- Greg A. Woods +1 416 218-0098; ; ; Planix, Inc. ; VE3TCP; Secrets of the Weird From bryan@stansell.org Tue May 28 18:06:18 2002 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4T16Ijq024687 for ; Tue, 28 May 2002 18:06:18 -0700 (PDT) Received: (from bryan@localhost) by underdog.stansell.org (8.12.2/8.12.2/Submit) id g4T16I1b024686 for users@conserver.com; Tue, 28 May 2002 18:06:18 -0700 (PDT) Date: Tue, 28 May 2002 18:06:18 -0700 From: Bryan Stansell To: users@conserver.com Subject: Re: conserver eventually goes catatonic after SIGPIPE (on NetBSD) Message-ID: <20020528180618.W10610@underdog.stansell.org> References: <20020523204542.34C49AC@proven.weird.com> <20020526001006.A10610@underdog.stansell.org> <20020528221056.73984AC@proven.weird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020528221056.73984AC@proven.weird.com>; from woods@weird.com on Tue, May 28, 2002 at 06:10:56PM -0400 Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: On Tue, May 28, 2002 at 06:10:56PM -0400, Greg A. Woods wrote: > Conserver definitely needs a SIGPIPE handler -- unless it wants to die > unexpectedly every time it writes to a client that has disconnected > abnormally. The kernel sends SIGPIPE to processes writing to closed > sockets just as it does to processes writing to closed pipes.... yep. guess it's just never come up before 'cause it's mostly processing a read() when it notices broken things (a client would have to be sending data at just the right time). i didn't even look for a SIGPIPE handler until this came up, actually. regardless, yes, this needs to be added. > code currently supports systems without sigaction(2). Is that > important? I'll bet conserver won't even compile on systems without > sigaction() despite the fact that API alone is handled portably.... yeah, i'm not sure myself. i've been adding and changing things and trying to not break older systems, but at this point, i have no idea if i've succeeded. i haven't heard complaints, so that's promising, but i don't want to just assume everyone is posix-compliant or has foo and bar or whatever. i wish i knew for sure. so, i'd like to try and keep it as forgiving as possible. > The alternative is to keep a list of chat child PIDs and walk through > them after SIGCHLD is caught too.... That's a bit more work, but still > easily doable (I've got similar code already tested and working for some > other applications). It seems a little messier since it introduces > concurrency in the error handling for chat processes where they're > currently really more synchronous.... and that's one thing i'm worried about...synchronous behavior. anything that conserver does that isn't more "event-based" causes the server (or a set of consoles, in this case) to freeze until it completes. the re-read of the config file is one example of this. depending on the size of your config file, you can see a noticable delay while it does all it's work and rebuilds all it's data structures. the chat patch you submitted does similar things - it forks off chat and waits for it to return before continuing. depending on timeouts in that chat script, network availablity, etc, it can cause a major hang in conserver while it's waiting for things to happen. if a console goes down and it retries, that group of consoles is going to hang 'til the script completes. then it's even worse if conserver has been given the -O flag, that hang will occur repeatedly. but don't get me wrong, i really like the idea of conserver being able to handle a chat-like situation. we just need to get things so they don't cause the server to stop processing other consoles and client connections. we're already forking off processes as consoles and looping over them - it just needs to be extended to the chat scripts (i think - haven't really put a lot of thought into it - but i doubt it would be *that* hard). Bryan From woods@proven.weird.com Wed May 29 09:40:34 2002 Received: from most.weird.com (IDENT:CQ3IAfXRMoH5JLwJZ3o7nl4na9w2nOFkEby0Ko/M3CR0ApLeTo/6T0+bqnFyzkI8kyx06lhVXdY@most.weird.com [204.92.254.2]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4TGeXjq005094 for ; Wed, 29 May 2002 09:40:33 -0700 (PDT) Received: from proven.weird.com([204.92.254.15]) (5172 bytes) by most.weird.com via smail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident <[zqhtGZ0EQakuR1gTWHvSmujHVk9CrPFVVrR1peLBxd9JilqNi1l40QjjpbVq97SeOP7J0gSSvg4m77hvqzYGNA==]> using rfc1413) id for ; Wed, 29 May 2002 12:40:31 -0400 (EDT) (Smail-3.2.0.115-Pre 2001-Aug-6 #9 built 2002-May-28) Received: by proven.weird.com (Postfix, from userid 1000) id F4230AC; Wed, 29 May 2002 12:40:29 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: ;j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz;@-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= References: <20020523204542.34C49AC@proven.weird.com> <20020526001006.A10610@underdog.stansell.org> <20020528221056.73984AC@proven.weird.com> <20020528180618.W10610@underdog.stansell.org> X-Mailer: VM 7.03 under Emacs 21.2.1 Reply-To: users@conserver.com (ConServer Users Mailing List) Organization: Planix, Inc.; Toronto, Ontario; Canada Message-Id: <20020529164029.F4230AC@proven.weird.com> Date: Wed, 29 May 2002 12:40:29 -0400 (EDT) Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: [ On Tuesday, May 28, 2002 at 18:06:18 (-0700), Bryan Stansell wrote: ] > Subject: Re: conserver eventually goes catatonic after SIGPIPE (on NetBSD) > > yeah, i'm not sure myself. i've been adding and changing things and > trying to not break older systems, but at this point, i have no idea if > i've succeeded. i haven't heard complaints, so that's promising, but i > don't want to just assume everyone is posix-compliant or has foo and > bar or whatever. i wish i knew for sure. so, i'd like to try and keep > it as forgiving as possible. Well, according to Stevens' APUE, waitpid() is new with POSIX.1. However conserver currently uses it (as per the note in CHANGES), without even bothering to use an autoconf check for it.... Signal blocking can be done without using POSIX.1 sigaction() on everything back to AT&T SysVr3(.2?), but writing the code to do it portably, and especially testing it in this day and age, is rather difficult. On the other hand I've never seen a system with waitpid(2), but without POSIX.1 signals, and I've seen almost all the possibilities.... (though in the past I've implemented a user-level waitpid() wrapper using wait4(), and presumably such a wrapper would fool an autoconf check anyway....) So, what I'm trying to say is that conserver currently requires at least the level of POSIX.1 compliance I'm suggesting would be needed to implement the signal-blocking fix to my chat patch. However I'm also sort of saying that conserver could easily be made portable in its currently released state to older *BSD systems at least as old as 4.3BSD. Does anyone care? We're talking about some pretty ancient stuff here -- even SunOS-4.0 has enough POSIX compliance. Could anyone using conserver even test such portability any more? > and that's one thing i'm worried about...synchronous behavior. I'm not worried at all about synchronous behaviour in the "chat" case. Indeed it must be synchronous -- it's equivalent to, or at least part of the process of, the opening and initialization of the port (or telnet connection, in my case) itself, i.e. you can't open a bunch of ports in parallel. It's really only possible to initialize one console at a time. Presumably a failed chat even requires a disconnect and later retry, though I don't thing I've implemented quite that much yet.... Asynchronous initialization is best done by reducing the number of consoles handled per group and forking more handler processes.... Ultimately the best case for parallel operation is one handler process per console "port". Personally that's the way I would have implemented it from the get go. It makes things a lot simpler to implement, and it doesn't really make the reload situation any more difficult (it might even make it easier since this way the master knows exactly which consoles have had parameter changes and thus will know exactly which processes will need to be restarted). It also makes TTY signal handling possible for true serial ports -- you make the controlling terminal for the process be the serial port it's managing. Currently there's no way to handle situations where signals are generated on the serial port by its driver, such as SIGHUP, since you can't have multiple TTYs all sending signals to the same process. BTW, nobody should be afraid of having one process per console port either, even if they have a thousand console ports to manage. This is unix, after all! (even if some implementations are a bit stupid about fork(), it's not as if this application would be constantly re-forking processes continuously) -- Greg A. Woods +1 416 218-0098; ; ; Planix, Inc. ; VE3TCP; Secrets of the Weird From bryan@stansell.org Wed May 29 11:59:43 2002 Received: from underdog.stansell.org (localhost [127.0.0.1]) by underdog.stansell.org (8.12.2/8.12.2) with ESMTP id g4TIxhjq006491 for ; Wed, 29 May 2002 11:59:43 -0700 (PDT) Received: (from bryan@localhost) by underdog.stansell.org (8.12.2/8.12.2/Submit) id g4TIxhpS006490 for users@conserver.com; Wed, 29 May 2002 11:59:43 -0700 (PDT) Date: Wed, 29 May 2002 11:59:43 -0700 From: Bryan Stansell To: users@conserver.com Subject: Re: conserver eventually goes catatonic after SIGPIPE (on NetBSD) Message-ID: <20020529115943.A10610@underdog.stansell.org> References: <20020523204542.34C49AC@proven.weird.com> <20020526001006.A10610@underdog.stansell.org> <20020528221056.73984AC@proven.weird.com> <20020528180618.W10610@underdog.stansell.org> <20020529164029.F4230AC@proven.weird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020529164029.F4230AC@proven.weird.com>; from woods@weird.com on Wed, May 29, 2002 at 12:40:29PM -0400 Sender: users-admin@conserver.com Errors-To: users-admin@conserver.com X-BeenThere: users@conserver.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Conserver Users List-Unsubscribe: , List-Archive: On Wed, May 29, 2002 at 12:40:29PM -0400, Greg A. Woods wrote: > Well, according to Stevens' APUE, waitpid() is new with POSIX.1. > However conserver currently uses it (as per the note in CHANGES), > without even bothering to use an autoconf check for it.... doh! shows you how good my memory is - i totally forgot i introduced that dependency. cool....posix it is. > On the other hand I've never seen a system with waitpid(2), but without > POSIX.1 signals, and I've seen almost all the possibilities.... that's good to hear. > However I'm also sort of saying that conserver could easily be made > portable in its currently released state to older *BSD systems at least > as old as 4.3BSD. Does anyone care? We're talking about some pretty > ancient stuff here -- even SunOS-4.0 has enough POSIX compliance. > Could anyone using conserver even test such portability any more? my question as well. but, at this point, i would be more scared than worried about compatibility if someone really wanted to run conserver under something so old. > I'm not worried at all about synchronous behaviour in the "chat" case. > Indeed it must be synchronous -- it's equivalent to, or at least part of > the process of, the opening and initialization of the port (or telnet > connection, in my case) itself, i.e. you can't open a bunch of ports in > parallel. It's really only possible to initialize one console at a > time. well, that's true, it does only initialize things one at a time, but in the case of '|' syntax consoles, all that requires is a fork of a process. could a similar mode of thinking could be used for the chat-based consoles? > BTW, nobody should be afraid of having one process per console port > either, even if they have a thousand console ports to manage. This is > unix, after all! (even if some implementations are a bit stupid about > fork(), it's not as if this application would be constantly re-forking > processes continuously) well, actually, maybe they should. in the past, i've seen multi-gig systems run low on vm because of conserver's footprint. and that was with 32 consoles per process (they had a *lot* of consoles - heck, still do, as far as i know). that was pre-7.2.0, so it shouldn't be as much of an issue now, but it still could be a concern. i personally like the idea of being able to use a relatively low-end machine as a console server (i can't count the number of times i've heard of infrastructure machines like this left out of budgets or seen as unimportant by management or just added to an already loaded admin box). and there are other possibilities - cyclades ts terminal servers, for example, run linux and can cross-compile conserver to run on it (one person has reported success doing this). i'm not sure if 48 processes would kill the box or not (or if the memory usage would), but this too would be a nice situation to handle (regardless of manufacturer). so, there's a few more scenarios for everyone. posix is definitely already a requirement (you know, the more i think about this the more i remember deciding posix wouldn't be a big deal, hence the change in 7.1.0) so further posix requirements are no big deal (now if i can just remember that!). as for the other stuff, being as responsive as possible is my goal. Bryan