$!-----------------------------------------------------------------'f$verify(0) $! SECURE_PRE81_INFO.COM $! $! Provide a set of pages of description about the changes performed during $! the pre version 8.1 site conversion. Give choice to continue. $! $! 07-NOV-2009 MGD disable for WASD v10 $! 01-NOV-2002 MGD v1.0, initial $!----------------------------------------------------------------------------- $! $ type sys$input ***************************************** * NOT INTENDED FOR WASD V10 OR LATER * ***************************************** If "upgrading" from pre-v8.1 then start from scratch and perform a completely fresh installation! $ exit 44 $! $ if f$trnlnm("INSTALL$DBUG") .nes. "" then set verify $ ss$_abort = 44 $ ss$_bugcheck = 676 $ say = "write sys$output" $ on controly then exit ss$_abort $! $ if f$environment("depth") .eq. 1 then say "" $! $ type sys$input ************************************************* * P L E A S E R E A D C A R E F U L L Y * ************************************************* When converting a pre-v8.0.1 site ... After performing this update you may find you no longer have Web access to some files and directories you did previously. This will probably only be of nuisance value and is well offset by the increase in site security. These procedures do an extensive job of converting an existing site to the new structure and file settings, even to the point of optionally copying the existing scripting environment and modifying for the new structure. However (there's always at least one 'however', isn't there?) the site's document structure and scripting environment NEEDS TO BE THORUGHLY CHECKED and most probably some fine tuning applied. There are also configuration recommendations in the WASD Technical Overview section "Securing the Site" that should be considered. $! $ response = "YES" $ read sys$command response /prompt="Read more? [YES]: " $ say "" $ if response .eqs. "" then response = "YES" $ if .not. response then exit ss$_abort $! $ type sys$input "REFRESHING" A V8.1 OR LATER SITE --------------------------------- The [INSTALL]SECURE.COM procedure may be used to "reset" a WASD site's structure back to recommended directory and file permissions. This can be done just to restore confidence in the installation or if an additional requirement becomes known and later needs to be applied. It is advised that site capabilities (especially scripting) are always thoroughly checked after applying this tool. $ response = "YES" $ read sys$command response /prompt="Read more? [YES]: " $ say "" $ if response .eqs. "" then response = "YES" $ if .not. response then exit ss$_abort $! $ type sys$input SERVER STARTUP PROCEDURES ------------------------- After these changes have been made startup DCL procedures, that may have been in the [LOCAL] directory, will be found in the [STARTUP] directory. File system security will have been set to allow the server account sufficient access to start and operate. Site startup procedures that used @HT_ROOT:[LOCAL]STARTUP.COM may need to be modified to specify @HT_ROOT:[STARTUP]STARTUP.COM. This is the file's new permanent location. $ response = "YES" $ read sys$command response /prompt="Read more? [YES]: " $ say "" $ if response .eqs. "" then response = "YES" $ if .not. response then exit ss$_abort $! $ type sys$input SERVER CONFIGURATION FILES -------------------------- The directory [LOCAL] should contain only configuration files (.CONF) and the like. The security on this directory and it's contents is set to SYSTEM ownership and access only. The server image enables SYSPRV to access it's own configuration files so this is not an issue. Other scripts or Web applications that have had files in this directory may not now be able access them and such files may need to be relocated to somewhere the scripting account has access. $ response = "YES" $ read sys$command response /prompt="Read more? [YES]: " $ say "" $ if response .eqs. "" then response = "YES" $ if .not. response then exit ss$_abort $! $ type sys$input SERVER ACCESS AND PROCESS LOGS ------------------------------ The server creates new and opens existing access log files by enabling SYSPRV. The server account must have write access for LOGINOUT to create the process log. Traditionally the process log has been placed in a subdirectory of the access log directory. To allow protection on the parent directory to be increased server process logs have been relocated. A new directory [LOG_SERVER] exists with requisite security settings to allow the server account write access for it's process (SYS$OUTPUT) logs. This required a change to the definition of logical name HT_SERVER_LOGS. With security on the access log [LOG] directory now increased scripts and Web applications that were used to process log files may now fail. Logs may now need to be moved/copied from [LOG] to some other accessable area before such processing can be done. $ response = "YES" $ read sys$command response /prompt="Read more? [YES]: " $ say "" $ if response .eqs. "" then response = "YES" $ if .not. response then exit ss$_abort $! $ type sys$input SERVER AND SCRIPTING ACCOUNTS ----------------------------- The account the server process executes within requires minimal privileges and access restricted to network (and sometimes batch) activities. It should be flagged as restricted so as to limit potential changes to the CLI environment. It is STRONGLY recommended to execute scripts in an account distinct from the server account. This minimised the risk of unintentional or malicious interactions. WASD v8.1 and later uses TWO accounts to support it's operation. $ response = "YES" $ read sys$command response /prompt="Read more? [YES]: " $ say "" $ if response .eqs. "" then response = "YES" $ if .not. response then exit ss$_abort $! $ type sys$input SCRIPT EXECUTABLES AND SIMILAR FILES ------------------------------------ These procedures can optionally copy script files from the existing [AXP]/[VAX] and [SCRIPT] and [SCRIPT_LOCAL] directories to the new structure. [AXP-BIN] Alpha executables [CGI-BIN] architecture neutral files (DCL procedures, Perl scripts, etc.) [VAX-BIN] VAX executables CGI-BIN:[000000] defined as [CGI-BIN.],[AXP-BIN.]/[VAX-BIN.] The disadvantage of this approach is it retains ALL the current scripting environment. This is not necessarily best-practice in Web server security however. It is better to install only the scripts you require, not everything available. You will be given an option during procedure execution. It also changes directory ownership and protections on [AXP], [VAX], [SCRIPT], [SCRIPT_LOCAL] directories to restrict access to the server account which means NO SCRIPTING UNTIL required files are copied to the new structure. $ response = "YES" $ read sys$command response /prompt="Read more? [YES]: " $ say "" $ if response .eqs. "" then response = "YES" $ if .not. response then exit ss$_abort $! $ type sys$input ********************* * C A U T I O N * ********************* WASD VMS Web Services, Copyright (C) 1996-2017 Mark G.Daniel. This package (all associated programs), comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under the conditions of the GNU GENERAL PUBLIC LICENSE, version 3, or any later version. http://www.gnu.org/licenses/gpl.txt This procedure presupposes a vanilla WASD installation. If you've completely restructured it the results are indeterminate!! Execution may make some or all parts of the installation or Web site unusable. EXPECT THESE CHANGES TO CAUSE SOME DISRUPTION! Before making any significant changes to anything it is always good policy to have a MEANS OF RECOVERING. Do you have a recent and READILY ACCESSABLE BACKUP of your WASD package installation? If not, back off for a moment and make one! $ response = "" $ read sys$command response /prompt="Make changes? [NO]: " $ say "" $ if .not. response then exit ss$_abort $! $!-----------------------------------------------------------------------------