ispcp auto install for CentOS 5.5 i386

[motokochan]

Then you can access the control panel via hxxp://admin.domain.com/. No extra path is needed.

If DNS isn't working, you can set up an entry in your hosts file until you get it configured.

[lucian0308]

centos don't work

you must remove from suported OS

i try with debian and it work perfectly
from first time

[motokochan]

(12-30-2010 05:45 AM)lucian0308 Wrote:  centos don't work

you must remove from suported OS

i try with debian and it work perfectly
from first time

Oddly, it works for me (as long as I'm on 1.0.6 - 1.0.7 requires special changes for an updated Perl) and I have two servers running it. One server is using RHEL 5u5, the other is CentOS 5.5 (equivalent of RHEL 5u5).

[lucian0308]

then write the correct documentation for it

the docs from archive is not correctly

[motokochan]

(12-30-2010 08:30 PM)lucian0308 Wrote:  then write the correct documentation for it

Sorry I was away for a while and others messed up the documentation. If their changes weren't added to the package, my original working instructions are still in the download.

I will not support 1.0.7 on RHEL5/CentOS 5 because it requires the replacing of a core system tool. Such a thing is completely untested and can cause stability problems. A the very least, it causes severe maintainability issues.

Use ispCP 1.0.6 and also tell the developers that you are unhappy about how they broke compatibility with an entire supported distro.

(12-30-2010 08:30 PM)lucian0308 Wrote:  the docs from archive is not correctly

I ran through the documentation, and although it wasn't ideal, it still works for an install on a publicly-accessible server.

[lucian0308]

am i happy with debian and ispcp 1.0.7
and i will use this for other tests

ty

[ajonate]

I'm sorry for posting while I'm in a bad mood, but I'm a bit of a grouch today. You see, I just spent the better part of 2 days fooling with CentOS 5.5 and ispcp 1.0.7. The two are simply incompatible, due to the fact that ispcp is too dependent on newer perl features that are not native to CentOS 5.5.

I first thought my problem was that I was using the 64 bit version of CentOS while the instruction was written for the 32 bit version. Accordingly I reinstalled the operating system with the 32 bit version. Unfortunately I got the same error messages generated. There is no way that anyone could run through the recipe and not see the broken dependency errors. Among other things, "courier-authlib" and "courier-imap" both had to be installed while ignoring dependencies.

And what's up with upgrading to perl 8? Ispcp 1.0.7 absolutely, POSITIVELY requires perl 10 or higher. And that's a problem.

You see, if you remove the old perl version then a lot of applications that depend on it won't have access to the new perl installation. You also lose your perl modules, since they are only registered to the original perl version. The best solution is to not remove the older version. That's what this recipe suggests.

http://www.kirsle.net/doc/perl510.html

At the end of the day, CentOS needs to be stripped and cobbled back together, then ispcp 1.0.7 is installed with rpm's that are force installed while ignoring dependencies. That's can help but create an unstable environment.

A better solution would be to not have the application be so dependent on perl modules. Witout perl modules the application will certainly be larger, but the alternative is what we see here.

(12-31-2010 07:28 AM)motokochan Wrote:  Sorry I was away for a while and others messed up the documentation. If their changes weren't added to the package, my original working instructions are still in the download.

I will not support 1.0.7 on RHEL5/CentOS 5 because it requires the replacing of a core system tool.

So you had instructions that worked, but someone came along and changed them so they didn't work, yet you've left them there. But it doesn't work anyway.

(12-31-2010 07:28 AM)motokochan Wrote:  I ran through the documentation, and although it wasn't ideal, it still works for an install on a publicly-accessible server.

I'm not sure what that means, but if the publicly-accessible server uses CentOS I kind of doubt it.

******

Okay, so now I'm faced with some practical choices.

1) Switch to Debian and install 1.0.7.
2) Stay with CentOS and install 1.0.6.
3) Seek a different software solution.

My only real reservation with Debian is that I've always used redhat distros (or those that are arranged like redhat) and I would prefer to avoid any more of a learning curve than I need to.