CentOS 3.5 with 7.5.3 - Problems

[brooks]

Anyone have 7.5.3 running under CentOS 3.5? I was finally able to get the OS installed with the needed RPMs. That alone turned out to be much more work than we ever had installing Plesk under RH 7.3 or ES 3.x. I used the RPM distribution of Plesk but even after a lot of tweaking things still are not working. And even though I've been able to get the install to run with only minor (?) errors I still don't have an operational system. The 2 errors that I'm still seeing in during the install are:

# websrvmng: Service httpd failed to start
# websrvmng: Service httpd failed to start

# ===> Installing Admin Server
# find: /usr/local/psa/admin/plib/api-cli: No such file or directory

I have a list of things you have to do just to get this combination to install which probably isn't worth posting unless someone really wants to see it.

Here's a list of the known (at this point) problems:

spamassassin atempts to start prior to MySQL loading which causes it to fail. It does start correctly later.

Can't use the web based updater since it is tied to version 3.3 (why?). We've been runnin ES3 for over a year and it has never been tied to a specific minor release. I know that all you have to do is change the string in the redhat-release file to read 3.3 vs. 3.5. But, why has SWSoft tied the web updater to a specific version of CentOS? Version 3 should be all that they care about, not version 3.3 (as it is with RH ES 3).

Can't install a new license key. It says:
usr/local/psa/admin/bin/httpsdctl graceful: configuration broken, ignoring restart
/usr/local/psa/admin/bin/httpsdctl graceful: (run 'apachectl configtest' for details)
/usr/local/psa/admin/bin/httpsdctl execution failed (no output)
/usr/local/psa/admin/bin/httpsdctl execution failed (no output)
fatal error: Plesk graceful restart failed
fatal error: Plesk graceful restart failed

Yet running:

/usr/local/psa/admin/bin/httpsdctl configtest

or

/usr/local/psa/admin/bin/httpsdctl graceful at the command line works perfectly.

I had high hopes for the CentOS/Plesk combination but it looks to me like this release was put together by a less experienced engineer and had minimal testing.

If I drop back to CentOS 3.3 will things work - better? Given that 3.5 is really just a repackaged 3.3 with updated RPMs I'm not hopeful. I'd appreciate hearing from others who may have already been down this road.

 

[sieb@]

I have 7.5.3 running/installing fine on my CentOS 3.4 test boxes, both with ART's yums and PSA's installer. I would say hold off on using 3.5 and use CentOS4 when 7.5.4 comes out, which I am assuming should support Cent/RHES 4. Or start over, it sounds like something didn't get setup right initially. You check the httpd and message logs for more verbose errors?

 

[brooks]

After SWSoft logged into the server and told me "all services are running so everything is fine" I decided to do some additional debugging. In relation to the problem where the init.d scripts are not installed with the correct priority (things start out of order at boot time) I found the following:

1. If you include the "Required-start" LSB info in the init.d script you have to also include a "Required-stop" line or chkconfig will take the stop value from the "chkconfig" line in the script which prevents the "frobber" routine from calculating a priority. This then causes the start priority to be set to "-1" which in turn causes the link to be created as "/etc/rc*.d/S-1component_name".

Since the psa-spamassassin init script had no "Required-stop" line it was getting installed as "/etc/rc*.d/S-1psa-spamassassin".

2. The frobDependencies routine in chkconfig.c doesn't correctly calculate the correct priority anyway. See bugzilla bug:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161870

This causes all init scripts with LSB info to get installed with a priorty of 50! Check this out (from my CentOS 3.5 install):

[root@ds1 init.d]# ls /etc/rc3.d/S50*
/etc/rc3.d/S50courier-imap /etc/rc3.d/S50psa-spamassassin
/etc/rc3.d/S50psa /etc/rc3.d/S50qmail

At this point my suggestion to SWSoft is that they remove the LSB data from the CentOS/RedHat RPMs.

I'm unsure how this ever made it out given the above problems. Add to this the problem of having the GUI based updater tied to CentOS version 3.3 and it makes it very difficult to sell this combination to customers. At this point we've spent almost a week trying to get this combination working when it should have taken less than a day.

P.S. The license key issue I mentioned above was due to human error (using a 7.1r key vs. a 7.5r key).

P.P.S What good is a "support" contract if we have to find and fix the bugs ourselves?

 

[brooks]

So this looks like an even bigger mess than I thought. This is (IMO) extremely poor quality software engineering.

After fixing the above problems by removing the LSB info from the problematic init.d scripts and readding the services I noticed that things were still not set up correctly. Both psa-spamassassin and drwebd start at priorty levels prior to psa. This doesn't appear to be a problem for psa-spamassassin but causes drwebd to fail. I also noticed that these services were both being started twice, once from rc and once from the psa init script. What's that about? It would seem reasonable to just use the normal priority system to start these services after psa (if needed) and to not have the psa init script start and enable them (via chkconfig). What is the purpose of turning them on in the psa init script anyway? Given the incorrect run levels they either fail, or appear to start twice.

We don't want to deliver servers to customers that have services starting twice, or appearing to fail at boot time. SWSoft needs to either remove the references from the psa init script, or remove the code from the psa script that enables psa-spamassassin and drwebd (chkconfig on) and start them out of psa. One way or another this needs to be fixed.

 

[sieb@]

I've only seen this happen on my CentOS boxes, where it starts before its supposed to, or twice, hasn't happened on my ES3 boxes. The only time I got it to do it though is when I loaded ARTs qmail scanner and spamassassin rpms. They do in fact start out of order. Though a clean install of PSA on CentOS 3.3/3.4 doesn't exibit these problems, at least it hasn't on my boxes. Then again, your doing this on an unsupported OS so SW-Soft isn't directly responsible.

Best to wait for 7.5.4, or use a supported OS.