Patching gremlins - default config files introduced

[Duncan Beattie]

I have known HPUX patch bundles on occasion to overwrite system configuration files with default copies, for example a hardened inetd.conf had once been replaced by a default copy with all the unnecessary stuff enabled.

Has anyone else experienced similar patching side-effects? Does anyone have any useful links that support this behaviour?

many thanks

[Sridhar Bhaskarla]

Hi,

I have been patching the HP servers for the last 10 years and I have never encountered a situation where my config files got replaced by the patches.

However, some patches require us to pay special attention. For ex., a patch may introduce a new parameter in one of the OS configuration files. It will be indicated in Patch readme file to merge the existing configuration file with the new configuration file to make use of the parameter. Most of the times SAs overlook such instructions.

Ofcourse if we do not pay attention to patch readmes, they may get us into trouble.

-Sri

[doug hosking]

Any HP-UX patch that overwrites a customer's configuration files this was is very likely in serious violation of the HP-UX compatibility policies and should immediately be brought to the attention of your HP-UX support person. HP developers are generally very much aware of the importance of preserving such configuration files and go out of their way not to lose customer edits when new software is installed. That's why directories such as /usr/newconfig exist. If you know of specific examples where legitimate customizations are being lost when installing software, please bring them to the immediate attention of your HP-UX support person so the problem can be corrected.

[Chris Wilshaw]

The only instance of this that I've seen was at 10.20, where a patch overwrote /usr/lib/tztab (which we have customized on our systems). I suspect that if/when a patch is released on 11 that affects this, that the file will be overwritten again, as it's probably not that common for this file to be changed manually.

[doug hosking]

Chris, since there is a /usr/newconfig/usr/lib/tztab, normal practice in patches would be to preserve as much as possible of the one in /usr/lib. Of course, with something as basic/important as time zones, the correct action would depend on the situation. If, for example, the government of Elbonia decided that daylight savings time there should start on a different day next year, it would be reasonable for a patch to just run a sed/awk/ed/perl script over tztab to fix the entries for Elbonia. It would not be reasonable to overwrite the whole tztab (unless it could be determined that it had not been modified from the original).

Out of curiosity, what changes did you have to make to tztab? Anything HP should be aware of, or something only relevant to you?

[Bill Hassell]

Probably the easuest way to track down the offending patch is to search all the files contained in the currently installed patches. Each patch has a record of the file(s) that were replaced. Try this:

swlist -l file | grep inetd.conf

(this will take a while and will find the original installation files as part of InternetSrvcs.INETSVCS-INETD. If you search for just inetd, you'll see man pages and perhaps the executable. Now there is a possibility that a bad patch stored inetd.conf in /usr/newconfig/etc and then copied the reference version onto /etc. However, I ran a complete grep for inetd.conf on 11.11 completely patched to Dec2003 and only one patch shows up for inetd (PHNE_24130) and it patches 3 man pages and the executable only.