When an AFP connection moves to idle, a token is used to establish a reconnect. By default, AFP stores tokens in the local /etc/AFP.conf. But in order to have users reconnect if they move between servers, as in a failoverd event or even in a more active/active relationship with a load balancer you need to move the shared cache to a shared location. To do so you’ll edit the /Library/Preferences/com.apple.AppleFileServer.plist file using the defaults command. The key that you’ll need to change is the reconnectKeyLocation, specifying the string in the key that corresponds to the path to the local server that is running afp to the volume. Therefore, if the…
-
-
Xsan: Unresponsive Xsan Admin
There are times with Xsan when the admin utility sits unresponsive (the pinwheel at the bottom of the screen spins annoyingly to no end). When the Admin tool gets unresponsive you are typically staring down the barrel of some kind of naming issue. In these cases I almost universally have DNS administrators tell me that everything is fine without first bothering to actually look at the records for the hosts on the SAN. The easy way to verify this hypothesis is to build a custom hosts file (/etc/hosts). This bypasses the DNS resolver and if everything loads up correctly then you do indeed have a DNS/host naming issue.
-
Practical ILM
I originally posted this at http://www.318.com/TechJournal The amount of data used by Small Businesses is on target to rise 30% to 35% in 2006. Sarbanes-Oxley, HIPPA and SEC Rule 17a-4 have introduced new regulations on the length of time data must be kept and in what format. Not only must data be kept, it must be backed up and secured. These factors have the cost of data storage for the Small Business increasing exponentially. Corporations valued at more than 75 million dollars are generating 1.6 billion gigabytes of data per year. Small and medium sized companies can reap the benefits of developments being made with larger corporations. Different methods and…
-
Xsan: umask and Default Permissions
I originally posted this at http://www.318.com/TechJournal By default the global permissions for new files written into an Xsan volume are 644 (rw-r–r–). This can result in a permissions problem where one user can read another user’s posted items, but not make changes to it. This can be resolved by changing the default umask value for groups. It’s a simple command line: sudo defaults write -g NSUmask 23 In this case, the 23 is a decimal equivalent of “rw-â€. So the result of running this command line is that files posted to the shared volume will have 664 permissions (rw-rw-r–), allowing other users in the group to modify the files. Note…
-
Preventing Firewall Issues with Xsan
I originally posted this at http://www.318.com/TechJournal Introduction Xsan requires a dedicated ethernet network in the supported architecture by Apple. For systems that are obtaining directory information or need to be wired into the corporate network of many organizations this can cause issues. Namely that Xsan will attempt to use the corporate network for connectivity with clients. We see this in many configurations and it can cause dropped packets, unmountable volumes and other intermittent issues. One way to fix this for metadata controllers is to choose the network adapter that you would like to use on the metadata network in Server Admin. This can be done by: Open Xsan Admin Click…
-
Xsan Presentation from Black Hat
My Xsan presentation from Black Hat 2006, in Las Vegas, NV: bh-us-06-edge
-
Xsan: cvadmin
Xsan Admin is a little wonky sometimes. This isn’t to say there are bugs, just that sometimes given the environmental factors it can be slow to respond. But once your SAN is up and running you can pretty much do all the admin tasks you’ll ever need using cvadmin rather than Xsan Admin. cvadmin is an interactive command line environment and will always need to be run with escalated priveleges (er, sudo). So use the following command to see which Metadata Controllers are available and to see which is your primary per volume: sudo cvadmin man Now you can use sudo cvadmin and from within the interactive cvadmin command…
-
Xsan Admin slow to respond?
It’s probably a naming or DNS issue… As a temp test, create a hosts file with all the systems in it. If it works fine then try and isolate that DNS issue…
-
Xsan: Backing up the Configuration
cvgather is a tool that can be used to “gather” up all the relevant information (cfg files, etc) on your Xsan and back them up to a specified location. Any time you will be fussing around with the SAN, etc. then you should run this first. Additionally the copy of the config files can provide you with an escape clause with regard to certain issues that could cause the volume to get destroyed so I would have a copy of all your info on a location other than the SAN at all times anyway. This isn’t to say that cvgather will actually back the SAN itself up. It very specifically…
-
Xsan: Corruption
Volumes can become corrupt no matter what file system you are talking about (er, there might a magical file system out there that cannot become corrupted but I’ve never heard of it and would like to sell a certain bridge to you if you have). Xsan is no different and so you need to be ready to use the command line to combat said corruption. fsck is the traditional *nix tool to fix issues with volume corruption. cvfsck is the weird cousin that’s used for Xsan. If you see any iNode errors in your logs, corruption errors, high latency or just too many weird issues to shake a stick at…