[Samba] Looking for a set of definitive answers (long)

Question:

We recently moved to a Samba-based file server, which holds mission-
critical data on it (.dbf files used by our Accounting software, etc.)
The goal was to create a file server that had excellent performance while
providing Volume Management, but we felt that something like Veritas was
overkill for our needs.

Design Goals:
- Redundant Hardware
- Manual Failover (this was an acceptable solution)
- Very large storage capacity (minimum 1 Terabyte)
- Better than 100Mbyte/sec throughput
- Volume Management, Journaled Filesystem
- Drop-In Replacement for aging Win2k file server
- Use existing admin tools to avoid retraining


The proposed solution was a Samba file server running on a pair of
redundant servers, with one connected to an eSATA raid box, with LVM and
Ext3 providing volume management and journaling. Our transition was a
bit rough, but in the end it has been very stable and fast. We have been
really pleased with the performance of the hardware/software combo,
seeing sustained throughput of about 250Mbyte/sec with peaks as high as
300Mbyte/sec. But along the way, we encountered some oddities, and I
have some remaining questions.

First, the oddities (long-time Samba devs and admins, take this with a
grain of salt, when I say oddity I mean it from the perspective of an
experienced Windows administrator):

- File permissions do not behave as expected (from the viewpoint of other
staff working with the server).

The *nix permission bits cause a user, group, and "Everyone" entry to
become permanent and persistent. There was some initial grousing over
this fact as our long-time Windows admin scratched his head over why he
couldn't remove these entries as he saw fit. After explaining that there
would always be three settings no matter what, that they could never be
deleted, and that they represented actual filesystem-level bits that
wouldn't go away, it was accepted. I didn't notice if this was in the
docs or not, but I certainly didn't find it. It also meant enabling ACLs
on all of the filesystems and doing some creative thinking with the
permissions. The closest I could do was to map all files as owner root,
group set to Domain Admins, and Everyone set to disallowed; members of
the IT staff would be mapped with the "admin users" parameter; from
there, any additional permissions would be mapped via ACLs. We've found
that this method has the closest behavior to a "real" Windows server and
has satisfied everyone.

- Permissions don't propigate through the filesystem.

On a Real Windows Box(tm) you would be able to set permissions at the
parent level of a directory and have them show up for each child object.
Because the filesystem semantics are not the same in *nix-land, you need
to go into the directly and manually propigate the permissions, or if
you're stuck trying to administer permissions through a windows session
(like the other IT staffers in my department), using the Advanced setting
to force-reset all permissions on all child objects. This has also
caused a bit of grousing as we have several nested directories with a
heiarchy of permissions; getting one parent directory wrong means
rebuilding permissions for several child directories as well. I have
never been able to get a satisfactory answer as to how to resolve this
issue, other than the process I described above (which I had to resolve
for myself without documentation).

- To oplock or not to oplock: that is the question

The documentation is not entirely clear about when you should and
shouldn't use oplocks on shared files. It would have been much simplier
(IMHO) to simply say "use your best judgement, BUT if you are using
shared data files like Access or Excel or DBF's, you will want to disable
them or you'll have problems!". Yes those words show up on newsgroups,
but it should also show up in the documentation clearly.

- Office file locking workaround(s) were not immediately obvious

Buried in the nice (but large) Official Samba Reference and HOWTO is a
fix for sharing Word and Excel files through Samba, which involves using
the sticky bit for group permissions. While the fix was adequate and
works well, it should have been I think a little more prominently
displayed in the documentation.

- What? You want me to unlock that file?

We have had recurring instances where a workstation on the network has
seized a DBF file and held onto it, not allowing any other workstation or
server to perform writes to the file. This locking issue shows up in
random intervals and always requires that we have the person quit the
program we are using and log back in. It is not an application issue
that we can determine - the rest of the system continues to funciton, it
just prevents one of our servers (or anyone else) from locking the file.

- Speaking of which - just WHO does have that file lock?

For some reason, using the computer management tool in a windows
workstation shows stale information. In our past arrangement, we were
able to determine who would have the locked file by simply connecting the
tool to the server, and sorting on the number of locks present; the tool
would show the data file with a lock count greater than zero. Apparently
this doesn't fly when connecting to the Samba server - it shows files
open, but the lock count is for ALL locks (including reads) and not just
write locks.

- You sure you still have that file open? It says you don't even have it!

The computer management tool also has an issue with data appearing to be
stale. Workstations that have been powered down still show a file open.
Or in some cases, the workstation is working with the file, but no file
handle appears in the tool! This was (and still is) a major issue for
our staff, and as a result of this they have learned not to trust this
once-reliable tool, because from their point of view, it lies to them. I
have had to come up with some work-arounds and while they do work they
are suboptimal in their eyes.

Now, the remaining question(s):

- The vendor initially set up our authentication via tdb files and
Winbind. We have been using this combination succesfully for some time,
but in the Official Samba Guide it talks about regular maintenance of the
tdb files via tdbbackup. The department head has asked that I find the
definitive answer on how to do this, as we cannot afford more than a few
minutes of scheduled downtime. The vendor's response was that tdb files
should not be used because they can be corrupted when applying tdbbackup
to them (despite the fact that it was the vendor that set us up to use
them to begin with - go figure). This has caused even more concern -
millions of dollars in business and 50+ users are supported by this
server, running 24/7/365. So, if we were to loose our file server
tomorrow, and had to activate the backup server (which we would do by
plugging in the eSATA array into the new units and starting up the
system), how could we guarantee that the GUIDs, etc. would be consistent
and we wouldn't have a complete mess on our hands? I have seen someone
else recently mention that they should be using an LDAP authentication
backend. So who's correct, the vendor's original setup which uses tdb
files, or the 2nd vendor response which says don't use them, or should we
be on LDAP authentication connected to our Win2k3 domain controllers?

- Is there a way to get the Computer Mangement tool to not "lie" to us
about the state of file handles and locks? It would be a godsend to not
have to watch everyone roll their eyes because the "expected" way of
locating file issues simply doesn't work for them. This is an ongoing
issue and I can't really provide a satisfactory answer - even SWAT
appears to have this issue as well! I have resorted to shell scripting
to provide us with the answers we need but this is hardly a long-term
solution. Is there some magic setting I need to flip in the registry for
our Windows XP clients to make this issue just go away? Is it related to
protocol changes in the newer versions of the Windows redirectors? Just
why does this happen?

A parting thought as well:

