Re: news?

Hi Joerg,



On 10/25/05, Joerg Delker <[email protected]> wrote:
>
> I'm planing on having four major blocks with the next generation of
> ISPMan:
> 1) an encapsulated backend
> * contains all business logic
> * does no provisioning at all (totally enclosed!)
> * runs on RDBMS
> * feed to LDAP
> * complete webservice (SOAP) interface for interaction
> * single instance
> * probably a J2EE application (under evaluation, due to much better
> WS handling)


I am ok on all points. Is it neccessary to bring in J2EE. Nothing against it
but will make more difficult to modify for non-programmers.
The app is used mostly by system administrators and they can usually hack on
perl/php etc more easily.
PS: What is WS handling?

Moving LDAP out and feeding it via RDBMS is ok too. We are also doing
something similar here at my employer but mainly due to the reason that they
were running RDBMS already and we brought in LDAP to take away some load
from the DB.




2) frontend agent
> * does the provisioning work (as ispman-agent)
> * runs on every box to be provisioned
> * calls backend via SOAP
> * most probably PERL (due to better flexibility/connectivity)
>
> 3) frontend CLI
> * a basic set of of CLI commands for manual/batch jobs
> * call backend via SOAP
>
> 4) frontend UI
> * runs the admin/customer interface
> * interacts via SOAP with backend
> * may be any of PHP, Perl, JSP, Python, whatever...
>
> > And any chance to use ISPMan with LDAP/SASL/SSL?
>
> The main repository will shift to an RDBMS.
> At front, I had quite some objections against this idea (being a "LDAP
> guy" ;), but as it turned out, this is the only reasonable way to go.
> Nevertheless, LDAP is a very integrational part of about any ISP, so
> this must be accounted for. The current idea is, to feed the LDAP
> (a)synchronously from the RDBMS.
> Thus, the LDAP connection isn't that sensible anymore regarding security.
> Despite of that, security (most probably in form of SSL) will/must be
> realized for all external protocols (esp. SOAP via https).
>
> > We modified ISPMan with a more restrictive structure to allow access
> > to public hosting, but have installed ISPMan over a hard FreeBSD jail
> > structure. I don't like to see ldap/cyrus password's in plain text on
> > a hosting server.
>
> That'll be always a problem, because the agent on the hosted machine
> needs a "trusted" connection to the backend, thus requiring at least on
> secret credential (password/certificate/...).
> As long as you allow foreign root access on such machines, I see no way
> to prevent spoofing.
>
> > I have modified the ISPMan schema and the source to allow selling
> > public resellers/client account's and enforce limit for mail, vhosts,
> > database and dns accounts with a complete control over each level.
>
> Sounds good! Current ISPMan really lacks on this issue.
> I'll post my idea of an RDBMS schema to this list, so anyone
> can look over it, and add anything that might be missing.
>
> > Some screen shot's:
> > http://novo.dotpix.com.br/aberto/site.conteudo.Telas
>
> Hmm... looks nice (a bit small, though ;)
> You may be a good candidate to work on block 4 (frontend UI)
>
> > What about a 'TODO List' for the new ISPMan platform? I think that
> > user like us can contribute for a more focused solution on enterprise
> > class hosting service.
>
> That's a good idea.
> How about using the RFE List on SF for that, to get it tracked properly.
>
> > Some suggestions:
> Some comments
>
> > Secure communication between agents and directory.
> Will be an integrational part
>
> > Secure password storing for ISPMan agent's.
> What do you consider "secure"?
> Secure from whom?
>
> > More control over account hosting resources.
> We need to specify this in more detail
>
> > Plug in API for adding new services like: database's, cms's, forums,
> > etc.
> I desperately hope, that we'll get there eventually ;)
> Going with SOAP this will become already more flexible/pluggable.
>
> My thoughts,
> Joerg
>
>
>


--
best regards
Atif Ghaffar