Notes for the Snap Drives that arrived 1-4-2006. ------------------------------------------------------------------------------------- Registered at www.adaptec.com with my e-mail address & generic password, rick.jasper@thomson.com r-3 ------------------------------------------------------------------------------------- Registered the threee pieces, Product Name Serial Number TSID Number Server Number ======================= ============== ============ ============= Snap Server 4500, 1.0TB QTFCSA54800111 807352100549 428678 Snap Disk 10, 1.0TB QTFCSA54200043 807347960548 Snap Disk 10, 1.0TB QTFCSA54200050 807348000548 ------------------------------------------------------------------------------------- It seems we're missing the "Serial ATA" card on the Snap Server 4500. This is what's used to connect up the two "expansion arrays". ------------------------------------------------------------------------------------- To contact Snap's Technical Support, (321) 207-2000 but the first time I tried this, I was on hold for 15 minutes before giving up. Adaptec Sales Rep at (408) 957-7274 option 3, ------------------------------------------------------------------------------------- Maybe I'll have better luck from where these Snap pieces were purchased, Expert Servergroup. Cute. www.expertservergroup.com resolves to 127.0.0.1 Their web site is www.expertserver.com. Their info is Expert Server Group 318 South River Road Bedford, NH 03110 Toll Free Number: 1-800-726-9797 Our order is Expert Servergroup's reference number 559112. Found out that Christian (female) Clark (x5250) is our Sales Rep. I contacted her on 1-4-2006 and asked her about the apparently optional Serial ATA card for the 4500. It's coming - I've got it now. ------------------------------------------------------------------------------------- I have OS Version 4.0.228, which on 3-6-2006, was not the latest. I had to send e-mail off to Adaptec to get the latest, v4.1.043 (case # is 000000001681519). Three days later, they told me I could get this from http://acsn.adaptec.com/product/pasword.htm File Name: GUARDIANOS_4.1.043_FULL_OSIMAGE.GSU Password: CHARGER but acsn.adaptec.com did not resolve to an IP address. (Sigh) I updated this ticket with that info. ------------------------------------------------------------------------------------- When I first connected it all together & powered it on, it was suppose to get an IP address via DHCP & register itself in the DNS server as SNAP428678. It got 10.222.211.144, but didn't register itself, so I had to jump through hoops to find it. Get into the admin pages with userid/password of admin/admin. Finally did and hard-coded the IP address to 10.222.211.30, aka sunas1.delphion.com. ------------------------------------------------------------------------------------- One of the first things those pages ask you to do, is enter a "Registration Key" and it points you off to their web pages to obtain one. Had to use my rick.jasper@thomson.com userid (r-3), but I still didn't see it on those pages. Called Adaptec Tech Support (1-321-207-2000) and Shawn pointed me to the "Product Registration: 0A068A86-ovSU-f+ZP-Lua+-uPqI". That's what it wanted. ------------------------------------------------------------------------------------- To create a volume, Storage->Volumes->Create Volume, Volume Name: VOL0 <-- Changed to home RAID Set: md0 Capacity: 408832 MB (Maximum volume size = 408832 MB) <-- Which is what is unallocated on md0 And here is where it appears is the only place where you can specify the Snapshot Pool Size: 20% of Capacity <-- Lowered this to 5% Despite the comment of "Reserve a certain amount of volume capacity (typically around 20%) for storing snapshots.", which implies this is a volume attribute, I think this may be a RAID Set attribute, because on the xxxxxxx screen, it shows "Snapshot Reserve" = xxxxxxxx and you can change it there. When creating the home volume, I changed this to 5%, which is 20,441.6 MB, but after creating it, it said the Snapshot Pool Size was 20,352 MB After creating home, I also enabled Quotas since I'm going to try to control usage based on userids. Storage->Quotas Click the "No" underneath "Enabled" for the home volume, click the "Enable Quotas on Volume home (requires a restart)." Changed from the default of "Allow user to consume the entire disk (no limit)" to "Limit user to 2048 MB". And yes, I did have to restart, which rebooted the Linux OS, kicking me off the admin web page, the SSH screen, and generating two notification e-mails (Shutdown & Rebooting) to me at rick.jasper@thomson.com. ------------------------------------------------------------------------------------- When NFS-exporting a volume, follow Security -> Shares, select a volume from the list on the left, and then either - Select "Properties". The important thing here is the "Name" field. I gave the "T3DB" volume, the name "Tier3DB" name. This case-sensitive(!!) name is what you use in the Unix mount command - or Select "NFS Access". In that "NFS access for :" box, enter something like *(ro,insecure,async,root_squash,all_squash) kristine (rw,insecure,async,no_root_squash,no_all_squash) to give all (the "*") hosts read-only access and don't allow root any special privileges (root_squash) and ignore userid permissions (all_squash). But for the kristine machine (there's no space between "kristine" and the left parenthesis - the window just wraps things that way), do allow root privileged access and do allow userids their specific permissions based on userid & groupid. - - - - - - - - - - - - - - - - - - - - - - - - - - - - When creating a volume, this is presented somewhat differently. You're offered the opportunity "to create a share for this volume", which gets you To create a new share, specify a name, volume, and path to a folder. Name: (Defaulting to something like SHARE3) Volume: dfs Path: (Defaulting to / but offers you a "Browse" button, which says "Browse to the folder you want to use for the root of share SHARE3 and press OK. The current browse path is: dfs/" There are no existing folders, but you can create one.) Description: Security model for path: Windows (default) or Unix A toggle where you can choose one of these two next lines. ? Create share with full read and write access for all users ? Create share with Admin-only access and proceed to Share Access page For dfs, I guessed to make all that Name: dfs Volume: dfs Path: Left / (I don't know what this is) Description: Shared R/W Storage for All Security model for path: Unix * Create share with full read and write access for all users But it seemed that changing the security model from Windows to Unix overrode any other changes, 'cause afterwords I still had Name: SHARE3 and a blank Description: I had to go back in and change these. Later though, I recreated home and made sure I had Name: home Volume: home Path: / (the default) Description: Everybody's Home Directories Security model for path: Unix * Create share with full read and write access for all users and everything worked as it should, so I guess I was wrong before when I did dfs. ------------------------------------------------------------------------------------- There are 3 units to our Snap drive setup. Each unit has four, 230-GB disk drives in it. Head Unit (4500): Disks 1-4 are in RAID Set md0 Expansion Unit 1 (SD10): Disks 1-4 are in RAID Set md1 along with Expansion Unit 2 (SD10): Disks 1-3 Disk 4 is the one and only Global Hot Spare. RAID Set md0 provides us with 692 GB RAID Set md1 provides us with 1350 GB md0 has two volumes, home & dfs, with 96 MB Free md1 has one volume, T3DB, with 583.75 GB Free - - - - - - - - - - - - - - - - - - - - - - - - - - - - The Volume details (In Storage->Volumes) are Name RAID Set Size Mount Point Quotas ==== ======== ========= ============ ======== T3DB md1 776.00 GB /hd/vol_mnt1 Disabled dfs md0 268.75 GB /hd/vol_mnt3 Disabled home md0 379.38 GB /hd/vol_mnt0 Enabled or confusingly, if you go into each volume from that screen, the info is Name Size Available User Space ==== ========== ==================== T3DB 794,624 MB 730,740 MB dfs 275,200 MB 275,070 MB home 388,480 MB 388,350 MB apparently 1 GB = 1024 MB for Size calculations. - - - - - - - - - - - - - - - - - - - - - - - - - - - - The Share details are (In Security->Shares, select a volume, then ->Properties) Name (used for Volume NFS Mounting) Name Path Description ============== ====== ==== ============================== dfs dfs / Shared R/W Storage for All home home / Everybody's Home Directories Tier3DB T3DB / Load Files for Tier 3 Database I don't understand what that "Path" is all about. There doesn't seem to be any way to change it once the volume (share?) is defined and I don't see what its purpose is nor where it's used. If you expand the "Advanced" tab under this screen, you'll see A "Hide this share (the share will be hidden from network browsing)" toggle. I never turn this on. I always turn off the "Apple (AFP)", "Web (HTTP, HTTPS)", and "FTP" protocols. The web & FTP protocols are interesting, but I don't know what they present nor how they're authenticated. I just never played around with it. I leave on "Windows (SMB)" and "Unix (NFS)". The "Snapshot Share Name" is volumeName_SNAP (eg, home_SNAP or dfs_SNAP) except for T3DB, where I don't have a snapshot share defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - More Share details are (In Security->Shares, select one, then ->Access) This is where Windows access is set up. Volume Users/groups with access to ======= ================================================= dfs (1) admingrp home (1) admingrp Tier3DB (1) admingrp where the only ones in the admingrp group are admin & jasper. - - - - - - - - - - - - - - - - - - - - - - - - - - - - More Share details are (In Security->Shares, select one, then ->NFS Access) This is where Unix NFS access is configured. It's like editing a Linux system's /etc/export file, so refer to the Linux man page for details on what you can do (man exports). Volume NFS access for ======= =============================================================== dfs 10.222.211.0/24(rw,insecure,async,no_root_squash,no_all_squash) home 10.222.211.0/24(rw,insecure,async,no_root_squash,no_all_squash) Tier3DB 10.222.211.0/24(ro,insecure,async,no_root_squash,no_all_squash) kristine(rw,insecure,async,no_root_squash,no_all_squash) root_squash = Converts root client NFS requests, to userid nfsnobody. (Maybe a good idea, but not for us today) all_squash = Converts every client NFS requests, to userid nfsnobody. (Obviously not what we want) ==================================================================================== Just for the experience, I enabled quotas on the home volume. To set quotas on a per userid basis, each userid must be defined in the Snap server. This is a bit inconvenient 'cause now I've got userids defined in multiple places. **** Unless I define it in an NIS domain, maybe. I've got to get that **** **** to find out. Hmmmm. **** - - - - - - - - - - - - - - - - - - - - - - - - - - - - The Snap Appliance offers many different ways to access volumes - Windows Shares (SMB) - Apple (AFP) - Unix (NFS) - FTP - Web (HTTP, HTTPS) but we're only interested in NFS and maybe Windows Shares. NFS access from Unix systems work mostly as one expects, but there's a bug because directories can be removed from userids that don't have the right permissions (see below). This is true from either a Unix NFS client or a Windows share. Windows Share access is by userids & passwords defined on the local Snap server. There seems to be a way for the Snap appliance to join a Windows domain, but since we're not on a Windows domain (and we don't have an AD server), I didn't try this. When accessing things from a Windows share, group 100 is used because on the Snap server, all local users are defined with a primary group of AllLocalUsers (GID 100). So when looking at files created from a Windows machine, you'll see things owned by usr on AIX and users on Linux 'cause that's what GID 100 is in /etc/group. >>> There seems to be no way to change a local user's primary group (too bad). <<< >>> I originally thought this 'cause I didn't have root access to the <<< >>> Snap Appliance, but I do now, so I wonder if I CAN change the <<< >>> group for local userids. What would I want? staff=1? <<< >>> delphion=5001 <<< Similarly, when looking at files created from a Windows machine using the Snap Appliance local id admin (UID 1), files come out as being owned by daemon on AIX and bin on Linux 'cause that's what UID 1 is in /etc/passwd. - - - - - - - - - - - - - - - - - - - - - - - - - - - - On 3-30-2006, I added yurgis (pw=new4you) to sunas1's local users so he could use Windows Explorer and "connect" to the Tier3DB "share". Security -> Local Users -> New ... Security -> Shares -> Select Tier3DB -> Access ... - - - - - - - - - - - - - - - - - - - - - - - - - - - - I thought this would work, but it doesn't. Having group write turned on, ala -rw-rw-r-- 1 rebecca delphion 61 Mar 8 15:58 /dfs/rebecca/foobar.txt and trying to change it from a Windows system using an ID that is defined to be in the delphion group (GID 5001) on the Snap server, doesn't allow one to change it. Another bug? - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bug: With no special permissions and no_*_squash, why can rebecca on a Unix system, rm directories made by jasper, but not files? One can also delete directories (sorry, folders) from a Windows system that they shouldn't be able to. As jasper> mkdir /dfs/prod As jasper> ls -l /dfs drwxr-xr-x 2 jasper jasper 16 Mar 8 13:09 prod as expected, but As rebecca> rmdir /dfs/prod works just fine. This should not work. As jasper> mkdir /dfs/prod jasper> touch /dfs/prod/foo jasper> ls -lR /dfs /dfs: total 0 drwxr-xr-x 2 jasper jasper 16 Mar 8 13:09 prod /dfs/prod: total 0 -rw-r--r-- 1 jasper jasper 0 Mar 8 13:09 foo As rebecca> rm /dfs/prod/foo rm: remove write-protected regular empty file `/dfs/prod/foo'? y rm: cannot remove `/dfs/prod/foo': Permission denied =========================================================================================== I had troubles with the SUNAS1 web server on 3-6-2006 after I deleted the home volume. It apparently killed the httpd daemon (I could ssh -l admin sunas1 and didn't see any httpd processes with a ps -ef command) and this line was in /flash/syslog.txt <4> Mar 6 14:58:15 SNAP1NAS java: '/bin/umount -f /shares/home_SNAP' failed. I opened up a problem ticket with Adaptec Support (ticket #1681551), but after 24 hours and no call back, I gave up and power-cycled the Snap controller. Three days later, Adaptec told me I coulda recycled the servers with these commands. ssh to sunas1 (They didn't specify which id to use, but see below) chmod 755 /usr/bin/reset_sysbroker.sh chmod 755 /usr/bin/do_sysbroker_reset.sh /usr/bin/do_sysbroker_reset.sh This didn't work as admin because these files are owned by root. Presumably they want me to login as root, but I don't know root's password to the Linux system under the covers of the Snap 4500. I updated this ticket. Now I guess I gotta wait another 3 days 'till they get back to me. root's password is 0001n - - - - - - - - - - - - - - - - - - - - - - - - - - - I updated the firmware with 4.1.043 on 3-13-2006.