It would have been nice to have had a reasonably generic template or
example somewhere that pointed this out, instead of wasting an incredible
amount of time (a month!) reading many many many pages of documentation,
sometimes scattered into different chapters, as well as contacting the
vendor twice with over a half-dozen messages. I would think that a
simple, single smb.conf file named "smb.conf.dom-member.filesserver" with
a generic looking setup would have resolved many of these issues, by
having the appropriate settings and comments already in the file while
pointing out what parts of the template needed to be changed. Everyone
that I have talked to outside of my work looks at Samba as a drop-in
replacement for existing Win2k(3) file servers, and a template with
settings that come closest to emulating that same behavior would go a
long ways towards adoption. I'm not trying to be overly critical, but
rather, I'm trying to point out a missing part of the software package
that I think administrators would like to have, especially as more and
more companies start to operate in mixed environments.

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Wed, May 21, 2008 at 06:47:52PM +0000, Avery Payne wrote:
> Question:
>
> We recently moved to a Samba-based file server, which holds mission-
> critical data on it (.dbf files used by our Accounting software, etc.)
> The goal was to create a file server that had excellent performance while
> providing Volume Management, but we felt that something like Veritas was
> overkill for our needs.
>
> Design Goals:
> - Redundant Hardware
> - Manual Failover (this was an acceptable solution)
> - Very large storage capacity (minimum 1 Terabyte)
> - Better than 100Mbyte/sec throughput
> - Volume Management, Journaled Filesystem
> - Drop-In Replacement for aging Win2k file server
> - Use existing admin tools to avoid retraining
>
>
> The proposed solution was a Samba file server running on a pair of
> redundant servers, with one connected to an eSATA raid box, with LVM and
> Ext3 providing volume management and journaling. Our transition was a
> bit rough, but in the end it has been very stable and fast. We have been
> really pleased with the performance of the hardware/software combo,
> seeing sustained throughput of about 250Mbyte/sec with peaks as high as
> 300Mbyte/sec. But along the way, we encountered some oddities, and I
> have some remaining questions.
>
> First, the oddities (long-time Samba devs and admins, take this with a
> grain of salt, when I say oddity I mean it from the perspective of an
> experienced Windows administrator):

Great post, thanks for writing it !

I always appreciate it when users come and tell us about their
experiences, and where we can improve.

Now onto the specifics:

> - File permissions do not behave as expected (from the viewpoint of other
> staff working with the server).

Yes, ACLs are just different between UNIX & Windows. We map Windows
ACLs onto POSIX as best as we can, but the mapping is not perfect.
The goal is to make the two common cases : "these groups and user
fred have access", and "these groups but *not* user fred have access"
as intuitive as possible.

For 3.3 we're planning to overlay a Windows ACL model that will
allow perfect Windows ACL restrictions to be added to Samba,
but not perfect Windows ACL allowances (ie. we'll store the
Windows ACLs and use them to restrict access early on access
denied returns, but still map down to POSIX to allow the underlying
file permissions to take effect).

Hopefully this might help you.

> - To oplock or not to oplock: that is the question
>
> The documentation is not entirely clear about when you should and
> shouldn't use oplocks on shared files. It would have been much simplier
> (IMHO) to simply say "use your best judgement, BUT if you are using
> shared data files like Access or Excel or DBF's, you will want to disable
> them or you'll have problems!". Yes those words show up on newsgroups,
> but it should also show up in the documentation clearly.

Ok, I believe we are *identical* w.r.t. Windows as far as
oplocks go. If the vendor says disable oplocks with Windows,
disable them with Samba also. If not, leave them in place.

> - Office file locking workaround(s) were not immediately obvious
>
> Buried in the nice (but large) Official Samba Reference and HOWTO is a
> fix for sharing Word and Excel files through Samba, which involves using
> the sticky bit for group permissions. While the fix was adequate and
> works well, it should have been I think a little more prominently
> displayed in the documentation.

Can you point that out to me. We've done more work on ACL compatibility
with 3.0.28a and I believe that fix may not now be needed.

> - What? You want me to unlock that file?
>
> We have had recurring instances where a workstation on the network has
> seized a DBF file and held onto it, not allowing any other workstation or
> server to perform writes to the file. This locking issue shows up in
> random intervals and always requires that we have the person quit the
> program we are using and log back in. It is not an application issue
> that we can determine - the rest of the system continues to funciton, it
> just prevents one of our servers (or anyone else) from locking the file.

Sounds like a bug to me. Not sure where, client app or Samba. Need
more info on this.

> - Speaking of which - just WHO does have that file lock?
>
> For some reason, using the computer management tool in a windows
> workstation shows stale information. In our past arrangement, we were
> able to determine who would have the locked file by simply connecting the
> tool to the server, and sorting on the number of locks present; the tool
> would show the data file with a lock count greater than zero. Apparently
> this doesn't fly when connecting to the Samba server - it shows files
> open, but the lock count is for ALL locks (including reads) and not just
> write locks.

This seems like a Samba dificiency with that tool. You should be
able to get that info by running smbstatus on the Samba box.

> - You sure you still have that file open? It says you don't even have it!
>
> The computer management tool also has an issue with data appearing to be
> stale. Workstations that have been powered down still show a file open.
> Or in some cases, the workstation is working with the file, but no file
> handle appears in the tool! This was (and still is) a major issue for
> our staff, and as a result of this they have learned not to trust this
> once-reliable tool, because from their point of view, it lies to them. I
> have had to come up with some work-arounds and while they do work they
> are suboptimal in their eyes.

Same as above. smbstatus should give you this info.

> Now, the remaining question(s):
>
> - The vendor initially set up our authentication via tdb files and
> Winbind. We have been using this combination succesfully for some time,
> but in the Official Samba Guide it talks about regular maintenance of the
> tdb files via tdbbackup. The department head has asked that I find the
> definitive answer on how to do this, as we cannot afford more than a few
> minutes of scheduled downtime. The vendor's response was that tdb files
> should not be used because they can be corrupted when applying tdbbackup
> to them (despite the fact that it was the vendor that set us up to use
> them to begin with - go figure). This has caused even more concern -
> millions of dollars in business and 50+ users are supported by this
> server, running 24/7/365. So, if we were to loose our file server
> tomorrow, and had to activate the backup server (which we would do by
> plugging in the eSATA array into the new units and starting up the
> system), how could we guarantee that the GUIDs, etc. would be consistent
> and we wouldn't have a complete mess on our hands? I have seen someone
> else recently mention that they should be using an LDAP authentication
> backend. So who's correct, the vendor's original setup which uses tdb
> files, or the 2nd vendor response which says don't use them, or should we
> be on LDAP authentication connected to our Win2k3 domain controllers?

It is safe to use tdbbackup on a live system. The vendor is
mistaken.

