Andreas Jellinghaus | 1 Oct 01:42 2002
Picon

Re: FAQ: flexible administration of multiple kolab servers

dns does not allow _ in names.

> e.g. hans_mayer_kde_org.kde.org points to kolab.kde.org in our case.

andreas
Martin Konold | 1 Oct 08:09 2002
Picon

Re: FAQ: flexible administration of multiple kolab servers

On Tuesday 01 October 2002 01:42 am, Andreas Jellinghaus wrote:

Hi,

> dns does not allow _ in names.
>
> > e.g. hans_mayer_kde_org.kde.org points to kolab.kde.org in our case.

Yes, you have a point. Actually it looks like newer version of DNS do allow it 
but the 1985 (sic!) RFC 952 explicitly mentions only A-Z, . and - as beeing 
allowed in names. The special meaning of the . is well known.

Side Note: This rather old RFC also makes other rules which are not followed 
today anymore like the naming of gateways...

On the other hand this RFC does not forbidd using double hyphens?!

What about changing from "_" to hyphen "-"?

Yours,
--martin
P.S.: All my tests with recent DNS servers did work without problems.

--
Dipl.-Phys. Martin Konold
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Germanenstrasse 15, 70563 Stuttgart, Germany
email: martin.konold <at> erfrakon.de
(Continue reading)

Brad Hards | 1 Oct 09:21 2002
Picon

Re: FAQ: flexible administration of multiple kolab servers


On Tue, 1 Oct 2002 16:09, Martin Konold wrote:
> > dns does not allow _ in names.
> >
> > > e.g. hans_mayer_kde_org.kde.org points to kolab.kde.org in our case.
> What about changing from "_" to hyphen "-"?
"DNS and Bind", 4th ed. pp 77,  says 

* A hyphen is allowed in the middle of  of a label.
* Underscores are not allowed in hostnames.

AFAICT, underscores are OK just about anywhere else, and are required in SRV 
records.

Brad
--

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Aust. Tickets booked.
Tassilo Erlewein | 1 Oct 10:53 2002
Picon

Re: Web interface frontend

Hi Lutz,

sorry for my late answer. I find your ldap postfix findings quite useful.
We think heavily about getting the whole server config into a special 
access-restricted LDAP object.

However I'm not so sure it's generally good to have the daemons
get their running config directly from LDAP (where possible)

So I would propose the following:

- have the web interface only interact with ldap
- provide a backend (perl) that reads stuff from ldap and
  fills out config file templates 

How do you think about that ?

Note that it's possible to arrange for special settings in the config file 
templates that don't get overwritten by the backend. So it would be possible 
for you to have postfix fetch whatever it supports directly from ldap.

My understanding is, that requires we stay postfix conformant with regard to 
the ldap config object. So what you point out here could be very useful. 
Please let me know further requirements like this, if you like.

Thanks

Tassilo

Am Montag, 30. September 2002 12:07 schrieb Lutz Badenheuer:
(Continue reading)

Tim Jansen | 1 Oct 20:00 2002
Picon

Re: FAQ: flexible administration of multiple kolab servers

On Monday 30 September 2002 07:43, Martin Konold wrote:
> The proposed solution to this issue is to use the _very_ scalable DNS for
> our purposes.
> Basically we add for every account an A record in DNS which is pointing to
> the correct kolab server.
> e.g. hans_mayer_kde_org.kde.org points to kolab.kde.org in our case.

Having thought about it... how can DNS help to make it more scalable? DNS does 
not scale because the DNS servers have the fastest databases on earth and the 
protocol is so fast. If you have 20 Million users/hosts in the .kde.org 
domain the DNS server still has to search through all 20 million users/hosts. 

DNS scales because you can distribute the entries. So if you have 20 million 
users, you can create 20 subdomains like hans_mayer_kde_org.subdomain.kde.org 
with 1 million users per subdomain. But you can do exactly the same with 
LDAP, AFAIK. So I dont see the point in introducing DNS and its additional 
complexity.

bye...
Andreas Jellinghaus | 2 Oct 08:04 2002
Picon

Re: Web interface frontend

Tassilo Erlewein wrote:
> However I'm not so sure it's generally good to have the daemons
> get their running config directly from LDAP (where possible)

hmm. i know lots of people using databases and then dump configs,
so the running service does not need the database.
you seem to suggest this when you write:
> - provide a backend (perl) that reads stuff from ldap and
>   fills out config file templates 

