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