> - Is there a way to get the Computer Mangement tool to not "lie" to us
> about the state of file handles and locks? It would be a godsend to not
> have to watch everyone roll their eyes because the "expected" way of
> locating file issues simply doesn't work for them. This is an ongoing
> issue and I can't really provide a satisfactory answer - even SWAT
> appears to have this issue as well! I have resorted to shell scripting
> to provide us with the answers we need but this is hardly a long-term
> solution. Is there some magic setting I need to flip in the registry for
> our Windows XP clients to make this issue just go away? Is it related to
> protocol changes in the newer versions of the Windows redirectors? Just
> why does this happen?

Needs more work in Samba on supporting the Computer management
tool. Currently smbstatus works better for this.

> A parting thought as well:
>
> It would have been nice to have had a reasonably generic template or
> example somewhere that pointed this out, instead of wasting an incredible
> amount of time (a month!) reading many many many pages of documentation,
> sometimes scattered into different chapters, as well as contacting the
> vendor twice with over a half-dozen messages. I would think that a
> simple, single smb.conf file named "smb.conf.dom-member.filesserver" with
> a generic looking setup would have resolved many of these issues, by
> having the appropriate settings and comments already in the file while
> pointing out what parts of the template needed to be changed. Everyone
> that I have talked to outside of my work looks at Samba as a drop-in
> replacement for existing Win2k(3) file servers, and a template with
> settings that come closest to emulating that same behavior would go a
> long ways towards adoption. I'm not trying to be overly critical, but
> rather, I'm trying to point out a missing part of the software package
> that I think administrators would like to have, especially as more and
> more companies start to operate in mixed environments.

Yep, this is true. We depend on the Linux vendors to do this as
we don't have the resources (or more accurately haven't spent
the resources we have) on doing this. Sometimes they do a good
job, sometimes not. This is why server appliance vendors often
are a better choice than a full blown Linux solution, as they
sell a pre-set up solution.

Thanks for your thoughts !

Jeremy.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

Avery,

OK - I'll respond too. I see Jeremy has beaten me to it.

Let me tell you up front, if you want the documentation to be improved the
best thing you can do is contribute changes and updates. Making us aware of
docuentation problems is a good start, but please take this a step further -
send us your updates and changes.

One other thing, before I get too far into answer or commenting is this: The
Official Samba3 HOWTO and Reference Guide (TOSHARG) is a document (book) that
sets out how specific parts of Samba function. It was never intended to
provide a working template or a scripted recipe.

I did write the Samba3-ByExample book with the specific objective to provide
detailed step-by-step, fully worked, examples of real working networks, did
you consult that document at any time? Are you offering to improve its value
and utility by contributing your experiences and recommendations?

Users and admins like yourself are in the best position to improve the
documentation.

Please see comments below.

Chees,
John T.

On Wednesday 21 May 2008 01:47:52 pm Avery Payne wrote:
> Question:
>
> We recently moved to a Samba-based file server, which holds mission-
> critical data on it (.dbf files used by our Accounting software, etc.)
> The goal was to create a file server that had excellent performance while
> providing Volume Management, but we felt that something like Veritas was
> overkill for our needs.

A noble goal that can be achieved.

> Design Goals:
> - Redundant Hardware
> - Manual Failover (this was an acceptable solution)
> - Very large storage capacity (minimum 1 Terabyte)
> - Better than 100Mbyte/sec throughput
> - Volume Management, Journaled Filesystem
> - Drop-In Replacement for aging Win2k file server
> - Use existing admin tools to avoid retraining

The last two goals are a little ambitious. A drop-in replacement is a tall
order that I believe can not be met today. There are some existing tools,
but none are a complete replacement for the nicely integrated Microsoft
toolset.

> The proposed solution was a Samba file server running on a pair of
> redundant servers, with one connected to an eSATA raid box, with LVM and
> Ext3 providing volume management and journaling.

I would not architect the solution this way. There are way too many pitfals
with this solution. You have identified one already - the SID <=> UID/GID
mapping challenge.

I would have used a RAID5 array in each server with rsync to synchronize from
the master to the slave. This could be run from cron. Anyhow, this is a
digression from your problems.

> Our transition was a
> bit rough, but in the end it has been very stable and fast. We have been
> really pleased with the performance of the hardware/software combo,
> seeing sustained throughput of about 250Mbyte/sec with peaks as high as
> 300Mbyte/sec. But along the way, we encountered some oddities, and I
> have some remaining questions.

What lab work did you do in a test environment before rolling this life?
Proper pre-rollout evaluation can save a lot of head-banging later.

> First, the oddities (long-time Samba devs and admins, take this with a
> grain of salt, when I say oddity I mean it from the perspective of an
> experienced Windows administrator):

Grain of salt taken. Your initiative to write this email is most appreciated.
It is a first step in the process of improvement.

> - File permissions do not behave as expected (from the viewpoint of other
> staff working with the server).
>
> The *nix permission bits cause a user, group, and "Everyone" entry to
> become permanent and persistent. There was some initial grousing over
> this fact as our long-time Windows admin scratched his head over why he
> couldn't remove these entries as he saw fit.

Samba is an engine that sits on top of a host OS. That host OS is NOT Windows.
Samba has to go along with the rules imposed by the host OS. The TOSHARG
chapter on "File, Directory, and Share Access Controls" should be the red
flag that underlying file system semantics are exerted by Samba. Windows
admins need to be trained to understand that Samba is not Windows NT/2Kx,
etc.

Jeremy's notes about the VFS modular work aimed at providing better Windows
ACLs emulation may provide the solution you are looking for.

> After explaining that there
> would always be three settings no matter what, that they could never be
> deleted, and that they represented actual filesystem-level bits that
> wouldn't go away, it was accepted. I didn't notice if this was in the
> docs or not, but I certainly didn't find it.

It would help me to understand your problem if you can point out how you went
about searching for answers. What questions did you frame mentally in your
search? Where and how did you look?

Did you use a hard-copy of the book? Search online in the HTML web pages? Or
did you download the PDF of the book and use the hotlinked pages in the
subject and topic indexes?

> It also meant enabling ACLs
> on all of the filesystems and doing some creative thinking with the
> permissions. The closest I could do was to map all files as owner root,
> group set to Domain Admins, and Everyone set to disallowed; members of
> the IT staff would be mapped with the "admin users" parameter; from
> there, any additional permissions would be mapped via ACLs. We've found
> that this method has the closest behavior to a "real" Windows server and
> has satisfied everyone.

Please write this up in a step-by-step form that can be added to one of the
books.


> - Permissions don't propigate through the filesystem.
>
> On a Real Windows Box(tm) you would be able to set permissions at the
> parent level of a directory and have them show up for each child object.
> Because the filesystem semantics are not the same in *nix-land, you need
> to go into the directly and manually propigate the permissions, or if
> you're stuck trying to administer permissions through a windows session
> (like the other IT staffers in my department), using the Advanced setting
> to force-reset all permissions on all child objects.

