CentOS rpm -qa reporting incorrect version

[shoe]

Long story short, I upgraded from 6.16 to 6.20 this past Sunday evening, and everything went well. Last night I (stupidly) chose to install a few more modules via the CentOS GUI package manager and apparently selected some module option I shouldn't have, after which I had errors all over the place. Argued with that for several hours before deciding that my users would mutiny this morning without groupware, and restored /opt/open-xchange/* and /var/www/html/ox6/* from my pre-upgrage backup. Everything works, but CentOS still reports all the Open-xchange modules at 6.20 version. Is it possible to rectify this so that I may upgrade again?

[Martin Heiland]

Hi,

umm good question - i guess you'll have to look at the CentOS package manager documentation how to remove packages from the database or even reset their version number. I don't know a package manager who allows that. Perhaps re-installing of the OX packages is an option?

Greetings

[shoe]

Thanks for the quick follow-up, Martin. Your intuition regarding a package manager that would allow for those types of changes is correct, at least where CentOS is concerned. It's all wrapped up in a Berkeley DB file, and I'm not going there. I can apparently use 'yum reinstall' to force a package, but my question now is, should I choose them on an individual basis, or meta package(s)? I run a single server, plain vanilla environment (no push, Xtender, or mobile; not a reseller or SAS provider). Any direction in that area to avoid what happened last night, where I ended up with '503 service not available' at log in and 'Can't fix Socket is null, cannot connect to 127.0.0.1:57461' coming from the open-xchange.log.0 (which I suspect came from installing an admin package I should not have, based on what I read in the forum).

[Martin Heiland]

Hi,

the 503 and the exception you posted are not necessarily connected to each other. HTTP status "503" is returned by the web server because the backend service (OX in this case) is not responding. That can be caused by a variety of issues. The "cannot connect" message is thrown if one of the services (OX groupware or OX admindaemon) are not running and JCS caches fail to initialize (which is bad but not grave). However, the root cause might be the same for both errors. Reading the log files carefully (especially at the server startup) helps a lot when running into such kind of issues.

If you're planning to use just a basic system, you're fine with the meta packages described at the install guide. Keep in mind that those meta-packages are only ... well meta packages ... and refer to single packages which are installed by selecting the meta packages. Both ways will install the same packages while the meta-way is just a bit easier for managing dependencies. Installing open-xchange* will not work since some packages contain different implementations of the same feature and will cause unwanted or unexpected behavior if the software.

Greetings