I've installed the apache 2.2.x it's not the one shipped with centos, just installed the rpm then tried starting it from /usr/sbin/httpd. By the way which version of postgresql libs do I need to use with it

On 3/9/07, Jim Perrin jperrin@gmail.com wrote:

On 3/9/07, Ern jura exjura@gmail.com wrote:

...

I get the following error when starting the apache2 server, any ideas.

./httpd: error while loading shared libraries: libpq.so.4: cannot open shared object file: No such file or directory [root@localhost sbin]#

Why are you calling httpd directly instead of using the init script? What version of httpd is this, as it's not the version that centos ships. The centos version of httpd is not linked against postgresql, and what you're using seems to be.

If you would like assistance, you might start by explaining what you've done here.

-- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

yep rpm -i httpd-2.2.x from rpm.pbone.net how do I work around the problem?

On 3/9/07, Ralph Angenendt ra+centos@br-online.de wrote:

Ern jura wrote:

...

I've installed the apache 2.2.x it's not the one shipped with centos,

just

...

installed the rpm

"Just installed the rpm" - which rpm? From where? And why?

Regards,

Ralph

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 3/9/07, Ern jura exjura@gmail.com wrote:

yep rpm -i httpd-2.2.x from rpm.pbone.net how do I work around the problem?

*WHICH* rpm from pbone, as there are several?

The problem isn't the packaging, it's the administration. You're shooting yourself in the server with your actions. The workaround is -> Uninstall that rpm and use the version of httpd that comes with centos.

On Fri, 2007-03-09 at 15:40 +0100, Ralph Angenendt wrote:

Ern jura wrote:

...

yep rpm -i httpd-2.2.x from [1]rpm.pbone.net

That was a very clear answer, not that there are around 50 different apache 2.2 rpms on there.

...

how do I work around the problem?

With using the httpd from CentOS. Why do you think you need apache-2.2?

---- those who want to host ruby on rails definitely want Apache 2.2

(just answering the question).

Thus on CentOS 4.4, I am still stuck with Apache 2.0 & fcgid

Craig

Jim Perrin wrote:

Where did you get this rpm? How did you install it, as an rpm should have complained about missing dependencies.

Uhhh. rpm -i --force --nodeps --no-i-do-not-know-what-i-am-doing?

Ralph

Joshua Gimer wrote:

And now for an answer that actually fixes the problem. You can download the Postgres libs from here: [1]http://rpm.pbone.net/index.php3/stat/3/srodzaj/1/search/libpq.so.4 You will see the CentOS rpm's about mid page.

Those postgresql rpms are also available from the centosplus repository. http://wiki.centos.org/Repositories, so there's no need to download them separately, as they can be installed via yum ...

Ralph

On 09/03/07, Steven Vishoot sir_funzone@yahoo.com wrote:

hmmm... telling someone to compile programs from source, isn't that like telling them to shoot their own foot with their sever? Especially when they are having this much troubles with rpm in the first place. Sorry i do not get the logic behind that advice!

On balance, and if someone knows what they're doing I'd recommend compiling from source before random packages off the internet.

Though obviously sticking with the distro packages is preferable to either option, and if they don't provide what you want then packaging, testing and documenting your own would be the next best step I suppose.

Will.

From a security perspective I am not going to be held waiting for Red Hat to release a new version or patch. I install primary packages from source, this allows ME to decide when I want to install a new version. It also allows me to have more control of the features that I am installing with a package, not the ones that others have decided to be useful.

Some people prefer the upstream approach, I personally do not. Just my opinion, this is the advice that I give to even our Junior sys admins. The attackers that actually know what they are doing, know that people wait for a patches from the vendor; these are the people that I am worried about recieving attacks from.

hmmm... telling someone to compile programs from

source, isn't that like telling them to shoot their own foot with their sever? Especially when they are having this much troubles with rpm in the first place. Sorry i do not get the logic behind that advice!

Steven

-- Thx Joshua Gimer

John R Pierce wrote:

Joshua Gimer wrote:

...

From a security perspective I am not going to be held waiting for Red Hat to release a new version or patch. I install primary packages from source, this allows ME to decide when I want to install a new version. It also allows me to have more control of the features that I am installing with a package, not the ones that others have decided to be useful.

Some people prefer the upstream approach, I personally do not. Just my opinion, this is the advice that I give to even our Junior sys admins. The attackers that actually know what they are doing, know that people wait for a patches from the vendor; these are the people that I am worried about recieving attacks from.

then why are you using RHEL/CentOS at all? Why not a source based distro like Gentoo ?

I agree. The whole point of RHEL/CentOS is that the system is vetted by people that know a lot more about the interactions of various pieces of the puzzle than I do. Almost as importantly, they also track and implement security patches and generally do so a LOT faster than you could do so yourself....assuming you had the time, energy and (most importantly) the skills to monitor the hundreds of mailing lists that track problems in all the various puzzle pieces. So I don't compile ANYTHING mission critical from scratch unless I absolutely positively HAVE to and even then it is only as a last resort.

Cheers,

Joshua Gimer wrote:

> then why are you using RHEL/CentOS at all?  Why not a source based
> distro like Gentoo ?

Becuase I am not the one that is paying for the support contract with RH. IF it was up to me I would run everything on OpenBSD; but it is not.

You just nullified the value of that support by installing your own 'primary packages' (which I would assume would include the kernel, all outward facing services, and anything else, if you've achieved what you stated your goals are).

On 09/03/07, Joshua Gimer jgimer@gmail.com wrote:

I am not going to fight about Admin Practices with everyone. If you take what you recieve from any list as gold you aparently cannot think for yourself anyway.

I think this has been gone over a couple of times. The problem is that the OP asked for help with a problem (actually, a number of related problem, all in separate posts) of his own doing without further justification.

I'm sure you, and I, and plenty of others are capable of rolling our own bits outwith the core distro where necessary but the problem is how to advise people who don't?

Best Practice for an RPM based system is to stick with the packages. You should only ever stray outside those boundaries if you're experienced and know what you're doing. If you DO stray and know what you're doing then you should be able to formulate a post to a mailing list which states:

a) I have a system running BlarghOS 12.z b) I need functionality from BlipApp 6 not included with BlarghOS 12.z c) I'm compiling BlipApp 6 from these sources from http://blip.org/blip-6.0.0.tgz with support for additional libraries X, X and Z. etc. etc. d) And the resultant error is [error message here]

When someone relatively inexperienced, or who provides scant detail, as the OP did, posts such vague questions it make sense to point them toward the Way Things Are Done, if they provide no information as to why they're veering from that path.

The core problem is that people who've read and understood ESR's "How To Ask Questions The Smart Way" generally ask different questions which don't prompt tail chasing.

Will.