1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Customizing your login on Purdue CS computers (WIP, but updated) — Luke T. Shumaker</title>
<link rel="stylesheet" href="assets/style.css">
<link rel="alternate" type="application/atom+xml" href="./index.atom" name="web log entries"/>
</head>
<body>
<header><a href="/">Luke T. Shumaker</a> » <a href=/blog>blog</a> » purdue-cs-login</header>
<article>
<h1
id="customizing-your-login-on-purdue-cs-computers-wip-but-updated">Customizing
your login on Purdue CS computers (WIP, but updated)</h1>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>The lab boxes all run Gentoo.</p>
<h2 id="gdm-the-gnome-display-manager">GDM, the Gnome Display
Manager</h2>
<p>The boxes run <code>gdm</code> (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:</p>
<p>System configuration:</p>
<ul>
<li><code>/usr/share/gdm/defaults.conf</code> (lower precidence)</li>
<li><code>/etc/X11/gdm/custom.conf</code> (higher precidence)</li>
</ul>
<p>User configuration:</p>
<ul>
<li><code>~/.dmrc</code> (more recent versions use
<code>~/.desktop</code>, but Purdue boxes aren’t running more recent
versions)</li>
</ul>
<h3 id="purdues-gdm-configuration">Purdue’s GDM configuration</h3>
<p>Now, <code>custom.conf</code> sets</p>
<pre><code>BaseXsession=/usr/local/share/xsessions/Xsession
SessionDesktopDir=/usr/local/share/xsessions/</code></pre>
<p>This is important, because there are <em>multiple</em> 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
<code>/etc/X11/gdm/Xsession</code> (which exists, and is where it would
look by default).</p>
<p>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:</p>
<ul>
<li>Last session</li>
<li>1. MATE (<code>mate.desktop</code>;
<code>Exec=mate-session</code>)</li>
<li>2. CS Default Session (<code>default.desktop</code>;
<code>Exec=default</code>)</li>
<li>3. Custom Session (<code>custom.desktop</code>;
<code>Exec=custom</code>)</li>
<li>4. FVWM2 (<code>fvwm2.desktop</code>; <code>Exec=fvwm2</code>)</li>
<li>5. gnome.desktop (<code>gnome.desktop</code>;
<code>Exec=gnome-session</code>)</li>
<li>6. KDE (<code>kde.desktop</code>, <code>Exec=startkde</code>)</li>
<li>Failsafe MATE (<code>ShowGnomeFailsafeSession=true</code>)</li>
<li>Failsafe Terminal (<code>ShowXtermFailsafeSession=true</code>)</li>
</ul>
<p>The main 6 are configured by the <code>.desktop</code> files in
<code>SessionDesktopDir=/usr/local/share/xsessions</code>; the last 2
are auto-generated. The reason <code>ShowGnomeFailsafeSession</code>
correctly generates a Mate session instead of a Gnome session is because
of the patch
<code>/p/portage/*/overlay/gnome-base/gdm/files/gdm-2.20.11-mate.patch</code>.</p>
<p>I’m not sure why Gnome shows up as <code>gnome.desktop</code> instead
of <code>GNOME</code> as specified by <code>gnome.desktop:Name</code>. 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.</p>
<p>Which of the main 6 is used by default (“Last Session”) is configured
with <code>~/.dmrc:Session</code>, which contains the basename of the
associated <code>.desktop</code> file (that is, without any directory
part or file extension).</p>
<p>Every one of the <code>.desktop</code> files sets
<code>Type=XSession</code>, which means that instead of running the
argument in <code>Exec=</code> directly, it passes it as arguments to
the <code>Xsession</code> program (in the location configured by
<code>BaseXsession</code>).</p>
<h4 id="xsession">Xsession</h4>
<p>So, now we get to read
<code>/usr/local/share/xsessions/Xsession</code>.</p>
<p>Before it does anything else, it:</p>
<ol type="1">
<li><code>. /etc/profile.env</code></li>
<li><code>unset ROOTPATH</code></li>
<li>Try to set up logging to one of <code>~/.xsession-errors</code>,
<code>$TMPDIR/xses-$USER</code>, or <code>/tmp/xses-$USER</code> (it
tries them in that order).</li>
<li><code>xsetroot -default</code></li>
<li>Fiddles with the maximum number of processes.</li>
</ol>
<p>After that, it handles these 3 “special” arguments that were given to
it by various <code>.desktop</code> <code>Exec=</code> lines:</p>
<ul>
<li><code>failsafe</code>: 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.</li>
<li><code>startkde</code>: Displays a message saying KDE is no longer
available.</li>
<li><code>gnome-session</code>: Displays a message saying GNOME has been
replaced by MATE.</li>
</ul>
<p>Assuming that none of those were triggered, it then does:</p>
<ol type="1">
<li><code>source ~/.xprofile</code></li>
<li><code>xrdb -merge ~/.Xresources</code></li>
<li><code>xmodmap ~/.xmodmaprc</code></li>
</ol>
<p>Finally, it has a switch statement over the arguments given to it by
the various <code>.desktop</code> <code>Exec=</code> lines:</p>
<ul>
<li><code>custom</code>: Executes <code>~/.xsession</code>.</li>
<li><code>default</code>: Executes <code>~/.Xrc.cs</code>.</li>
<li><code>mate-session</code>: It has this whole script to start DBus,
run the <code>mate-session</code> command, then cleanup when it’s
done.</li>
<li><code>*</code> (<code>fvwm2</code>): Runs
<code>eval exec "$@"</code>, which results in it executing the
<code>fvwm2</code> command.</li>
</ul>
<h2 id="network-shares">Network Shares</h2>
<p>Your data is on various hosts. I believe most undergrads have their
data on <code>data.cs.purdue.edu</code> (or just <a
href="https://en.wikipedia.org/wiki/Data_%28Star_Trek%29"><code>data</code></a>).
Others have theirs on <a
href="http://swfanon.wikia.com/wiki/Antor"><code>antor</code></a> or <a
href="https://en.wikipedia.org/wiki/Tux"><code>tux</code></a> (that I
know of).</p>
<p>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, <code>data</code> 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
<code>BASENAME-NUMBER.cs.purdue.edu</code>. For example,
<code>data-25.cs.purdu.edu</code> is 128.10.25.13.</p>
<p>They use <a
href="https://www.kernel.org/pub/linux/daemons/autofs/">AutoFS</a> quite
extensively. The maps are generated dynamically by
<code>/etc/autofs/*.map</code>, which are all symlinks to
<code>/usr/libexec/amd2autofs</code>. As far as I can tell,
<code>amd2autofs</code> is custom to Purdue. Its source lives in
<code>/p/portage/*/overlay/net-fs/autofs/files/amd2autofs.c</code>. The
name appears to be a misnomer; seems to claim to dynamically translate
from the configuration of <a href="http://www.am-utils.org/">Auto
Mounter Daemon (AMD)</a> to AutoFS, but it actually talks to NIS. It
does so using the <code>yp</code> 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.</p>
<p>There are 3 mountpoints using AutoFS: <code>/homes</code>,
<code>/p</code>, and <code>/u</code>. <code>/homes</code> creates
symlinks on-demand from <code>/homes/USERNAME</code> to
<code>/u/BUCKET/USERNAME</code>. <code>/u</code> mounts NFS shares to
<code>/u/SERVERNAME</code> on-demand, and creates symlinks from
<code>/u/BUCKET</code> to <code>/u/SERVERNAME/BUCKET</code> on-demand.
<code>/p</code> mounts on-demand various NFS shares that are organized
by topic; the Xinu/MIPS tools are in <code>/p/xinu</code>, the Portage
tree is in <code>/p/portage</code>.</p>
<p>I’m not sure how <code>scratch</code> works; it seems to be
heterogenous between different servers and families of lab boxes.
Sometimes it’s in <code>/u</code>, sometimes it isn’t.</p>
<p>This 3rd-party documentation was very helpful to me: <a
href="http://www.linux-consulting.com/Amd_AutoFS/"
class="uri">http://www.linux-consulting.com/Amd_AutoFS/</a> 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.</p>
<h3 id="lore">Lore</h3>
<p><a
href="https://en.wikipedia.org/wiki/List_of_Star_Trek:_The_Next_Generation_characters#Lore"><code>lore</code></a></p>
<p>Lore is a SunOS 5.10 box running on Sun-Fire V445 (sun4u) hardware.
SunOS is NOT GNU/Linux, and sun4u is NOT x86.</p>
<p>Instead of <code>/etc/fstab</code> it is
<code>/etc/mnttab</code>.</p>
</article>
<footer>
<p>The content of this page is Copyright © 2015 <a href="mailto:lukeshu@lukeshu.com">Luke T. Shumaker</a>.</p>
<p>This page is licensed under the <a href="https://creativecommons.org/licenses/by-sa/4.0/">CC BY-SA 4.0</a> license.</p>
</footer>
</body>
</html>
|
