Emulate DFS virtual netbios name

[Nicolas Ecarnot]

Dear all,

Presently using a mixed architecture IT (Windows / Linux), we are still 
actively using parts of Microsoft's DFS functions :
- publishing remote shares amongst a unique tree
- sharing this whole hierarchy as \\uniqueName
and that on our hundred remote sites.

We absolutely do not use any replication with MS-DFS.

* DFS publishing
This first point is supported by Samba with msdfs directive, and it is 
working.
In Microsoft's implementation of DFS, the schema is :
- the client is browsing a local server tree
- when reaching a DFS link, the DFS server silently informs the client 
of the new target - the remote server
- the client now browse the remote server tree, but still displays the 
path as a subfolder of the local server
- the local server is not used anymore - client and remote server are 
speaking directly

We don't know whether samba's implementation of MSDFS links is working 
the same : once client and remote server get connected, does the local 
server gets useless?

* \\uniqueName share
Microsoft's DFS allows to publish a global share with a name that can be 
the same amongst many remote sites.
This publication is supported by a dfs.exe process running on many 
servers. The setup of the DFS root and its links can be stored in Active 
Directory, and thus spread and backuped.
The benefit is that the users can access the share via \\uniqueName, 
whichever site they are.
In case one server shuts down, the netbios name is still resolved by the 
other remote servers, and the DFS root is still available.

We are trying to find a way to emulate this function.

** Network issue
CTDB can publish a common netbios name amongst many cluster nodes, 
supported by a round-robin DNS A-record, so that would make the trick.
But the idea would be to setup servers in different remote sites, each 
with local network scheme. Issue = those remote servers could not handle 
any remote IP address.



I guess that many sysadmins don't bother with such a setup, but reading, 
searching and testing eventually lead me to think there is no complete 
solution - even a complex one - to answer every issue.

I'd be glad to discuss those points with you, to prove me wrong.

-- 
Nicolas Ecarnot