PDA

View Full Version : What was the most difficult part of installing 4.0?


jstanden
02-29-2008, 05:44 AM
Even though 4.0 makes a lot of things much easier -- guided installer, upgrading, patching, group configuration, scheduled jobs -- we've introduced some new requirements like PHP5 and its extensions IMAP and Mailparse.

The new requirements allow us to develop faster and produce more efficient software, but consequently by using more cutting-edge technology we're less compatible with many discount shared hosting accounts.

It's tough to increase the capabilities of Cerberus Helpdesk without adding any technical complexity. I think we're doing a good job, but we're obviously still a long way from a simple installation for people who just want e-mail up and running (short of our Hosted Cerberus offerings, of course).

What did you find the most difficult when installing Cerberus Helpdesk 4.0?

hxc
02-29-2008, 02:22 PM
I own a small hosting company on a tier 1 network that provides everything required to host Cerb4 very inexpensively. We'll even install it for customers at no charge and provide weekly svn updates. While I realize this conflicts with your hosted solution, might you eventually post a list of Cerb4 compatible hosts? If so, we'd love to be on it!

jstanden
02-29-2008, 09:26 PM
Hey hxc,

We welcome the competition. ;)

We've definitely thought of trying another XSP type approach for outside hosting resellers (and automation).

I also agree that it would help to refer our community to hosts that can provide PHP5/Mailparse/IMAP/memcached/Subversion with decent backups and support. With the minimum requirements being a little higher than 3.x we could use the help. The XSP approach would try to do some profit-sharing with the hosts, offset by them doing some marketing. Though XSP isn't technically necessary, a VAR would work just as well.

Send me an e-mail or PM if you'd like to discuss this further.

Thanks!

hxc
02-29-2008, 10:27 PM
PM sent. Subject: Outside Web Hosting for Cerb4

Thanks Jeff!

CWasko
03-01-2008, 05:17 PM
I think the hardest part was just meeting the requirements. I'm lucky enough to have plenty of CPU and HD space on a virtual server that I just created another VM, ran Fedora in it, and got all the extensions through yum. It took about 30 minutes of my time - once I decided to do that path.

chewtoy
03-04-2008, 04:23 PM
I had some post-install problems related to using the back button during the install process. I ended up with duplicate users and duplicate groups, and that caused quite a bit of confusion.

Luckily I kind of expected it, understanding that it was possible that going back and forward would cause problems later. However, it would be better if the installer had its own "previous" link and was also written to summarize all the settings at the end before actually committing to the install, giving an opportunity to change things.

I also didn't get the apache mod_rewrite stuff working correctly, but that wasn't a big deal -- I just took it back out and went on.

jstanden
03-05-2008, 12:59 AM
I had some post-install problems related to using the back button during the install process. I ended up with duplicate users and duplicate groups, and that caused quite a bit of confusion.

Yeah, that's something we actually just talked about over here at WGM this morning.

I'd like to split up the installation part from the guided setup part. It would likely help people out a lot more if everything installed and a simple superuser account was created.

The first logins from a superuser could prompt for the guided setup to create workers, groups and routing. But it would become entirely optional, and not mix understanding the 4.0 concepts with just getting the script running.

Splitting the two concepts would also allow us to do paid installations and hosted helpdesk installations without having to complete the guided setup with dummy information.

It would also make the installation process even simpler, and would be more "back-button friendly". :)

jstanden
03-05-2008, 01:03 AM
I also didn't get the apache mod_rewrite stuff working correctly, but that wasn't a big deal -- I just took it back out and went on.

Yeah, that's why the default is off. The "/cerb4/index.php/tickets" style URLs aren't too bad -- we still haven't tweaked our MediaWiki to get rid of them. ;)

I wish it was easier for us to check for Apache/IIS configuration and detect mod_rewrite from our PHP installer.

Crazy-Software
03-05-2008, 01:15 AM
Getting the MailParse extension enabled was my biggest problem. After installation all seems great. Although I would love to see the customer screen more user friendly like in previous versions I have seen in other places.

I hope to see many improvements soon with this.... Specifically the Support-Center section....

