Apache Startup - Do You Agree With This Change?

[Robert Atkinson]

After upgrading to Apache-CSWS v2.1, I found one of my instances wasn't starting on the port I'd assigned.

When I dugg into this with HP, I found the instance was starting using the HTTPD.CONF from our Production nodes, because of this code in APACHE$STARTUP.COM :-

$ IF P2 .EQS. ""
$ THEN
$ ConfigFile = "APACHE$COMMON:[CONF]HTTPD.CONF"
$ ELSE
$ ConfigFile = F$EDIT (P2, "TRIM,UPCASE")
$ ENDIF

My gut feeling is that this is really a bug in the startup, and it should look at APACHE$ROOT for the file, so I can automatically assign different configurations to different nodes. As it stands, I have to start Apache like this, to make it read the correct CONF :-

$ @sys$startup:apache$startup start apache$root:[conf]httpd.conf

If I restart the server, but forget to specify the correct CONF, it could then end up running the Production config instead.

The problem with changing the command file to APACHE$ROOT (as I believe is should be) is it could easily break a lot of sites.

Given that, I'd like to know if you think this should be changed and documented in the next release, or that it's fine and people are aware of this already?

Thanks, Rob.

[Wim Van den Wyngaert]

Rob,

The startup prefers a cluster wide config file as default. In my case that would be correct because both cluster nodes run the same server (but WASD). You prefer the node specific file. OK but whatever the script takes as default, someone will complain.

Wim

[Robert Atkinson]

By using APACHE$ROOT, I think you can have the best of both worlds.

If you want Cluster wide, just place the CONF in APACHE$COMMON. If you want node-specific, then place it in APACHE$SPECIFIC.

Does this sound reasonable.

Rob.

[Wim Van den Wyngaert]

OK, now I understand. It should use the search list apache$root which points to spec and common. It shouldn't use apache$common.

I agree 100%.

Wim

[John Gillings]

Rob,

I agree you'd be better off with a search list for the default. I'd go one step further and add an additonal layer of defaults using a logical name. I'd also structure the code differently to make it easier to implement a cascade of defaults.

$! Search for a valid config file
$ ConfigFile = F$SEARCH(P2)
$ IF ConfigFile .EQS. "" THEN ConfigFile =F$SEARCH("APACHE$DEFAULT_CONFIG")
$ IF ConfigFile .EQS."" THEN ConfigFile = F$SEARCH("APACHE$ROOT:[CONF]HTTPD.CONF")
$ IF ConfigFile .EQS.""
$ THEN
$ report error - no config file found.
$ ENDIF

(I've removed the "UPCASE" because you might want an ODS5 filespec)

You may also want to report which config file you end up using to help debug incorrect filespecs.

Obviously other defaults can be added to the search.

>If I restart the server, but forget to
>specify the correct CONF, it could then
>end up running the Production config
>instead.

If that's an issue, I'd recommend moving your production config out of the cluster wide location, so you can't accidently start it from the wrong node. Put a "catch all" config in the cluster wide area that contains a default page telling you something is wrong.

[Robert Atkinson]

> If that's an issue, I'd recommend moving your production config
> out of the cluster wide location

That would cause a common dilema. One node with a specific config and other nodes with a common config, and a nightmare to maintain.

It's often overcome by using a 'SET FILE/ENTER' so you're using an alias to always edit the common file, but I have never liked doing this.

Another more visible option would be to use a HTTPD_NODE_SPECIFIC.CONF, which may already be an option by using an 'INCLUDE' statement? Not sure if Apache would allow the specific config to override the generic one though.

Rob.

[John Gillings]

Rob,

>That would cause a common dilema. One node
>with a specific config and other nodes
>with a common config, and a nightmare to
>maintain.

In that case either I haven't explained myself, or I haven't understood your problem! You implied having one node start up the "common" config was a problem. To my mind that means it's not a common config!

If you have a cluster with several groups of nodes sharing different configs, then the simple specific+common model doesn't fit your reality. You need an extra layer(s) to create the appropriate structure.

With the code I posted, you could easily move shared configs to other places, outside the specific+common tree, and use my proposed APACHE$DEFAULT_CONFIG logical name to point each node to its correct config, some shared, some not. Leave the fall through "common" default config as a "something's wrong!". That way you avoid your maintenance issue, and you fail safe for all nodes.

[Willem Grooters · Accepted solution]

One thing you could do, is put anything node-specific into one or more separate files (one set per node) to be located on a directory accessabel by all nodes.
add an include of this file in the configuration file but use a logical there, that is defined when starting Apache, and based on the nodename (/SYSTEM, or /TABLE=LNM$GROUP_).
(I haven't tried this particular scenario but used a similar method for other purposes)

[Robert Atkinson]

I'll be submitting this thread to HP to see if they'd like to include the change in future releases, based on your feedback.

Rob.