You can also add to the smb.conf share definition stanza the following
parameters that are documented in the smb.conf man page:

inherit owner
inherit acls
inherit permissions

Did you consider these? If so, what problems did they cause you?

> This has also
> caused a bit of grousing as we have several nested directories with a
> heiarchy of permissions; getting one parent directory wrong means
> rebuilding permissions for several child directories as well. I have
> never been able to get a satisfactory answer as to how to resolve this
> issue, other than the process I described above (which I had to resolve
> for myself without documentation).

OK - I understand the problem. What did you do to bring about better
documentation? Did you consider contributing some guidance documentation and
then circulation to get positive feedback from other Samba users?

Better documentation is always welcome. Contributions are continually sought.


> - To oplock or not to oplock: that is the question
>
> The documentation is not entirely clear about when you should and
> shouldn't use oplocks on shared files. It would have been much simplier
> (IMHO) to simply say "use your best judgement, BUT if you are using
> shared data files like Access or Excel or DBF's, you will want to disable
> them or you'll have problems!". Yes those words show up on newsgroups,
> but it should also show up in the documentation clearly.

I have not seen a single installation where DBF files and MDB file sharing
works acceptably with more than 3-5 concurrent users. It makes not
difference if the files are served off Windows Server 2003 or off a Samba
server. Oplocks slow things down and have side-effects. What-ever problems
you have with Windows servers will follow you to the Samba server also.

Best advice is do not use file sharing for multiple concurrent access database
files. Instead, use a SQL backend database.


> - Office file locking workaround(s) were not immediately obvious
>
> Buried in the nice (but large) Official Samba Reference and HOWTO is a
> fix for sharing Word and Excel files through Samba, which involves using
> the sticky bit for group permissions. While the fix was adequate and
> works well, it should have been I think a little more prominently
> displayed in the documentation.

Where in the book would you prefer to see this documented? What changes would
you make to the documentation to make this more prominent and more readily
capble of being found?


> - What? You want me to unlock that file?
>
> We have had recurring instances where a workstation on the network has
> seized a DBF file and held onto it, not allowing any other workstation or
> server to perform writes to the file. This locking issue shows up in
> random intervals and always requires that we have the person quit the
> program we are using and log back in. It is not an application issue
> that we can determine - the rest of the system continues to funciton, it
> just prevents one of our servers (or anyone else) from locking the file.

This is a client-side caching issue. Samba does not know that the file has
been released until the client notifies Samba that it has released the file.
Windows clients can go down without ever releasing the file. There are
Microsoft KB articles on how to disable client-side caching. Should this be
more vigorously documented in the HOWTO? If so, where should it be documented
in TOSHARGs?


> - Speaking of which - just WHO does have that file lock?
>
> For some reason, using the computer management tool in a windows
> workstation shows stale information. In our past arrangement, we were
> able to determine who would have the locked file by simply connecting the
> tool to the server, and sorting on the number of locks present; the tool
> would show the data file with a lock count greater than zero. Apparently
> this doesn't fly when connecting to the Samba server - it shows files
> open, but the lock count is for ALL locks (including reads) and not just
> write locks.

What tool are you using to explore this?


> - You sure you still have that file open? It says you don't even have it!
>
> The computer management tool also has an issue with data appearing to be
> stale. Workstations that have been powered down still show a file open.

See comment to previous question about this.

> Or in some cases, the workstation is working with the file, but no file
> handle appears in the tool! This was (and still is) a major issue for
> our staff, and as a result of this they have learned not to trust this
> once-reliable tool, because from their point of view, it lies to them. I
> have had to come up with some work-arounds and while they do work they
> are suboptimal in their eyes.

This sounds like a bug. How can we reproduce this?


> Now, the remaining question(s):
>
> - The vendor initially set up our authentication via tdb files and
> Winbind. We have been using this combination succesfully for some time,
> but in the Official Samba Guide it talks about regular maintenance of the
> tdb files via tdbbackup.

Unless I am sadly mistaken, the TOSHARG docs are correct. You really should
use tdbbackup on a regular basis in every large installation.

> The department head has asked that I find the
> definitive answer on how to do this, as we cannot afford more than a few
> minutes of scheduled downtime. The vendor's response was that tdb files
> should not be used because they can be corrupted when applying tdbbackup
> to them (despite the fact that it was the vendor that set us up to use
> them to begin with - go figure).

The vendor is mistaken. Please ask the vendor to speak with one of the Samba
developers.

> This has caused even more concern -
> millions of dollars in business and 50+ users are supported by this
> server, running 24/7/365. So, if we were to loose our file server
> tomorrow, and had to activate the backup server (which we would do by
> plugging in the eSATA array into the new units and starting up the
> system), how could we guarantee that the GUIDs, etc. would be consistent
> and we wouldn't have a complete mess on our hands? I have seen someone
> else recently mention that they should be using an LDAP authentication
> backend. So who's correct, the vendor's original setup which uses tdb
> files, or the 2nd vendor response which says don't use them, or should we
> be on LDAP authentication connected to our Win2k3 domain controllers?

LDAP is the way to go for IDMAP sharing across domain member servers. The tdb
files really should not be replicated across servers.

> - Is there a way to get the Computer Mangement tool to not "lie" to us
> about the state of file handles and locks? It would be a godsend to not
> have to watch everyone roll their eyes because the "expected" way of
> locating file issues simply doesn't work for them. This is an ongoing
> issue and I can't really provide a satisfactory answer - even SWAT
> appears to have this issue as well!

SWAT is not being actively maintained.

> I have resorted to shell scripting
> to provide us with the answers we need but this is hardly a long-term
> solution. Is there some magic setting I need to flip in the registry for
> our Windows XP clients to make this issue just go away? Is it related to
> protocol changes in the newer versions of the Windows redirectors? Just
> why does this happen?

So far as I am aware Samba fully matches the behavior of Windows server 2003.
Samba can not fix client-sied issues. You need to set your client registry
correctly to stop client-side caching for MDB and DBF files. I do believe
that is documented somewhere in TOSHARG.


> A parting thought as well:
>
> It would have been nice to have had a reasonably generic template or
> example somewhere that pointed this out, instead of wasting an incredible
> amount of time (a month!) reading many many many pages of documentation,
> sometimes scattered into different chapters, as well as contacting the
> vendor twice with over a half-dozen messages. I would think that a
> simple, single smb.conf file named "smb.conf.dom-member.filesserver" with
> a generic looking setup would have resolved many of these issues, by

Where would you search for this information? Which chapter? Which book? How
should it be documented? Are you willing to write this up in a usable form?

> having the appropriate settings and comments already in the file while
> pointing out what parts of the template needed to be changed. Everyone
> that I have talked to outside of my work looks at Samba as a drop-in
> replacement for existing Win2k(3) file servers,

