[Samba] preexec and msdfs proxy

[Daniel Müller]

Perhaps it may help: http://sourceforge.net/projects/winexe/

"Winexe remotely executes commands on Windows® NT/2000/XP/2003 systems....."

Greetings
Daniel





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 Greg Enlow
Gesendet: Donnerstag, 21. Mai 2015 08:26
An: samba at lists.samba.org
Cc: David Bear; Jeremy Allison
Betreff: Re: [Samba] preexec and msdfs proxy

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
______________________________________________________________________
--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba