Windows Admin looking to start out small with Linux (ubuntu) file server
Solution 1:
EDIT: Why not to start with a fileserver
Don't start with a fileserver unless you feel comfortable enough to troubleshoot it in case of failure without vast amounts of downtime, you don't want your users to be waiting for a file restore for hours/days just because you set up samba and now have some component failing that you don't know how to fix.
I'd start out with something like the following:
- run linux as your main desktop OS
- this will give you the option of running into problems in "non-critical" systems, learning one bit at a time
- in any case do install a virtual machine running Windows to get work done
- I'd not do it the other way around since you will need a lot more self discipline to fire up the VM and work with linux - if linux is the default you'll probably start working with it rather sooner than later
- define some requirements you have in your company and figure out which systems you could run in parallel (like a second system to do backups) and if not time critical try to meet your requirements
- personally I think a backup system makes a good start you'll probably run into some issues like I/O bound scaling, disk management and such you can solve without running into a lot of problems since you will be running your well known backup infrastructure anyway
- also some complementary monitoring system will help you a lot, it won't need too much ressources but will get you started with the problems in heterogenous networks, like "How do I get monitoring data from a Windows host into my Linux system" the same could be true for a central logserver
So much for some examples to get started with which won't interrupt your day to work or services.
Linux is not Windows - forget about things like "But in Windows I do it this way" rather search for the "correct" way to do it in Linux. Also try to do as much as possible without "falling back" to X.org. You will want to be able to manage your systems with as few dependencies as possible, X is a huge dependency. Since you were managing an AIX box I guess you know the basics already (Unix permisions and such). Also start as early as possible with stuff like cfengine (Windows + Linux) or puppet (Linux only) and FAI (or the various other deployment tools depending on the distro you choose) to have a management framework in place for more than a single server in case you need it - and you will, *nix based operating systems don't have as much glue ready to use as Windows to manage multiple servers. This makes it a bit more complex (not necessarily more complicated - mind the difference) but gives you also more flexibility
VERY SUBJECTIVE: I'd avoid Ubuntu for servers as I found there package quality to be too low for servers, also Fedora isn't really good for server IMHO as they provide bleeding edge packages, which is nice for desktops or "tech previews" but I'd rather want my servers to run on a stable base.
Solution 2:
Ok, first off, I've run an actual Samba server in a production environment for over a year. I can tell you there will be ups and downs to this process and that it is not as straightforward as it would be under Windows Server. The second thing I can tell you is that, as long as you bring Windows baggage with you (expectations on behavior) it will never work as well as you would like.
My setup was a bit different - RHEL 5.1 - but the principle is the same.
First, you'll find that you will really, really need to understand how Samba handles file permissions in a manner that is consistent with your perception of "File Properties -> Security Tab" because it's just not the same. It's really close, but no cigar. Because you are translating between two semantically different filesystems, you will find such oddities as "the Everyone group can't be deleted" and "root owns all my files", that is if you use root as the primary listing in "Take Possession". This is because there is always a world permission (the Other group) and always a user permission (which roughly corresponds to "Owner"), and in Unix-land these can never go away, and if they can't go away, you can't really delete them now, can you? My department teammates couldn't come to grips with this - they just couldn't abandon the Windows baggage that they were used to. So it was always lots and lots of grief about "why can't I delete these" (because of the reason I just gave) and "But if everyone is listed then there's a security hole" (it isn't, the semantics are different), and so forth, and each time, I would have to re-explain this over and over again. File permissions are tricky when you're translating them. Be sure to settle on a schema that makes sense for your deployment.
Second, Winbind is your weakest link. Seriously. RHEL 5.1 comes bundled with 3.0.25 (3.0.28 if you update) and the out-of-box version will collapse due to a bug. When Winbind goes, the file services go with it, because there isn't anything to authenticate against. Something as simple as pressing and holding the refresh key in an Explorer window (press F5) would result in a collapse of the connection, and if done under enough load, collapse of Winbind itself. Updating to 3.0.28 resolved this issue but it does indicate that there are some sore spots in older versions of the software. Short version: stay up to date with the version you are using. Try to get the newest if possible, as several bugs may be fixed. Distro packagers are notorious for being way behind the bugfix curve when it comes to Samba.
Third, the Samba team is hard at work on adding support that will allow existing Windows administration tools to interface directly with the service. You can, for instance, set up scripts that will start and stop local *nix services using the interface for Windows services, just don't use the same service to stop Samba (because you'll cut your connection). Very handy for doing other services on the server. You can also attach via Computer Management and see open sessions, files open, etc. However, not all of the RPC protocol is implemented and some attempts will result in (non-fatal) errors. So be sure you factor this into your systems management perspective and take advantage of it when possible. If you can harness an existing Windows administrative tool to interface with Samba, and you have other staffers in a "Windows" world that need help with the transition, you can soften the blow by re-using those tools, until they are comfortable with a command line.
Forth, I would look hard at the version of Samba you're deploying. Ubuntu is good for a desktop, so-so for a server. It's an ancient African word that means "I can't install Debian". You're really deploying someone else's remix of Debian, and frankly, if you want stable, why not go with the original?
Debian may have software that seems "stale" but in reality, the security team is prompt about backporting security fixes, and the policy of "we don't rev releases because a behavior could change, leading to breakage" sometimes makes better sense, especially if you're going for a long-term setup with stability. If you lean in the other direction and want new features to constantly show up, then a commercial distro like Red Hat or SuSE might be more to your liking. Each update of the software will rev the package higher, fixing bugs, and sometimes bringing unintended consequences with new features. You picks your distro, you picks your poison.
Hopefully this will provide some additional perspective about what lies ahead of you. I can tell you that when set up properly, it will not only run smoothly, but very quickly. Try running some file-based databases (Access, FoxPro, etc.) on a Samba share sometime, and notice how it just screams, especially if you can get two NICs going. Dual NICs can easily be accommodated without "bonding" or other silliness, the clients don't seem to care and the only thing you need to worry about is making sure your switch supports it (which a good quality switch from the last 5 years will anyways). Just put different addresses on each NIC, but when you specify an address to use in Samba, pick only one. Linux (and the switch) will do the rest.
Solution 3:
I guess you are going to want to serve files to a Windows machine, so the software you are looking for is called Samba.
Probably the biggest thing that differentiates a "home file server" from a "work file server" is whether or not you have shared IDs between machines.
On a home file server, you may connect with a username and password, and you can access the files.
On a work file server, you have a directory of shared IDs (such as LDAP/Active Directory), and each file is owned by the owner of the person who connects, meaning you can say "only the financial group can access this directory".
Samba supports integration with AD, and the same guide has a section on setting up an AD-integrated file server.
Alternatively, if you want a turn-key solution for acting as a file server (where you run an appliance, without the extensibility of a standard distribution like Ubuntu), I would recommend looking at OpenFiler, a "NAS/SAN in a box" with a web GUI for setting all this up. You give it your Windows domain passwords and join it as simply as you would a Windows box. However, you're not learning Linux, you're learning OpenFiler, which is an abstraction layer (albeit a very nice one).
Solution 4:
Download Ubuntu Server edition.
Installation guide:
Ubuntu Server Guide - Chapter 2. Installation
Ubuntu Server Guide - Wiki
That's all you need, these tutorials are very easy to follow.
Look at sections: Samba File Server, HTTPD - Apache2 Web Server