User:Rewood/AFS Myths
==Myth #1: With regard to the AFS Cells, Unity=ITD, Eos=Engineering, BP=Bobby Pham==
RealDeal(tm) #1: Today, May/2002 - the cell names don't mean much with regard to the organizations that manage them.
Generally today: BP = software installs, Unix system management Unity=Almost all user volumes, ITD managed "space" Eos=Pams managed "space", CSC paid for/ITD managed "space", WolfWare, some long-time user volumes, Legacy ITECS managed "space", Engineering AFS Lockers
BP=Bobby Pham is NCSU urban legend. It's only a fun thing to talk about, complain about, whatever you want to do with it.
Myth #2: "ITECS manages the EOS [afs cell] AFS file servers."
RealDeal(tm) #2: No we don't. Not all of them anyway. ITD manages many of them for WolfWare and other volumes. PAMS manages AFS servers in /afs/eos. There's a CSC fileserver currently in /afs/eos managed by ITD. ITD manages all the authentication, volume locaation, and backup database servers (all lumped together under the term "DB servers")
ALL our file servers in /afs/eos are named engr##f.eos.ncsu.edu.
If a vos examine doesn't show a volume to be on one of those boxes, it's not our space.
Myth #3: All Unity AFS File servers are managed by ITD.
RealDeal(tm) #3: Nope - we have a user file server in Unity
Our /afs/unity file server is engr00uf.eos.ncsu.edu, subsequent /afs/unity file servers will be engr##uf.eos.ncsu.edu.
It's for Engineering admin/faculty/staff (not student) user volumes that need additional quota over and above 50MB.
==Myth #4: Squirrels are out to take over the Power infrastructure at NC State.==
RealDeal(tm) #4: This one is true. Except now they are hiring rats to do the suicide missions.
More information than you ever wanted to know:
Regarding Myth #1:
Things get a little confusing with ITECS/COE Labs called "Eos" labs and ITD Labs called "Unity" labs - and there still being some lingering, separation in both term and practice between groups - but erase from your mind that this extends to the AFS cells.
For future reference - we are calling all ID's "UnityID's" as opposed to "Unity/Eos ID's" because that's what they are - Campus Wide login identifiers.
And "Eos" is becoming the umbrella term for all computing in ITECS/COE. Not limited to Realm or Unix, or labs, or whatever.
Regarding Myth #2 and #3:
From this point forward:
All new Engineering User volumes are in the Unity cell with everyone else. If a Engineering user (not a student) needs > 50MB - they get moved to our file server (server(S) if necessary) and the quota bumped. We very likely will be gently moving *over time* User volumes under our purview from /afs/eos to /afs/unity
All Engineering AFS space allocations come under our structured "Locker model" (standard volume names, mounts, separate mounts for server and user access, system:anyuser ACLs eradicated..., more technical details forthcoming). This means we can find stuff - and know who owns things and ask them to "renew" their locker every year ala MajorDomo2. And we aren't charging for space - yet.
We are running most AFS locker management through scripts built on top of an in-house written AFS perl module (the "official" perl module is missing some of the command suite - and the wolfware api modules weren't available at the time we started - and what little we have works cross-platform for the most parts, win32, solaris, linux)
Quota updates, moves, mounts, new locker creation, permission setting, auditing, etc. are going to get wrapped in a script, stay as best as we can within spec, and logged. This is why we are little ornery about staying out of sections of AFS.
All Engineering AFS space will be mounted at /afs/eos/lockers/research, eos/lockers/admin, eos/lockers/workspace, eos/lockers/people, eos/engrwww, and eos/engrservers (and any new locker types we need to have end up in eos/lockers/somethingorother). EVERYTHING on our servers that's not a user volume will be migrated into those namespaces by the end of this year.