(csh)-jbaldwin-22> more ../init.d/xppws
#!/bin/sh
#
# S92xppws - XPP web server startup for TOMCAT XPP Web services
#
# Copyright (c) 2003 by XyEnterprise, Inc.
# All rights reserved.
#

# Run the XPP Web server as a user. It will run as 'root' if undefined
# NOTE: The 'conf', 'logs', 'temp', and 'work' directories in "CATALINA_HOME"
# must be writable by this user. Make 'chmod/chown' modifications with care

If anyone from RWS is peeking, Case #00671960 

Getting a little weary of arguing.

Hi Jay,

This really isn't the proper forum for this, but it does appear that things with your support ticket have gotten a bit confused. So, I will try to clarify here for you (and anyone else who is now interested).

First, in your ticket you asked: "Do you deliver a systemd [aka systemctl] services startup file and/or the documentation to set it up and enable it in Red Hat EL7 [for the old SOAP-based XPP Web Services]?"

And the answer, as was stated in your ticket, is: No.

For XPP (all products), we have never yet developed, let alone delivered, any systemd/systemctl services startup files.

In XPP development, we are just now developing systemd/systemctl services startup files for non-retired XPP products (such as XPP itself and the newer XPP RESTful Web Services) - to replace the init.d type of startup files. But these won't be available/delivered until the next core release of XPP and the next release of XPP RESTful Web Services. However, there are no plans to develop such systemd type startup scripts for any retired products like the old SOAP-based XPP Web Services.

Support did not say in your ticket that we never delivered any init.d startup scripts; as you've pointed out it's obvious that we do. They were stating that we never did that for the systemd/systemctl type of startup scripts that you specifically asked about.

And what support was trying to convey about "starting up Tomcat on Linux at boot" was that we deliver an init.d startup script that provides a framework for our (old) XPP WS add-on product to help get the XPP environment set up before invoking Tomcat's startup script, but if you are having problems getting Tomcat to run at boot or you are having some kinds of "permission" problems in Tomcat then support cannot really provide much help because Tomcat is not our product.

If you are using RHEL 7, I have to ask why you are not just using the init.d startup script that is provided with the (old) XPP WS product?

Here at RWS we are still using all of the XPP-delivered init.d startup scripts on our RHEL 7 systems (and I believe RHEL 8 as well).

Within this RHEL article (Overview of systemd for RHEL 7 - Red Hat Customer Portal) it states (highlights added):

Transitioning to systemd

If you are used to using the init process and System V init scripts prior to RHEL 7, there are a few things you should know about transitioning to systemd:

• Using RHEL 6 commands: For the time being, you can use commands such as service, chkconfig, runlevel, and init as you did in RHEL 6. They will cause appropriate systemd commands to run, with similar, if not exactly the same, results. Here are some examples:

  # service cups restart
  Redirecting to /bin/systemctl restart cups.service
  # chkconfig cups on
  Note: Forwarding request to 'systemctl enable cups.service'.
  

• System V init Scripts: Although not encouraged, System V init scripts are still supported. There are still some services in RHEL 7 that are implemented in System V init scripts. ...

AFAIK, it's only starting with RHEL 9 that init.d scripts are no longer supported at all (but don't quote me on that). And that's why in XPP development, we have started working on the new systemd type of startup scripts for the next core releases of our active products.

RH themselves provide guidance on converting from init.d scripts to the systemd way, for example in this blog (Converting traditional sysV init scripts to Red Hat Enterprise Linux 7 systemd unit files). Perhaps that blog can help you if you still want to try to convert to using the systemd way to start Tomcat. But I think it is unnecessary and you should be fine with the init.d startup script delivered with XPP WS.

BTW, in your ticket you mentioned something about the PERL5LIB environment variable.

The XPP-delivered (init.d) startup scripts, and related files like xyv.cshrc and xyv.profile, have not manipulated the PERL5LIB environment variable at all since around 2011. Even before that, all that was being done was to save/restore any existing PERL5LIB variable setting around calling the (now long obsolete) Mainwin "set runtime" stuff, since the Mainwin stuff had the side effect of destroying any existing PERL5LIB setting. XPP itself, as delivered, never needed or depended on any PERL5LIB environment variable.

So if in your (XPP/Tomcat) environment you actually need the PERL5LIB environment variable to be set to something (or any other environment settings), it would be your responsibility to get that done.

A "hook" that is often used for this type of "custom", or "site specific", stuff is the XYV_EXECS/global.cshrc and/or XYV_EXECS/global.profile files. These files are considered "customizable", so they won't be stepped on by an XPP "install" (whereas the xyv.cshrc and xyv.profile files are not considered customizable and thus will be overwritten).

Thank you for the de-confusion and clarification, Jonathan. And thanks for indulging me. 

I think we are on the track you've outlined, to incorporate the sysV-style init.d script as-is. But this has been a low-priority project here, and I haven't been much help to the Linux admin who I threw this over to. (That person does know know much about XPP.) Anyway, so your detailed explanation (and links) helps fill in a couple of blanks. I appreciate the time.

