msdfs referrals at share-level
hello everybody, as far as i have looked into msdfs.c it seems to be impossible to send a client a dfs-referral at the share level (\\fileserver\msdfs-link). maybe there is another way to "proxy" a request to \\samba\thisshare to \\anothersamba\thatshare ? i currently want to migrate a couple of nt-servers transparently for clients. the basic idea is to setup one samba-server that offers faked file-service via netbios-aliases and dfs-redirects to the real samba-fileserver. unfortunatly touching the clients is a no-go. old setup with *nt*: client -> //fileserver/share1 planned setup with *samba*: client -> //fileserver/share1 where share1 -> msdfs:samba-file\whatever any help is much appreciated. bye, guenther -- Guenther Deschner [EMAIL PROTECTED] SuSE Linux AGGnuPG: 8EE11688 Berliner Str. 27 phone: +49 (0) 30 / 430944778 D-13507 Berlin fax: +49 (0) 30 / 43732804 msg02877/pgp0.pgp Description: PGP signature
Re: msdfs referrals at share-level
Hi, Clients do request dfs referrals for every share they connect to. In a dfs reply for a share, you could try and send a different sharename and see what happens. I don't know if clients will be able to handle this. Look for self_referral in the setup_dfs_referral() code to find out where to start making changes. Let me know how the clients take it.. Thanks, Shirish - Original Message - From: "Guenther Deschner" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, September 04, 2002 2:48 PM Subject: msdfs referrals at share-level hello everybody, as far as i have looked into msdfs.c it seems to be impossible to send a client a dfs-referral at the share level (\\fileserver\msdfs-link). maybe there is another way to "proxy" a request to \\samba\thisshare to \\anothersamba\thatshare ? i currently want to migrate a couple of nt-servers transparently for clients. the basic idea is to setup one samba-server that offers faked file-service via netbios-aliases and dfs-redirects to the real samba-fileserver. unfortunatly touching the clients is a no-go. old setup with *nt*: client -> //fileserver/share1 planned setup with *samba*: client -> //fileserver/share1 where share1 -> msdfs:samba-file\whatever any help is much appreciated. bye, guenther -- Guenther Deschner [EMAIL PROTECTED] SuSE Linux AGGnuPG: 8EE11688 Berliner Str. 27 phone: +49 (0) 30 / 430944778 D-13507 Berlin fax: +49 (0) 30 / 43732804
Re: msdfs referrals at share-level
hello shirish,
we made some more experiments with the dfs-code and now have a running
solution for our smb-proxy, without breaking msdfs (well, i didn't had a
look on the dfs_rpc-pipe for now...)
you can now have a samba-share behave like an mdfs-symlink.
if you set a share to "msdfs proxy = yes" and declare the link in its
path to "msdfs link name = linkname" the clients will reveive correct
referrals already when they access the share :)
since we are planning to use this patch in production, it would be very
nice if you could comment on this.
-8<--snip--8<--
add to smb.conf:
[global]
host msdfs = yes
[dfs-fake]
path = /export/dfs-fake
msdfs root = yes
msdfs proxy = yes
msdfs link name = "linkname"
create a link:
ln -s msdfs:unimak\\storage /export/dfs-fake/linkname
->8--snap-->8--
thanks a lot,
guenther
On Thu, Sep 05, 2002 at 09:50:51AM -0700, Shirish Kalele wrote:
> Hi,
>
> Clients do request dfs referrals for every share they connect to. In a dfs
> reply for a share, you could try and send a different sharename and see what
> happens. I don't know if clients will be able to handle this. Look for
> self_referral in the setup_dfs_referral() code to find out where to start
> making changes.
>
> Let me know how the clients take it..
>
> Thanks,
> Shirish
>
> - Original Message -
> From: "Guenther Deschner" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 04, 2002 2:48 PM
> Subject: msdfs referrals at share-level
>
> hello everybody,
>
> as far as i have looked into msdfs.c it seems to be impossible to send
> a client a dfs-referral at the share level (\\fileserver\msdfs-link).
>
> maybe there is another way to "proxy" a request to \\samba\thisshare to
> \\anothersamba\thatshare ?
>
> i currently want to migrate a couple of nt-servers transparently for
> clients. the basic idea is to setup one samba-server that offers faked
> file-service via netbios-aliases and dfs-redirects to the real
> samba-fileserver. unfortunatly touching the clients is a no-go.
>
> old setup with *nt*:
>
> client -> //fileserver/share1
>
> planned setup with *samba*:
>
> client -> //fileserver/share1 where share1 -> msdfs:samba-file\whatever
>
> any help is much appreciated.
>
> bye,
> guenther
> --
> Guenther Deschner [EMAIL PROTECTED]
> SuSE Linux AGGnuPG: 8EE11688
> Berliner Str. 27 phone: +49 (0) 30 / 430944778
> D-13507 Berlin fax: +49 (0) 30 / 43732804
>
>
--
Guenther Deschner [EMAIL PROTECTED]
SuSE Linux AGGnuPG: 8EE11688
Berliner Str. 27 phone: +49 (0) 30 / 430944778
D-13507 Berlin fax: +49 (0) 30 / 43732804
--- source/param/loadparm.c Thu Oct 10 00:26:52 2002
+++ source/param/loadparm.c Mon Oct 14 14:21:08 2002
@@ -408,6 +408,8 @@
BOOL bInheritPerms;
BOOL bInheritACLS;
BOOL bMSDfsRoot;
+ BOOL bMSDfsProxy;
+ char *bMSDfsLinkName;
BOOL bUseClientDriver;
BOOL bDefaultDevmode;
BOOL bNTAclSupport;
@@ -533,6 +535,8 @@
False, /* bInheritPerms */
False, /* bInheritACLS */
False, /* bMSDfsRoot */
+ False, /* bMSDfsProxy */
+ NULL, /* bMSDfsLinkName */
False, /* bUseClientDriver */
False, /* bDefaultDevmode */
True, /* bNTAclSupport */
@@ -1107,6 +,8 @@
{"MSDfs options", P_SEP, P_SEPARATOR},
{"msdfs root", P_BOOL, P_LOCAL, &sDefault.bMSDfsRoot, NULL, NULL, FLAG_SHARE},
+ {"msdfs proxy", P_BOOL, P_LOCAL, &sDefault.bMSDfsProxy, NULL, NULL,
+FLAG_SHARE},
+ {"msdfs link name", P_STRING, P_LOCAL, &sDefault.bMSDfsLinkName, NULL, NULL,
+FLAG_SHARE},
{"host msdfs", P_BOOL, P_GLOBAL, &Globals.bHostMSDfs, NULL, NULL, 0},
#endif
@@ -1754,6 +1760,8 @@
FN_LOCAL_STRING(lp_veto_oplocks, szVetoOplockFiles)
FN_LOCAL_STRING(lp_driverlocation, szPrinterDriverLocation)
FN_LOCAL_BOOL(lp_msdfs_root, bMSDfsRoot)
+FN_LOCAL_BOOL(lp_msdfs_proxy, bMSDfsProxy)
+FN_LOCAL_STRING(lp_msdfs_link_name, bMSDfsLinkName)
FN_LOCAL_BOOL(lp_autoloaded, autoloaded)
FN_LOCAL_BOOL(lp_preexec_close, bPreexecClose)
FN_LOCAL_BOOL(lp_rootpreexec_close, bRootpreexecCl
Re: msdfs referrals at share-level
ops. patch is against 2_2 - cvs.
On Mon, Oct 14, 2002 at 03:36:04PM +0200, Guenther Deschner wrote:
> hello shirish,
>
> we made some more experiments with the dfs-code and now have a running
> solution for our smb-proxy, without breaking msdfs (well, i didn't had a
> look on the dfs_rpc-pipe for now...)
>
> you can now have a samba-share behave like an mdfs-symlink.
> if you set a share to "msdfs proxy = yes" and declare the link in its
> path to "msdfs link name = linkname" the clients will reveive correct
> referrals already when they access the share :)
>
> since we are planning to use this patch in production, it would be very
> nice if you could comment on this.
>
> -8<--snip--8<--
> add to smb.conf:
> [global]
> host msdfs = yes
>
> [dfs-fake]
> path = /export/dfs-fake
> msdfs root = yes
> msdfs proxy = yes
> msdfs link name = "linkname"
>
> create a link:
>
> ln -s msdfs:unimak\\storage /export/dfs-fake/linkname
> ->8--snap-->8--
>
> thanks a lot,
> guenther
>
>
> On Thu, Sep 05, 2002 at 09:50:51AM -0700, Shirish Kalele wrote:
> > Hi,
> >
> > Clients do request dfs referrals for every share they connect to. In a dfs
> > reply for a share, you could try and send a different sharename and see what
> > happens. I don't know if clients will be able to handle this. Look for
> > self_referral in the setup_dfs_referral() code to find out where to start
> > making changes.
> >
> > Let me know how the clients take it..
> >
> > Thanks,
> > Shirish
> >
> > - Original Message -
> > From: "Guenther Deschner" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, September 04, 2002 2:48 PM
> > Subject: msdfs referrals at share-level
> >
> > hello everybody,
> >
> > as far as i have looked into msdfs.c it seems to be impossible to send
> > a client a dfs-referral at the share level (\\fileserver\msdfs-link).
> >
> > maybe there is another way to "proxy" a request to \\samba\thisshare to
> > \\anothersamba\thatshare ?
> >
> > i currently want to migrate a couple of nt-servers transparently for
> > clients. the basic idea is to setup one samba-server that offers faked
> > file-service via netbios-aliases and dfs-redirects to the real
> > samba-fileserver. unfortunatly touching the clients is a no-go.
> >
> > old setup with *nt*:
> >
> > client -> //fileserver/share1
> >
> > planned setup with *samba*:
> >
> > client -> //fileserver/share1 where share1 -> msdfs:samba-file\whatever
> >
> > any help is much appreciated.
> >
> > bye,
> > guenther
> > --
> > Guenther Deschner [EMAIL PROTECTED]
> > SuSE Linux AGGnuPG: 8EE11688
> > Berliner Str. 27 phone: +49 (0) 30 / 430944778
> > D-13507 Berlin fax: +49 (0) 30 / 43732804
> >
> >
>
> --
> Guenther Deschner [EMAIL PROTECTED]
> SuSE Linux AGGnuPG: 8EE11688
> Berliner Str. 27 phone: +49 (0) 30 / 430944778
> D-13507 Berlin fax: +49 (0) 30 / 43732804
> --- source/param/loadparm.c Thu Oct 10 00:26:52 2002
> +++ source/param/loadparm.c Mon Oct 14 14:21:08 2002
> @@ -408,6 +408,8 @@
> BOOL bInheritPerms;
> BOOL bInheritACLS;
> BOOL bMSDfsRoot;
> + BOOL bMSDfsProxy;
> + char *bMSDfsLinkName;
> BOOL bUseClientDriver;
> BOOL bDefaultDevmode;
> BOOL bNTAclSupport;
> @@ -533,6 +535,8 @@
> False, /* bInheritPerms */
> False, /* bInheritACLS */
> False, /* bMSDfsRoot */
> + False, /* bMSDfsProxy */
> + NULL, /* bMSDfsLinkName */
> False, /* bUseClientDriver */
> False, /* bDefaultDevmode */
> True, /* bNTAclSupport */
> @@ -1107,6 +,8 @@
> {"MSDfs options", P_SEP, P_SEPARATOR},
>
> {"msdfs root", P_BOOL, P_LOCAL, &sDefault.bMSDfsRoot, NULL, NULL, FLAG_SHARE},
> + {"msdfs proxy", P_BOOL, P_LOCAL, &sDefault.bMSDfsProxy, NU
Re: msdfs referrals at share-level
On Mon, 14 Oct 2002, Guenther Deschner wrote: > ops. patch is against 2_2 - cvs. Thanks. But please patch against HEAD. I'm not going to add any newfunctionality to SAMBA_2_2. cheers, jerry - Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org --http://www.plainjoe.org "SAMS Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--
Re: msdfs referrals at share-level
hi,
On Mon, Oct 14, 2002 at 09:15:41AM -0500, Gerald Carter wrote:
> On Mon, 14 Oct 2002, Guenther Deschner wrote:
>
> > ops. patch is against 2_2 - cvs.
>
> Thanks. But please patch against HEAD. I'm not going to add any
> newfunctionality to SAMBA_2_2.
right. here is the diff (that needs review) against HEAD.
thanks,
guenther
--
Guenther Deschner [EMAIL PROTECTED]
SuSE Linux AGGnuPG: 8EE11688
Berliner Str. 27 phone: +49 (0) 30 / 430944778
D-13507 Berlin fax: +49 (0) 30 / 43732804
--- source/param/loadparm.c Wed Oct 9 21:17:05 2002
+++ source/param/loadparm.c Mon Oct 14 16:33:08 2002
@@ -386,6 +386,8 @@
BOOL bInheritPerms;
BOOL bInheritACLS;
BOOL bMSDfsRoot;
+ BOOL bMSDfsProxy;
+ char *bMSDfsLinkName;
BOOL bUseClientDriver;
BOOL bDefaultDevmode;
BOOL bNTAclSupport;
@@ -508,6 +510,8 @@
False, /* bInheritPerms */
False, /* bInheritACLS */
False, /* bMSDfsRoot */
+ False, /* bMSDfsProxy */
+ NULL, /* bMSDfsLinkName */
False, /* bUseClientDriver */
False, /* bDefaultDevmode */
True, /* bNTAclSupport */
@@ -1079,6 +1083,8 @@
{"msdfs root", P_BOOL, P_LOCAL, &sDefault.bMSDfsRoot, NULL, NULL, FLAG_SHARE},
+ {"msdfs proxy", P_BOOL, P_LOCAL, &sDefault.bMSDfsProxy, NULL, NULL,
+FLAG_SHARE},
+ {"msdfs link name", P_STRING, P_LOCAL, &sDefault.bMSDfsLinkName, NULL, NULL,
+FLAG_SHARE},
{"host msdfs", P_BOOL, P_GLOBAL, &Globals.bHostMSDfs, NULL, NULL,
FLAG_ADVANCED | FLAG_DEVELOPER},
{"Winbind options", P_SEP, P_SEPARATOR},
@@ -1730,6 +1736,8 @@
FN_LOCAL_STRING(lp_veto_oplocks, szVetoOplockFiles)
FN_LOCAL_STRING(lp_driverlocation, szPrinterDriverLocation)
FN_LOCAL_BOOL(lp_msdfs_root, bMSDfsRoot)
+FN_LOCAL_BOOL(lp_msdfs_proxy, bMSDfsProxy)
+FN_LOCAL_STRING(lp_msdfs_link_name, bMSDfsLinkName)
FN_LOCAL_BOOL(lp_autoloaded, autoloaded)
FN_LOCAL_BOOL(lp_preexec_close, bPreexecClose)
FN_LOCAL_BOOL(lp_rootpreexec_close, bRootpreexecClose)
--- source/msdfs/msdfs.cTue Jul 2 08:34:24 2002
+++ source/msdfs/msdfs.cMon Oct 14 16:49:57 2002
@@ -600,12 +600,38 @@
int reply_size = 0;
char *pathnamep = pathname;
+ struct connection_struct conns;
+ struct connection_struct* conn = &conns;
+ int snum;
+ pstring conn_path;
+ struct dfs_path dpi;
+
+ struct junction_map junction2;
+ parse_dfs_path(pathname, &dpi);
+ pstrcpy(junction2.service_name, dpi.servicename);
+ snum = lp_servicenumber(junction2.service_name);
+ create_conn_struct(conn, snum, conn_path);
+
+
ZERO_STRUCT(junction);
/* get the junction entry */
if (!pathnamep)
return -1;
+if (lp_msdfs_proxy(SNUM(conn))) {
+ DEBUG(10,("running in proxy mode\n"));
+ pstrcpy(pathnamep, "\\");
+ pstrcat(pathnamep, dpi.hostname);
+ pstrcat(pathnamep, "\\");
+ pstrcat(pathnamep, dpi.servicename);
+ pstrcat(pathnamep, "\\");
+ pstrcat(pathnamep, (char *) lp_msdfs_link_name(SNUM(conn)));
+} else {
+ DEBUG(10,("running in normal mode\n"));
+ }
+
+
/* Trim pathname sent by client so it begins with only one backslash.
Two backslashes confuse some dfs clients
*/
@@ -631,6 +657,17 @@
}
}
+if ( lp_msdfs_proxy(SNUM(conn)) ) {
+ DEBUG(10,("running in proxy mode\n"));
+ pstrcpy ( pathnamep, "\\" );
+ pstrcat ( pathnamep, dpi.hostname);
+ pstrcat ( pathnamep, "\\" );
+ pstrcat ( pathnamep, dpi.servicename);
+} else {
+ DEBUG(10,("running in normal mode\n"));
+ }
+
+
/* create the referral depeding on version */
DEBUG(10,("max_referral_level :%d\n",max_referral_level));
if(max_referral_level<2 || max_referral_level>3)
msg03694/pgp0.pgp
Description: PGP signature
Re: msdfs referrals at share-level
Hi, This is cool. Which Windows clients have you tested with? As for the patch, it might be better if you coded this such that a self-referral either pointed to itself, or to the proxied share. Having something like 'msdfs proxy = server\share' in smb.conf, and sending that whenever a self-referral was to be sent would be better than the hack you have where you manipulate the client's requested path to become the msdfs link to the proxy. imho, anyway. This might also make it easier to code the NETDFS interface to this proxy stuff. Cheers, Shirish - Original Message - From: "Guenther Deschner" <[EMAIL PROTECTED]> To: "Shirish Kalele" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Thomas Wiebach" <[EMAIL PROTECTED]> Sent: Monday, October 14, 2002 6:36 AM Subject: Re: msdfs referrals at share-level hello shirish, we made some more experiments with the dfs-code and now have a running solution for our smb-proxy, without breaking msdfs (well, i didn't had a look on the dfs_rpc-pipe for now...) you can now have a samba-share behave like an mdfs-symlink. if you set a share to "msdfs proxy = yes" and declare the link in its path to "msdfs link name = linkname" the clients will reveive correct referrals already when they access the share :) since we are planning to use this patch in production, it would be very nice if you could comment on this. -8<--snip--8<-- add to smb.conf: [global] host msdfs = yes [dfs-fake] path = /export/dfs-fake msdfs root = yes msdfs proxy = yes msdfs link name = "linkname" create a link: ln -s msdfs:unimak\\storage /export/dfs-fake/linkname ->8--snap-->8-- thanks a lot, guenther On Thu, Sep 05, 2002 at 09:50:51AM -0700, Shirish Kalele wrote: > Hi, > > Clients do request dfs referrals for every share they connect to. In a dfs > reply for a share, you could try and send a different sharename and see what > happens. I don't know if clients will be able to handle this. Look for > self_referral in the setup_dfs_referral() code to find out where to start > making changes. > > Let me know how the clients take it.. > > Thanks, > Shirish > > ----- Original Message - > From: "Guenther Deschner" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, September 04, 2002 2:48 PM > Subject: msdfs referrals at share-level > > hello everybody, > > as far as i have looked into msdfs.c it seems to be impossible to send > a client a dfs-referral at the share level (\\fileserver\msdfs-link). > > maybe there is another way to "proxy" a request to \\samba\thisshare to > \\anothersamba\thatshare ? > > i currently want to migrate a couple of nt-servers transparently for > clients. the basic idea is to setup one samba-server that offers faked > file-service via netbios-aliases and dfs-redirects to the real > samba-fileserver. unfortunatly touching the clients is a no-go. > > old setup with *nt*: > > client -> //fileserver/share1 > > planned setup with *samba*: > > client -> //fileserver/share1 where share1 -> msdfs:samba-file\whatever > > any help is much appreciated. > > bye, > guenther > -- > Guenther Deschner [EMAIL PROTECTED] > SuSE Linux AGGnuPG: 8EE11688 > Berliner Str. 27 phone: +49 (0) 30 / 430944778 > D-13507 Berlin fax: +49 (0) 30 / 43732804 > > -- Guenther Deschner [EMAIL PROTECTED] SuSE Linux AGGnuPG: 8EE11688 Berliner Str. 27 phone: +49 (0) 30 / 430944778 D-13507 Berlin fax: +49 (0) 30 / 43732804
Re: msdfs referrals at share-level
hi, now that the msdfs-proxy is in cvs (thanks again for taking a deeper look on that) i still have a small fix for the dfsenum-pipe that just prints the first dfsroot and then stops. with that fix it'll show you all dfsenum-infolevels. attached you'll find a backport of the msdfs-proxy for 2_2, maybe you could have a quick look and comment on that one too. thanks again, guenther On Mon, Oct 14, 2002 at 12:15:17PM -0700, Shirish Kalele wrote: > Hi, > > This is cool. Which Windows clients have you tested with? > > As for the patch, it might be better if you coded this such that a > self-referral either pointed to itself, or to the proxied share. Having > something like 'msdfs proxy = server\share' in smb.conf, and sending that > whenever a self-referral was to be sent would be better than the hack you > have where you manipulate the client's requested path to become the msdfs > link to the proxy. imho, anyway. This might also make it easier to code the > NETDFS interface to this proxy stuff. > > Cheers, > Shirish > > - Original Message - > From: "Guenther Deschner" <[EMAIL PROTECTED]> > To: "Shirish Kalele" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; "Thomas Wiebach" <[EMAIL PROTECTED]> > Sent: Monday, October 14, 2002 6:36 AM > Subject: Re: msdfs referrals at share-level > > > hello shirish, > > we made some more experiments with the dfs-code and now have a running > solution for our smb-proxy, without breaking msdfs (well, i didn't had a > look on the dfs_rpc-pipe for now...) > > you can now have a samba-share behave like an mdfs-symlink. > if you set a share to "msdfs proxy = yes" and declare the link in its > path to "msdfs link name = linkname" the clients will reveive correct > referrals already when they access the share :) > > since we are planning to use this patch in production, it would be very > nice if you could comment on this. > > -8<--snip--8<-- > add to smb.conf: > [global] > host msdfs = yes > > [dfs-fake] > path = /export/dfs-fake > msdfs root = yes > msdfs proxy = yes > msdfs link name = "linkname" > > create a link: > > ln -s msdfs:unimak\\storage /export/dfs-fake/linkname > ->8--snap-->8-- > > thanks a lot, > guenther > > > On Thu, Sep 05, 2002 at 09:50:51AM -0700, Shirish Kalele wrote: > > Hi, > > > > Clients do request dfs referrals for every share they connect to. In a dfs > > reply for a share, you could try and send a different sharename and see > what > > happens. I don't know if clients will be able to handle this. Look for > > self_referral in the setup_dfs_referral() code to find out where to start > > making changes. > > > > Let me know how the clients take it.. > > > > Thanks, > > Shirish > > > > - Original Message - > > From: "Guenther Deschner" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, September 04, 2002 2:48 PM > > Subject: msdfs referrals at share-level > > > > hello everybody, > > > > as far as i have looked into msdfs.c it seems to be impossible to send > > a client a dfs-referral at the share level (\\fileserver\msdfs-link). > > > > maybe there is another way to "proxy" a request to \\samba\thisshare to > > \\anothersamba\thatshare ? > > > > i currently want to migrate a couple of nt-servers transparently for > > clients. the basic idea is to setup one samba-server that offers faked > > file-service via netbios-aliases and dfs-redirects to the real > > samba-fileserver. unfortunatly touching the clients is a no-go. > > > > old setup with *nt*: > > > > client -> //fileserver/share1 > > > > planned setup with *samba*: > > > > client -> //fileserver/share1 where share1 -> msdfs:samba-file\whatever > > > > any help is much appreciated. > > > > bye, > > guenther > > -- > > Guenther Deschner [EMAIL PROTECTED] > > SuSE Linux AGGnuPG: 8EE11688 > > Berliner Str. 27 phone: +49 (0) 30 / 430944778 > > D-13507 Berlin fax: +49 (0) 30 / 43732804 > > > > > > -- > Guenther Deschner [EMAIL PROTECTED] > SuSE Linux AG
Re: msdfs referrals at share-level
On Fri, 7 Feb 2003, Guenther Deschner wrote:
> now that the msdfs-proxy is in cvs (thanks again for taking a deeper look on
> that) i still have a small fix for the dfsenum-pipe that just prints the first
> dfsroot and then stops. with that fix it'll show you all dfsenum-infolevels.
>
> attached you'll find a backport of the msdfs-proxy for 2_2, maybe you could
> have a quick look and comment on that one too.
Hmmm, how is this any different from having a normal MSDFS share set up in
Samba, say to \\server1\share1, and doing:
ln -s "msdfs:server1\share2,server2\share3,..." /path/to/share1/share1
Just what does this msdfs-proxy stuff do that you can't do with the
existing code?
Regards
-
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org,
sharpe[at]ethereal.com, http://www.richardsharpe.com
--- source/param/loadparm.c 20 Dec 2002 20:23:05 - 1.472
+++ source/param/loadparm.c 29 Dec 2002 23:29:07 - 1.473
@@ -343,6 +343,7 @@
char *fstype;
char *szVfsObjectFile;
char *szVfsOptions;
+ char *szMSDfsProxy;
int iMinPrintSpace;
int iMaxPrintJobs;
int iWriteCacheSize;
@@ -468,6 +469,7 @@
NULL, /* fstype */
NULL, /* vfs object */
NULL, /* vfs options */
+ NULL, /* szMSDfsProxy */
0, /* iMinPrintSpace */
1000, /* iMaxPrintJobs */
0, /* iWriteCacheSize */
@@ -1105,6 +1107,7 @@
{"msdfs root", P_BOOL, P_LOCAL, &sDefault.bMSDfsRoot, NULL, NULL, FLAG_SHARE},
{"host msdfs", P_BOOL, P_GLOBAL, &Globals.bHostMSDfs, NULL, NULL, 0},
+ {"msdfs proxy", P_STRING, P_LOCAL, &sDefault.szMSDfsProxy, NULL, NULL,
+FLAG_SHARE},
#endif
{"Winbind options", P_SEP, P_SEPARATOR},
@@ -1745,6 +1748,7 @@
FN_LOCAL_STRING(lp_fstype, fstype)
FN_LOCAL_STRING(lp_vfsobj, szVfsObjectFile)
FN_LOCAL_STRING(lp_vfs_options, szVfsOptions)
+FN_LOCAL_STRING(lp_msdfs_proxy, szMSDfsProxy)
static FN_LOCAL_STRING(lp_volume, volume)
FN_LOCAL_STRING(lp_mangled_map, szMangledMap)
FN_LOCAL_STRING(lp_veto_files, szVetoFiles)
--- docs/docbook/manpages/smb.conf.5.sgml 27 Nov 2002 02:47:55 - 1.68
+++ docs/docbook/manpages/smb.conf.5.sgml 29 Dec 2002 23:29:08 - 1.69
@@ -869,6 +869,7 @@
max
connections
max print
jobs
min print
space
+ msdfs
+proxy
msdfs
root
nt acl
support
only
guest
@@ -4847,6 +4848,23 @@
+
+ msdfs proxy (S)
+ This parameter indicates that the share is a
+ stand-in for another CIFS share whose location is specified by
+ the value of the parameter. When clients attempt to connect to
+ this share, they are redirected to the proxied share using
+ the SMB-Dfs protocol.
+ Only Dfs roots can act as proxy shares. Take a look at the
+ msdfs root
+ and
+ host msdfs
+ options to find out how to set up a Dfs root share.
+ Example: msdfs proxy =
+\otherserver\someshare
+
+
+
+
@@ -4857,8 +4875,8 @@
Samba treats the share as a Dfs root and allows clients to browse
the distributed file system tree rooted at the share directory.
Dfs links are specified in the share directory by symbolic
- links of the form msdfs:serverA\shareA,serverB\shareB
-and so on. For more information on setting up a Dfs tree
+ links of the form
+msdfs:serverA\shareA,serverB\shareB
+ and so on. For more information on setting up a Dfs tree
on Samba, refer to msdfs_setup.html
.
--- docs/manpages/smb.conf.52003-02-01 18:43:47.0 +0100
+++ docs/manpages/smb.conf.52003-02-07 10:29:02.0 +0100
@@ -1276,6 +1272,9 @@
\fImin print space\fR
.TP 0.2i
\(bu
+\fImsdfs proxy\fR
+.TP 0.2i
+\(bu
\fImsdfs root\fR
.TP 0.2i
\(bu
@@ -4664,14 +4663,29 @@
Default: \fBmin wins ttl = 21600\fR
.TP
+\fBmsdfs proxy (S)\fR
+This parameter indicates that the share is a
+stand-in for another CIFS share whose location is specified by
+the value of the parameter. When clients attempt to connect to
+this share, they are redirected to the proxied share using
+the SMB-Dfs protocol.
+
+Only Dfs roots can act as proxy shares. Take a look at the
+\fImsdfs root\fR
+and
+\fIhost msdfs\fR
+options to find out how to set up a Dfs root share.
+
+Example: \fBmsdfs proxy = \\otherserver\\someshare\fR
+.TP
\fBmsdfs root (S)\fR
This boolean parameter is only available if
Samba is configured and com
Re: msdfs referrals at share-level
hi, On Sat, Feb 08, 2003 at 05:30:21PM -0800, Richard Sharpe wrote: > On Fri, 7 Feb 2003, Guenther Deschner wrote: > > > now that the msdfs-proxy is in cvs (thanks again for taking a deeper > > look on that) i still have a small fix for the dfsenum-pipe that just prints > > the first dfsroot and then stops. with that fix it'll show you all > > dfsenum-infolevels. > > > > attached you'll find a backport of the msdfs-proxy for 2_2, maybe you > > could have a quick look and comment on that one too. > > Hmmm, how is this any different from having a normal MSDFS share set up > in Samba, say to \\server1\share1, and doing: > > ln -s "msdfs:server1\share2,server2\share3,..." /path/to/share1/share1 > > Just what does this msdfs-proxy stuff do that you can't do with the > existing code? as far as i have understood (shirish, please correct me if i'm wrong): the msdfs implementation in samba is close to nt4-semantics, where a dfsroot is just a share. only in that share you can create volumes that contain junctions to other storage locations but you cannot make a dfs-root behave as a direct redirect itself. since dfs-volumes are implemented as symlinks that are masqueraded as directories to the client, you cannot just point to a "path" in a share-definition that is itself a symlink. thus ln -s "msdfs:server1\\share1" /tmp/volume1 [dfsproxy] path = /tmp/volume1 msdfs root = yes will not work without a "msdfs proxy". bye, guenther -- Guenther Deschner [EMAIL PROTECTED] SuSE Linux AGGnuPG: 8EE11688 Berliner Str. 27 phone: +49 (0) 30 / 430944778 D-13507 Berlin fax: +49 (0) 30 / 43732804 msg05917/pgp0.pgp Description: PGP signature
Re: msdfs referrals at share-level
hello shirish,
On Fri, Feb 07, 2003 at 05:13:50PM -0800, Shirish Kalele wrote:
> Hi Guenther,
>
> I'll try and take a look at it Monday.
>
> Is the fix for the dfs-enum pipe attached as well?
yes. i'll add it again just to be sure.
> I'm not sure I understand your description of the fix.
oh sorry, maybe i'll describe my test setup a bit.
i have in smb.conf two msdfs roots, one of them acts as a proxy:
[dfsroot1]
path = /tmp/dfs-real
msdfs root = yes
[dfsroot2]
path = /tmp/empty
msdfs root = yes
msdfs proxy = \unimak\tmp2
without the fix i can just see the first dfsroot (and not even all the
entrypaths that exist under that root):
mthelena:~ # rpcclient localhost -N -c "dfsenum 3"
entrypath: \\MTHELENA\dfsroot1
comment:
state: 1
num_storages: 1
storage[0] servername: mthelena
storage[0] sharename: dfsroot1
with the fix i do see my second dfsroot and i get all storage information
about
the other entrypaths that are created as symlinks and i even get
information
about the proxy destination of [dfsroot2]:
mthelena:~ # rpcclient localhost -N -c "dfsenum 3"
entrypath: \\MTHELENA\dfsroot1
comment:
state: 1
num_storages: 1
storage[0] servername: mthelena
storage[0] sharename: dfsroot1
entrypath: \\MTHELENA\dfsroot1\linkone
comment:
state: 1
num_storages: 1
storage[0] servername: win2ksrv
storage[0] sharename: data
entrypath: \\MTHELENA\dfsroot1\linktwo
comment:
state: 1
num_storages: 1
storage[0] servername: smbsrv
storage[0] sharename: test
entrypath: \\MTHELENA\dfsroot1\linkthree
comment:
state: 1
num_storages: 2
storage[0] servername: unimak2
storage[0] sharename: tmp2
storage[1] servername: unimak
storage[1] sharename: tmp
entrypath: \\MTHELENA\dfsroot2
comment:
state: 1
num_storages: 1
storage[0] servername: unimak2
storage[0] sharename: tmp2
is that fix correct?
thanks,
guenther
--
Guenther Deschner [EMAIL PROTECTED]
SuSE Linux AGGnuPG: 8EE11688
Berliner Str. 27 phone: +49 (0) 30 / 430944778
D-13507 Berlin fax: +49 (0) 30 / 43732804
--- source/msdfs/msdfs.c2002-12-30 00:30:15.0 +0100
+++ source/msdfs/msdfs.c2003-02-07 14:19:37.0 +0100
@@ -851,7 +851,9 @@
ref->ttl = REFERRAL_TTL;
if (*lp_msdfs_proxy(snum) != '\0') {
pstrcpy(ref->alternate_path, lp_msdfs_proxy(snum));
- *jn_count = 1;
+ pstrcpy(jn[cnt].service_name, lp_servicename(snum));
+ cnt++;
+ *jn_count = cnt;
return True;
}
msg05918/pgp0.pgp
Description: PGP signature
Re: msdfs referrals at share-level
Hi Guenther, Thanks for the dfsenum fix. I've checked it into HEAD and 3.0. The msdfs-proxy patch for 2.2 looks good too. I don't think it should be any different from the changes for 3.0? I won't be checking it into 2_2 CVS though as I understand that 2.2.8 is only a maintenance/bugfix/security release. Thanks, Shirish On Fri, 7 Feb 2003, Guenther Deschner wrote: >hi, > >now that the msdfs-proxy is in cvs (thanks again for taking a deeper look on >that) i still have a small fix for the dfsenum-pipe that just prints the first >dfsroot and then stops. with that fix it'll show you all dfsenum-infolevels. > >attached you'll find a backport of the msdfs-proxy for 2_2, maybe you could >have a quick look and comment on that one too. > >thanks again, >guenther > >On Mon, Oct 14, 2002 at 12:15:17PM -0700, Shirish Kalele wrote: >> Hi, >> >> This is cool. Which Windows clients have you tested with? >> >> As for the patch, it might be better if you coded this such that a >> self-referral either pointed to itself, or to the proxied share. Having >> something like 'msdfs proxy = server\share' in smb.conf, and sending that >> whenever a self-referral was to be sent would be better than the hack you >> have where you manipulate the client's requested path to become the msdfs >> link to the proxy. imho, anyway. This might also make it easier to code the >> NETDFS interface to this proxy stuff. >> >> Cheers, >> Shirish >> >> - Original Message - >> From: "Guenther Deschner" <[EMAIL PROTECTED]> >> To: "Shirish Kalele" <[EMAIL PROTECTED]> >> Cc: <[EMAIL PROTECTED]>; "Thomas Wiebach" <[EMAIL PROTECTED]> >> Sent: Monday, October 14, 2002 6:36 AM >> Subject: Re: msdfs referrals at share-level >> >> >> hello shirish, >> >> we made some more experiments with the dfs-code and now have a running >> solution for our smb-proxy, without breaking msdfs (well, i didn't had a >> look on the dfs_rpc-pipe for now...) >> >> you can now have a samba-share behave like an mdfs-symlink. >> if you set a share to "msdfs proxy = yes" and declare the link in its >> path to "msdfs link name = linkname" the clients will reveive correct >> referrals already when they access the share :) >> >> since we are planning to use this patch in production, it would be very >> nice if you could comment on this. >> >> -8<--snip--8<-- >> add to smb.conf: >> [global] >> host msdfs = yes >> >> [dfs-fake] >> path = /export/dfs-fake >> msdfs root = yes >> msdfs proxy = yes >> msdfs link name = "linkname" >> >> create a link: >> >> ln -s msdfs:unimak\\storage /export/dfs-fake/linkname >> ->8--snap-->8-- >> >> thanks a lot, >> guenther >> >> >> On Thu, Sep 05, 2002 at 09:50:51AM -0700, Shirish Kalele wrote: >> > Hi, >> > >> > Clients do request dfs referrals for every share they connect to. In a dfs >> > reply for a share, you could try and send a different sharename and see >> what >> > happens. I don't know if clients will be able to handle this. Look for >> > self_referral in the setup_dfs_referral() code to find out where to start >> > making changes. >> > >> > Let me know how the clients take it.. >> > >> > Thanks, >> > Shirish >> > >> > - Original Message - >> > From: "Guenther Deschner" <[EMAIL PROTECTED]> >> > To: <[EMAIL PROTECTED]> >> > Sent: Wednesday, September 04, 2002 2:48 PM >> > Subject: msdfs referrals at share-level >> > >> > hello everybody, >> > >> > as far as i have looked into msdfs.c it seems to be impossible to send >> > a client a dfs-referral at the share level (\\fileserver\msdfs-link). >> > >> > maybe there is another way to "proxy" a request to \\samba\thisshare to >> > \\anothersamba\thatshare ? >> > >> > i currently want to migrate a couple of nt-servers transparently for >> > clients. the basic idea is to setup one samba-server that offers faked >> > file-service via netbios-aliases and dfs-redirects to the real >> > samba-fileserver. unfortunatly touching the clients is a no-
