Re: DTC competition with ISPMAN

"Atif Ghaffar" <[email protected]> Sun, 16 Dec 2007 22:32:12 +0100
Newsgroups gmane.comp.isp.ispman.user
Message-ID <[email protected]>
--===============1968969959==
Content-Type: multipart/alternative; 
	boundary="----=_Part_7074_2861563.1197840732678"

------=_Part_7074_2861563.1197840732678
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Joerg,

You once did a database entity diagram  mockup for ispman.
Do you have it lying around somewhere for me to have a look again.

I am coming back to ISPman after 4 years of experience in ISPs and
database/directory and will see if I can jumpstart a re-write

thanks


On Mar 23, 2005 11:28 PM, J=F6rg Delker <[email protected]> wrote:

> thomas-5VVOt45T8ASrG/[email protected] wrote:
>
> >http://www.gplhost.com/?rub=3Dsoftwares&sousrub=3Ddtc
> >
> >
> >well, yeah, seriously nice with DTC
> >ISPMAN using ldap, DTC using mysql
> >
> >for those who don't interested in setting up ldap server, mysql might be
> >alternative choice for you. but, isn't openldap performance is faster
> than
> >mysql ? (also, I know once openldap being setup, it is not easy to break=
)
> >
> >that's your call, mysql or ldap :)
> >
> >
> Thomas,
>
> don't think of this in terms of mysql vs. ldap or solely performance.
>
> The decision, whether to use mysql or ldap for the backend repository is
> mostly driven by functionality and your environment's demands.
> MySQL is a classic RDBMS and thus very flexible when it comes to data
> handling (esp. queries) and storage of structured data. Is is quite easy
> to store arbitrary data, such as Logs, Traffic, or other transaction data=
.
> Unfortunately, (My)SQL lacks connection to many (professional) software
> products, typically used within ISP business, since there is no open
> protocol such systems could use.
>
> LDAP on the other hand is a *directory* service, providing fast access
> to hierarchical structured "objects", while having limitations on write
> performance and storage of arbitrary data.
> Extending schemas to store "other" data can be quite painful and
> requires good knowledge of LDAP specifications.
> The reason why LDAP is actually very popular, esp. with ISPs, is the
> open protocol and therefor the many systems that can connect to your
> directory. Besides that it is very easy to make it highly available by
> using replication.
>
> Actually, neither of those alone will fit the requirements of typical
> ISPs, because you certainly need a fast directory service for all your
> mail, calendar, web, ftp, samba, ... servers, which can't be provided by
> SQL servers.
> On the other hand, you need easy storage for that arbitrary data, you
> have to manage for your domains, which cries for a RDBMS.
>
> So...
> regarding ISPMan, choosing LDAP was the right choice, because it opened
> up to many other applications out there, using all those valuable
> directory data.
> But with rising functionality and growing demands, it has become more
> and more painful to extend the schema and store "other" data, such as
> transactional data (logs, traffic, etc.).
> We certainly can't drop LDAP, because this would mean imminent death to
> ISPMan , but to have a future with this software I believe we need both,
> LDAP *and* (My)SQL.
> Maybe MySQL as the main repository, provisioning LDAP with all necessary
> entries... not clear about that yet.
>
> Comments welcome...
>
> Joerg
>
>


--=20
best regards
Atif Ghaffar
http://atif.ghaffar.googlepages.com

------=_Part_7074_2861563.1197840732678
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Joerg,<br><br>You once did a database entity diagram&nbsp; mockup for is=
pman.<br>Do you have it lying around somewhere for me to have a look again.=
<br><br>I am coming back to ISPman after 4 years of experience in ISPs and =
database/directory and will see if I can jumpstart a re-write
<br><br>thanks<br><br><br><div class=3D"gmail_quote">On Mar 23, 2005 11:28 =
PM, J=F6rg Delker &lt;<a href=3D"mailto:[email protected]">[email protected]</a=
>&gt; wrote:<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px=
 solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class=3D"Ih2E3d"><a href=3D"mailto:thomas-5VVOt45T8ASrG/[email protected]">thomas@hkeas=
yhost.com</a> wrote:<br><br>&gt;<a href=3D"http://www.gplhost.com/?rub=3Dso=
ftwares&amp;sousrub=3Ddtc" target=3D"_blank">http://www.gplhost.com/?rub=3D=
softwares&amp;sousrub=3Ddtc
</a><br>&gt;<br>&gt;<br>&gt;well, yeah, seriously nice with DTC<br>&gt;ISPM=
AN using ldap, DTC using mysql<br>&gt;<br>&gt;for those who don&#39;t inter=
ested in setting up ldap server, mysql might be<br>&gt;alternative choice f=
or you. but, isn&#39;t openldap performance is faster than
<br>&gt;mysql ? (also, I know once openldap being setup, it is not easy to =
break)<br>&gt;<br>&gt;that&#39;s your call, mysql or ldap :)<br>&gt;<br>&gt=
;<br></div>Thomas,<br><br>don&#39;t think of this in terms of mysql vs. lda=
p or solely performance.
<br><br>The decision, whether to use mysql or ldap for the backend reposito=
ry is<br>mostly driven by functionality and your environment&#39;s demands.=
<br>MySQL is a classic RDBMS and thus very flexible when it comes to data
<br>handling (esp. queries) and storage of structured data. Is is quite eas=
y<br>to store arbitrary data, such as Logs, Traffic, or other transaction d=
ata.<br>Unfortunately, (My)SQL lacks connection to many (professional) soft=
ware
<br>products, typically used within ISP business, since there is no open<br=
>protocol such systems could use.<br><br>LDAP on the other hand is a *direc=
tory* service, providing fast access<br>to hierarchical structured &quot;ob=
jects&quot;, while having limitations on write
<br>performance and storage of arbitrary data.<br>Extending schemas to stor=
e &quot;other&quot; data can be quite painful and<br>requires good knowledg=
e of LDAP specifications.<br>The reason why LDAP is actually very popular, =
esp. with ISPs, is the
<br>open protocol and therefor the many systems that can connect to your<br=
>directory. Besides that it is very easy to make it highly available by<br>=
using replication.<br><br>Actually, neither of those alone will fit the req=
uirements of typical
<br>ISPs, because you certainly need a fast directory service for all your<=
br>mail, calendar, web, ftp, samba, ... servers, which can&#39;t be provide=
d by<br>SQL servers.<br>On the other hand, you need easy storage for that a=
rbitrary data, you
<br>have to manage for your domains, which cries for a RDBMS.<br><br>So...<=
br>regarding ISPMan, choosing LDAP was the right choice, because it opened<=
br>up to many other applications out there, using all those valuable<br>
directory data.<br>But with rising functionality and growing demands, it ha=
s become more<br>and more painful to extend the schema and store &quot;othe=
r&quot; data, such as<br>transactional data (logs, traffic, etc.).<br>We ce=
rtainly can&#39;t drop LDAP, because this would mean imminent death to
<br>ISPMan , but to have a future with this software I believe we need both=
,<br>LDAP *and* (My)SQL.<br>Maybe MySQL as the main repository, provisionin=
g LDAP with all necessary<br>entries... not clear about that yet.<br><br>
Comments welcome...<br><br>Joerg<br><br></blockquote></div><br><br clear=3D=
"all"><br>-- <br>best regards<br>Atif Ghaffar<br><a href=3D"http://atif.gha=
ffar.googlepages.com">http://atif.ghaffar.googlepages.com</a>

------=_Part_7074_2861563.1197840732678--


--===============1968969959==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
--===============1968969959==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Ispman-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ispman-users

--===============1968969959==--