Celerra

The Celerra is multiprotocol NAS head that can be attached to an EMC Clariion to provide SAN access via CIFS, NFS, or FTPS. The OIT-ISO-PROV group is building a storage service (and price point) around using this instead of accessing the SAN via Fibre Channel.

One of the primary features of the Celerra is the ability to create CIFS servers and join them to AD domains.

Quirks:

• Access Based Enumeration (ABE) has to be enabled on the back end.
• Shadow Copy has to be enabled on the back end.
• File Filtering (by extension) has to be enabled on the back end.
• Quotas must be managed using a command-line tool from EMC.
• While the shares on the Celerra "server" can be used for DFS Roots or leaf nodes, NTFRS/DFR-R are not supported.
• The first share on the "server" must be created on the back end (and it comes with some *nix-y folders that automatically get created within it). You can create additional shares inside the first one, but you do not have access directly under C$ to create any. You also will need to type in the share paths since it won't let you browse inside the original share.
• When using the MMC Share snap-in to set NTFS permissions (not share permissions), you will be disabling inheritence of NTFS permissions. It is recommended to change the permissions by mapping higher-level share and setting them there.

GPO Support: The Celerra "server" will update its Group Policy every 90 minutes (need to double check) to update certain settings:

• Security Settings
• Audit Policy
• Restricted Groups??

The information that OIT needs if you wish to use the service:

 Amount of storage (current pricing is <$1300/year)
 FQDN of the "server"
 Shadow Copy Enabled?
 ABE Enabled?
 AD Group that will be assigned permissions
 Name of the 1st share you want on it

Support models:

• Support it yourself (OIT Creates is, gives permissions, you move it to your OU, and you deal with it)
• Helpdesk Supported (more info once the HD is trained)

Getting Started

Your Server

It's recommended that when requesting a new Celerra file server, that you following the naming convention of starting the name with "celerra-". Doing so will avoid confusion when attempting to manage these "servers". You're welcome to use any description after this -- for example, my two servers are "celerra-ece.ece.ncsu.edu" and "celerra-freedm.ece.ncsu.edu".

This brings up the question of when do you need multiple servers versus multiple shares? Why didn't I just put the files for our FREEDM research group under the main ECE celerra server? Delegation of responsibility. The FREEDM center will have its own IT staff who will be responsible for running their file storage. Before we had celerra services, they would have purchases a separate physical server that they would have managed themselves. This acknowledges and continues that practice.

Your Primary Shares

When you server is created, you'll find that it will come with at least one primary share. In the case of "celerra-ece", this was the share "ECE" on C:\ECE. This is the only *primary* share on the server currently. OK, so what's a "primary share"? First off, this is a term I'm making up on the spot -- but something is needed to describe this. When you purchased space from OIT, they created this storage location for you. Within the virtual server, this primary share is where your purchased space has been placed. As I mentioned, for us, it was C:\ECE.

I *HIGHLY* recommend that you don't place any files here. Keep it empty. And the first thing you need to do is change the permissions on this space to only allow your server admins access.

"Remotely setting permissions on the folder at the root of a share removes all inherited permissions from the root folder and all subfolders. To set permissions without removing the inherited permissions, click No and either change the permissions on a child folder or make the change while logged in locally. Do you want to continue?"

Treat this share as a special one. And recognize that it's tied to a specific purchase/fee. When you later decide you need more space, or more likely, when one of your research groups decides to pony up for more space, you should create another primary share. If my "ARM" research group decides they want to purchase space, I'll ask OIT to create a new primary share called "C:\ARM" on my celerra-ece.ece.ncsu.edu server. (why not create a new server for them? We directly support them -- they have no IT staff). Once again, no files will be placed in the root of that share.

Your File Shares

When you're ready to start using your space, you'll need to create file shares. My first was for storage of our security camera footage (we have a system that captures still images from our teaching labs).

I used the Computer Management MMC for celerra-ece.ece.ncsu.edu to create a "New Share". The location was C:\ECE\cameras. The share name was "cameras$". Share permissions was Everyone with Full Rights. The NTFS permissions limited access to our camera server admins group and a service account we have to move these files around.