jpowell
03-24-2008, 11:54 PM
Have you folks put any thought into creating vmware and/or XenServer Virtual Appliances?

It is a great way to evaluate software, and often even for the production install. Many of your potential customers (especially those in the web-hosting business, though I am not) have access to virtual servers.

Take a look at http://www.rpath.com/corp/products/products.html

Using rpath you can build vmware, XenServer and other Virtual Appliances with all the dependencies working up front.

Just a thought.

JP

Hildy
03-25-2008, 10:32 PM
We've talked somewhat about virtual servers (setup and ready to go), but we've talked more about doing a whole package deal, with XAMPP, etc, where it would be a single download / install and everything is already there where it belongs.

We're also very seriously looking into how we can lower the bar to entry. The IMAP and mbstring extensions don't seem to cause a lot of problems, but the mailparse one tends to be a hangup for getting installed on shared hosting. Obviously, the ideal solution is to host with someone who will support it, or to have us here at WGM host the helpdesk, but a lot of people don't want to do that for one reason or another, and so we're exploring gracefully degrading (e.g. from mailparse to PEAR's mail handling).

There's a limit to how much we want to give up, though, in the name of being able to run on every conceivable system. We've been down that road before, and it's not the way to get good, fast, or efficient code. ;-)

hxc
03-26-2008, 12:16 AM
and so we're exploring gracefully degrading (e.g. from mailparse to PEAR's mail handling).

Personally, it's my belief that much of the problem of installing mailparse is really related to directing people to use the PECL/PEAR/RPM installers instead of providing instructions to compile from source. I've used the following procedure on several different platforms, including cPanel, and it's worked every single time:

wget http://pecl.php.net/get/mailparse-2.1.1.tgz
tar xvzf mailparse-2.1.1.tgz
cd mailparse-2.1.1
phpize
./configure
make
make install

Then edit your php.ini and add:

extension=mailparse.so

Before you degrade the code, why not try upgrading the installation documentation to provide a solution to the problem that works for the greatest proportion of your target audience?

Hildy
03-26-2008, 08:06 PM
Well, the installation documentation already references a very nice writeup by BlueC on this: http://wiki.cerberusdemo.com/index.php/Installing_PHP_Mailparse#From_source_code

If you think it needs cleaned up / reiterated / restated in a different fashion, any registered user can edit the install docs on the wiki (we *do* monitor all changes, though).

hxc
03-26-2008, 10:00 PM
I think BlueC did a wonderful job on the writeup, but you're missing my point.

1.) Do a search in the forums for PECL.
2.) Now notice the thousands of views related to those posts.

Were you to stop directing people to use PECL/PEAR/RPM entirely and compile from source from the very start, then I think most of the problems with mailparse will go away and code degradation will not be necessary.

Just my two cents ;)

g00fy
05-26-2008, 10:03 AM
In fact FINDING the SVN url to download was the most difficult part of all :p.

I think it should be mentioned on the download page or so... Now it's very hard to find.

goodgirl
08-18-2008, 04:13 AM
Is there a guide how to convert the database from 2.6.x to cerb 4 ?

Apart from a guide how to convert, a list of issues to expect would also be helpful.
For example is there any data from 2.x that would not be restored when converting, any settings that would not apply anymore due to changes in functionality.

A list of features that were removed since 2.x.

Also some more detailed help about Mailparse installation would be good.
The server I tried to test cerb 4 on doesnt have pecl (CentOS 5).

hxc
08-18-2008, 01:26 PM
Is there a guide how to convert the database from 2.6.x to cerb 4 ?

Apart from a guide how to convert, a list of issues to expect would also be helpful.
For example is there any data from 2.x that would not be restored when converting, any settings that would not apply anymore due to changes in functionality.

A list of features that were removed since 2.x.

Also some more detailed help about Mailparse installation would be good.
The server I tried to test cerb 4 on doesnt have pecl (CentOS 5).
I can't help you with the 2.6 to 4.0 conversion, but for mailparse you might give this a try:

http://cpanelhostingsolutions.com/blog/2008/04/07/how-to-install-mailparse-from-source/

WJeff
09-04-2008, 08:35 PM
ooo.... VMware prebuilt Appliance..... What an awesome idea!