[Samba] preexec and msdfs proxy

[David Bear]

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