Customizing your login on Purdue CS computers (WIP, but updated)
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.
GDM, the Gnome Display Manager
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:
/usr/share/gdm/defaults.conf
(lower precidence)/etc/X11/gdm/custom.conf
(higher precidence)
User configuration:
~/.dmrc
(more recent versions use~/.desktop
, but Purdue boxes aren't running more recent versions)
Purdue's GDM configuration
Now, custom.conf
sets
BaseXsession=/usr/local/share/xsessions/Xsession
SessionDesktopDir=/usr/local/share/xsessions/
This is important, because there are multiple locations that look like these files; I take it that they were used at sometime in the 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).
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:
- Last 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 MATE (
ShowGnomeFailsafeSession=true
) - Failsafe Terminal (
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 is 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:
. /etc/profile.env
unset ROOTPATH
- Try to set up logging to one of
~/.xsession-errors
,$TMPDIR/xses-$USER
, or/tmp/xses-$USER
(it tries them in that order). xsetroot -default
- 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:
source ~/.xprofile
xrdb -merge ~/.Xresources
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 themate-session
command, then cleanup when it's done.*
(fvwm2
): Runseval exec "$@"
, which results in it executing thefvwm2
command.
Network Shares
Your data is on various hosts. I believe most undergrads have their data on data.cs.purdue.edu
(or just data
). Others have theirs on antor
or 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 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) 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 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
.