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.