Note the location of the share -- this file share is within the "ECE" primary share. As such, it will eat up some of my quota there and inherits the permissions of that primary share (this is why it's important to edit the permissions on that primary share straight away -- you can edit your shares to not inherit permissions, but this can get you into trouble later on so I'd advise against it).

The share name is also important. Note the fact that it ends with a dollar sign. Why? Doing so will hide the share. Someone navigating to \\celerra-ece.ece.ncsu.edu\ will not see this share listed. If you've set the permissions correctly, this shouldn't matter, but it never hurts to add a layer of protection.

Even if you SHOULD be able to get into this share, I don't want anyone finding this location accidentally and mapping it -- everyone coming to my shares should do so via the DFS path I've published for my users.

The share permissions should be set to Everyone Full simply to avoid confusion and permission hell. Setting it in this manner eliminates its use. The permssions on your files should be completely determined by their NTFS permissions.

Quick Steps

1. In your Unit OU, make sure you have a subOU called "Servers". In here, create "Celerra" -- here's where you'll place all of the Celerra server objects OIT will create for you.
2. Create a group in this OU -- "<OU>-Celerra Server Admins"
3. Place in this group any admins you expect to control these file servers. When asked by OIT, this is the group you'll tell them to give control over your Celerra server. NOTE: Make sure OIT adds this group to the local Administrators group on the Celerra server.
4. Most Units will only need one server as multiple "volumes" can be purchased and hung onto this single server. Why would you need a 2nd server? Control. He who controls the server, controls the shares on it. Remember that its not possible to delegate the ability to make a share -- you must be an administrator on a computer to do this. So if you think that someone outside of your group will need access that high, you need to create a 2nd Celerra server object and give a different group control over it.
5. On your server, you'll have a folder and share created automatically (everyone is different -- but looking at your server, you'll know what I'm talking about). In the case of ECE, this is the C:/ECE folder on our server "celerra-ece.ece.ncsu.edu". It's shared as "ECE" by the OIT service group. It's permissions are set to allow your admin group and a standard admin group for the celerra admins (OIT) access. None others. Leave it be. Don't edit it. This is your emergency backdoor just in case you muck something up. NOTE: Remember to confirm this - the Security on this folder should show "Administrators (SERVERNAME\Administrators)". Sometimes OIT will instead add your <OU>-Celerra Server Admins group here by mistake.
6. C:\ECE is the location of the mounted storage space. This is the "volume" which you've purchased -- likely a 1TB one. For all intents and purposes, you need to think of C:\ECE as the D:\ drive of a standard Windows file server. It's not a folder -- its the root of the drive. When you purchase your next slice of space, it will be created along side. For example, if one of your research groups pays for a 1TB of space -- you'll request that it be mounted as C:\ECE2 or perhaps C:\SPEC if one of your research groups named SPEC pays for it. Whatever helps you differentiate.
7. Your first step is to create the root share. When creating this SMB share, its important that you set the share perms to allow EVERYONE *FULL* access to the share. We'll protect the files within in another way.You'll be placing all of your files in C:\ECE\data. If you're only dealing with shared data (files which are shared by groups of users), within the C:\ECE folder will be nothing else. If you're looking to create user profiles or redirected folders for individual users, you may also create a second C:\ECE\profiles\ directory which we'll discuss later.
   1. You may have a "tools" directory created by OIT -- this contains some scripts for managing your celerra instance -- specifically regarding features like ABE. Which we'll discuss later.
8. Something you do need to consider is caching -- do you want your endusers to be able to access these files while off the network? If so, enable; if not, disable.
9. Create your data$ share -- and yes, use the "$"; this will hide the share from people casually looking at your server. Set the appropriate caching setting. Set the share perms as mentioned previously. Add a description for yourself.

What we're trying to do is create a system of shares that can preserve data permissions and make the file locations seem obvious to your endusers... but we've created a scenario that works great for your WINDOWS computers. These can use DFS and function as you've planned out. What about Linux and Mac users? Unfortunately, neither of these operating systems can currently understand DFS shares correctly (though Linux appears to have this partially working (empty root folders throw RHEL5 boxes into a tailspin) and you can cheat on an Apple *if* you purchase 3rd party apps like ADmitMac).

