1) I'm a semi security freak, and i've been using a lot of control panels that operate on a totally independent port from Apache. I'm wondering if you guys could get the control panel to work on a separate Apache instance (or possibly a lightweight HTTPS engine) so not to confuse things for some ?

2) Why not attempt to integrate HORDE IMP into the installation for webmail? I've been considering tackling this problem, but I've yet to find a suitable horde debian install that actually works

Just some thoughts....

we integrated squirrelmail.
(instead of horde)

thats because squirrelmail is secure, active developed (yes i know horde, too) and a lot of enhancements were available.
You're free to make a theme for horde, too - then we can present our users a second alternative.
For now we made a theme for squirrel - and i think thats miles better already than uebimiau or whatever this mail app was called with the discontinued development since 2002 (which is the mailer in vhcs2) .

And squirrel is compatible to most browsers (only few javascript used etc) .
Our Intention was to provide a stable alternative.
We've probably have to look that we can support the debian squirrel - package as well but thats something far away atm because the squirrel we use is actually enhanced a lot.

Regarding your first question :
we thought that making the panel(login) a separate vhost (defaults to admin.yourdomain.tld) is a good idea (and needed because only that SuExec user (vu2000) may access the files of the panel.
You're free now to add https to that vhost, too.
(later we will integrate a SSL - wizard maybe as well for the panel itself)

Hi
if I may add something...
Squirrel really *is* a big step forward from uebimau. I'm more a "horde type"... :-)

The thing with making this or that extension compatible to ispcp is the lack of a good extension api - so you have to give good support for your application - when there is a security update for it you have to provide an update for the ispcp version... this is not as efficint as programmers or admins like it.
I'd rather think of: taking the original application and adding/replacing some lines of code to make ist ispcp compatible...

Now there are plans to make this better with ispcp (not omega). So the question is:
how do theese plans look like, what about ispcp omega, when will ispcp start, what are the most important "fixpoints" for this project...
I think soon it's time to have a look at theese things... (most of the other control panels are working on their new modular version - it's hight time to start this with ispcp.

/joximu

yes we know that.

Our planning for ispCP is just some orientation notes for now.
But the path is clear -> a bit buzz :

* plugin architecture ala typo3 (extend each and everything even write a plugin for a plugin etc)
that means object-orientated styles with the possibility to hook objects into the procedures.
* Inter Communication soap prefered
* central storage (the one which has to be distributed over the servers) ldap
* storage on the "master(s)" server per adodb (mysql,pgsql whatever you like & is supported by adodb - favorite is mysql)

* agents on clientservers are plugin-ready as well (to support different servers and services)

mh thats all for now Ideas ? Comments ?

Hi Ephigenie
yeah - sounds good but smells of alot of work... (literally translated from german :-)

My comments/ideas to this:
give the lead for ispcp omega to someone else (e.g. when 1.0 is released) and focus on ispCP "reloaded". Omega is for small installations, the new one for bigger - there are other rules and other "competitors"... I don't think that omega will be replaced by the other - they will have both their place.

Is there a place to discuss the ideas and also to compare omega with other projects - maybe in "Small talk"??
What do you think?

/joximu

yeah in Development thats what it is - isn't it ?

but it's not omega... :-) - ok, we stay here...

I think it would be great if there is a sort of comparison table where is ispCP omega compared to the other control panels, with some reasons, why some things are solved differently.
ispconfig is more a complete system (like plesk :-( - SysCP does store mailbox infos in the database (has pros and cons - when DB is down... :-) - and alot of other things.
On my journey to find a good cp I came also to "GNU Hosting Helper" - seems to be very modular (but ugly). There are a lot of other CP near the known. Eg baifox, ispman and some really small projects. The point is to keep the balance between reinventing everything and bringing all together to one big thing...

This comparison table also should help to build the new panel.

Another suggestion:
add another category to the tickets:
installer/update script
there are now some tickets active which are things in the installer - and this is another big part (first it's perl and then there are other people already busy with equal things...)

yes indeed thats a good idea.

Perhaps we shall begin with pointing out whats maybe good in general on the one or other panel out there.

Lets start with ispman - the concept is really nice
which means (they use ldap for storage things )
and they've the same agent - master concept i'd like to have

second - syscp
the new 1.4 has a nice code-design (everything in modules with hooks available to place plugins in there)

well, I couldn't test all of them :-/

To SysCP 1.2.16: the concept is very likely to ispCP - except oft fastcgi. The possibility to install somewhere and then getting the options via web interface which have to be written into the different config files I liked very much. For me they did the best separation control panel <-> official/standard packages.

I couldn't install ispMan (because LDAP is still to less important for me) - the concept really seems to be also for big players...

ok, to have a good overview, it'd be nessesary to have a closer look at the more than 20 FOSS control panels... hm... is there someone having the time???