Everyone can be mistaken, fortunately not everone is always mistaken.

> and a template with
> settings that come closest to emulating that same behavior would go a
> long ways towards adoption. I'm not trying to be overly critical, but
> rather, I'm trying to point out a missing part of the software package
> that I think administrators would like to have, especially as more and
> more companies start to operate in mixed environments.

I want to commend you on your email. You comments are due criticism. Your
assistance to close out your concerns is most appreciated.

Cheers,
John T.
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Wed, 21 May 2008 18:47:52 +0000 (UTC)
Avery Payne <apayne@pcfruit.com> wrote:

> Question:
>
> We recently moved to a Samba-based file server, which holds mission-
> critical data on it (.dbf files used by our Accounting software, etc.)
> The goal was to create a file server that had excellent performance while
> providing Volume Management, but we felt that something like Veritas was
> overkill for our needs.
>
> Design Goals:
> - Redundant Hardware
> - Manual Failover (this was an acceptable solution)
> - Very large storage capacity (minimum 1 Terabyte)
> - Better than 100Mbyte/sec throughput
> - Volume Management, Journaled Filesystem
> - Drop-In Replacement for aging Win2k file server
> - Use existing admin tools to avoid retraining

[snip]

>
> - Permissions don't propigate through the filesystem.
>

With POSIX ACL's they do. Take a look at "default ACL", it defines permissions
newly created files/directories inherits from their parent directory.
I might be misunderstanding your complains, though.
My Windows know-how is limited to an absolute minimum necessary to survive
in the wild world out there ;-)

As for the winbind and tdb files: if you fail over to the standby server you don't have
your SID to UID/GID mappings anymore, unless you copy then somehow over.
The LDAP backend for winbind is a great feature and I would suggest you to take it into
consideration.
I run several Samba instances on few Linux clusters with a SunOne Ldap "cluster" as backend
and it works very well (touching wood ;-)

Thanks and regards,
Chris
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Wed, 21 May 2008 12:33:34 -0700, Jeremy Allison wrote:

> On Wed, May 21, 2008 at 06:47:52PM +0000, Avery Payne wrote:
>> Question:
>>
>> We recently moved to a Samba-based file server, which holds mission-
>> critical data on it (.dbf files used by our Accounting software, etc.)
>> [big snip]

>> But along the way, we encountered some oddities,
>> and I have some remaining questions.
>>
>> First, the oddities (long-time Samba devs and admins, take this with a
>> grain of salt, when I say oddity I mean it from the perspective of an
>> experienced Windows administrator):
>
> Great post, thanks for writing it !
>
> I always appreciate it when users come and tell us about their
> experiences, and where we can improve.
>
> Now onto the specifics:
>
>> - File permissions do not behave as expected (from the viewpoint of
>> other staff working with the server).
>
> Yes, ACLs are just different between UNIX & Windows. We map Windows ACLs
> onto POSIX as best as we can, but the mapping is not perfect. The goal
> is to make the two common cases : "these groups and user fred have
> access", and "these groups but *not* user fred have access" as intuitive
> as possible.
>
> For 3.3 we're planning to overlay a Windows ACL model that will allow
> perfect Windows ACL restrictions to be added to Samba, but not perfect
> Windows ACL allowances (ie. we'll store the Windows ACLs and use them to
> restrict access early on access denied returns, but still map down to
> POSIX to allow the underlying file permissions to take effect).
>
> Hopefully this might help you.

I think it will. :)

>
>> - To oplock or not to oplock: that is the question
>>
>> [snip]
>
> Ok, I believe we are *identical* w.r.t. Windows as far as oplocks go. If
> the vendor says disable oplocks with Windows, disable them with Samba
> also. If not, leave them in place.

I was in a hurry to write all of this (as I am always pressed for time)
but what I was trying to convey is that the documentation could probably
be a bit clearer on this. Yes, I will be happy to contribute some
documentation to this specific issue. :)
>
>> - Office file locking workaround(s) were not immediately obvious
>>
>> Buried in the nice (but large) Official Samba Reference and HOWTO is a
>> fix for sharing Word and Excel files through Samba, which involves
>> using the sticky bit for group permissions. [snip]
>
> Can you point that out to me.

Sure. "The Official Samba-3 HOWTO and Reference Guide", Second Edition,
(c) 2006 John H. Terpstra, printed by Prentice-Hall, Professional
Technical Reference. Turn to page 264, last 4 paragraphs on the page
(including 1 inset caption). Heading is 15.6.3, "MS Word with Samba
Changes Owner of File". The description of what to do provided a
significant fix for us.

> We've done more work on ACL compatibility
> with 3.0.28a and I believe that fix may not now be needed.

The vendor's version is samba-3.0.25b-1.el5_1.4. I can't mention the
vendor but I think you could probably guess it by looking at that version
number. ;)

>> - What? You want me to unlock that file?
>>
>> We have had recurring instances where a workstation on the network has
>> seized a DBF file and held onto it, not allowing any other workstation
>> or server to perform writes to the file. [snip]
>
> Sounds like a bug to me. Not sure where, client app or Samba. Need more
> info on this.

The application is ACCPAC Pro Series 7.2 (now relabeled Sage Pro
Series). It is written in Visual FoxPro 8, and uses VFP DBF, CDX, DBC,
VCX, etc. files, almost all of which are really just mutant dBase tables,
so any record or file locking semantics that apply to DBF files will
apply to those files as well.

I used to see this behavior years ago with Win95 workstations talking
with a Win2k file server. The issue disappeared when we migrated the
workstations to Win2k. It might not be so much a Samba bug as it is an
issue with the settings for the workstation redirectors.

>
>> - Speaking of which - just WHO does have that file lock?
>>
>> For some reason, using the computer management tool in a windows
>> workstation shows stale information. [snip]
>
> This seems like a Samba dificiency with that tool. You should be able to
> get that info by running smbstatus on the Samba box.

There's the rub. The existing staff expect to use the in-place GUI
toolset and have no interest in learning command line tools (including
the department head). Yeah, I know, nothing you can do about that
directly, but indirectly, it might be worth looking into making minor
tweaks to function with the Computer Management snap-in.

