Archive-Date: Sat, 17 Sep 2005 13:00:14 -0400 Resent-Date: Sat, 17 Sep 2005 12:58:53 -0400 Date: Sat, 17 Sep 2005 14:50:04 +0100 Resent-From: Geoff Bryant From: Tom Garcia Reply-To: Info-TCPware@process.com Subject: ms services for unix 3.5 uid/gid mapping Resent-To: info-tcpware@process.com To: info-tcpware@process.com Resent-Message-ID: <01LT4ZYYPA028WXFSP@PROCESS.COM> Message-ID: <5uGdnTHNR_-UgrHeRVnyjA@eclipse.net.uk> Using TCPware 5.6-2 under OpenVMS 7.3 for VAX (vax-host) and Microsoft Services for Unix 3.5 under Windows XP SP2 (pc-host). I have ADD PROXY TGARCIA/UID=201/GID=200 then RELOAD PROXY. A login of the form: c:\sfu\common\mount -o pcnfs=pcnfs-host vax-host:/users/tgarcia -u:tgarcia z: where for pcnfs-host (the host which is instructed to be used for pcnfs authentication) I try both: - vax-host, running the TCPware pcnfs authentication server; - pc-host, using Server for PCNFS which I have set up to specifically map the username "tgarcia" to uid=200,gid=201. In TCPWARE:NFS_V3_SERVER.LOG I get: %%%%%%%%%%%% NFSD 17-SEP-2005 13:39:14.68 %%%%%%%%%%%% %MOUNT-E-NOTPXY, no PROXY entry for user uid 0, gid 3 on worker (pc-host ip) %MOUNT-I-NOTMNT, path /users/tgarcia not mounted for uid 0, gid 3 on worker (pc-host ip) --- note specifically uid **0** and gid **3**. I can confirm the TCPware pcnfs authentication server is correctly sending back the uid/gid combination: NETCU> tcpdump /rpc=udp udp Tcpdump: listening on IPA0: snip 14:15:24.880000 912 > 2049:pc-host.f95dbdc > vax-host.PCNFS: udp NULL() 14:15:24.880000 2049 > 912:vax-host.PCNFS > pc-host.f95dbdc: udp NULL = OK 14:15:24.880000 912 > 2049:pc-host.f95dbdd > vax-host.PCNFS: udp PCNFSD2_AUTH(Client="pc-host",User="tgarcia",Password="") 14:15:24.990000 2049 > 912:vax-host.PCNFS > pc-host.f95dbdd: udp PCNFSD_AUTH = OK, Uid 201, Gid 200 but it does not seem to decode further packets so I'm unsure what's going on after that -- ie is the MS client not sending this uid/gid back to TCPware, or is TCPware being sent it but ignoring it? Anyone else had similar problems? Separate thing, re-asking since I just realised people on the TCPware list don't get messages with invalid domain names: Is BIND 8.2 or later (ie with TSIG, etc.) coming out in TCPware 5.7 or soon after? Thanks, -- Tom | tgarcia@hivemind.NOSPAM.org ================================================================================ Archive-Date: Sun, 18 Sep 2005 21:18:19 -0400 Date: Sun, 18 Sep 2005 21:16:51 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: ms services for unix 3.5 uid/gid mapping In-Reply-To: <5uGdnTHNR_-UgrHeRVnyjA@eclipse.net.uk> To: info-tcpware@process.com Message-ID: <432E1183.5080706@process.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <5uGdnTHNR_-UgrHeRVnyjA@eclipse.net.uk> Tom Garcia wrote: > Using TCPware 5.6-2 under OpenVMS 7.3 for VAX (vax-host) and Microsoft > Services for Unix 3.5 under Windows XP SP2 (pc-host). > > I have ADD PROXY TGARCIA/UID=201/GID=200 then RELOAD PROXY. > > A login of the form: > > c:\sfu\common\mount -o pcnfs=pcnfs-host vax-host:/users/tgarcia -u:tgarcia > z: > > where for pcnfs-host (the host which is instructed to be used for pcnfs > authentication) I try both: > - vax-host, running the TCPware pcnfs authentication server; > - pc-host, using Server for PCNFS which I have set up to specifically map > the username "tgarcia" to uid=200,gid=201. > > In TCPWARE:NFS_V3_SERVER.LOG I get: > > %%%%%%%%%%%% NFSD 17-SEP-2005 13:39:14.68 %%%%%%%%%%%% > %MOUNT-E-NOTPXY, no PROXY entry for user uid 0, gid 3 on worker (pc-host ip) > %MOUNT-I-NOTMNT, path /users/tgarcia not mounted for uid 0, gid 3 on worker > (pc-host ip) > > --- note specifically uid **0** and gid **3**. > > I can confirm the TCPware pcnfs authentication server is correctly sending > back the uid/gid combination: > > NETCU> tcpdump /rpc=udp udp > Tcpdump: listening on IPA0: > snip > 14:15:24.880000 912 > 2049:pc-host.f95dbdc > vax-host.PCNFS: udp NULL() > 14:15:24.880000 2049 > 912:vax-host.PCNFS > pc-host.f95dbdc: udp NULL = OK > 14:15:24.880000 912 > 2049:pc-host.f95dbdd > vax-host.PCNFS: udp > PCNFSD2_AUTH(Client="pc-host",User="tgarcia",Password="") > 14:15:24.990000 2049 > 912:vax-host.PCNFS > pc-host.f95dbdd: udp > PCNFSD_AUTH = OK, Uid 201, Gid 200 > > but it does not seem to decode further packets so I'm unsure what's going on > after that -- ie is the MS client not sending this uid/gid back to TCPware, > or is TCPware being sent it but ignoring it? Anyone else had similar > problems? Hi Tom, Try a different TCPDUMP. Try capturing all traffic from the client - $ netcu tcpdump/snap=1600/rpc=all host regards Mike ================================================================================ Archive-Date: Mon, 19 Sep 2005 06:41:50 -0400 Resent-Date: Mon, 19 Sep 2005 06:40:26 -0400 Date: Mon, 19 Sep 2005 11:03:58 +0100 Resent-From: Geoff Bryant From: Tom Garcia Reply-To: Info-TCPware@process.com Subject: Re: ms services for unix 3.5 uid/gid mapping Resent-To: info-tcpware@process.com To: info-tcpware@process.com Resent-Message-ID: <01LT7FCHRKUK8WXFSP@PROCESS.COM> Message-ID: <3Y2dnSEV6KaXELPeRVnygg@eclipse.net.uk> "Michael Corbett" wrote in message news:432E1183.5080706@process.com... > Tom Garcia wrote: >> Using TCPware 5.6-2 under OpenVMS 7.3 for VAX (vax-host) and Microsoft >> Services for Unix 3.5 under Windows XP SP2 (pc-host). snip >> --- note specifically uid **0** and gid **3**. >> >> I can confirm the TCPware pcnfs authentication server is correctly >> sending back the uid/gid combination: snip >> but it does not seem to decode further packets so I'm unsure what's going >> on after that -- ie is the MS client not sending this uid/gid back to >> TCPware, or is TCPware being sent it but ignoring it? Anyone else had >> similar problems? snip > Try a different TCPDUMP. Try capturing all traffic from the > client - > > $ netcu tcpdump/snap=1600/rpc=all host Thanks for your response. I entered: $ set def web:[stuff] $ netcu tcpdump/snap=1600/rpc=all/output="tcppcnfs.log" -"X" (bit of munging to clarify hostnames, etc. - worker is pc-host where it appears in the decoding) giving http://queen.hivemind.org/stuff/tcppcnfs.log , where during the logging I executed the mount attempt twice, each time receiving: --- >c:\sfu\common\mount -o pcnfs=vax-host vax-host:/users/tgarcia -u:tgarcia z: Password: Network Error - 53 Type 'NET HELPMSG 53' for more information. >net helpmsg 53 The network path was not found. --- and same messages relating to uid 0, gid 3 as before in tcpware nfsd log. (SFU is just the current downloadable install at http://www.microsoft.com/windowsserversystem/sfu/downloads/default.mspx - the Windows mapper service's .maphosts file has a single + to allow all hosts, and I have *also* set up an appropriate static map there, though I'm pretty certain the mount command above overrides that as it's explicitly instructing use of the vax-host pcnfs server.) Cheers, -- Tom | tgarcia@hivemind.no-spam-please.org ================================================================================ Archive-Date: Mon, 19 Sep 2005 16:52:47 -0400 Date: Mon, 19 Sep 2005 16:53:57 -0400 From: Michael Corbett Reply-To: Info-TCPware@process.com Subject: Re: ms services for unix 3.5 uid/gid mapping In-Reply-To: <3Y2dnSEV6KaXELPeRVnygg@eclipse.net.uk> To: info-tcpware@process.com Message-ID: <432F2565.7040804@process.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <3Y2dnSEV6KaXELPeRVnygg@eclipse.net.uk> Tom Garcia wrote: > > > Thanks for your response. I entered: > > $ set def web:[stuff] > $ netcu tcpdump/snap=1600/rpc=all/output="tcppcnfs.log" -"X" > (bit of munging to clarify hostnames, etc. - worker is pc-host where it > appears in the decoding) > > giving http://queen.hivemind.org/stuff/tcppcnfs.log , where during the > logging I executed the mount attempt twice, each time receiving: > > --- > >>c:\sfu\common\mount -o pcnfs=vax-host vax-host:/users/tgarcia -u:tgarcia z: > > Password: > Network Error - 53 > > Type 'NET HELPMSG 53' for more information. > > >>net helpmsg 53 > > > The network path was not found. > --- > > and same messages relating to uid 0, gid 3 as before in tcpware nfsd log. > > (SFU is just the current downloadable install at > http://www.microsoft.com/windowsserversystem/sfu/downloads/default.mspx - > the Windows mapper service's .maphosts file has a single + to allow all > hosts, and I have *also* set up an appropriate static map there, though I'm > pretty certain the mount command above overrides that as it's explicitly > instructing use of the vax-host pcnfs server.) > TCPDUMP did not decode some of the udp packets. I'm not sure why. I installed SFU here and see the same problem with TCPDUMP. I was able to use SFU to mount up a TCPware export. My guess is that the global NFS security setting or the settings on your export are preventing the mount. Check the nfsserver.log or nfs_v3_server.log for any errors that might indicate what the problem is. The client might be sending the mount command with a UID of 0 so you might have to add the export with the /NOPROXY_CHECK or add a proxy for UID 0. regards Mike -- +-------------------------------------------------------------------------+ Michael Corbett Email: Corbett@process.com Process Software Phone: 800 722-7770 x369 959 Concord St. 508 879-6994 x369 Framingham MA 01701-4682 FAX: 508 879-0042 ================================================================================ Archive-Date: Mon, 19 Sep 2005 19:17:33 -0400 Date: Tue, 20 Sep 2005 00:03:27 +0100 From: Tom Garcia Reply-To: Info-TCPware@process.com Subject: Re: ms services for unix 3.5 uid/gid mapping To: info-tcpware@process.com Message-ID: Hi, "Michael Corbett" wrote in message news:432F2565.7040804@process.com... > I was able to use SFU to mount up a TCPware export. My guess is that > the global NFS security setting or the settings on your export are > preventing the mount. Yes, PROXY_CHECK on (intentionally - otherwise a mount will certainly happen): NETCU> sh export/ful NFS EXPORT Database V5.6-2 Copyright (c) 2002 Process Software Path Directory Host(s) ---- --------- ------- /users/tgarcia SYS$SYSDEVICE:[USERS.TGARCIA] WORKER.HIVEMIND.ORG /VERSION=SEMICOLON /CONVERT=STREAM_LF /FILENAME=SRI /PROXY_CHECK /RFM=STREAM_LF I tried adding a GUEST user as follows, assuming that the SFU NFS client was trying to do something as guest before using the proper uid=201/gid=200 (actually, I *know* it was, from the nfs server log entry in my original posting, though it still seemed to try to mount thereafter using the uid=3/gid=0 credentials): NETCU> sh proxy NFS PROXY Database V5.6-2 Copyright (c) 2002 Process Software Username UID GID Host(s) -------- --- --- ------- GUEST -2 -2 WORKER.HIVEMIND.ORG TGARCIA 201 200 WORKER.HIVEMIND.ORG Now I get successful mounts using the same command as before, the nfs_v3_server.log giving: %%%%%%%%%%%% NFSD 19-SEP-2005 22:48:20.62 %%%%%%%%%%%% %MOUNT-I-MOUNTED, path /users/tgarcia mounted by uid 0, gid 3 on worker ...which confuses me *more* now, because uid 0/gid 3 is not in the proxy database, and I have PROXY_CHECK on. I'm pretty sure it is not using the default GUEST (-2/-2) either (SH MOUNT doesn't show this info, alas), because I appear to have access to [USERS.TGARCIA] as if user TGARCIA -- a file without group/world read permission owned by SYSTEM or GUEST is inaccessible, but SET SEC/OWNER=TGARCIA renders it readable. If delete the proxy entry TGARCIA, mounts fail (well, actually, they claim to succeed, but I can't then access the mount). Or, I may be fundamentally misunderstanding the log or something about nfs, which is not impossible! Thanks again and regards, -- Tom ================================================================================ Archive-Date: Tue, 27 Sep 2005 17:00:07 -0400 Date: Tue, 27 Sep 2005 15:38:12 -0500 (EST) From: bryant@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: DRIVERS_V562P052 To: TCPware-Announce@TRITON.PROCESS.COM Message-ID: <01LTJ4H5RO9E00G6EK@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: DRIVERS_V562P052 Description: Support new kerberos v5 kit from HP Release date: 27-SEP-2005 Ranking: 3 Max ranking: 3 Versions: 5.6-2 Requisites: ftp://ftp.process.com/support/56_2/drivers_v562p052.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. ----------------------------------------------------------- DRIVERS patch kit revision 5.2 for TCPware Version 5.6-2 14-Sep-2005 Copyright (c) 2002-2005 Process Software, LLC Highest ECO Rank 0 (Version 2.0) Version 5.2 Rank 3 - Corrects a specific problem ********************* PLEASE NOTE ******************************* Support for Kerberos 5 requires the HP Kerberos V5 for OpenVMS Release 2.0 or later. TCPware support for Kerberos 5 is restricted to the platforms and VMS versions supported by the HP kit. Though Kerberos 5 now runs on TCPware, it is not currently supported for TELNET on VAX due to some missing entry points in the current images from HP. DRIVERS_V562P030 (or later) must be installed prior to configuring the HP Kerberos product. Once this ECO has been applied, Kerberos may be installed and configured. For OpenVMS VAX the following logicals must be defined: $ DEFINE/SYSTEM TCPIP$ACCESS_SHR TCPWARE:UCX$ACCESS_SHR $ DEFINE/SYSTEM UCX$ACCESS_SHR TCPWARE:UCX$ACCESS_SHR For more details, see the product information page at: http://h71000.www7.hp.com/openvms/products/kerberos ***************************************************************** This patch kit provides new versions of the following drivers for TCPware Version 5.6-2: DRIVERS_V562P052 - ECO rank: 3 - Corrects a specific problem ------------------ UCX$IPC_SHR - Update the GSMATCH value for OpenVMS for Alpha V7 to support the Kerberos V2.1-72 kit from HP. This kit also includes the following changes from previous ECO kits: DRIVERS_V562P050 - ECO rank: 3 - Corrects a specific problem ------------------ UCX$IPC_SHR - Update the entry points for VAX to match TCP/IP Services to support Kerberos V5 kits from HP. (DE 9109) Modification to getnameinfo to allow Python to work (DE 9591) UCX$ACCESS_SHR - Provide image to support VAX Kerberos V5 kits from STARTNET.COM HP. (DE 9109) SHUTNET.COM TCPDRIVER - Correct status returned on end of file to resolve problems with SWS 2.0 (Apache) and cgi (DE 9645) DRIVERS_V562P040 - ECO rank: 3 - Corrects a specific problem ------------------ BGDRIVER - Add support for ioctl calls for SIOCGIFINDEX INETDRIVER SIOCGIFNUM, and NSIOCGIFCONF which are required IPDRIVER for java v1.4.0 or later. (D/E 8939) TCPDRIVER UDPDRIVER UCX$IPC_SHR - Add support for getaddrinfo and getnameinfo routines required by DECwindows. (D/E 9087) DRIVERS_V562P030 - ECO rank: 3 - Corrects a specific problem ------------------ UCX$IPC_SHR - Entry points have been added to support Kerberos V5 release 2 on OpenVMS for Alpha V7.2-2 and later. (D/E 8986) NTDRIVER - Allows TELNETD_FLAGS to have bit 2 set (OR with 4) causing NT devices to not be marked mounted/foreign. This causes problems for some customer applications, but setting this bit will restore the problem reported in DE 1095 whereby if a user enables the terminal as an operator terminal, but doesn't specify it as temporary, another user may later telnet into the system and be using an operator terminal. (D/E 8745) DRIVERS_V562P020 - ECO rank: 0 - Mandatory for AXP V7 systems ------------------ BGDRIVER - A defect was present in an error path that would cause a system crash in 64-bit environments. (D/E 8746) DRIVERS_V562P010 - ECO rank: 3 ------------------ UCX$IPC_SHR - BSD 4.4 entry points have been added for OpenVMS Alpha V7.1 and later. This allows code compiled for these entry points to run. An example is Mozilla. (D/E 8245) NOTE: You must reboot your system after installing this patch in order to load the new driver(s). The old versions of the driver(s) will be renamed to *.EXE_OLD. Once installed, you may undo this patch by renaming the file(s) back to: TCPWARE_COMMON:[TCPWARE]UCX$IPC_SHR.EXE_OLD to TCPWARE_COMMON:[TCPWARE]UCX$IPC_SHR.EXE TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]BGDRIVER.EXE TCPWARE_COMMON:[TCPWARE]INETDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]INETDRIVER.EXE TCPWARE_COMMON:[TCPWARE]TCPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]TCPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]UDPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]UDPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]IPDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]IPDRIVER.EXE TCPWARE_COMMON:[TCPWARE]NTDRIVER.EXE_OLD to TCPWARE_COMMON:[TCPWARE]NTDRIVER.EXE TCPWARE_COMMON:[TCPWARE]STARTNET.COM_OLD to TCPWARE_COMMON:[TCPWARE]STARTNET.COM TCPWARE_COMMON:[TCPWARE]SHUTNET.COM_OLD to TCPWARE_COMMON:[TCPWARE]SHUTNET.COM Delete TCPWARE_COMMON:[TCPWARE]UCX$ACCESS_SHR.EXE [End of ECO announcement] ================================================================================ Archive-Date: Tue, 27 Sep 2005 17:00:38 -0400 Date: Tue, 27 Sep 2005 15:38:45 -0500 (EST) From: bryant@process.com Reply-To: Info-TCPware@process.com Subject: TCPware ECO kit available: SSH_V562P070 To: TCPware-Announce@TRITON.PROCESS.COM Message-ID: <01LTJ4HUMIRM00G6EK@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: SSH_V562P070 Description: Assorted fixes and support for new Kerberos V5 kit from HP Release date: 27-SEP-2005 Ranking: 3 Max ranking: 2 Versions: 5.6-2 Requisites: DRIVERS_V562P052 ftp://ftp.process.com/support/56_2/ssh_v562p070.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. ----------------------------------------------------------- ----------------------------------------------------------------------- SSH patch kit (revision 7.0) for TCPware 5.6 26-Sep-2005 Copyright (c) 2002-2005 by Process Software This VMSinstallable saveset provides a new version of the following SSH components: - SSH client (SSH2.EXE) - SSH1 server (SSHD.EXE) - SSH2 server (SSHD2.EXE) - SSH master control program (SSHD_MASTER.EXE) - SSH identity agent program (SSH-AGENT2.EXE) - SSH key generators (SSH-KEYGEN.EXE and SSH-KEYGEN2.EXE) - SSH key signer (SSH-SIGNER2.EXE) - SSH loadable executive image (SSHLEI.EXE, LOAD_SSHLEI.EXE, UNLOAD_SSHLEI.EXE) - SSH agent identity manipulation program (SSH-ADD2.EXE) - SSH file copy client (SCP2.EXE) - SSH SFTP client (SFTP2.EXE) - SSH file copy servers (SFTP-SERVER2.EXE and SCP-SERVER1.EXE) - SSH certificate enrollment program (SSH-CERTENROLL2.EXE) - SSH server configuration template file (SSHD2_CONFIG.TEMPLATE) - SSH configuration procedure (SSH_CONTROL.COM) - The SSH HELP (either in a standalone library or as part of SYS$HELP:HELPLIB.HLB, as determined by the original TCPware install) - SSH Public Key Assistant (PUBLICKEY_ASSISTANT.EXE) - SSH Public Key Server (PUBLICKEY-SERVER.EXE) - SSH Certificate Viewer (SSH-CERTVIEW.EXE) - SSH client configuration template (SSH2_CONFIG.TEMPLATE) A new version of the following common TCPware utilities are provided: - NETCU utility (NETCU.EXE) - TCPware command definitions (TCPWARE_COMMANDS.COM and TCPware.CLD) This patch is applicable to TCPware SSH on all supported versions of OpenVMS VAX and OpenVMS Alpha. NOTE: The TCPware ECO DRIVERS_V562P052 or later is required and must be installed in order to run SSH after installing the SSH_V562P070 ECO. A system reboot is requred after installing this ECO, to load the new software features. This ECO has a ranking of 2 - Recommended; individual component may fail. *** Notes for Kerberos 5 Support *** Support for Kerberos 5 is based on HP Kerberos V5 for OpenVMS. Prior to installing and configuring the HP Kerberos product, the following TCPware ECO must be installed: - DRIVERS_V562P052 or later Once the above ECO has been applied, Kerberos may be installed and configured. SSH may be configured and used at any time, either with or without Kerberos; however, Kerberos is required to perform Kerberos authentication in the SSH server. If Kerberos is installed at some later time after SSH is started, restarting SSH will allow it to use Kerberos. Some chapters of the TCPware documentation having to do with SSH have been updated. New PDF files of these are supplied in this ECO, and are copied to the TCPWARE_COMMON:[TCPWARE] directory. These are: TW_MANAGEMENT_SSH1_SERVER_CH25.PDF TW_MANAGEMENT_SSH2_SERVER_CH26.PDF TW_USER_GUIDE_SSH_CLIENT_CH16.PDF TW_USER_GUIDE_FILE_XFER_CH17.PDF This ECO kit provides fixes for the following DE's: - When the HP Kerberos V2.1-72 kit is installed on AXP systems, SSH and ktelnet stopped working, and the various Kerberos components (e.g., kadmin) would encounter SYSTEM-F-SHRIDMISMAT errors regarding the TCPIP$IPC_SHR (UCX$IPC_SHR) image. [DE 10099] - Since installing SSH_V562P060 the AllowGroups keyword in SSHD2_CONFIG no longer works. [DE 10077] - Since installing SSH_V562P060 the SSH2 server doesn't handle expired passwords for captive accounts properly. [DE 10121] - When attempting to use the /OPENSSH_CONVERT qualifier with SSHKEYGEN, the error message: option requires an argument -- w is returned. [DE 10073] - Correct an ACCVIO that can occur when using SFTP2 with /BATCHFILE. Observe the /NOPROGRESS qualifier. [DE 10092] - Correct a problem that can cause some files to be truncated when copying. [DE 10090] - Correct problems with transferring files greater than 4GB on OpenVMS Alpha V7. [DE 9866] - Correct an error that caused support for the ftruncate operation to be absent from the code. [DE 10102] --------------------------------------------------------------------------- Post Installation Notes If you have NOT previously installed a TCPware 5.6 SSH patch kit, or are not sure if one was previously installed, you must perform the following procedure: - Save your old SSH2_DIR:SSHD2_CONFIG. file and create a new one from the new TCPWARE:SSHD2_CONFIG.TEMPLATE file: $ COPY SSH2_DIR:SSHD2_CONFIG. SSH2_DIR:SSHD2_CONFIG.OLD $ COPY TCPWARE:SSHD2_CONFIG.TEMPLATE SSH2_DIR:SSHD2_CONFIG. - If you previously customized your SSH2_DIR:SSHD2_CONFIG file (now renamed to ".OLD"), you must edit the new SSH2_DIR:SSHD2_CONFIG file and add your customizations to it. You MUST use the new file created from the new TCPWARE:SSHD2_CONFIG.TEMPLATE file for this. - Note that if you are in a clustered environment with a shared system disk, you must copy the TCPWARE:SSHD2_CONFIG.TEMPLATE from the node where the ECO was initially installed to the SSH2_DIR: directory on each of the other nodes in the cluster before making the new SSHD2_CONFIG file and making any changes as noted above. The old version of the replaced SSH components will be renamed to TCPWARE_COMMON:[TCPWARE]SSH2.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSHD.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSHD2.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSHD_MASTER.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSH-ADD2.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSH-AGENT2.EXE_OLD TCPWARE_COMMON:[TCPWARE]SCP2.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSH-KEYGEN.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSH-KEYGEN2.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSH-SIGNER2.EXE_OLD TCPWARE_COMMON:[TCPWARE]SCP-SERVER1.EXE_OLD TCPWARE_COMMON:[TCPWARE]SFTP-SERVER2.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSHD2_CONFIG.TEMPLATE_OLD TCPWARE_COMMON:[TCPWARE]SSHLEI.EXE_OLD TCPWARE_COMMON:[TCPWARE]LOAD_SSHLEI.EXE_OLD TCPWARE_COMMON:[TCPWARE]UNLOAD_SSHLEI.EXE_OLD TCPWARE_COMMON:[TCPWARE]NETCU.EXE_OLD TCPWARE_COMMON:[TCPWARE]SSH_CONTROL.COM_OLD TCPWARE_COMMON:[TCPWARE]TCPWARE_COMMANDS.COM_OLD Once installed, you may undo this patch by renaming the files back to their original names, and restarting the SSH component. NOTE: You must reboot your system after installing this ECO, to load the new software features. [End of ECO announcement]