DICE Meeting 2002-08-06
Kings Buildings, JCMB 2509
Present
gdmr, iainr, neilb, sxw, jmho, ajs (mins)
Previous Actions
- Profile server (site specific .def files)
- Filesystems
- LDAP population
- Kerberos at installation
- Order of kerberos/localauth on laptops
- Root account
- Misc stuff
- AMD problems
- Minimal client features
- Multihomed machines
- Laptops
- Bugzilla
New agenda items
- LDAP replication
- Voodoo
- DICE wires
- Mail server UPS
Profile server (site specific .def files)
AJS had proposed a new path site specific .def files :-
/usr/lib/lcfg/defaults/{client|server}/{domainname}.
Simon wants to separate out LCFG generic from site-specific om defaults in component
def files - ie have the component def files somehow include a site specific om.def
which in turn includes the LCFG generic om.def. This turns out not to be currently
possible. Current hack is that a locally hacked version of om.def is shipped instead of the
LCFG generic om.def.
ACTION: paul
Filesystems
GDMR has completed the code to transform LDAP home directory info
and partition table info into LDAP data suitable for use by amd.
The tables are now "rfe editable", but until trigger updates into
LDAP are implemented, a manual run to feed the data into LDAP
is necessary. Instructions on how to perform the manual run are
included in the "rfe editable" files; all CO/CSOs have permission
to perform the manual runs.
ACTION: sxw
Simon has added a zero length check on input to ldapsync, as an extra
sanity check.
George has pulled hesiod from DNS to prove that we're not using
hesiod at all. No problems were encountered.
AJS has replaced the hesiod /export/local,
/usr/local and /useful/srpms maps with symlink equivalents, prior to
implementing the final package file structure (dependent on the
new RPM/SRPM repository)
We need to keep up-to-date the list of "trusted" machines to which
legacy NFS fileservers export their filesystems. We can do this by
generating a list of trusted hosts using a spanning map, generating
a list that can be exported to the legacy fileservers via rsync
or http. It was agreed that, given that this was a short term measure,
instead of creating yet another spanning map, we would add a
temporary field called "exportto" to the inventory spanning map which
would then be exported off the inventory server by http or rsync.
ACTION: ajs
LDAP population
We will continue to use the pam_access module with netgroups
(fed from roles) for controlling access to machines, at least
for the short term. It gives more control
than the PAM pam_diceauth module - we'll use it until we clarify our real
requirements in the light of experience.
- people
- Real account data now live. All support scripts now in
service; a few problems, Neil addressing.
ACTION: neilb
- hosts
- Simon has written the code to generate the hosts map, but he
is concerned about the resultant linkage between tomato (profile
server) and stapag (LDAP master); if the LDAP update to stapag
blocks, this
would hang LCFG profile generation on tomato. Possible solutions are
running a shadow profile server or producing a text file on the profile
server which is then published to the LDAP master.
ACTION: sxw
- printing
- Neil believes that printer information is mastered
in LDAP. Configuration not yet rfe editable, so manual
LDAP changes just now; not too much of a concern because only
a small number of COs need to edit printer entries.
- roles/netgroups
- Simon suggested that we have a "free for all" in creating capabilities for this
year ; we can reevaluate next year in the light of experience. This was agreed.
A tentative informal syntax for naming capabilities is forming.
Kerberos at installation
Tim has created install principals for the technicians
so that they can install machines.
Order of Kerberos/local auth on laptops
The current order for PAM based authentication is kerberos, followed
by localauth. Although this is suitable for desktop machines, it
is arguably the incorrect order for laptops where the user wants
more control of when the laptop communicates with other machines.
It looks like driving the order from contexts is the correct way
forward.
Root account
It was agreed that unifying the single-user root password with the
multi-user root password, for any given machine, was necessary.
The single-user root password currently comes from /etc/{passwd,shadow}
courtesy of the auth component. The multi-user root password
is created by the kerberos component, and is stored in /etc/localpasswd
in a kerberos encrypted form for use by the PAM localauth module.
Possibly the best solution is look at changing the single user code
to understand the /etc/localpasswd format (by linking against the
kerberos libraries).
Another possibility had been to write a PAM module that authenticates
all root against /etc/passwd, but that is not as secure as the
passwd would be stored in simple MD5 form and would be world readable (while
profiles are world readable).
Meanwhile the root password should be manually synchronised in
the auth and kerberos resources.
ACTION: ajs
Simon and George noted that it was becoming increasingly difficult to
logon to a hung machine as "root". Two possible causes are LDAP (maybe the
default bash environment shouldn't do an LDAP search for roles if the
user is "root") and the automounter (maybe the environment is trying
to access an automounter managed path). George will investigate.
ACTION: gdmr
AMD problems
George thinks that the LDAP related problems are fixed. The only remaining problem
is the am-utils bug triggered by rhymer.cogsci's misbehaviour (where it
disappears for 1min at a time). George is still investigating this.
As an aid to eliminating any other factors in BP, one of the BP COs will
move their home directory (or part of) onto a DCS server and one of the KB COs will
move their home directory (or part of) onto rhymer.cogsci
ACTION: gdmr
Minimal client features
The minimal client is now in service.
Laptop support
Folk would really like this ASAP. AJS will revisit and evaluate what
needs to be done, how long and what won't/doesn't work (eg
IP filtering will need completely revisited). Will have a look
through existing laptop.h. Paul has ported and tested divine.
ACTION: ajs
Bugzilla
Simon requested that bugzilla.inf.ed.ac.uk be moved onto a more
supported 7.1 DICE machine, from it's current home on dice3.
AJS reported that the intention was for bugzilla to be installed
on the RPM/SRPM master server, but this has yet to be installed.
Simon and AJS will discuss moving bugzilla.inf.ed.ac.uk in the
interim.
ACTION: sxw/ajs
LDAP Replication
There are three possible schemes for LDAP replication.
- Scheme A
- Replicate all clients off LDAP master (stapag) using ldapreplicate.
This doesn't scale.
- Scheme B
- LDAP master replicates to one of four read-only site LDAP slaves (using
KDC slaves as they've got plenty of spare resource) using the official
OpenLDAP replication mechanism (slurpd). The individual clients replicate
off these site slaves using ldapreplicate. The disadvantage with this
scheme is that ldapreplicate doesn't cope well with certain LDAP V3 operations.
- Scheme C
- LDAP master replicates to LDAP slaves, as in scheme B, which then generate and
publish Changelog information that can be used by the clients for replication.
Currently, scheme A is the default. Scheme B has been half deployed with only
a handful of clients. Simon hopes that scheme C will be ready for wide-scale deployment
by 23rd August. Alastair didn't feel this was early enough as there are a number
of DICE labs now being commissioned and this will probably have a negative impact
on the LDAP master. It was agreed that we should deploy scheme B until scheme C
is ready; we will wait until Tim returns next week (Aug 14th).
ACTION: sxw/timc
Voodoo
There is still some undocumented voodoo associated with routine admin tasks.
Much of this voodoo is necessary because LDAP triggers aren't available yet, or
because the spanning host map is not yet available. These need to be added to
the DICE documentation pages (if not already there).
ACTION: Documentation team
- localusers (for laptops)
-
Simon will publish the voodoo on how to add localusers to individual machines (eg for laptops).
ACTION: sxw
- buildamdmaps
-
This needs to be run after changing the partitions map or changing a user's home directory.
- Creating a new rfe service
-
Simon will publish the voodoo on how to add LDAP entries for new rfe services.
ACTION: sxw
- sshkeys
-
The current state of play with sshkeys is that
things internally will continue to work without them (hosts are
authenticated via GSSAPI). Each machine will continue attempting to
publish their sshkey until a suitable record for them to publish into is
created, which will happen just as soon as the LCFG->LDAP gateway is
going.
ACTION: sxw
DICE Wires
There are still a large number of machines that need to be moved from wire-M (129.215.212)
to their permanent home. These need moved to minimize traffic over EdLAN connections and
to minimize dependence on EdLAN.
ACTION: ALL
The following DICE wires will exist in the short term.
| Wire | Location | Use |
| M | SB | All? |
| C | KB | Staff and servers |
| K | KB | Staff and servers (overflow) |
| D | KB | Students |
| W | FH | All? |
| G | BP | All? |
We need LCFG wire headers for these
ACTION: ajs
The intention is for the installservers (installroot + DHCP) to coexist with the site RPM slaves.
The RPM slaves are not yet in service, so as a temporary measure DHCP will be run on the
site network infrastructure machines with the installroot continuing to be mounted off medlar.
This will reduce the need to carry client VLANs across multiple sites.
ACTION: ajs/iainr
Mail UPS
Neil and George will discuss UPS requirements for the Informatics Mail server.
ACTION: neilb/gdmr
Next meeting
No time set - aiming for week beginning 26th August
|
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is
copyright The University of Edinburgh
|
|