The PERL5LIB situation is easier to answer. We use it because it was required for Contenta (specifically when XPP and Contenta were on the same server, I think?), for many purposes including Contenta publishing to XPP. As things like this happen and evolve, we naturally found it convenient to add additional Perl packages to one of the locations specified in PERL5LIB. So now, even though we retired Contenta a few years ago, we can't extract ourselves from the need to keep using PERL5LIB (without a lot of work/reconfiguring). And we incorporated a lot of professional services-developed Perl subs from Contenta packages in our non-Contenta Perl programs.

We set PERL5LIB in global.cshrc, as we are very "CSH" oriented. I suspect that when we did the setup of Red Hat EL7, we didn't match the default shells as they existed on EL5. So it could be that root (bash) may be looking down xyv.profile and global.profile instead of xyv.cshrc and global.cshrc. It's true that we haven't copied our customizations in global.cshrc to global.profile. That is my latest hunch. It might be as simple as updating global.profile.

I do realize this is our responsibility. I don't think I was wrong to open a ticket (or ask here) to see if anyone could enlighten me on the RWS/SDL/XyEnterprise delivered parts. There was indeed confusion. FYI, when we did our fresh install of XPPWS on RH 7, I don't think there is a init.d file anywhere to be found, and I don't believe it's in the documentation for XPPWS either. It there is, I could not find anything.

Jay, in no way at all was it wrong for you to open a support ticket.  

When I said that "this really isn't the proper forum for this", I only meant that (I felt) it was perhaps more appropriate to keep following up with some part of your support questions using your ticket.

But on the other hand, it was definitely appropriate to to ask here because at some level you were asking for help in converting an init.d type of startup script into a systemd/systemctl type of startup file, which as I said is something we are just learning how to do ourselves in development and (AFAIK) support hasn't had any experience with this either.

And once you raised your questions in this forum, I did feel there could be some value to others with the information that I provided and so I did.

As far as your question about the new install on RHEL 7 apparently lacking the deliver of any init.d type startup script, I cannot really say much as most of the "installers" are not within my area of experience. I do see that at some point the installer for the SOAP-based XPP WS product changed from an "old" method to using InstallAnywhere. Perhaps something got "lost in the translation", and if so we're sorry about that. In any case, as I've mentioned this is now a retired product and so we'll have to keep working together via tickets and this forum to get you to a resolution since there won't be any product/installer updates.

Thanks, Jonathan!

I don't like it when I cannot give a "complete" answer, so I did a bit more research. This time I did that using the documentation.

It's not posted on the docs.rws.com web site any more, but I found a source document for XPP Web Services 1.2 Installation and Release Notes. In that document it does talk about the init.d S92xppws startup script that gets delivered and installed into the init.d services on Linux for automatically starting Tomcat.

However, in the latest "install" document for XPP Web Services 1.3 I see that all of the discussions of the delivered and installed init.d service file on Linux was (consciously) removed.

I cannot say for sure (this goes back to 2013), but I'd guess that with the change to using an InstallAnywhere-based installer that the decision was made to no longer have the XPP WS installer do anything to deliver or install a startup script for Tomcat.

Or perhaps the change in "policy" wasn't really related to the change in how the installer worked, but it was just changed at the same time as changing the installer technology.

Perhaps more likely is that we found that with new versions of Tomcat that it became a "moving target" to try to keep up with how to correctly set up the init.d startup script, and/or that it didn't make sense for the XPP WS installer to be setting up a startup script for Tomcat since it is not an XPP-delivered product. After all, I believe that XPP WS is really just an "add on" to Tomcat in that we deliver files that then are used by the Tomcat "engine". Or maybe there was a "conflict" because the Tomcat installer was itself setting up a startup script.

Whereas AFAIK that is not true for XPP RESTful WS, where we deliver the "engine" as well as all the "helper" files and so the installer does deliver and install an init.d startup script (and this installer also is InstallAnywhere-based so the change for the XPP WS installer was not due to just that).

In any case, what I think we really missed doing was to add an explicit statement into the XPP Web Services 1.3 "install" document that the responsibility for setting up a startup script for Tomcat was (now) the user's responsibility (as the XPP WS installer would no longer do that), rather than only leaving it implied by having removed all the stuff about the startup script from it.

Anyway, hopefully that's a more "complete" answer.  

Jonathan, I love the "why" answer, and I completely relate to not being able to let go of things like this. I am legendary within Tweddle for sending explanations like yours in emails to people who will never read them (TL;DR). 

Anyway, it is the most helpful to know that I'm not going crazy. And I do understand from firsthand experience that S92xppws is a "moving target" ... the fickle nature of Java requirements and installations (and 32-bit vs 64-bit) being one of the bigger annoyances. It does need to start as a service in our environment; it is a conundrum for both of us that Tomcat is not a delivered product, but XPPWS as a Tomcat webapp is (requiring Tomcat to inherit certain XPP environment settings). We will figure it out now that we know more about what doesn't work, and why.

I would love to transition to RESTful WS, but we have so much invested in legacy code in Tridion Docs "publish to XPP" tools that we'd have to go through a major rewrite. Probably not going to happen on my watch (I am 64 and toying with the "R word").