Managing Server Component Output from WebSphere Application Server on z/os A WebSphere on z/os exclusive!

Transcription

1 Managing Server Component Output from WebSphere Application Server on z/os A WebSphere on z/os exclusive! Mike Loos IBM [email protected] Session number Monday, August 12, :30 PM

2 WebSphere Application Server on z/os Sessions in Boston Day Time Room # Title Speaker Monday 9: Getting Started with WebSphere Liberty Profile on z/os David Follis Monday 4: Managing Server Output from WAS on z/os Mike Loos Tuesday 9: Tuesday 11: Using WAS Optimized Local Adapters (WOLA) to migrate your COBOL to zaapable Java Need A Support Assistant? Check Out IBM s! (ISA) Jim Mulvey Mike Stephen Tuesday 3: zwas: In Real Life Rod Feak Wednesday 1: Lab: WebSphere Liberty Profile on z/os everybody Thursday 11: Getting Started with Compute Grid (Batch) John Hutchinson Thursday 3: Configuring Security for Liberty Mike Loos 2 2

3 What is this all about? Why another form of output? What does this one do that's different? How do you set it up? In WebSphere... Security The HTTP Server (V7 V8.5)... Demo. Q and A? 3 This presentation, which is based on the techdoc titled Implementing the Output APAR (PM74923) enhancements in WebSphere Application Server on z/os, will describe a new method of providing output to both z/os and non-z/os based folks. The historical output solutions will be described briefly, then this new methodology will be described in more detail. How to set this up in WebSphere on z/os, how to set up security covering the output, and how to set up the http server to allow browsing of the output and limit it to the appropriate viewers will be covered. We'll do a short demonstration of a configuration that implements this method, and hopefully still allow for some Q and A. 3

4 What is available now? SYSOUT. Great for z/os familiar folks! For others, not so much... SYSOUT redirected to the file system. Naming and sizing limitations. HPEL. 4 Platform agnostic. Some nice operational features. File switching and archiving on size, date/time, number of files. End user may find working with it a little clumsy at times... This new thing... Since early versions of WebSphere, the ability to allow non-z/os folks access to the WebSphere on z/os output (stdout and stderr), has presented a bit of a challenge. The stdout stream is available in the z/os SYSPRINT DD and the stderr stream is available in the z/os SYSOUT DD, both of which default to spool output. The first iteration of a solution, involved changing the DD statements to point to the file system, while allowing the access desired, has some limitations in that the names are set in the DD statement, and the file, since basically you can only switch it by restarting the server, will continue to grow in size as long as the server is up. Also, there was the possibility of file naming conflicts if two servants were started at the same time. The next major solution was the introduction of the High Performance Extensible Logging (HPEL) option in V8. It has the advantage of being platform agnostic, and has some nice operational features, such as file switching and archiving based on the size of the file, date and/or time, and limits on the number of files. Since it is a binary file type, it does require that you use a provided interface to view the logs, either the viewer provided within the adminconsole, or the logviewer.sh script. Some folks might view this interface as a little less than elegent. So finally we come to this new thing... 4

5 The New(est) Method File based. WebSphere ensures that there will be no naming conflicts. Works for all components (Daemon, Dmgr, Nodeagents, Servers (both controllers, adjuncts, and servants)). File switching is simple using a z/os MODIFY command. No need for users to access the filesystem. Access to the output can be uncontrolled or controlled... At the cell level. At the node. Server by server. 5 Via any security system that the HTTP server supports (SAF, LDAP, etc.). This new implementation is file based, much the same as the redirection via the SYSOUT DD cards. But in this case, WebSphere ensures that there will be no naming conflicts. This works with, and is granular enough to allow seperate security over, the output of all WebSphere on z/os components (Daemons, the Deployment Manager (controller and servant), nodeagents, and servers (controller, adjunct, and servants). Switching to a new file is accomplished by either a component restart, or a simple z/os Modify command. The use of the Modify command interface allows control by normal z/os automation procedures. There is no need for viewers of the output to access the filesystem directly, so the viewers of the output can be restricted from reading, writing, and/or other modification of the files in the filesystem. Access to the ouput may be either completely uncontrolled, or it may be controllled at the cell level, the node level, or the server level. The controlling security may be any security provider supported by the http server, SAF (RACF, other vendor solutions) or LDAP. 5

6 How does it work? What do I do to set it up? In WebSphere: Add variables at appropriate scopes. 6 They will be inherited by lower levels... Simplest setup is to just add them at the cell level and let all components write to the same path. The same variable at a lower level will take precedence. Variable names: DAEMON_redirect_server_output_dir (for the Daemon). redirect_server_output_dir (for everything else). Value is simply the path name where you wish the output to be written. Ex. /wasv85config/wasoutput/shcell/shcell This is all setup rather simply. In the WebSphere on z/os cell, you simply add variables at appropriate scopes (cell, node, server). The variables will be inherited by lower (more granular) scope levels, unless overridden at the lower scope level. The most simple setup is to add the variables at the cell level and allow all components to write to the same path. That also effectively limits to security to a single level, which may be adequate for many cells. There are two variable names, DAEMON_redirect_server_output_dir and redirect_server_output_dir for the daemon and other components respectively. The value associated with the variable is simply the path name to which you wish the output to be written. 6

7 Setup in WebSphere. 7 That's all there is!...in WebSphere. This is what it looks like when you are adding the variable in the adminconsole. 7

8 How does it work? What do I do to set it up? In WebSphere: All that is left is to restart the components you believe that you have modified, and the output will be redirected to the path you've specified. :/shared/wasoutput/shcell/shcell -> ls SHCELL.SHDMNODE.SHDMGR.SHDMGR.STC00160.CTL SYSOUT.txt SHCELL.SHDMNODE.SHDMGR.SHDMGR.STC00160.CTL SYSPRINT.txt SHCELL.SHDMNODE.SHDMGR.SHDMGRS.STC00165.SR SYSOUT.txt SHCELL.SHDMNODE.SHDMGR.SHDMGRS.STC00165.SR SYSPRINT.txt SHCELL.SHDMNODE.SYSC.SHDEMN.STC00163.DAEMON SYSOUT.txt SHCELL.SHDMNODE.SYSC.SHDEMN.STC00163.DAEMON SYSPRINT.txt SHCELL.SHNODEC.SHAGNTC.SHAGNTC.STC00167.CTL SYSOUT.txt SHCELL.SHNODEC.SHAGNTC.SHAGNTC.STC00167.CTL SYSPRINT.txt SHCELL.SHNODED.SHAGNTD.SHAGNTD.STC00168.CTL SYSOUT.txt SHCELL.SHNODED.SHAGNTD.SHAGNTD.STC00168.CTL SYSPRINT.txt SHCELL.SHNODED.SYSD.SHDEMN.STC00169.DAEMON SYSOUT.txt SHCELL.SHNODED.SYSD.SHDEMN.STC00169.DAEMON SYSPRINT.txt 8 After the variable(s) have been added, all you have to do to make it take effect is to restart the component(s) you believe that you have covered with the variable(s) and the output will be redirected to the location to which the path name specified points. The files are named, for all components except the daemon(s) by concatenating the cell short name, node short name, server short name, job name, started task id, creation date, creation time, output type (SYSOUT for stderr and SYSPRINT for stdout), and the constant txt indicating the output type. The daemon output is named slightly differently, cell short name, node short name, system id, job name, started tast id, the constant DAEMON, creation date, creation time, output type, and the constant txt. 8

9 How does it work? What do I do to set it up? If you wish to switch to a new file, from any z/os Console: F SHDEMN,ROLL_LOGS BBOO0211I MODIFY COMMAND ROLL_LOGS COMPLETED SUCCESSFULLY :/shared/wasoutput/shcell/shcell -> ls SHCELL.SHDMNODE.SHDMGR.SHDMGR.STC00160.CTL SYSOUT.txt SHCELL.SHDMNODE.SHDMGR.SHDMGR.STC00160.CTL SYSPRINT.txt SHCELL.SHDMNODE.SHDMGR.SHDMGRS.STC00165.SR SYSOUT.txt SHCELL.SHDMNODE.SHDMGR.SHDMGRS.STC00165.SR SYSPRINT.txt SHCELL.SHDMNODE.SYSC.SHDEMN.STC00163.DAEMON SYSOUT.txt SHCELL.SHDMNODE.SYSC.SHDEMN.STC00163.DAEMON SYSPRINT.txt SHCELL.SHDMNODE.SYSC.SHDEMN.STC00163.DAEMON SYSOUT.txt SHCELL.SHDMNODE.SYSC.SHDEMN.STC00163.DAEMON SYSPRINT.txt SHCELL.SHNODEC.SHAGNTC.SHAGNTC.STC00167.CTL SYSOUT.txt SHCELL.SHNODEC.SHAGNTC.SHAGNTC.STC00167.CTL SYSPRINT.txt SHCELL.SHNODED.SHAGNTD.SHAGNTD.STC00168.CTL SYSOUT.txt SHCELL.SHNODED.SHAGNTD.SHAGNTD.STC00168.CTL SYSPRINT.txt SHCELL.SHNODED.SYSD.SHDEMN.STC00169.DAEMON SYSOUT.txt SHCELL.SHNODED.SYSD.SHDEMN.STC00169.DAEMON SYSPRINT.txt 9 At this point, if all you want is ISPF browse or telnet access, you are done...but if you want to make it really cool... Switching a component to use a new file, without a component restart, is as simple as issuing a z/os Modify command for the component, with the operand roll_logs. For demonstration purposes, the command was issued for the daemon on SYSC. The system responds with the BBOO0211I message, indicating successful completion. Examination of the output path location, shows that the daemon in question now has another set of files with a newer timestamp. If you were to examine the specific output files, you would find that there would be a message (the last message in the file) in the old file with a forward pointer to the new file name, and a message in the new file (first message) that has a backward pointer to the previous file. So you could concievably write a script to chain all of the files together in proper order if that were your desire. 9

10 How does it work? What do I do to set it up? Security setup: For the HTTP Server (we're going to build later). RDEF STARTED SHHTTP01.* STDATA(USER(SHADMIN) GROUP(SHCFG)TRACE(YES)) SETR RACLIST(STARTED) REFRESH PERMIT BPX.SERVER CLASS(FACILITY) ID(SHCFG) AC(READ) SETR RACLIST(FACILITY) REFRESH For the access controls we'll be implementing. AG SHCELL OMVS(AUTOGID) /* Entire cell access */ AG SHDMNODE OMVS(AUTOGID) /* Entire dmgr node access */ AG SHNODEC OMVS(AUTOGID) /* Entire shnodec node access */ AG SHNODED OMVS(AUTOGID) /* Entire shnoded node access */ AG SHSR01C OMVS(AUTOGID) /* Access to shsr01c only */ AG SHSR01D OMVS(AUTOGID) /* Access to shsr01d only */ AG SHSR02C OMVS(AUTOGID) /* Access to shsr02c only */ 10 AG SHSR02D OMVS(AUTOGID) /* Access to shsr02d only */ There are two parts to setting up security for this process, both of which are optional. Everything will work fine if you want it to be unsecured. The first thing necessary if security is desired, is to set up the security for the http server which we'll be building a little later in this presentation. You'll need a STARTED class definition which allows the new http server to run with the cell's admin id and configuration group. We are considering the http server to be basically just another server in the cell, so this is appropriate. It also allows the http server access to all of the files which the cell's components create. The http server also needs read access to the FACILITY class profile BPX.SERVER. The second set of security definitions are used to allow access to the output from the various components. The various groups defined are subsequently named, either singly or in lists of groups, in access limiting statements in the http server's configuration file. The groups MUST have an OMVS group id, whether it is specifically specified or automatically generated. The http server which will be built as part of this presentation will only use the first, cell level, group, but there will be info on how to use the other groups to limit access on a more granular basis. 10

11 How does it work? What do I do to set it up? Building the HTTP server. From either OMVS, telnet, or SSH... (Can't do this from ISHELL or 3.17): cd /usr/lpp/ihsa/v8r5base/bin./install_ihs /wasv85config/shcell/shhttp The install command will respond with the following command, which you then enter, unchanged (cut and paste)../shared/ihsa/v8r5base/bin/postinst -i /wasv85config/shcell/shhttp01 -t install -v PORT=9898 -v SERVERNAME=wsc3.washington.ibm.com chown -Rh shadmin:shcfg /wasv85config/shcell/shhttp01 The HTTP server is now built and ready for appropriate modifications. 11 It is time to build the http server. This is the http server for z/os based upon Apache, not the older Domino Go Webserver (DGW). It is delivered as part of WebSphere on z/os, and can also be obtained as part of the ported tools package, although the one delivered with WebSphere on z/os is the most current version. To start, you have to run the install from an interactive shell (not ISHELL or ISPF 3.17), so from telnet, ssh, or OMVS, you change directory to the bin directory of the delivered server code. Issue the install_hfs command with target install location, /wasv85config/shcell/shhttp01 and the port number upon which the http server will listen, 9898 as arguments. The command will respond with another command as output text, which you simply cut and paste into the command prompt and issue. Next, issue a chown command to change the ownership of the files and directories in the target location to the cell's admin id and config group. That's all there is to building the server. It would start as is, (but not do much of anything we'd call useful). 11

12 How does it work? What do I do to set it up? Modifications to the httpd.conf file to make all of this work. httpd.conf is found in <server root>/conf/ or in our case, /wasv85config/shcell/shhttp01/conf. Add or modify the following statements using your favorite editor... The following LoadModule statements must be added or uncommented as appropriate. LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule authnz_saf_module modules/mod_authnz_saf.so LoadModule authz_default_module modules/mod_authz_default.so If SSL support is required, then the following LoadModule statement must be uncommented. LoadModule ibm_ssl_module modules/mod_ibm_ssl.so 12 Some modifications now must be done to the configuration file for the http server, found in the target location /conf directory, the httpd.conf file. The LoadModule statements that provide support for basic authentication, SAF support, and z/os authorization, and if required SSL support, must be either uncommented or if necessary added. 12

13 How does it work? What do I do to set it up? Continuing... The DocumentRoot directive should be changed to point at the base output location. DocumentRoot "/wasv85config/wasoutput/shcell" The Directory statement should be changed from where it points by default, /wasv85config/shcell/shhttp01/htdocs to be the same as the DocumentRoot directive. So change: From: <Directory "/wasv85config/shcell/shhttp01/htdocs"> To: <Directory "/wasv85config/wasoutput/shcell"> 13 The DocumentRoot statement mus tbe updated to point to the location which we have specified as the output location for the cell. In our case this location is a symbolic link which points to the actual output location. Also, the Directory statement must be changed to the same location. 13

14 How does it work? What do I do to set it up? Continuing... Add the following statements (immediately after the previous Directory statement is fine...). SetOutputFilter DEFLATE CharsetSourceEnc IBM-1047 CharsetDefault ISO Change the options directive: From: Options FollowSymLinks To: Options FollowSymLinks Indexes IndexOptions NameWidth=80 14 Immediately after the Directory statement which was just modified, the following statements should be added to support the fine encoding of the output files (EBCDIC). The Options directive must also be changed to support the lengthy file names. 14

15 How does it work? What do I do to set it up? Continuing... The following two changes are to support the suppression of an error message that Internet Explorer will throw when it sees a txt file with parts of verbose garbage collection data. These two changes suppress that behavior. # Uncomment the next line to allow MSIE verbose GC error suppression. LoadModule headers_module modules/mod_headers.so And: # Added the following to suppress MSIE from throwing error on verbose GC data. <Files *.txt> Header set X-Content-Type-Options nosniff </Files> 15 The output in the stderr stream (SYSOUT) commonly contains the output from the verbose garbage collection process of the Java virtual machine. This is, in fact, statements which belong in an xml file. Since Internet Explorer may be the browser used to view these files, you should include the following statements to prevent Internet Explorer from deciding that the files you wish to view are malformed xml files, which it will then refuse to allow the user to access. The two statements necessary are the LoadModule statement that supports file headers and the Files stanza that tell's Internet Explorer to not look ahead. 15

16 How does it work? What do I do to set it up? Continuing... The following changes are added to secure the server. This first Location directive controls access to the server, requiring anyone who accesses it to provide authentication. <Location /*> AuthName wasv85output AuthType Basic AuthBasicProvider saf Require valid-user AuthSAFExpiration "EXPIRED! oldpw/newpw/newpw" AuthSAFReEnter "Enter new password one more time" </Location> 16 The Location directive shown will require anyone who attempts to browse the url that specifies the location of the output to be authenticated with a userid and password. It also allows for a prompt to be specified for dealing with expired passwords. 16

17 How does it work? What do I do to set it up? Continuing... This next Location directive controls access to the cell directory and all files within it. <Location /shcell> AuthName shcelloutput AuthType Basic AuthBasicProvider saf Require saf-group SHCFG SHCELL AuthSAFExpiration "EXPIRED! oldpw/newpw/newpw" AuthSAFReEnter "Enter new password one more time" </Location> Save the httpd.conf file. 17 This Location directive specifies the /shcell subdirectory of the url. It will require that any authenticated user that attempts to access the specified directory be a member of the SHCFG (cell configuration) or SHCELL group. The SHCELL group was set up previously for the express purpose of allowing this check. If an user fails this check, they'll see an authorization failure at the browser. There will be no messages on the console or the joblog (ICH408I) indicating a failure, since all the server is doing is checking to see if the authenticated user has the required GID in their list groups of which they are a member. 17

18 How does it work? What do I do to set it up? Continuing... Create a JCL PROC to be used to start the HTTP server and save it in an appropriate PROCLIB. //SHHTTP01 PROC ACTION='start', // DIR='/wasv85config/shcell/shhttp01/', // CONF='conf/httpd.conf' //* //IHS EXEC PGM=BPXBATCH, // PARM='SH &DIR/bin/apachectl -k &ACTION -f &CONF -DNO_DETACH', // MEMLIMIT=512M //STDOUT DD SYSOUT=* //STDERR DD SYSOUT=* 18 Next we need a PROC (JCL Procedure) in a PROCLIB which allows started tasks to be started from it. The same PROC will be used to start and to stop the http server. The name of the PROC (member name in the PROCLIB PDS) must match the name specified earlier in the STARTED profile. The PROC simply executes the BPXBATCH program with a parm field specifying what we want to do. The default action is start. 18

19 How does it work? What do I do to set it up? Continuing... To start the HTTP Server, issue the following command from a console. Since the default action is 'start', no parameter is necessary. S SHHTTP01 To stop the server, issue the same command with the action='stop' parameter (case is important, so be careful about where this command is entered). S SHHTTP01,ACTION='stop' 19 19

20 And finally...a Result! 20 Finally we can open a browser (your choice which brand), and direct it to the appropriate url for the server. The user will get a prompt for a userid and password. The one we have used is a userid which is NOT connected to either of the two groups on the Location directive, so... 20

21 And finally...a Result! Whoops! No output...mjloos2 must not be a member of an appropriate group As you can see, the server has authenticated the user, but the user isn't allowed to see any output. This is simple to remedy... Connect the user to an appropriate group with a command like the one shown. Then the user can simply reload (or refresh) the browser and they'll see the files from the directory as appropriate, in this case, the cell level directory. To continue... 21

22 And finally...a Result! Then click on the cell name shcell Click on the cell name link shcell. 22

23 And finally...a Result! Then click on any file name you choose. 23 The user is now presented with a list of files, which are all clickable links. Clicking on any one of them will open and display the file. 23

24 And finally...a Result! 24 The ouput is scrollable, and dynamic. If you happen to be at the bottom of the screen and want to see output which has been added since you opened the file, simply click on the browser's refresh icon. 24

25 And if you prefer a more granular security setup... Add something similar to the following... This Location directive controls access to the files under the deployment manager node. <Location /shcell/shdmnode> AuthName shcellshdmnodeoutput AuthType Basic AuthBasicProvider saf Require saf-group SHCFG SHCELL SHDMNODE AuthSAFExpiration "EXPIRED! oldpw/newpw/newpw" AuthSAFReEnter "Enter new password one more time" </Location> Members of any of the three groups will be allowed access. 25 If you wished to implement more granular security, for instance to allow one group access to the deployment manager output only, you would first have to direct the output to a separate path (different directory in the same structure, keeping it hierarchical makes it easiest), with a WebSphere variable (same variable name, different scope (deployment manager node (shdmnode), and a different pathname for the value. Then you'd add a Location directive for the more specific pathname, in addition to the more generic one previously specified, that requires membership in a different group (SHDMNODE). In the shown directive, the two groups from the previous directive are also used. Although not actually necessary, this allows access in an hierarchical fashion. If you have access to the cell, you also have access to the node in the cell, the servers in the node, etc. If you only are a member of the node level group, you won't be able to see anything above the node level directory. You would also have to specify a more specific url in the browser, as you wouldn't have the access necessary to traverse through the hierarchy. Not a bad thing, necessarily, but worth knowing. 25

26 And if you prefer a more granular security setup... Continuing... This Location directive controls access to the files under a managed (AppServer) node. <Location /shcell/shnodec> AuthName shcellshnodecoutput AuthType Basic AuthBasicProvider saf Require saf-group SHCFG SHCELL SHNODEC AuthSAFExpiration "EXPIRED! oldpw/newpw/newpw" AuthSAFReEnter "Enter new password one more time" </Location> Members of any of the three groups will be allowed access. 26 The shown Location directive is very similar to the previous slide, but is for an appserver node. Setup is the same with altered names. 26

27 And if you prefer a more granular security setup... Continuing... This Location directive controls access to the files under an AppServer node for a particular server.. <Location /shcell/shnodec/shsr01c> AuthName shcellshnodecshsr01coutput AuthType Basic AuthBasicProvider saf Require saf-group SHCFG SHCELL SHNODEC SHSR01C AuthSAFExpiration "EXPIRED! oldpw/newpw/newpw" AuthSAFReEnter "Enter new password one more time" </Location> Members of any of the four groups will be allowed access. This Location directive is same as above for a different server. <Location /shcell/shnodec/shsr02c> AuthName shcellshnodecshsr02coutput AuthType Basic AuthBasicProvider saf Require saf-group SHCFG SHCELL SHNODEC SHSR02C AuthSAFExpiration "EXPIRED! oldpw/newpw/newpw" AuthSAFReEnter "Enter new password one more time" </Location> Members of any of the four groups will be allowed access. 27 The two directives shown take the concept from the previous two slides down a level from the node to the server(s). Same things must be specified. Note the additional group specified. Remember that membership in any one of the four groups will allow you access to the directory specified. 27

28 And if you prefer a more granular security setup... Continuing... Similar Location directives may (should?) be added for: /shcell/shnoded /shcell/shnoded/shsr01d /shcell/shnoded/shsr01d And for any other directories which you wish to protect. 28 You may add Location directives (and corresponding variable/value specifications at appropriate scopes) to get as much or as little granularity as you wish. It is worth noting that the same (or a different if you prefer) http server, with the specification of appropriate Location directives, could be used to view seperate files for verbose garbage collection (if you direct that output to a file instead of the stderr stream), ffdc files, or anything else you wish to view from a browser. 28

29 References... Directing SYSPRINT Output to an HFS File in WebSphere for z/os Routing Operator Messages in WebSphere Application Servers for z/os V6 & V7 Implementing the Output APAR (PM74923) enhancements in WebSphere Application Server on z/os This paper is the basis for this presentation and goes into much greater detail. IBM HTTP Server for WebSphere Application Server Version 8.5 SA These are a few references which you may find helpful as you implement this function. 29

30 And now... Q and A