Hi, Thank you for you input! We tried that already. That, however, doesn't do the same thing. It is then simply a DFS server and not the "magical" msdfs proxy - yes the user can now click on a link to get to the desired spot, but the proxy function _automagically_ sends the user, when they access the msdfs share, to the netapp's readonly share without the extra click. And it is that extra click that is our show-stopper: our users have sadly over many many years used a paricular server name in their office documents & co., of course also with lots and lots of links in the documents themselves. Presentations, speadsheet caluculations, links to other docs, etc. will all fail. The general managment then, understandably, forbade us from forcing everyone (1000+ people) to update their documents etc. overnight such that we had to find another solution. Ours is to provide the orginal path (URL with old server name, redirected per CNAME) to the documents, however only as readonly. To change the data they will have to use the new abstract name (also a CNAME) we will give them. Both paths point to the same data, as both shares are on the same netapp, but one path is RO while the other is RW. We think it is kinda cool ;-) The users know the change is coming. They also know that their links might fail anyway, but most will still work, such that the pressure is relieved. Those that don't will just have to be updated, forcing the users to think a bit more. Any changes they want or need to make will have to be done using the new path, such that over time the migration will eventually fully occur. Darwin, speaks. Now, as the icing on the cake, we were going to inform the user of their sins when they access to the RO share, by sending them a sysadmin from hell mail, and lots of them. Sadly, however, the preexec function doesn't fire for us. We were really excited about all the mails we would be sending, sort of like big company sactioned spam! ;-) But, alas, something no worky worky. So, that is why I am here. 'til then, Greg Enlow -- Greg Enlow grenlow at hk.mailbox.de On 19 May 2015, at 08:08, Daniel M?ller wrote: Just an idea: Why dont us msdfs just pointing to the netapp with ln -s msdfs: And in the smb.conf ex: [netapp] root preexec= yourscript path=yourpath msdfs root=yes EDV Daniel M?ller Leitung EDV Tropenklinik Paul-Lechler-Krankenhaus Paul-Lechler-Str. 24 72076 T?bingen Tel.: 07071/206-463, Fax: 07071/206-499 eMail: mueller at tropenklinik.de Internet: www.tropenklinik.de -----Urspr?ngliche Nachricht----- Von: samba-bounces at lists.samba.org [mailto:samba-bounces at lists.samba.org] Im Auftrag von Jeremy Allison Gesendet: Montag, 18. Mai 2015 18:21 An: Greg Enlow Cc: samba at lists.samba.org Betreff: Re: [Samba] preexec and msdfs proxy On Mon, May 18, 2015 at 03:31:55PM +0200, Greg Enlow wrote:> Hi, > > The Server to which the msdfs is pointing is a netapp. Though wetheoretically can access the shell on it then begin to mess around there, we would really like to avoid that. Warranty and such make it a bit of a legal issue. That is the reason we went with a separate instance in the first place and now wonder why the preexec doesn't fire.> > There is nothing in tmp of the msdfs box. > > Like I asked before, is this by design? If not what can we do to getaround playing with underwear of our netapp?> > Thanks!At the SambaXP conference all this week, but I'll try and find some time to look inside the code and let you know ! Ping me again if I haven't replied by Friday :-). Cheers, Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. Zu buchen bei Hegel & Koch - http://www.hk-online.de ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. Zu buchen bei Hegel & Koch - http://www.hk-online.de ______________________________________________________________________
Well, this doesn't fix the preexec issue, but you might scan through the samba logs finding connections to the RO share, identify that IP address there, track back to Hostname and/or user who authenticated to that share and the use that as the basis for the email address. On Tue, May 19, 2015 at 12:38 PM, Greg Enlow <grenlow at hk.mailbox.de> wrote:> Hi, > > Thank you for you input! > > We tried that already. That, however, doesn't do the same thing. It is > then simply a DFS server and not the "magical" msdfs proxy - yes the user > can now click on a link to get to the desired spot, but the proxy function > _automagically_ sends the user, when they access the msdfs share, to the > netapp's readonly share without the extra click. And it is that extra > click that is our show-stopper: our users have sadly over many many years > used a paricular server name in their office documents & co., of course > also with lots and lots of links in the documents themselves. > Presentations, speadsheet caluculations, links to other docs, etc. will > all fail. The general managment then, understandably, forbade us from > forcing everyone (1000+ people) to update their documents etc. overnight > such that we had to find another solution. Ours is to provide the orginal > path (URL with old server name, redirected per CNAME) to the documents, > however only as readonly. To change the data they will have to use the new > abstract name (also a CNAME) we will give them. Both paths point to the > same data, as both shares are on the same netapp, but one path is RO while > the other is RW. > > We think it is kinda cool ;-) The users know the change is coming. They > also know that their links might fail anyway, but most will still work, > such that the pressure is relieved. Those that don't will just have to be > updated, forcing the users to think a bit more. Any changes they want or > need to make will have to be done using the new path, such that over time > the migration will eventually fully occur. Darwin, speaks. > > Now, as the icing on the cake, we were going to inform the user of their > sins when they access to the RO share, by sending them a sysadmin from hell > mail, and lots of them. Sadly, however, the preexec function doesn't fire > for us. We were really excited about all the mails we would be sending, > sort of like big company sactioned spam! ;-) But, alas, something no > worky worky. So, that is why I am here. > > 'til then, > Greg Enlow > > -- > > Greg Enlow > grenlow at hk.mailbox.de > > > > On 19 May 2015, at 08:08, Daniel M?ller wrote: > > Just an idea: > Why dont us msdfs just pointing to the netapp with ln -s msdfs: > And in the smb.conf ex: > > [netapp] > root preexec= yourscript > path=yourpath > msdfs root=yes > > > > > EDV Daniel M?ller > > Leitung EDV > Tropenklinik Paul-Lechler-Krankenhaus > Paul-Lechler-Str. 24 > 72076 T?bingen > Tel.: 07071/206-463, Fax: 07071/206-499 > eMail: mueller at tropenklinik.de > Internet: www.tropenklinik.de > > > > -----Urspr?ngliche Nachricht----- > Von: samba-bounces at lists.samba.org [mailto:samba-bounces at lists.samba.org] > Im > Auftrag von Jeremy Allison > Gesendet: Montag, 18. Mai 2015 18:21 > An: Greg Enlow > Cc: samba at lists.samba.org > Betreff: Re: [Samba] preexec and msdfs proxy > > On Mon, May 18, 2015 at 03:31:55PM +0200, Greg Enlow wrote: > > Hi, > > > > The Server to which the msdfs is pointing is a netapp. Though we > theoretically can access the shell on it then begin to mess around there, > we > would really like to avoid that. Warranty and such make it a bit of a legal > issue. That is the reason we went with a separate instance in the first > place and now wonder why the preexec doesn't fire. > > > > There is nothing in tmp of the msdfs box. > > > > Like I asked before, is this by design? If not what can we do to get > around playing with underwear of our netapp? > > > > Thanks! > > At the SambaXP conference all this week, but I'll try and find some time to > look inside the code and let you know ! > > Ping me again if I haven't replied by Friday :-). > > Cheers, > > Jeremy. > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > Zu buchen bei Hegel & Koch - http://www.hk-online.de > ______________________________________________________________________ > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > Zu buchen bei Hegel & Koch - http://www.hk-online.de > ______________________________________________________________________ > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >-- David Bear mobile: (602) 903-6476
Hey, thanks for the input! I am looking into that. It is however a bit complicated due to the authentication lines and share connect lines being only related due to proximity in the log. It would probably work for most of the instances, but it would not be 100% viable, meaning we would be getting compaints and questions from our user "I ain't got that share?! WTF!!" I was going to wait to hear from Jeremy Allison before I get serious about either fuddling about with the netapp smb.conf or parsing logs on the msdfs box. 'til then, Greg Enlow -- Greg Enlow grenlow at hk.mailbox.de On 21 May 2015, at 05:09, David Bear wrote: Well, this doesn't fix the preexec issue, but you might scan through the samba logs finding connections to the RO share, identify that IP address there, track back to Hostname and/or user who authenticated to that share and the use that as the basis for the email address. On Tue, May 19, 2015 at 12:38 PM, Greg Enlow <grenlow at hk.mailbox.de> wrote:> Hi, > > Thank you for you input! > > We tried that already. That, however, doesn't do the same thing. It is > then simply a DFS server and not the "magical" msdfs proxy - yes the user > can now click on a link to get to the desired spot, but the proxy function > _automagically_ sends the user, when they access the msdfs share, to the > netapp's readonly share without the extra click. And it is that extra > click that is our show-stopper: our users have sadly over many many years > used a paricular server name in their office documents & co., of course > also with lots and lots of links in the documents themselves. > Presentations, speadsheet caluculations, links to other docs, etc. will > all fail. The general managment then, understandably, forbade us from > forcing everyone (1000+ people) to update their documents etc. overnight > such that we had to find another solution. Ours is to provide the orginal > path (URL with old server name, redirected per CNAME) to the documents, > however only as readonly. To change the data they will have to use the new > abstract name (also a CNAME) we will give them. Both paths point to the > same data, as both shares are on the same netapp, but one path is RO while > the other is RW. > > We think it is kinda cool ;-) The users know the change is coming. They > also know that their links might fail anyway, but most will still work, > such that the pressure is relieved. Those that don't will just have to be > updated, forcing the users to think a bit more. Any changes they want or > need to make will have to be done using the new path, such that over time > the migration will eventually fully occur. Darwin, speaks. > > Now, as the icing on the cake, we were going to inform the user of their > sins when they access to the RO share, by sending them a sysadmin from hell > mail, and lots of them. Sadly, however, the preexec function doesn't fire > for us. We were really excited about all the mails we would be sending, > sort of like big company sactioned spam! ;-) But, alas, something no > worky worky. So, that is why I am here. > > 'til then, > Greg Enlow > > -- > > Greg Enlow > grenlow at hk.mailbox.de > > > > On 19 May 2015, at 08:08, Daniel M?ller wrote: > > Just an idea: > Why dont us msdfs just pointing to the netapp with ln -s msdfs: > And in the smb.conf ex: > > [netapp] > root preexec= yourscript > path=yourpath > msdfs root=yes > > > > > EDV Daniel M?ller > > Leitung EDV > Tropenklinik Paul-Lechler-Krankenhaus > Paul-Lechler-Str. 24 > 72076 T?bingen > Tel.: 07071/206-463, Fax: 07071/206-499 > eMail: mueller at tropenklinik.de > Internet: www.tropenklinik.de > > > > -----Urspr?ngliche Nachricht----- > Von: samba-bounces at lists.samba.org [mailto:samba-bounces at lists.samba.org] > Im > Auftrag von Jeremy Allison > Gesendet: Montag, 18. Mai 2015 18:21 > An: Greg Enlow > Cc: samba at lists.samba.org > Betreff: Re: [Samba] preexec and msdfs proxy > > On Mon, May 18, 2015 at 03:31:55PM +0200, Greg Enlow wrote: >> Hi, >> >> The Server to which the msdfs is pointing is a netapp. Though we > theoretically can access the shell on it then begin to mess around there, > we > would really like to avoid that. Warranty and such make it a bit of a legal > issue. That is the reason we went with a separate instance in the first > place and now wonder why the preexec doesn't fire. >> >> There is nothing in tmp of the msdfs box. >> >> Like I asked before, is this by design? If not what can we do to get > around playing with underwear of our netapp? >> >> Thanks! > > At the SambaXP conference all this week, but I'll try and find some time to > look inside the code and let you know ! > > Ping me again if I haven't replied by Friday :-). > > Cheers, > > Jeremy. > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > Zu buchen bei Hegel & Koch - http://www.hk-online.de > ______________________________________________________________________ > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > Zu buchen bei Hegel & Koch - http://www.hk-online.de > ______________________________________________________________________ > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >-- David Bear mobile: (602) 903-6476 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. Zu buchen bei Hegel & Koch - http://www.hk-online.de ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. Zu buchen bei Hegel & Koch - http://www.hk-online.de ______________________________________________________________________
El 19/05/15 a les 21:38, Greg Enlow ha escrit:> > It is then simply a DFS server and not the "magical" msdfs proxy - yes the user can now click on a link to get to the desired spot, but the proxy function _automagically_ sends the user, when they access the msdfs share, to the netapp's readonly share without the extra click.Not a solution to the msdfs problem but from the netapp you could export the directory via nfs, mount it on the samba server an re-export it from there as a samba share. It will kill performance but since your users will eventually have to use another share maybe it's not a big issue. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es Tel. +34 935883004 Fax +34 935883007
Hey, thanks for the input. We looked into that too. However, the nfs mount comes with the rights it was mounted with and not with the ones on the netapp. As we only use generic rights on the share and then do the fine granulation using NTFS ACEs as well as use ABE alot, the users would suddenly see and have access to much more than they should. So that is not a viable path, sadly. I had also attempted to mount the netapp file system (nfs or cifs) using the preexec when the share was accessed, using the rights of the user accessing, but I couldn't get access to the kerebos token to pass it through. Played with that a long while, but it was a lost cause. 'til then, Greg -- Greg Enlow grenlow at hk.mailbox.de On 21 May 2015, at 08:53, Luca Olivetti wrote: El 19/05/15 a les 21:38, Greg Enlow ha escrit:> > It is then simply a DFS server and not the "magical" msdfs proxy - yes the user can now click on a link to get to the desired spot, but the proxy function _automagically_ sends the user, when they access the msdfs share, to the netapp's readonly share without the extra click.Not a solution to the msdfs problem but from the netapp you could export the directory via nfs, mount it on the samba server an re-export it from there as a samba share. It will kill performance but since your users will eventually have to use another share maybe it's not a big issue. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es Tel. +34 935883004 Fax +34 935883007 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. Zu buchen bei Hegel & Koch - http://www.hk-online.de ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. Zu buchen bei Hegel & Koch - http://www.hk-online.de ______________________________________________________________________