This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
When you use ‘server create’ to create a new server the configuration and other files/folders created will be ‘owned’ by the userid that created it (and that userid’s primary group). That’s probably not what you want.
There’s all sorts of guidance on how to handle this. I’m going to try to skim across the top without getting into a lot of gory details about the steps involved.
First of all, there are generally three different identities (or sets of identities) that need access of some sort to files relating to a server. The first is the server itself (of course). It needs read access to its configuration and write access to log directories etc. The second group is whoever administrates the server. They need write access to the configuration and read (and maybe write) access to the logs and such. The final group is a set of ‘others’ who might need read access to the logs and maybe write access to specific parts of the configuration. Think of this third group as perhaps application developers who need to be able to see the logs to help with problems and might need to be able to update configuration specific to the application.
The generally recommended approach is to define a new userid that will ‘own’ the server configuration files. This userid probably doesn’t have a password and never actually logs on. You’ll do a ‘chown’ to change ownership of the files and directories created by ‘server create’ to this userid.
Next, create a group that will consist of users who need read access to the files. Change the owning group for these files to this new group, and connect all the users who need such access to the group.
If you’ve decided to keep the output from the server somewhere separate from the configuration (recommended), then the identity the server itself runs under should own that directory and its contents, and have write access. The server identity will also be part of the ‘read group’ mentioned above so it can read its own configuration.
But what about administrators? They need write access to the server configuration. The worst way to do that would be to define a password for the userid that now owns the server configuration files and share the password. Hopefully at this point all the security folks out there are nodding vigorously and nobody is sort of looking away embarrassed. This is terrible, don’t do this.
What you should do is make use of the RACF SURROGAT class to grant a set of users access to that owning userid. Then they can just ‘su’ to that userid from their own, without needing a password because SURROGAT says they are already allowed to do it. Then they ‘are’ the owning id and can make changes as required.
But we’ve still got that third group that needs access to some of the configuration and the logs. Well, join them to our read-only group so they can look at the logs. And for the configuration, we’re back to using include files and keep configuration bits you want them to be able to look at and maybe change in places where they can get to it and change it. Which means you’re back, again, to considering how you’re going to organize your included configuration files and where they will live in your file system.
You really need to spend some time thinking about that because how you set it up can easily make your life a lot easier, or a lot harder.