[Samba] Samba locking with NFS backend.
Jan Hugo Prins
I'm in a bit of a loss at the moment.
We have the following situation, we are running Samba for a lot of small
companies that need fileservices for there Windows Terminal Servers that
they use through a thin client on a Fiber / Lan extention to our datacentre.
We have this samba running on 2 linux hosts (Fedora Core 5 and Fedora 7)
with a ldap backend for all the domains.
This works ok, except for 1 thing.
In the past we synced server1 to server2 every hour and when there was a
problems with a server, the users would only loose 1 hour of work at
most and server 2 would take over all configurations. So far so good,
when there are not too much customers.
But we have had some growth recently and we added a central NFS server
to our setup. This server (Isilon IQ9000) is fully redundant so in
theory we could put any number of Samba frontend servers in front of it,
and we don't have to sync anymore.
But now the problem, when we put the user data on the NFS backend, users
are complaining that they are not able to edit documents in Word because
they get a error that they can only open the file readonly. Excell the
same problem. But copying a file for example works ok. In general you
can divide the applications in 2 groups, 1 only readonly access to the
data, and 1 no problem.
I found the following link that describes my problem rather well, but
I'm not able to test this sollution because it involved some patch
reverting etc to old kernels.
http://blog.notreally.org/ (blog entry of dec, 19th 2007). I could do
the memory hack that is described there to test if this is actually my
problem, but I thought, let's first ask here.
The following lines from the blog seem to describe my problem really
well, don't know if it really is my problem though, because I really
don't know how to check this appart from memory hacking:
"Unfortunately, linux 2.6.12 adds flock() emulation to the Linux NFS
client by translating it into a file-wide fcntl(). This means that
flock()s and fcntl()s *do collide* on remote NFS shares, which
introduces all the potential application race conditions which Linux
avoided by having them oblivious to each other locally. The practical
upshot of this is that if you re-share an NFS share via samba, then if a
Windows client (e.g. Outlook opening a PST file) opens a file with a
share mode, then byte-range locking operations will fail as the lock has
already been acquired. (The fact that NFS doesn’t realise the same PID
has both locks and allow them both is probably an even bigger problem)."
Is this a known issue with a sollution, or have I fould a problem here
without a current sollution?
Thanks a lot,
Greetings,
Jan Hugo Prins
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
Greg Byshenk
> I'm in a bit of a loss at the moment.
> We have the following situation, we are running Samba for a lot of small
> companies that need fileservices for there Windows Terminal Servers that
> they use through a thin client on a Fiber / Lan extention to our datacentre.
> We have this samba running on 2 linux hosts (Fedora Core 5 and Fedora 7)
> with a ldap backend for all the domains.
> This works ok, except for 1 thing.
> In the past we synced server1 to server2 every hour and when there was a
> problems with a server, the users would only loose 1 hour of work at
> most and server 2 would take over all configurations. So far so good,
> when there are not too much customers.
> But we have had some growth recently and we added a central NFS server
> to our setup. This server (Isilon IQ9000) is fully redundant so in
> theory we could put any number of Samba frontend servers in front of it,
> and we don't have to sync anymore.
> But now the problem, when we put the user data on the NFS backend, users
> are complaining that they are not able to edit documents in Word because
> they get a error that they can only open the file readonly. Excell the
> same problem. But copying a file for example works ok. In general you
> can divide the applications in 2 groups, 1 only readonly access to the
> data, and 1 no problem.
[...]
> Is this a known issue with a sollution, or have I fould a problem here
> without a current sollution?
I'm no Samba or Linux kernel expert, but in my experience, re-exporting
is almost always a bad idea.
I could be mistaken, but it strikes me that the best solution, if you have
something like the Isilon system, would be to use the Isilon's own CIFS
capabilities. What is the gain from exporting from the Isilon via NFS and
then trying to re-export using a separate Samba server?
--
greg byshenk - gbys...@byshenk.net - Leiden, NL
Jan Hugo Prins
is that it doesn't support how we use Samba / Ldap.
We have 1 LDAP tree, with all little OU's and each OU is the container
for 1 domain.
We use a filter to make sure that a user that connect to the samba he
has access to, only sees his part of the LDAP tree.
This filter functionality is something that is not available in the
stock samba, it was before, and we patch it back into every samba we use
in production.
We can't patch it into the Cifs server on the Isilon cluster.
Greetings,
Jan Hugo Prins
Volker Lendecke
> without a current sollution?
https://bugzilla.samba.org/show_bug.cgi?id=5168
See the module that is attached in comment#2.
Volker
Jan Hugo Prins
In theory it is exactly what we were looking for.
Have been going throught the man pages for 3 hours last night hoping to
find something like this, but couldn't find it.
:-)
Jan Hugo
Jan Hugo Prins
> Volker Lendecke wrote:
>> On Mon, Jan 07, 2008 at 10:38:30PM +0100, Jan Hugo Prins wrote:
>>
>>> Is this a known issue with a sollution, or have I fould a problem
>>> here without a current sollution?
>>>
>>
>> https://bugzilla.samba.org/show_bug.cgi?id=5168
>>
>> See the module that is attached in comment#2.
>>
>> Volker
>>
> Thanks a lot, we are going to test this one.
> In theory it is exactly what we were looking for.
> Have been going throught the man pages for 3 hours last night hoping
> to find something like this, but couldn't find it.
> :-)
>
> Jan Hugo
Just finished testing and, apart from some extra test done by the
customer, everything looks very good.
Greetings,
Jan Hugo Prins
Jeremy Allison
> The main reason we don't use the Cifs capabilities of the Isilon cluster
> is that it doesn't support how we use Samba / Ldap.
> We have 1 LDAP tree, with all little OU's and each OU is the container
> for 1 domain.
> We use a filter to make sure that a user that connect to the samba he
> has access to, only sees his part of the LDAP tree.
> This filter functionality is something that is not available in the
> stock samba, it was before, and we patch it back into every samba we use
> in production.
> We can't patch it into the Cifs server on the Isilon cluster.
You should be able to - it's just Samba and so you have
the source code.
Is the filter patch more generally useful ? Do you think
it's worth submitting to the list or as a feature request ?
Jeremy.
Jeremy Allison
> On Tue, Jan 08, 2008 at 10:27:51AM -0800, Jeremy Allison wrote:
> > Is the filter patch more generally useful ? Do you think
> > it's worth submitting to the list or as a feature request ?
>
> reporter to give his ok to check this in as GPL. Right now
> it says "public domain"
Ok, thanks.
Volker Lendecke
> it's worth submitting to the list or as a feature request ?
We have it already in the bug report -- I'm waiting for the
reporter to give his ok to check this in as GPL. Right now
it says "public domain"
Volker
Jan Hugo Prins
> On Tue, Jan 08, 2008 at 01:12:58AM +0100, Jan Hugo Prins wrote:
>
>
>> The main reason we don't use the Cifs capabilities of the Isilon cluster
>> is that it doesn't support how we use Samba / Ldap.
>> We have 1 LDAP tree, with all little OU's and each OU is the container
>> for 1 domain.
>> We use a filter to make sure that a user that connect to the samba he
>> has access to, only sees his part of the LDAP tree.
>> This filter functionality is something that is not available in the
>> stock samba, it was before, and we patch it back into every samba we use
>> in production.
>> We can't patch it into the Cifs server on the Isilon cluster.
>>
>
> You should be able to - it's just Samba and so you have
> the source code.
>
> Is the filter patch more generally useful ? Do you think
> it's worth submitting to the list or as a feature request ?
>
> Jeremy.
>
But as I understood from my colleges is was removed because noone seemed
to understand what you could do with it and therefor noone needed it. We
need it very much and that's why we have reverse engineered the patch
that removed this functionality and patch it back in every time we go to
a new version of Samba.
Jan Hugo Prins
Jan Hugo Prins
It's a ldap filter funtionality that is removed a while back, while we
still need it in our environment.
Jan Hugo Prins
Volker Lendecke
> No, we are talking here about a different patch.
> It's a ldap filter funtionality that is removed a while back, while we
> still need it in our environment.
Ah, ok. Sorry for the confusion.
No, "ldap filter" won't come back....
Sorry :-)
Volker
Jan Hugo Prins
Is there noone to maintain it? Is it to difficult?
Volker Lendecke
> What is the reason that it won't come back.
> Is there noone to maintain it? Is it to difficult?
Caused too much confusion, and it is by far not the only
search we're doing against ldap these days. So in theory you
would have to have to describe every search we're doing with
a separate filter option. Not good.
Volker
Volker Lendecke
> Ok, then I have a question for you.
> Suppose the following. We run terminal servers for al little customers.
> We have all those little domains in one big ldap. So far so good, we
> tell every samba where in the ldap tree the domain information is located.
> Now the following. Customer A wants to login to the terminal server with
> either the full name (Display Name value) or the CN of the account.
> Customer B wants to login with the UID and / or CN of the user.
> With ldap filter I could easilly configure this.
> How do I do this without ldap filter?
This is a bit too little information, but 99% you can get
what you want with LDAP ACLs on the ldap server side, based
on the different "ldap admin dn" that the two Samba servers
would use.
Volker
Jan Hugo Prins
Suppose the following. We run terminal servers for al little customers.
We have all those little domains in one big ldap. So far so good, we
tell every samba where in the ldap tree the domain information is located.
Now the following. Customer A wants to login to the terminal server with
either the full name (Display Name value) or the CN of the account.
Customer B wants to login with the UID and / or CN of the user.
With ldap filter I could easilly configure this.
How do I do this without ldap filter?
Jan Hugo Prins
Adam Tauno Williams
> >> is that it doesn't support how we use Samba / Ldap.
> >> We have 1 LDAP tree, with all little OU's and each OU is the container
> >> for 1 domain.
> >> We use a filter to make sure that a user that connect to the samba he
> >> has access to, only sees his part of the LDAP tree.
> >> This filter functionality is something that is not available in the
> >> stock samba, it was before, and we patch it back into every samba we use
> >> in production.
> >> We can't patch it into the Cifs server on the Isilon cluster.
> > You should be able to - it's just Samba and so you have
> > the source code.
> > Is the filter patch more generally useful ? Do you think
> > it's worth submitting to the list or as a feature request ?
> But as I understood from my colleges is was removed because noone seemed
> to understand what you could do with it and therefor noone needed it. We
> need it very much and that's why we have reverse engineered the patch
> that removed this functionality and patch it back in every time we go to
> a new version of Samba.
If ACLs aren't sufficient you certainly can accomplish it via back-meta
and rewrite rules, all on the DSA, and keeping a simpler Samba
configuration.
--
Adam Tauno Williams, Network & Systems Administrator
Consultant - http://www.whitemiceconsulting.com
Developer - http://www.opengroupware.org
Adam Tauno Williams
I agree with it not coming back, and it is the wrong solution anyway.
If a client should only be able to see a certain portion of the Dit...
then the client should only be able to see a certain portion of the Dit.
The correct solution to this kind of issue is to implement appropriate
ACLs on the DSA so that the clients only has access to the data they
need.
--
Adam Tauno Williams, Network & Systems Administrator
Consultant - http://www.whitemiceconsulting.com
Developer - http://www.opengroupware.org
--