You can test this easily by openning several files (Excel, Word, Access,
doesn't matter) at several workstations, start making changes but *don't
save them*...let the workstations and server sit for a bit...then open
the Comp. Mgmt. snap-in, right-click on the top of tree, select "Connect
to another computer...", place the server name in the dialog that appears
and click on [OK]. Navigate to Computer Management -> System Tools ->
Shared Folders -> Open Files. You'll see a list of files that are
"open". Note that after a long period of time - say, a few days - that
the file you openned *doesn't appear in the list* after a refresh (press
F5 to refresh). Nothing wrong with that, as I understand that the client
or server may close the connection - but if you do this same operation on
a "stock" Windows box, the file handle is persisent for as long as you
have the file open and both the server and workstation running. In short
- the file semantics being reported are different between a Samba server
and a Windows server when using this tool. If this is a design decision,
you might want to have a small blurb in the docs someplace about how
those semantics differ, so administrators don't feel like they're going
insane when they can't figure out why a file is still in use but it isn't
reported by the snap-in.

Another way to look at this is to open a shell and compare the output of
lsof against smbstatus - you'll see that, over time, there are occasional
discrepencies between the two as far as what files are open, etc.

Using smbstatus was (unfortunately) not effective for us - it showed
different results from the snap-in I mentioned above, but like the snap-
in, it would have discrepencies between what lsof reports and what it
reports. We would also see "no one has that file open" but when we try
to obtain an exclusive lock on the DBF, it would report that it is in use
by someone (and indeed, it was). The final solution in locating a locked
file was to place this in a shell script named 'find-lock':

lsof | grep 'vp' | grep 'u[wW] '

As crude as it is, it works. The "vp" refers to a fixed pathname that is
unique to our installation, so we can narrow down the number of files to
just those files that may contain DBF data. The grep looks for write
locks, either at a table (file) level or a record level. It has been
100% accurate in the 8 times that we have had to use it.

>
>> - You sure you still have that file open? It says you don't even have
>> it!
>>
>> The computer management tool also has an issue with data appearing to
>> be stale. [snip]
>
> Same as above. smbstatus should give you this info.

Addressed above.

>
>> Now, the remaining question(s):
>>
>> - The vendor initially set up our authentication via tdb files and
>> Winbind. [snip]
>> So who's correct, the
>> vendor's original setup which uses tdb files, or the 2nd vendor
>> response which says don't use them, or should we be on LDAP
>> authentication connected to our Win2k3 domain controllers?
>
> It is safe to use tdbbackup on a live system. The vendor is mistaken.

THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU....

That single reply was worth its weight in gold. I can now sleep a little
better at night.

>> - Is there a way to get the Computer Mangement tool to not "lie" to us
>> about the state of file handles and locks? [snip]
>
> Needs more work in Samba on supporting the Computer management tool.
> Currently smbstatus works better for this.

Also addressed above.

>
>> A parting thought as well:
>>
>> It would have been nice to have had a reasonably generic template or
>> example somewhere that pointed this out... [snipped long frustration]
>
> Yep, this is true. We depend on the Linux vendors to do this as we don't
> have the resources (or more accurately haven't spent the resources we
> have) on doing this. Sometimes they do a good job, sometimes not. This
> is why server appliance vendors often are a better choice than a full
> blown Linux solution, as they sell a pre-set up solution.

Long story short, it wasn't on the radar due to other issues - but I'll
keep that in mind. :)

>
> Thanks for your thoughts !

Thanks for the reply!

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Wed, 21 May 2008 15:31:48 -0500, John H Terpstra wrote:

> Avery,
>
> OK - I'll respond too. I see Jeremy has beaten me to it.
>
> Let me tell you up front, if you want the documentation to be improved
> the best thing you can do is contribute changes and updates. Making us
> aware of docuentation problems is a good start, but please take this a
> step further - send us your updates and changes.

More than happy to as soon as I can find the time. :)
'
>
> One other thing, before I get too far into answer or commenting is this:
> The Official Samba3 HOWTO and Reference Guide (TOSHARG) is a document
> (book) that sets out how specific parts of Samba function. It was never
> intended to provide a working template or a scripted recipe.

Understood. I am using it as a tech reference.

> I did write the Samba3-ByExample book with the specific objective to
> provide detailed step-by-step, fully worked, examples of real working
> networks, did you consult that document at any time?

I didn't even know it existed. The majority of web queries resulted in
the online version of TOSHARG being displayed. Thanks for pointing that
out, I'll look for it.

> Are you offering to improve its value and utility by contributing your
> experiences and recommendations?

Yes, as time permits.

>
> On Wednesday 21 May 2008 01:47:52 pm Avery Payne wrote:
>> Question:
>>
>> The goal was to create a file server that had excellent performance
>> while providing Volume Management, but we felt that something like
>> Veritas was overkill for our needs.
>
> A noble goal that can be achieved.

I think we're 99.9% there, it's that 0.1% that's holding up the works.
Overall, everyone is pleased.

> [lots 'o stuff snipped]
>> The proposed solution was a Samba file server running on a pair of
>> redundant servers, with one connected to an eSATA raid box, with LVM
>> and Ext3 providing volume management and journaling.
>
> I would not architect the solution this way. There are way too many
> pitfals with this solution. You have identified one already - the SID
> <=> UID/GID mapping challenge.

The solution is that there are nightly backups of all the tdb's to a
known LVM volume. The idea is that in the even of manual failover, the
volume would be mounted, the tdb's copied into place, some minor settings
changed, and the service started.

Originally I was aiming for a "clustered" approach but it appears that
the software (both the OS and Samba) were not ready for this - yet Samba
4 may still surprise me. :)

>
> I would have used a RAID5 array in each server with rsync to synchronize
> from the master to the slave.

There is no master-slave, the other machine is a cold-standby solution.
The RAID 10 array contains 16 drives on a eSATA box that has redundant
power, redundant connects, etc. A manual failover was chosen by
mangement due to cost and software constraints. The downtime involved
was deemed acceptable - 5 to 10 minutes. Downtime exceeding 15 minutes
however would start creeping costs into the red.

>
>> Our transition was a
>> bit rough, but in the end it has been very stable and fast. We have
>> been really pleased with the performance of the hardware/software
>> combo, seeing sustained throughput of about 250Mbyte/sec with peaks as
>> high as 300Mbyte/sec. But along the way, we encountered some oddities,
>> and I have some remaining questions.
>
> What lab work did you do in a test environment before rolling this life?
> Proper pre-rollout evaluation can save a lot of head-banging later.

3 months. This is an epic story for another time. :)

>
>> - File permissions do not behave as expected (from the viewpoint of
>> other staff working with the server).
>>
>> [snip]
>
> Samba is an engine that sits on top of a host OS. That host OS is NOT
> Windows. Samba has to go along with the rules imposed by the host OS.
> The TOSHARG chapter on "File, Directory, and Share Access Controls"
> should be the red flag that underlying file system semantics are exerted
> by Samba. Windows admins need to be trained to understand that Samba is
> not Windows NT/2Kx, etc.

