[ale] Switching from Server 2003 to Samba

Michael Trausch mike at trausch.us
Sat Jul 12 14:55:23 EDT 2014


Testing, testing, testing.

Before I go further: I can't speak to anything more recent than about 18
months ago, as I haven't had to admin a setup like this for a while.
however, it doesn't appear that much has changed.

Since you have an existing system and you need to migrate, you *NEED* to be
given a lab environment that allows you to deploy a mirror of the current
AD domain, so that you can test migrating it to e.g., Samba 4.  Users need
to ensure that all of their applications work correctly, as well.  Windows
and applications that run on it make many assumptions that may or may not
hold true under Samba 4 for a variety of reasons (not the least of which is
the fact that it is a different implementation than Microsoft Windows).

That said, I've had good luck.  The major sticking points I ran into:

   - File permissions are an issue. Ensure that you're using POSIX ACLs,
   and ensure that your Samba configuration is suitably configured to use
   them.  Note, however, that POSIX filesystem permissions and Win32
   filesystem permissions are two very different beasts, and there will be
   issues in mapping.  Samba 4 does a much better job than Samba 3, but as of
   the last I used it, they're still not perfect.
   - Some AD functionality is stubbed out.  Ensure that none of the
   functionality that your users depend on is missing/stubbed.
   - It's relatively easy to get it to function for UNIX systems as well,
   but it's better to use FreeIPA to create a trust with the AD server and
   re-export that way.
   - In fact, if you're doing this and not going to be running Windows
   clients after the migration (or are going to be doing this in order to
   support the addition of UNIX/Linux clients to the network) just deploy a
   FreeIPA domain.
   - Also, pay very close attention to the Samba/AD replication.  In order
   to replace the AD server, you're going to have to have Samba 4 configured
   as a secondary controller, synchronize it with the domain, and then promote
   it.  After promotion of Samba 4, you can demote the Windows box, and then
   retire it.
   - Multiple users attempting to work on the same document at the same
   time was quite broken in Samba 3.  It seems to work halfway in Samba 4;
   instead of fully supporting concurrent access, the first time a file is
   opened, that process gets the ability to read/write it; all other processes
   are not allowed to write the file at all.

Samba 4.1 has support for efficient hosting on top of btrfs and claims
better AD replication support, as well as SMB3 encrypted connections.  You
should be able to implement VSS and server-side copy operations now with
Samba 4.  (This is on my todo-list to try out.)  This means that it can
function as a backup destination for the Windows machines on the network,
too.

Full disclosure: The last version of Samba I've had the pain of having to
administer was 4.0.3—Samba 4.1 appears to be much better and if it works as
advertised, should provide for you a much smoother transition than was
previously possible.  The network that I had to administer was a Samba 3
network for a long time simply because all the systems in the network were
happy with NT4-style domains.

One other thing to note: deploying AD with Samba first seems to be much,
much more difficult than installing a temporary microsoft domain controller
and then using Samba to take over from it.  This seems to have to do with
the setup of a lot of the AD-things that Samba 4.0 had stubbed out.  This
may have changed since then.


On Sat, Jul 12, 2014 at 11:42 AM, Michael Trausch <mike at trausch.us> wrote:

> I can't do so right this second, but I will post a decent write up of my
> experiences for you later today.
>
> Sent from my iPhone
>
> > On Jul 10, 2014, at 3:53 PM, Edward Holcroft <eholcroft at mkainc.com>
> wrote:
> >
> > All,
> >
> > The time has finally come to ditch our Micro$haft file servers as another
> > increment towards weaning ourselves of our Windows habit. For now, I have
> > to keep Active Directory in the picture, although I have managed to
> reduce
> > the AD server footprint from 18 servers down to 4. Corporate mindset
> issues
> > demand small steps.
> >
> > Question: Is it better to go with an "appliance solution" such as FreeNAS
> > vs. distro+Samba?
> >
> > I played around with FreeNAS a bit and while it has great automation of
> > things like AD integration (which I will need to do for now) and a great
> > web interface, it seems less flexible when it comes to e.g. backup
> options.
> > It seems a simple Ubuntu/Samba box gives me many options on how to handle
> > our daily backups to USB, while FreeNAS can potentially close doors to
> me,
> > or at least make things harder. That's just one example that I ran into.
> >
> > So, I'd like to hear from you about experiences/pros-cons of
> appliance-type
> > options vs the manual way. I've tried both at a simple test level. They
> > both seem viable and I really want to like FreeNAS, but just cannot seem
> to
> > get comfortable with it - little glitches seem to pop up that have the
> > potential to be major sticking points. So right now I'm leaning towards
> > distro+Samba.
> >
> > Feel free to suggest other options besides the two mentioned here.
> Whatever
> > solution I deploy I have to be able to use Windows ACL's on the shares
> ...
> > for now.
> >
> > cheers
> > ed
> >
> > --
> > Edward Holcroft | Madsen Kneppers & Associates Inc.
> > 11695 Johns Creek Parkway, Suite 250 | Johns Creek, GA 30097
> > O (770) 446-9606 | M (770) 630-0949
> >
> > --
> > MADSEN, KNEPPERS & ASSOCIATES USA, MKA Canada Inc.
> WARNING/CONFIDENTIALITY
> > NOTICE: This message may be confidential and/or privileged. If you are
> not
> > the intended recipient, please notify the sender immediately then delete
> it
> > - you should not copy or use it for any purpose or disclose its content
> to
> > any other person. Internet communications are not secure. You should scan
> > this message and any attachments for viruses. Any unauthorized use or
> > interception of this e-mail is illegal.
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> http://mail.ale.org/pipermail/ale/attachments/20140710/5da89949/attachment.html
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140712/ea68a15e/attachment.html>


More information about the Ale mailing list