update purdue-cs-login

1 files changed, 138 insertions, 17 deletions

diff --git a/public/purdue-cs-login.md b/public/purdue-cs-login.md
index 7bc1b10..a8c0189 100644
--- a/public/purdue-cs-login.md
+++ b/public/purdue-cs-login.md
@@ -1,22 +1,23 @@
-Customizing your login on Purdue CS computers (WIP)
+Customizing your login on Purdue CS computers (WIP, but updated)
 =============================================
 ---
-date: "2014-04-21"
+date: "2015-02-06"
 ---
 
-> This article is currently a Work-In-Progress, but it may be enough
-> to get someone started, so I'm publishing it as is.
+> This article is currently a Work-In-Progress.  Other than the one
+> place where I say "I'm not sure", the GDM section is complete.  The
+> network shares section is a mess, but has some good information.
 
 Most CS students at Purdue spend a lot of time on the lab boxes, but
 don't know a lot about them.  This document tries to fix that.
 
 The lab boxes all run Gentoo.
 
-## About GDM
+## GDM, the Gnome Display Manager
 
-They run `gdm` (Gnome Display Manager) 2.20.11 for the login screen.
-This is an old version, and has a couple behaviors that are slightly
-different than new versions, but here are the important bits:
+The boxes run `gdm` (Gnome Display Manager) 2.20.11 for the login
+screen.  This is an old version, and has a couple behaviors that are
+slightly different than new versions, but here are the important bits:
 
 System configuration:
 