So what do you tell endusers on these operating systems? Well, to begin with, you'll need to provide the SMB path to the data they need. In our case, this would be \\celerra-ece.ece.ncsu.edu\sharename$\ -- both OSes will correctly resolve this and voila you have your data.

BUT if you have their data in multiple shares? Then you have the messy situation of having to have them mount multiple SMB shares. If we're only talking about a few, that's not too bad. But if its a dozen, I'm not sure how well that'll go over.

Luckily for us, all of our administrative staff use Windows boxes. So we can map a drive to the top of our DFS path and we're done. These are the users most likely to be accessing data in multiple shares (think a share for "finance", "HR", etc). I don't envy a department in which Mac is the primary desktop for these users. I'm not aware of anyone with Linux being used for these users.

I find that most faculty and graduate students (think researchers) will have one, maybe two, shares they'll need to access for their research. These are the most likely people you'll find on Macs or Linux boxes that will need to mount individual shares. You'll need to either tell them the location of these shares, or provide them a way to find them -- perhaps even a website with this information listed plus instructions for mounting these locations. If you know what you're doing, and have standardized your Linux roll out to use the campus RHEL system, you may be able to auto-mount some of these automagically. Same goes for Macs IF you've joined them to the AD or an OpenDirectory domain -- I honestly don't know enough about Macs to do more than throw out the idea; the reality of this option is outside of my grasp.

Why use distinct shares for all shared folders?

In AFS, you move a file from one protected volume to another and the correct people have access -- it uses the perms in the new location. Let's try testing that on Celerra folders.

1. Create two folders -- C:\ECE\test1 and C:\ECE\test2.
2. Give one of your users modify perms in test1 and a different user modify perms in test2.
3. Create a txt file in test1. Look at the perms. Do you see the user you expected to see w/ modify perms?
4. Now move the file from test1 to test2.
5. Review the perms on the file now. You'll note that the perm's haven't changed. The user who should have modify perms on objects in test2 doesn't -- the first still does.

What's going on? It turns out that moving a file doesn't initiate ACL propagation. You could copy, then delete the original file, but what enduser is going to think to do this? This is where the distinct shares for every shared folder comes in -- each is its own namespace and moving files between namespaces forces ACL propagation -- therefore, files moved in and out of our folders will automatically receive the permissions we expect them to.

Please note that this issue was resolved in Windows 2008 file servers -- moving a file within a namespace on a Windows 2008 file server should initiate an ACL update on the file. But Celerra appears to be built on 2003 (if not 2000) fileserver technology -- so, at least for now, this way of managing your files/shares is important to remember.

Access from OSes

Linux

Setup

(update 8/17/2010 -- Micah found he no longer has to do this setup section to make the Client section work) To get samba to talk to AD/DFS I've had to do the following... Edit /etc/samba/smb.conf:

   change workgroup to WOLFTECH
   change security to ads
   change realm to WOLFTECH.AD.NCSU.EDU

It can help if you ensure that in the /etc/resolv.conf you have ad.ncsu.edu and wolftech.ad.ncsu.edu in the search field, but not required if you enter FQDN hostnames.

Client Side

For smbclient access (limited usage):

   smbclient -U username //fileserver/share

Mounting the partition manually (with the mount point being /mnt/dracula in this example) is:

sudo mount -t cifs //celerra-freedm.ece.ncsu.edu/freedm_dracula$ /mnt/dracula -o username=USERNAME,domain=Wolftech,sec=ntlmv2i

It is also possible to do the following to make it mountable by a user:

mkdir /mnt/dracula
chmod u s /sbin/mount.cifs
chmod u s /sbin/umount.cifs

Add the following line to /etc/fstab:

//celerra-freedm.ece.ncsu.edu/freedm_dracula$   /mnt/dracula  cifs  users,noauto,sec=ntlmv2i,domain=WOLFTECH   0   0

• IMPORTANT*

The directory /mnt/dracula needs to be owned by the user that is going to mount the share (say, aqhuang). If they do not own the directory, the following mount command will not work.

chown aqhuang.ncsu /mnt/dracula

Then the user can enter the command as follows and then type in their password, and the share will be mounted:

mount /mnt/dracula

To unmount:

umount /mnt/dracula

Mac

• Accessing Celerra Shares from OSX