Point appreciated. As a Linux admin (since '98) and a Windows NT admin
(since '97), I can appreciate the semantical differences between the two,
and the efforts involved by the Samba devs to make things "work". I did
read those sections (repeatedly). Sometimes it's easy to miss things
when the world is at your door screaming for blood - especially when it's
your blood.

As for the admin training side, my co-worker is an MCSE coming from 20
years of VAX/PDP experience, and the department head (my direct boss) is
an OS X fan who uses 10.5 on a daily basis. Which makes for interesting
conversations between us all. :)

>
> Jeremy's notes about the VFS modular work aimed at providing better
> Windows ACLs emulation may provide the solution you are looking for.

I have read about some of the VFS features and will be using the audit
feature in the near future. However, some of what I face may be a
versioning issue due to the vendor (or not).

>
>> After explaining that there
>> would always be three settings no matter what, that they could never be
>> deleted, and that they represented actual filesystem-level bits that
>> wouldn't go away, it was accepted. I didn't notice if this was in the
>> docs or not, but I certainly didn't find it.
>
> It would help me to understand your problem if you can point out how you
> went about searching for answers. What questions did you frame mentally
> in your search?

Q: Why can't I delete these entries inside of the directory/file property
pane? They keep reappearing no matter what I do. (the question phrased
as given to me by both my coworker and my boss)

The issue is that the frame of reference - "this is how we set file
permissions and this is the expected behavior of the vendor-provided GUI
tool" - is somewhat different from the material that is being presented.
I have had to do alot of verbal footwork in translating things. Perhaps
I can help here with some new material...

> Where and how did you look?

"The Official Samba-3 HOWTO and Reference Guide", Second Edition,
(c) 2006 John H. Terpstra, printed by Prentice-Hall, Professional
Technical Reference.

The quickest solution to the issue was found with deductive reasoning
coupled with emprical experimentation. Good old-fashioned 'sit down and
work it out'. :)

> Did you use a hard-copy of the book?

Yes. See above book reference.

> Search online in the HTML web
> pages?

Yes, both through site searches at samba.org and through google.
Unfortunately, they ended up being web versions of the book.

> Or did you download the PDF of the book and use the hotlinked
> pages in the subject and topic indexes?

Yes.

>
>> [snip]
>> We've found that this method has the closest behavior to a
>> "real" Windows server and has satisfied everyone.
>
> Please write this up in a step-by-step form that can be added to one of
> the books.

More than happy to, as time permits. :)

>
>
>> - Permissions don't propigate through the filesystem.
>>
>> [dumb issue that I could have avoided snipped]
>
> You can also add to the smb.conf share definition stanza the following
> parameters that are documented in the smb.conf man page:
>
> inherit owner
> inherit acls
> inherit permissions

Thanks! The reason they were not used initially is that the initial
permissions model didn't account for that (because I didn't know the
settings were there), and on top of that, it changed during the
transition. Some of the filesystem is using the original model - where
domain groups are mapped to a GID on the linux box and the directory/
files are then updated with that GID - while other directories are
following the ACL approach. Throw in some complete confusion by the
vendor's muddled guidence, and it gets messy. As I have time permitting,
the entire filesystem will be migrated to the ACL approach.

>
> Did you consider these?

No (see above). It will be rememdied. Lesson: when in doubt, stick with
your gut, because the vendor usually doesn't get it right on the first
try.

> If so, what problems did they cause you?

N/A (see above)

>
>> This has also
>> caused a bit of grousing as we have several nested directories with a
>> heiarchy of permissions; getting one parent directory wrong means
>> rebuilding permissions for several child directories as well. I have
>> never been able to get a satisfactory answer as to how to resolve this
>> issue, other than the process I described above (which I had to resolve
>> for myself without documentation).
>
> OK - I understand the problem. What did you do to bring about better
> documentation?

I repeatedly hit myself on the head with a baseball bat. Just kidding.

The documentation was created in-house at my employer's expense. I will
attempt to re-write the docs I created on my own time and provide them to
you later.

> Did you consider contributing some guidance
> documentation and then circulation to get positive feedback from other
> Samba users?

Yes, but the time factor involved was prohibitive. Hard to do the right
thing when you're holding off end-users with a pointy stick. See my
other post to Jeremy re: users screaming for blood. That, and it's hard
to think straight after working a 38 hour shift with no sleep, no food,
no breaks, and no rest.

>
> Better documentation is always welcome. Contributions are continually
> sought.

More on that later. I have some ideas that I think would be worthwhile,
and I'm willing to type them up.

>> - To oplock or not to oplock: that is the question
>>
>> The documentation is not entirely clear about when you should and
>> shouldn't use oplocks on shared files. [frustrations snipped]
>
> I have not seen a single installation where DBF files and MDB file
> sharing works acceptably with more than 3-5 concurrent users.

In our prior version of the software we had 50 workstations, of which
half were concurrently active, updating/reading DBF files every day.
Locking is kept to a minimum, which contributes to a very low latency.
The general "gut feel" we have here is that the limit of our system is
probably around 50 concurrent users; on busier days with more than 30
workstations active, the system started to visibly slow, although
performance degraded gracefully. The setup (at the time) was a Win2k
Server with 50 Win2k Workstations on switched 100BaseT, with gigabit
going into the server.

>
> Best advice is do not use file sharing for multiple concurrent access
> database files. Instead, use a SQL backend database.

The ERP package in use allows us to do so for a very prohibitive price.
It would actually be cheaper to employ me for an entire year to develop
an object wrapper to intercept all calls to the DB API and send them to a
PostgreSQL or MySQL backend, working full time on this project and doing
none of my other duties (networking, sysadmin, security, email services,
data warehouse, end-user support, customization of the accounting
package, etc.), while struggling to emulate all of the features with only
the API interface as a document to guide me (there is no source
available). Of course, that isn't going to happen. :(

>
>
>> - Office file locking workaround(s) were not immediately obvious
>>
>> [snip]
>
> Where in the book would you prefer to see this documented? What changes
> would you make to the documentation to make this more prominent and more
> readily capble of being found?

The largest issue encountered revolved around locking semantics and how
the system would behave. This I will fully address later when I write up
my docs and send them to you.

>> - What? You want me to unlock that file?
>>
>> We have had recurring instances where a workstation on the network has
>> seized a DBF file and held onto it, not allowing any other workstation
>> or server to perform writes to the file. This locking issue shows up
>> in random intervals and always requires that we have the person quit
>> the program we are using and log back in. It is not an application
>> issue that we can determine - the rest of the system continues to
>> funciton, it just prevents one of our servers (or anyone else) from
>> locking the file.
>
> This is a client-side caching issue. Samba does not know that the file
> has been released until the client notifies Samba that it has released
> the file. Windows clients can go down without ever releasing the file.
> There are Microsoft KB articles on how to disable client-side caching.
> Should this be more vigorously documented in the HOWTO?

