Archive-Date: Wed, 2 May 2001 11:03:17 -0400 Date: Wed, 02 May 2001 11:00:54 -0400 (EDT) From: Jeff Schreiber Reply-To: Info-TCPware@process.com Subject: DECUS/ITUG 2001 Joint European Conference To: info-tcpware@process.com, info-multinet@process.com, info-pmdf@process.com Message-ID: <01K333J67CIIA3EGI6@ALCOR.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii This is just an informal for anyone planning on attending the DECUS/ITUG 2001 Joint European Conference next week that Process Software will be in attendance. We won't be having a trade show booth, but I should be around the conference all week. If you would like to talk to us, please seek me out [the message board is probably the best method, with e-mail being possible as I will probably be checking my e-mail in the evenings]. I will be giving a seminar on TCP/IP Procotols on Monday, and an Introduction to DNS on Tuesday [session OS-18 - 5:15 - 6:15]. I am not planning a customer BOF, as there were only 3 people that showed up a the BOF last year [who I might add weren't customers, but were tied, 2 directly, 1 indirectly] to Compaq's TCP/IP services development group. If there is interest in a BOF, please let me know via e-mail and I will try to schedule one. The abstract for the seminar can be found on the conference website [I unfortunately can't find the abstracts for the sessions there]: SE-11: TCP/IP Networking Protocols http://www.jointconference.org/AttendeeInfo/Seminars.cfm#se11 Details of the conference in general [if you weren't planning on going, but would like to look into the possiblity of attending] can be found at: http://www.jointconference.org/ -Jeff Schreiber -- Jeff Schreiber, Process Software LLC schreiber@mx.process.com http://www.process.com TCPware, MultiNet & PMDF: Stronger than Ever ================================================================================ Archive-Date: Thu, 3 May 2001 11:21:47 -0400 Date: Thu, 03 May 2001 10:14:57 -0500 (EST) From: bryant@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTP_V543P160 To: TCPware-Announce@TRITON.PROCESS.COM Message-ID: <01K34GL0WY5U003JQM@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: FTP_V543P160 Description: Correct problem with creating STRU R files Release date: 3-MAY-2001 Ranking: Max ranking: Versions: 5.4-3 ftp://ftp.process.com/support/54_3/ftp_v543p160.zip To search the TCPware ECO database, please visit the following URL: http://vms.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- ----------------------------------------------------------------------- FTP Patch kit (revision 16.0) for TCPware version 5.4-3 25-Apr-01 Copyright (c) 2000, 2001 by Process Software This VMSinstallable saveset provides new versions of FTP.EXE, FTP_CONTROL.COM, FTP_LISTENER.EXE, and FTP_SERVER.EXE for TCPware for OpenVMS. TCPWare V5.4-3 VMS/VAX V5.5-2 and later VMS/ALPHA V6.1 and later The following change[s] has been made in this kit: FTP_SERVER.EXE -Correct a problem with writing out RECORD (STRU R) files. DE 6983. ECO FTP_V543P160 rank 3 -Fill in the resultant file name when an error status is returned due to unsupported I/O operations. (e.g. attempting to RETR a a directory when in Unix mode) DE 6987. ECO FTP_V543P160 rank 3 The following changes from previous kits are also in this kit: FTP_SERVER.EXE - Corrects a problem with VMS Plus mode transfers when the FDL information arrives split over multiple read requests. This causes the file to be created with the wrong attributes and part of the FDL information to be at the beginning of the file. ECO FTP_V543P150 rank 3 FTP_SERVER.EXE - Parse DIRECTORY A/*.* as a Unix-style file specification, but return the results in VMS directory format. (DE 6696) For this to work the logical TCPWARE_FTP_DISALLOW_UNIX_STYLE must be defined to be FALSE. This can be done at either the system level, or in the user's login.com file. ECO FTP_V543P130 rank 3 FTP_SERVER.EXE - Ensure that transfer is file structured when it is done in VMS Plus mode (DE 6413) ECO FTP_V543P120 rank 3 FTP_CONTROL.COM now asks if you wish to provide FTP service in the configuration phase. (DE 5058) ECO FTP_V543P010 rank 3. FTP_LISTENER.EXE - Correct a problem that can cause a new session to get dropped due to an internal race condition (DE 4581) ECO FTP_V543P140 rank 3 - Fix a problem which can cause the program to ACCVIO under certain rare conditions. (DE 6359) ECO FTP_V543P110 rank 3 - Fix a problem which in which a heavily loaded FTP_LISTENER can hang (DE 4581) ECO FTP_V543P110 rank 3. - Fix a problem which can cause the program to consume timer quota, and eventually require restarting of FTP in order to service more requests. The number of timer entries that the listener can be expected to use at one time can be computed by adding 1 (one) to the number of unauthenticated connections present. Unauthenticated connections are those that have not yet supplied a valid username and password. (DE 6334) ECO FTP_V543P100 rank 3. - A problem which caused the wrong IP addresses to be displayed in the log file has been corrected. (DE 5285) ECO FTP_V543P010 rank 3. - A possible denial of service attack has been corrected. (DE 5347) To control how much time can elapse before the connection is killed if it is not successfully authorized as an FTP user define TCPWARE_FTP_IDLE_TIMEOUT. The format for this logical is the delta time (dddd hh:mm:ss.hh) that can elapse between when the connection is established and when it must be successfully logged in. The default value for this is 10 minutes. ECO FTP_V543P020 rank 2. - Correct a problem with FTP_V543P030 that could cause the TCPware_FTP process to consume channels. ECO FTP_V543P040 rank 2. - Problems looking up the host name for a new connection could stall all connections when one of them provided authorization information. The code has been modified so that the logical TCPWARE_FTP_GETHOST_MAX_TIME can be used to control how long it will attempt to translate the name before it gives up. TCPWARE_FTP_GETHOST_MAX_TIME is specified as a VMS delta time, and has a default value of 10 seconds. (DE 6262) ECO FTP_V543P080, rank 3. - Fix a problem with the change in FTP_V543P080 that makes FTP_LISTENER use a lot of buffered I/O byte count quota. (DE6290) Because the reverse lookups were left pending after the program had given up on them there would buffered I/O byte count quota in use for longer than necessary. If the server was busy the available quota would get consumed quicker than the pending requests would complete. ECO FTP_V543P090 rank 3 FTP_SERVER.EXE - The default window size increased to improve performance of GET operations. (DE 5195) ECO FTP_V543P010 rank 3. - A problem with incorrect IP addresses in the log file has been corrected. (DE 5285) ECO FTP_V543P010 rank 3. - A data corruption problem has been corrected. (DE 5298) ECO FTP_V543P020 rank 2. - When the logical TCPWARE_FTP_SEMANTICS_VARIABLE_IGNORE_CC is defined to TRUE files with variable length records and carriage return carriage control will NOT have a new line character inserted after each line when the file is transfered in image (binary) mode. This logical is now defined to be TRUE by default in FTPSERVER_DTP.COM, returning to the behavior present in TCPWare 5.3 (DE 5709) ECO FTP_V543P030 rank 3. - Correct a problem that can occur when deleting files on a VAX from an NT system where the error "%LIB-F-INVSTRDES, invalid string descriptor" could occur. (DE 5722) ECO FTP_V543P040 rank 3. - Correct a problem when TCPWARE_FTP__ROOT is defined to be disk:[dir.] /translation=conceal that would cause the user to be denied access to directories that previous versions of FTP did not deny access to. (DE5670) ECO FTP_V543P040 rank 3. - Correct a problem with deleting wildcarded files in Unix mode. (DE 5734) ECO FTP_V543P040 rank 3. - Correct a problem with displaying the directory in the 150 reply message in Unix mode. (DE 5736) ECO FTP_V543P040 rank 3. - Correct a problem with the /IMAGE=size qualifier on the target file of a PUT command. (DE 6055) ECO FTP_V543P050 rank 3. - Correct a problem with recognizing that TCPWARE_FTP__ROOT being defined as * means no restrictions. (DE 6058) ECO FTP_V543P050 rank 3. - Allow /IMAGE=size to write out files with fixed length records of other than 512 bytes (DE 6055) ECO FTP_V543P060 rank 3. - There was a discrepency between the documentation and the code on how to disable Unix syntax in the FTP server. The documentation specified the logical TCPWARE_FTP_DISALLOW_UNIX_STYLE and the code checked for TCPWARE_FTPD_NOUNIX_SYNTAX. The code has been modified to check for both logicals. Note that the FTP server startup procedure defines TCPWARE_FTP_DISALLOW_UNIX_STYLE to TRUE if it is not already defined. If you want UNIX style directories to be enabled you must define TCPWARE_FTP_DISALLOW_UNIX_STYLE to FALSE. This can be done at either the system or user level. (DE 6219) ECO FTP_V543P070, rank 3. - Fix a problem with TCPWARE_FTP_IDLE_TIMEOUT being set to 0 (zero) causing immediate timeouts. (DE 6288) Note that Process Software recommends that this value not be set to 0, as it can cause resources to be tied up on your system. ECO FTP_V543P090 rank 3 FTP.EXE - Check a new logical (TCPWARE_FTP_LOWERCASE_USERNAME), which when defined as True, Yes, or 1 will make the username, password and account lowercase before they are sent to the remote system if the username was prompted for. (DE 6264) This allows behavior from earlier versions of TCPware FTP to be optionally restored. ECO FTP_V543P090 rank 3 After installing the patch kit you should do @TCPWARE:RESTART FTP to cause the new images to be used. [End of ECO announcement] ================================================================================ Archive-Date: Thu, 3 May 2001 14:08:36 -0400 Date: Thu, 03 May 2001 13:01:39 -0500 (EST) From: bryant@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: FTP_V553P010 To: TCPware-Announce@TRITON.PROCESS.COM Message-ID: <01K34MEPEWTE003K1A@DELTA.PROCESS.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT TCPware ECO kit announcement The following ECO kit is now available for TCPware: ECO: FTP_V553P010 Description: FTP server update Release date: 3-MAY-2001 Ranking: Max ranking: Versions: 5.5-3 ftp://ftp.process.com/support/55_3/ftp_v553p010.zip To search the TCPware ECO database, please visit the following URL: http://vms.process.com/eco.html For more information, contact Process Software via: E-mail: support@process.com Phone: 1-800-394-8700 The ECO kit README contents are below. ----------------------------------------------------------- ----------------------------------------------------------------------- FTP Patch kit (revision 1.0) for TCPware version 5.5-3 27-Apr-01 Copyright (c) 2001 by Process Software This VMSinstallable saveset provides new versions of FTP_SERVER.EXE for TCPware for OpenVMS. TCPWare V5.5-3 and later VMS/VAX V5.5-2 and later VMS/ALPHA V6.1 and later The following change[s] has been made in this kit: FTP_SERVER.EXE -Correct a problem with writing out RECORD (STRU R) files. DE 6983. ECO FTP_V553P010 rank 3 -Fill in the resultant file name when an error status is returned due to unsupported I/O operations. (e.g. attempting to RETR a a directory when in Unix mode) DE 6987. ECO FTP_V553P010 rank 3 After installing the patch kit you should do @TCPWARE:RESTART FTP to cause the new images to be used. [End of ECO announcement] ================================================================================ Archive-Date: Thu, 3 May 2001 16:47:25 -0400 Date: Thu, 03 May 2001 15:45:14 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: TCPware V5.5-3 is now shipping To: tcpware-announce@process.com Message-ID: <01K34S4WMK3Q8WVYKA@goat.goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Process Software is pleased to announce that TCPware v5.5 was released last Thursday. All TCPware v5.5 shipments are in route to customers with update service. 5.5 features SSH (Secure Shell) security, SMTP and FTP accounting and statistical reports, Agent X, DHCP v3.0, as well as other product enhancements. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Wed, 16 May 2001 13:26:55 -0400 Date: Wed, 16 May 2001 13:33:04 -0400 (EDT) From: Gary Reynolds Reply-To: Info-TCPware@process.com Subject: PURVEYOR questions RE: Access to Course ROSTER reports ... To: Purveyor@cjis.ci.lincoln.us, info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I'm hoping someone on the listserv may have some experience with using PURVEYOR web server for directly accessing Course ROSTER reports securely. The following message was sent to Michael Corbett at Process Software but I thought it may be worthwhile having the input of the listservs; given the broader range of experience of all the members. Basically, I am wanting to directly produce Course ROSTERS without having to duplicate the entire Registration database in the HTTPD Worker directory. It appears from my discussion below that I have everthing "READ-able" by the HTTPD_Worker process (using ACL's), but the file name for the STUDENT file is getting messed up somewhere when the ROSTER program attempts to access it. If anyone can give some help on this one, I'd appreciate it ... Gary PS. Does anyone know why I would have to have a copy of the CONFIG80.DB in the RSM Username-authenticated WWWREG Account as simply : [HTTPD.REG]CONFIG.;1? Honestly, the CGI Command script would not work until that was copied there in that format - no filename extension ... (???) ---------- Forwarded message ---------- Date: Wed, 16 May 2001 11:58:19 -0400 (EDT) From: Gary Reynolds To: corbett@Process.com Subject: PURVEYOR questions ... Hello Michael, Can I ask you to dig again into your recollections on correctly setting up and using Purveyor for restricted access to producing Registrar's COURSE roster files ? I've been using $MAIL and URLDECODE to unpack the data parameters from the web page query on a POST Action. The report is produced and then mailed to the requesting Faculty member. This has worked but is a little "clunky". The more I've worked on it, the more it seems that there should be a more direct way without compromising Security. The errors I'm encountering from the ~SCRIPTS/REGPOST.COM cgi-script which runs the ROSTER program are : %Illegal file name - Data file DISK:[REGISTRAR.FILES]STUDENT.DTA;[] %Illegal file name - Data file DISK:[REGISTRAR.FILES]STUDENT.KEY;[] ( the ";[]" characters would be sufficient to cause this problem, but they ) ( are not normally utilized by any of the REG Logicals or ROSTER program in) ( this way ... So why are they being reported to ROSTER program this way ? ) These are the first two files opened by the ROSTER.EXE program ... I have ACL's setup on both directories AND files to permit access by the HTTPD Worker account for the following directories and files : REGISTRAR.DIR & FILES.DIR to permit STUDENT and COURSE files As well as the Executable directory and ROSTER.EXE --- which I am not having a problem executing from the cgi-.COM file . Configuration Description ************************* I have the HTTPD Worker account set up UIC = [400,10]. Nevertheless, the WORKER_AXP Process shows a UIC = [000,010] when I do a $SHOW PROCESS/ID=pid The restricted access user is listed under the Default Virtual Server and authenicated under the Username : WWWREG, UIC = [300,10] This all works as far as logging in are concerned -- but I was curious why the Worker Process doesn't get the UIC/Access Rights of WWWREG as opposed to the HTTPD Worker ? I thought the authentication against the WWWREG account should enable the appropriate UIC access of WWWREG since it uses the normal SYSUAF authentication. The WWWREG Login.com is executed from the REGPOST.COM script to set the required logicals. I'm sure I'm pretty close in setting this up ... Let me know if you see anything obviously wrong or that I haven't explained adequately. What I want to do is fairly simple and should entail - Logging in - Enterind some data from the web page identifying COURSE and TERM - Producing Roster report for either Display or $MAIL. Thanks, Gary Reynolds greynold@waynesburg.edu ================================================================================ Archive-Date: Mon, 21 May 2001 08:08:38 -0400 Date: Mon, 21 May 2001 12:07:47 +0000 (GMT) From: engelandhv@freemail.nl (H. van Engeland) Subject: Central Disclaimer option for tcpware To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <9eb0ej$gij$1@porthos.nl.uu.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII We use Tcpware 5.3-2 on Openvms 7.2-1. Our clients are windows NT 4.0 with Pegasus 3.11 as e-mail client. Now there's a need for a central Disclaimer text. When using the "disclaimer" option in Pegasus, or any other client software, users can change the text. Is their a option in Tcpware/smtp henk -- _______________________________________________________________________________ ____________ H. van Engeland Network Administrator/Automation Consultant Gastec NV Centre of Gas Technology engelandhv@freemail.nl ================================================================================ Archive-Date: Mon, 21 May 2001 09:37:29 -0400 Date: Mon, 21 May 2001 14:32:53 +0100 From: Peter De La Cour Reply-To: Info-TCPware@process.com Subject: Controlling Spam To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Hi, We are using TCPWare V5.3. We have decided to set up some rules in the SMTP_SERVER_REJECT. file (See below), the aim is to stop our servers being used as a spam relay. However, after creating the file and stopping and restarting STMP, I am still able redirect mail from the server without receiving the "No relaying through this site" message. Do I have to run a utility or create a logical to get TCPWare to recognise the file ?. ! ! This is the Mail Server Reject file for xxyy.com ! ! Disallow relaying through our mailer. ! ! Don't reject mail to postmaster ! * postmaster* n ! ! Allow users on our network ! ! * *@xxyy.com n ! ! Disallow relaying through our Servers ! *@* * *@* y "No relaying through this site" * * *@* y "Missing domain name in Mail Path" Any help is appreciated Regards Peter de la Cour Systems Administrator ************************************************ CONFIDENTIALITY NOTICE The information contained in this e-mail and any attachments to it are for the exclusive use of the intended recipient(s). It may be confidential and contain privileged information and will be protected by copyright. If you are not the intended recipient(s) you must not review, copy, distribute or in any other way use or rely on the information contained in the message. If you have received this e-mail in error, please notify us by e-mail Administrator@itex.je, Tel: +44 1534 633633 or Fax: +44 1534 633644 and then delete all copies from your system. http://www.itex.je http://www.itex.gg ================================================================================ Archive-Date: Mon, 21 May 2001 10:03:44 -0400 Date: Mon, 21 May 2001 09:01:50 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: Re: Controlling Spam In-Reply-To: "Your message dated Mon, 21 May 2001 14:32:53 +0100" To: info-tcpware@process.com Message-ID: <01K3TJBE7RV88WVYKZ@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 > Hi, > We are using TCPWare V5.3. We have decided to set up some rules in the > SMTP_SERVER_REJECT. file (See below), the aim is to stop our servers being > used as a spam relay. However, after creating the file and stopping and > restarting STMP, I am still able redirect mail from the server without > receiving the "No relaying through this site" message. Do I have to run a > utility or create a logical to get TCPWare to recognise the file ?. The SMTP_SERVER_REJECT. file wasn't introduced until TCPware V5.4. If you're really running V5.3, you'll need to upgrade. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Mon, 21 May 2001 16:45:42 -0400 Date: Mon, 21 May 2001 15:44:44 -0500 (CDT) From: Hunter Goatley Reply-To: Info-TCPware@process.com Subject: IPP module now available for download To: tcpware-announce@process.com Message-ID: <01K3TXCOH1YG8WVYKZ@goatley.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Process Software has released the IPP (Internet Printing Protocol) module for TCPware V5.5. It is available via download to all TCPware V5.5 users by requesting from Process Software's Web site at: http://www.process.com/tcpip/ippreq.asp Process Software's IPP print symbiont client provides advanced printing capabilities using the OpenVMS queue management system. With IPP, features such as double-sided printing requires no special programming. Also, unlike LPD if a print job fails, the IPP print symbiont provides reason for this failure -- saving time in troubleshooting. Please see www.pwg.org if you want to know if your printers are IPP compliant or want more information on IPP. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ http://www.goatley.com/hunter/ ================================================================================ Archive-Date: Sat, 26 May 2001 07:01:54 -0400 Date: Sat, 26 May 2001 14:52:26 +0400 From: "Ruslan R. Laishev" Subject: IPP - good. IPP FAX ? To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3B0F8AEA.6F69D2E3@SMTP.DeltaTel.RU> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hello PSC! Is there a plan to port IPP fax ? -- Cheers, Ruslan. +---------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com vms-isps@dls.net - Forum for ISP running OpenVMS Mobile: +7 (901) 971-3222, AIM nickname:"VMS hardworker" ================================================================================ Archive-Date: Tue, 29 May 2001 10:27:45 -0400 Date: Tue, 29 May 2001 10:26:52 -0400 From: Mike Bartman Reply-To: Info-TCPware@process.com Subject: RE: IPP - good. IPP FAX ? To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE86039E7C1B@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Not at this time. -- Mike Bartman Process Software bartman@process.com 301-838-0071 > -----Original Message----- > From: Ruslan R. Laishev [mailto:Laishev@SMTP.DeltaTel.RU] > Sent: Saturday, May 26, 2001 6:52 AM > To: info-tcpware@process.com > Subject: IPP - good. IPP FAX ? > > > Hello PSC! > > Is there a plan to port IPP fax ? > > -- > Cheers, Ruslan. > +---------------pure personal opinion-----------------------+ > RADIUS Server for OpenVMS project - www.radiusvms.com > vms-isps@dls.net - Forum for ISP running OpenVMS > Mobile: +7 (901) 971-3222, AIM nickname:"VMS hardworker" > ================================================================================ Archive-Date: Tue, 29 May 2001 16:01:54 -0400 Date: Tue, 29 May 2001 23:47:50 +0400 From: "Ruslan R. Laishev" Subject: Re: IPP - good. IPP FAX ? To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3B13FCE6.584AC076@SMTP.DeltaTel.RU> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit It's very pity. Mike Bartman wrote: > > Not at this time. > > -- Mike Bartman > Process Software > bartman@process.com > 301-838-0071 > > > -----Original Message----- > > From: Ruslan R. Laishev [mailto:Laishev@SMTP.DeltaTel.RU] > > Sent: Saturday, May 26, 2001 6:52 AM > > To: info-tcpware@process.com > > Subject: IPP - good. IPP FAX ? > > > > > > Hello PSC! > > > > Is there a plan to port IPP fax ? > > > > -- > > Cheers, Ruslan. > > +---------------pure personal opinion-----------------------+ > > RADIUS Server for OpenVMS project - www.radiusvms.com > > vms-isps@dls.net - Forum for ISP running OpenVMS > > Mobile: +7 (901) 971-3222, AIM nickname:"VMS hardworker" > > -- Cheers, Ruslan. +---------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com vms-isps@dls.net - Forum for ISP running OpenVMS Mobile: +7 (901) 971-3222, AIM nickname:"VMS hardworker" ================================================================================ Archive-Date: Wed, 30 May 2001 06:40:55 -0400 Date: Wed, 30 May 2001 14:18:08 +0400 From: "Ruslan R. Laishev" Subject: sho intrusion (TCPWare 5.4-3) To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3B14C8E0.F969BF1E@SMTP.DeltaTel.RU> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Hi ! Is there any sence to assume follows records as different? Who form these records: loginout ? $ sho int Intrusion Type Count Expiration Source --------- ---- ----- ---------- ------ TERM_USER SUSPECT 2 30-MAY-2001 14:20:05.82 172.16.4.251,1501:yy_xxx TERM_USER SUSPECT 2 30-MAY-2001 14:19:22.83 172.16.4.251,1486:yy_xxx TERM_USER SUSPECT 2 30-MAY-2001 14:16:47.71 172.16.4.251,1397:yy_xxx TERM_USER SUSPECT 3 30-MAY-2001 14:21:05.86 172.16.4.251,1368:yy_xxx TERM_USER SUSPECT 3 30-MAY-2001 14:19:13.31 172.16.4.251,1205:yy_xxx -- Cheers, +OpenVMS [Sys|Net] HardWorker........................................+ Russia,Delta Telecom Inc, Cel: +7 (901) 971-3222 191119,St.Petersburg,Transportny per. 3 116-3222 +http://www.levitte.org/~rlaishev/ .......... SysMan rides HailStorm + ================================================================================ Archive-Date: Wed, 30 May 2001 08:47:10 -0400 Date: Wed, 30 May 2001 08:43:36 -0400 From: Beaudoin.Jean-Marc@hydro.qc.ca Reply-To: Info-TCPware@process.com Subject: Moving logfiles out of the Multinet or TCPWare default directorie s To: info-tcpware@process.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E906.24AD32E0" 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_01C0E906.24AD32E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good day, Situation: We are in the process of setting standards on all our vms platforms.=20 One of the goad to achieve is to centralize all logfiles for all products on each alpha or vax servers in a common directory pointed by a standardized system logical name. Question: With either TCPWare and Multinet how can I make sure that logfiles are located in the common location? Regards, Jean-Marc Beaudoin Conseiller Expertise en S=E9curit=E9 des T.I.=20 Direction Planification et Mise en place des infrastructures = technologiques=20 Hydro-Qu=E9bec=20 * 500, boul. Ren=E9-L=E9vesque ouest, 20e =E9tage Montr=E9al, Qc =20 H3C 3A7 * Courriel : Beaudoin.Jean-Marc@hydro.qc.ca * (514) 289-2211, poste 7161 Fax: (514) 289-6285 ------_=_NextPart_001_01C0E906.24AD32E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Moving logfiles out of the Multinet or TCPWare default = directories