@@ -28,7 +29,7 @@ User configuration:
  - `~/.dmrc` (more recent versions use `~/.desktop`, but Purdue boxes
    aren't running more recent versions)
 
-## Purdue's GDM
+### Purdue's GDM configuration
 
 Now, `custom.conf` sets
 
@@ -41,12 +42,132 @@ past.  Don't get tricked into thinking that it looks at
 `/etc/X11/gdm/Xsession` (which exists, and is where it would look by
 default).
 
-Values for `~/.dmrc:Session`:
+If you look at the GDM login screen, it has a "Sessions" button that
+opens a prompt where you can select any of several sessions:
 
- - `custom`: Executes `~/.xsession`
- - `default`: Executes ~/.Xrc.cs
- - `fvwm2`: ???
- - `gnome`: ...
- - `kde`: Displays a message saing KDE is no longer available
- - `failsafe`: Runs a single xterm window (NOPE)
- 
+ - _L_ast session
+ - _1_. MATE (`mate.desktop`; `Exec=mate-session`)
+ - _2_. CS Default Session (`default.desktop`; `Exec=default`)
+ - _3_. Custom Session (`custom.desktop`; `Exec=custom`)
+ - _4_. FVWM2 (`fvwm2.desktop`; `Exec=fvwm2`)
+ - _5_. gnome.desktop (`gnome.desktop`; `Exec=gnome-session`)
+ - _6_. KDE (`kde.desktop`, `Exec=startkde`)
+ - Failsafe _M_ATE (`ShowGnomeFailsafeSession=true`)
+ - Failsafe _T_erminal (`ShowXtermFailsafeSession=true`)
+
+The main 6 are configured by the `.desktop` files in
+`SessionDesktopDir=/usr/local/share/xsessions`).  The last 2 are
+auto-generated.  The reason `ShowGnomeFailsafeSession` correctly
+generates a Mate session instead of a Gnome session is because of the
+patch
+`/p/portage/*/overlay/gnome-base/gdm/files/gdm-2.20.11-mate.patch`.
+
+I'm not sure why Gnome shows up as `gnome.desktop` instead of `GNOME`
+as specified by `gnome.desktop:Name`.  I imagine it might be something
+related to the aforementioned patch, but I can't find anything in the
+patch that looks like it would screw that up; at least not without a
+better understanding of GDM's code.
+
+Which of the main 6 are used by default ("Last Session") is configured
+with `~/.dmrc:Session`, which contains the basename of the associated
+`.desktop` file (that is, without any directory part or file extension).
+
+Every one of the `.desktop` files sets `Type=XSession`, which means
+that instead of running the argument in `Exec=` directly, it passes it
+as arguments to the `Xsession` program (in the location configured by
+`BaseXsession`).
+
+#### Xsession
+
+So, now we get to read `/usr/local/share/xsessions/Xsession`.
+
+Before it does anything else, it:
+
+ 1. `. /etc/profile.env`
+ 2. `unset ROOTPATH`
+ 3. Try to set up logging to one of `~/.xsession-errors`,
+    `$TMPDIR/xses-$USER`, or `/tmp/xses-$USER` (it tries them in that
+    order).
+ 4. `xsetroot -default`
+ 5. Fiddles with the maximum number of processes.
+
+After that, it handles these 3 "special" arguments that were given to
+it by various `.desktop` `Exec=` lines:
+
+ - `failsafe`: Runs a single xterm window.  NB: This is NOT run by
+   either of the failsafe options.  It is likey a vestiage from a
+   prior configuration.
+ - `startkde`: Displays a message saying KDE is no longer available.
+ - `gnome-session`: Displays a message saying GNOME has been replaced by MATE.
+
+Assuming that none of those were triggered, it then does:
+
+ 1. `source ~/.xprofile`
+ 2. `xrdb -merge ~/.Xresources`
+ 3. `xmodmap ~/.xmodmaprc`
+
+Finally, it has a switch statement over the arguments given to it by
+the various `.desktop` `Exec=` lines:
+
+ - `custom`: Executes `~/.xsession`.
+ - `default`: Executes `~/.Xrc.cs`.
+ - `mate-session`: It has this whole script to start DBus, run
+   the `mate-session` command, then cleanup when it's done.
+ - `*` (`fvwm2`): Runs `eval exec "$@"`, which results in it executing
+   the `fvwm2` command.
+
+## Network Shares
+
+Your data is on various hosts.  I believe most undergrads have their
+data on `data.cs.purdue.edu` (or just
+[`data`](https://en.wikipedia.org/wiki/Data_%28Star_Trek%29)).  Others
+have theirs on [`antor`](http://swfanon.wikia.com/wiki/Antor) or
+[`tux`](https://en.wikipedia.org/wiki/Tux) (that I know of).
+
+Most of the boxes with tons of storage have many network cards; each
+with a different IP; a single host's IPs are mostly the same, but with
+varying 3rd octets.  For example, `data` is 128.10.X.13.  If you need
+a particular value of X, but don't want to remember the other octets;
+they are individually addressed with `BASENAME-NUMBER.cs.purdue.edu`.
+For example, `data-25.cs.purdu.edu` is 128.10.25.13.
+
+They use [AutoFS](https://www.kernel.org/pub/linux/daemons/autofs/)
+quite extensively.  The maps are generated dynamically by
+`/etc/autofs/*.map`, which are all symlinks to
+`/usr/libexec/amd2autofs`.  As far as I can tell, `amd2autofs` is
+custom to Purdue.  Its source lives in
+`/p/portage/*/overlay/net-fs/autofs/files/amd2autofs.c`.  The name
+appears to be a misnomer; seems to claim to dynamically translate from
+the configuration of
+[Auto Mounter Daemon (AMD)](http://www.am-utils.org/) to AutoFS, but
+it actually talks to NIS.  It does so using the `yp` interface, which
+is in Glibc for compatibility, but is undocumented.  For documentation
+for that interface, look at the one of the BSDs, or Mac OS X.  From
+the comments in the file, it appears that it once did look at the AMD
+configuration, but has since been changed.
+
+There are 3 mountpoints using AutoFS: `/homes`, `/p`, and
+`/u`. `/homes` creates symlinks on-demand from `/homes/USERNAME` to
+`/u/BUCKET/USERNAME`.  `/u` mounts NFS shares to `/u/SERVERNAME`
+on-demand, and creates symlinks from `/u/BUCKET` to
+`/u/SERVERNAME/BUCKET` on-demand.  `/p` mounts on-demand various NFS
+shares that are organized by topic; the Xinu/MIPS tools are in
+`/p/xinu`, the Portage tree is in `/p/portage`.
+
+I'm not sure how `scratch` works; it seems to be heterogenous between
+different servers and families of lab boxes.  Sometimes it's in `/u`,
+sometimes it isn't.
+
+This 3rd-party documentation was very helpful to me:
+<http://www.linux-consulting.com/Amd_AutoFS/> It's where Gentoo points
+for the AutoFS homepage, as it doesn't have a real homepage.  Arch
+just points to FreshMeat.  Debian points to kernel.org.
+
+### Lore
+
+[`lore`](https://en.wikipedia.org/wiki/List_of_Star_Trek:_The_Next_Generation_characters#Lore)
+
+Lore is a SunOS 5.10 box running on Sun-Fire V445 (sun4u) hardware.
+SunOS is NOT GNU/Linux, and sun4u is NOT x86.
+
+Instead of `/etc/fstab` it is `/etc/mnttab`.