Yes, although I would prefer the term "slightly expanded article". :)

> If so, where should it be documented in TOSHARGs?

The viewpoint comes from a small-to-medium sized LAN installation, using
shared-file databases (dBase, FoxPro, Paradox, Access). This may not be
very common in larger installations, but I can attest (from personal
experience) that it is frequently used in smaller setups.

I think the real issue is that there is a juncture between file locking
and file permissions that are critical to having those environments work
correctly. A small paragraph about shared-file databases would probably
go a long ways towards providing clarity to the implementor as to how
things will work, etc. Again, I'll try to get something to you later.

>> - Speaking of which - just WHO does have that file lock?
>>
>> [snip]
>
> What tool are you using to explore this?

Computer Management Snap-In.

>
>
>> - You sure you still have that file open? It says you don't even have
>> it!
>>
>> The computer management tool also has an issue with data appearing to
>> be stale. Workstations that have been powered down still show a file
>> open.
>
> See comment to previous question about this.
>
>> Or in some cases, the workstation is working with the file, but no file
>> handle appears in the tool! [snip]
>
> This sounds like a bug. How can we reproduce this?

See my posting to Jeremy on this. I'll try to develop a specific test,
but the description I gave is the best I can do for now until I can
catagorize the bug further.

>
>
>> Now, the remaining question(s):
>>
>> - The vendor initially set up our authentication via tdb files and
>> Winbind. We have been using this combination succesfully for some
>> time, but in the Official Samba Guide it talks about regular
>> maintenance of the tdb files via tdbbackup.
>
> Unless I am sadly mistaken, the TOSHARG docs are correct. You really
> should use tdbbackup on a regular basis in every large installation.

Jeremy has confirmed this. Thanks for the 2nd confirmation. :) And I am
backing up all tdb's daily to an LVM volume on the RAID array, so when
the 2nd system goes live, I can simply restore them with tdbbackup.



>
>> [snip]
> You need to set your client
> registry correctly to stop client-side caching for MDB and DBF files. I
> do believe that is documented somewhere in TOSHARG.

I am using both global and share-level "veto oplocks" settings, with a
very detailed match string. :)

>
>
>> A parting thought as well:
>>
>> It would have been nice to have had a reasonably generic template or
>> example somewhere that pointed this out [snip]
>
> Where would you search for this information? Which chapter? Which book?
> How should it be documented? Are you willing to write this up in a
> usable form?

1) it should be part of a section on implementing replacement file
services for Win2k(3) boxen.
2) undetermined. I will have to look at that. I am already almost over
my time limits on this reply today (forgoing lunch to reply).
3) again, undetermined.
4) Yes.


> Everyone can be mistaken, fortunately not everone is always mistaken.

:(

Part of my job is to pull magic rabbits out of the hat. I fear the day
when I reach in the hat and come up empty-handed.


--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Thu, 22 May 2008 10:59:08 +0200, Chris Osicki wrote:

> On Wed, 21 May 2008 18:47:52 +0000 (UTC) Avery Payne
> <apayne@pcfruit.com> wrote:
>
>> Question:
>>
>> We recently moved to a Samba-based file server, which holds mission-
>> critical data on it (.dbf files used by our Accounting software, etc.)
>> The goal was to create a file server that had excellent performance
>> while providing Volume Management, but we felt that something like
>> Veritas was overkill for our needs.
>>
>> Design Goals:
>> - Redundant Hardware
>> - Manual Failover (this was an acceptable solution)
> [snip]

> As for the winbind and tdb files: if you fail over to the standby server
> you don't have your SID to UID/GID mappings anymore, unless you copy
> then somehow over.
They "float on a liferaft" that is an LVM partition. The tdb's are
backed up nightly and placed in the partition. Should the server fail,
the tdb's are restored and the smb.conf modified...


--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba

On Thursday 22 May 2008 02:48:14 pm Avery Payne wrote:
> On Wed, 21 May 2008 15:31:48 -0500, John H Terpstra wrote:
> > Avery,
> >
> > OK - I'll respond too. I see Jeremy has beaten me to it.
> >
> > Let me tell you up front, if you want the documentation to be improved
> > the best thing you can do is contribute changes and updates. Making us
> > aware of docuentation problems is a good start, but please take this a
> > step further - send us your updates and changes.
>
> More than happy to as soon as I can find the time. :)

Good. Thanks.

>
> > One other thing, before I get too far into answer or commenting is this:
> > The Official Samba3 HOWTO and Reference Guide (TOSHARG) is a document
> > (book) that sets out how specific parts of Samba function. It was never
> > intended to provide a working template or a scripted recipe.
>
> Understood. I am using it as a tech reference.

Good.

> > I did write the Samba3-ByExample book with the specific objective to
> > provide detailed step-by-step, fully worked, examples of real working
> > networks, did you consult that document at any time?
>
> I didn't even know it existed. The majority of web queries resulted in
> the online version of TOSHARG being displayed. Thanks for pointing that
> out, I'll look for it.

Please check it out and let me know what is missing. Also, since you did not
know it exists, what should we do to make it more prominent? Is it worth
making it more prominent?

You can download it from:
http://www.samba.org/samba/docs/Samba3-ByExample.pdf

> > Are you offering to improve its value and utility by contributing your
> > experiences and recommendations?
>
> Yes, as time permits.

Great. This sort of contribution is necessary.

> ...
> More on that later. I have some ideas that I think would be worthwhile,
> and I'm willing to type them up.
>
> >> - To oplock or not to oplock: that is the question
> >>
> >> The documentation is not entirely clear about when you should and
> >> shouldn't use oplocks on shared files. [frustrations snipped]
> >
> > I have not seen a single installation where DBF files and MDB file
> > sharing works acceptably with more than 3-5 concurrent users.
>
> In our prior version of the software we had 50 workstations, of which
> half were concurrently active, updating/reading DBF files every day.
> Locking is kept to a minimum, which contributes to a very low latency.
> The general "gut feel" we have here is that the limit of our system is
> probably around 50 concurrent users; on busier days with more than 30
> workstations active, the system started to visibly slow, although
> performance degraded gracefully. The setup (at the time) was a Win2k
> Server with 50 Win2k Workstations on switched 100BaseT, with gigabit
> going into the server.

DBF files are a special case. While the client can cache any file, DBF's have
an internal locking method. A DBF application will set a record lock flag and
is responsible for resetting it on completion of write. If the client does
not flush its cache this info can get lost with the result that the record
remains locked. There are some apps that will scan the DBF file for stale
locks and reset them. Corruption of DBFs is usually not as big a problem as
with MDB files.

> > Best advice is do not use file sharing for multiple concurrent access
> > database