but for ldap i like the direct access, as ldap can replicate
quite easy and thus provide a high available solution.

also i would like to question: then why a new project.
there are several projects with the webfrontend -> database -> perl ->
config file idea out there, for that approach it might be usefull to
adapt one of them. i personaly do not see the advantage of storing data
in ldap, when it is later processed to config files.

also i do not see an advantage in ldap, if the config is split into
several objects (i guess this is necessary, if you want to seperate
public items such as users and private data such as
maildrop/mailacceptinggeneralid).

my personal view of ldap is: its a store for public data.
if my data is not public, i better not put it into ldap.
userpassword is ok as an excemption.

> So I would propose the following: 
> - have the web interface only interact with ldap
(Continue reading)

Paul de Vrieze | 2 Oct 11:59 2002
Picon
Picon

Re: FAQ: flexible administration of multiple kolab servers

On Tuesday 01 October 2002 20:00, Tim Jansen wrote:
>
> Having thought about it... how can DNS help to make it more scalable? DNS
> does not scale because the DNS servers have the fastest databases on earth
> and the protocol is so fast. If you have 20 Million users/hosts in the
> .kde.org domain the DNS server still has to search through all 20 million
> users/hosts.

Ever heard of hashing tables?
If you need to look up a word in the dictionary you don't start with the first 
word, and read through until you find the word you are interested in. If the 
word starts with a P you start searching somewhere in the middle of the book 
and you skip pages as you are gradually going to the word you are looking 
for. Hashing tables work similarly, except that they use something called a 
hashing function to calculate a hash of the word you are looking for. The 
hash table has a (large) number of buckets in which words are put. The hash 
determines in which bucket the system starts to look. This is speed efficient 
(though memory intensive).

Paul

--

-- 
Paul de Vrieze
Junior Researcher
Mail: pauldv <at> cs.kun.nl
Homepage: http://www.devrieze.net
Tim Jansen | 2 Oct 19:31 2002
Picon

Re: FAQ: flexible administration of multiple kolab servers

On Wednesday 02 October 2002 11:59, Paul de Vrieze wrote:
> On Tuesday 01 October 2002 20:00, Tim Jansen wrote:
> > Having thought about it... how can DNS help to make it more scalable? DNS
> Ever heard of hashing tables?

1. The point, that I was trying to make, is that there is no reason why DNS 
should be faster than LDAP, so DNS just increases complexity without adding 
any advantage
2. AFAIK no database uses hash tables. The problem is that inserting new items 
becomes too expensive when the table is full and needs to be resized. 

bye..
Andreas Jellinghaus | 3 Oct 01:51 2002
Picon

Re: FAQ: flexible administration of multiple kolab servers

dns can be very fast and effective.

i think the djbns has one file per value?
and a filesystem like ext2/3 with the new hashes or reiserfs
can handle that very well.

any db file or similiar storage (used in ldap and sql servers) is also
fast. and even though i don't know the bind internals, i guess it is
reasonable fast, too, since the domain server are run with million
domains.

bu i heard storries about bind loading .com and similiar domians
requireing hours? so i guess  bind/dns is not meant as a flexible
solutions. big zones like .de or .com reload once every 24h?

on the other side i now big providers using a two stage model:
first stage accepts connections, caches, etc. and then
communucates with a second stage, a storage server.

the first stage is usualy managed with loadbalancers or round robin.

also the first/second stage concept is nice when it commes to
moving data: the first stage can block for a while,
till the move is completed. i don't know how anyone would
handle moving data in a single stage system, I'd be interested to hear.

andreas
Martin Konold | 3 Oct 10:50 2002
Picon

Re: FAQ: flexible administration of multiple kolab servers

On Wednesday 02 October 2002 07:31 pm, Tim Jansen wrote:

Hi,

> 1. The point, that I was trying to make, is that there is no reason why DNS
> should be faster than LDAP, so DNS just increases complexity without adding
> any advantage

There are multiple advantages. 
- No need for extra client support. The scheme can be used by all clients 
without modification
- extra scalability via lacy caching
- availabilty of an enourmeous amount of already installed infrastructure aka 
dns servers
- passes firewalls easily
- last but not least only data which is actually really used is cached
- LDAP replication does not scale as good as DNS therefore

Regards,
--martin
--
Dipl.-Phys. Martin Konold
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Germanenstrasse 15, 70563 Stuttgart, Germany
email: martin.konold <at> erfrakon.de

Gmane