[207] in athena10
Re: 14 May 2008 Athena Release Team Status Report
daemon@ATHENA.MIT.EDU (Evan Broder)
Thu May 15 17:38:39 2008
Message-ID: <482CAD32.9070302@mit.edu>
Date: Thu, 15 May 2008 17:37:54 -0400
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: athena10@mit.edu
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I had a few quick thoughts in response to the progress report sent to
owls and release-team (transaction 5141 on the fuzz archive):
(1) Time synchronization: NTP sucks. ntp the Debian package really
sucks. chrony is much better in my experience, although it still kind of
sucks. That's what I would personally recommend using. If someone wants
something to go off of, I've been using a configuration package that I
built for XVM
(https://xvm.mit.edu:1111/trunk/packages/sipb-xen-chrony-config/) on
most of the servers I maintain, and it seems to work respectably well.
(Note that my scenario was a Xen HVM which wasn't getting consistant
ticks from the "hardware" and therefore was way off. It probably works
significantly better on machines that have non-sucky hardware clocks)
(2) ternus and I would both love to be involved in any printing
discussions that are happening if that's reasonable. cups.mit.edu has
unfortunately fallen into a sort of mostly functional but unpolished
state as ternus and I (the two maintainers) have been distracted by
other projects and schoolwork. We're hoping to have more time to put
into it over the summer, and in particular I'm interested in looking
into Kerberized CUPS printing, which I still think is possible.
The one major issue I still haven't resolved with CUPS is the issue of
private queues. In the CUPS model, when a server is polled for available
queues, it lists all queues it knows about, and that's the only way that
a CUPS client knows about a queue. It would require patching the server
code to support the idea of queues that aren't "default visible" or
something like that, and I'm not sure that clients would see the queues
when they were manually specified if that was done. The queue could
probably be added to the local configuration, although that's kind of a
poor solution.
In terms of client support, Linux support is excellent. Installing the
debathena-cupsys-config package causes all cluster and dorm printers to
show up in the standard GNOME print dialog box. Mac OS X support is
slightly less good. I haven't packaged support yet for MacAthena, but
making the configuration changes causes the CUPS command line tools to
recognize the new queues, but they have to each be manually added to
show up in the graphical print dialog. I don't really know anything
about Windows support, other than Kerberized printing is probably
impossible, but anything else should work.
- Evan