Good day,

Situation:      We are in the = process of setting standards on all our vms platforms.
        =         One of the goad to achieve is to centralize all logfiles = for all products
        =         on each alpha or vax servers in a common directory = pointed by a
        =         standardized system logical name.

Question:       With = either TCPWare and Multinet how can I make sure that logfiles
        =         are located in the common location?

Regards,

Jean-Marc = Beaudoin
Conseiller Expertise en = S=E9curit=E9 des T.I.
Direction Planification et Mise en place des infrastructures = technologiques
Hydro-Qu=E9bec
+ 500, boul. = Ren=E9-L=E9vesque ouest, 20e =E9tage
     = Montr=E9al, Qc   
     H3C = 3A7
: Courriel : Beaudoin.Jean-Marc@hydro.qc.ca
(  (514) 289-2211, = poste 7161
Fax: (514) = 289-6285

------_=_NextPart_001_01C0E906.24AD32E0-- ================================================================================ Archive-Date: Thu, 31 May 2001 11:29:29 -0400 Date: Thu, 31 May 2001 10:14:47 -0500 From: "David J. Dachtera" Subject: Re: Moving logfiles out of the Multinet or TCPWare default directorie s To: info-tcpware@process.com Reply-To: Info-TCPware@process.com Message-ID: <3B165FE7.DDDF82F3@fsi.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Beaudoin.Jean-Marc@hydro.qc.ca wrote: > > Good day, > > Situation: We are in the process of setting standards on all our > vms platforms. > One of the goad to achieve is to centralize all > logfiles for all products > on each alpha or vax servers in a common directory > pointed by a > standardized system logical name. > > Question: With either TCPWare and Multinet how can I make sure > that logfiles > are located in the common location? Strictly my opinion, but you may want to re-think that strategy. How can you guarantee that no two facilities will ever produce .LOG files with same name/extension? -- David J. Dachtera dba DJE Systems http://www.djesys.com/ Unofficial Affordable OpenVMS Home Page and Message Board: http://www.djesys.com/vms/soho/ This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings is to be expected. Feel free to exercise your rights of free speech and expression. However, attacks against individual posters, or groups of posters, are strongly discouraged. ================================================================================ Archive-Date: Thu, 31 May 2001 11:48:13 -0400 Date: Thu, 31 May 2001 11:47:32 -0400 From: Mike Bartman Reply-To: Info-TCPware@process.com Subject: RE: Moving logfiles out of the Multinet or TCPWare default direct orie s To: "'info-tcpware@process.com'" Message-ID: <63D30D6E10CFD11190A90000F805FE86039E7C27@lespaul.process.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 More than that, how can you guarantee that every application you ever use will have a way to put the log file where you want it? I've used things in the past where the logfile name is hardcoded and can't be changed. In my experience an *almost* standardized system is worse than one that has no standards. At least in the second case you don't have any expectations to be misled. :^) -- Mike Bartman Process Software bartman@process.com 301-838-0071 > -----Original Message----- > From: David J. Dachtera [mailto:djesys.nospam@fsi.net] > Sent: Thursday, May 31, 2001 11:15 AM > To: info-tcpware@process.com > Subject: Re: Moving logfiles out of the Multinet or TCPWare default > directorie s > > > > Beaudoin.Jean-Marc@hydro.qc.ca wrote: > > > > Good day, > > > > Situation: We are in the process of setting standards > on all our > > vms platforms. > > One of the goad to achieve is to centralize all > > logfiles for all products > > on each alpha or vax servers in a common directory > > pointed by a > > standardized system logical name. > > > > Question: With either TCPWare and Multinet how can I make sure > > that logfiles > > are located in the common location? > > Strictly my opinion, but you may want to re-think that strategy. > > How can you guarantee that no two facilities will ever produce .LOG > files with same name/extension? > > -- > David J. Dachtera > dba DJE Systems > http://www.djesys.com/ > > Unofficial Affordable OpenVMS Home Page and Message Board: > http://www.djesys.com/vms/soho/ > > This *IS* an OpenVMS-related newsgroup. So, a certain bias in postings > is to be expected. > > Feel free to exercise your rights of free speech and expression. > > However, attacks against individual posters, or groups of posters, are > strongly discouraged. >