[3389] in SIPB_Linux_Development
Re: outstanding bugs
daemon@ATHENA.MIT.EDU (Garry Zacheiss)
Mon Mar 19 11:46:20 2001
Message-Id: <200103191646.LAA19585@riff-raff.mit.edu>
To: Jonathon Weiss <jweiss@MIT.EDU>
cc: linux-dev@MIT.EDU
In-Reply-To: Your message of "Mon, 19 Mar 2001 02:40:29 EST."
<200103190740.CAA06282@Bearing-An-Hourglass.mit.edu>
Date: Mon, 19 Mar 2001 11:46:06 -0500
From: Garry Zacheiss <zacheiss@MIT.EDU>
>> [2950] [3062] [3323] [3361] [3368]
>> resolv.conf has nameserver supplied during install, not localhost.
>> fixed (has this been tested)
Fixed, pulled up, tested, dead.
>> [3213] [3383] [3384]
>> install lists bogus times in /etc/athena/version
>> believed fixed, needs to be tested and propogated to charon
Needs to be tested; currently only in AFS.
>> [2955]
>> Somehow, my kerberos realm defaulted to "EXAMPLE.COM".
>> This prevents athena users from logging in with xlogin.
>> I'm not sure who owns the /etc/krb5.conf file:
Don't remember original problem report, but this is someone who
either layered or did a custom install; The krb5-configs RPM is never
installed by the normal install method. Not our problem.
>> [2989]
>> Currently we install a null release RPMs file. This works except that
>> if the user selected not to install some Athena package as part of a
>> custom install it will be installed at next update. Alternatively if
>> the release drops some package it will get left on the system.
>> The release may drop RPMs in patch releases for security reasons
>> (this happened to gnorpm between 8.4.15 an 8.4.17).
The release-rpms file gets populated with the contents of the rpms in
the release when you take your first update, and I've verified in the
past that updating from "8.4.0" to some patch release will remove RPMs
that the release has removed. And we don't support the custom install
option anyway.
>> [3044] [3056] [3109] [3110] [3112] [3113] [3114]
>> We run getty on other vt's. I've seen a lot of back and forth on
>> this, as to whether we decided to leave it or fix it to be like the IS
>> install. At the very least we need to get our story straight. If we
>> leave it I think we need to make sure the customization gets into the
>> private-workstation-owners-guide.
People like their vt's. If we turn this off, the net result will be
increasing our support load by having people asking how to turn them
back on. It should stay the way it is.
>> [3048] [3051] [3052] [3055] [3058] [3059]
>> AFSCLIENT AFSADJUST AFSSRV
Adding a grep for the first two variables is easy, as is adding code
to deal with the third one. I'll do that. If someone wants to figure
out what's actually going on, they're welcome to.
>> [3073]
>> User with custom install problmes. Did we agree to and implement the
>> removal of the custom install option?
We haven't removed it. We either should or should document very
clearly that if it breaks, you get to keep both pieces.
>> [3316] [3317] 3318]
>> fix pcitable on sipb-nfs (not really a show stopper, but a trivial
>> file propogation from the floppy to charon as I understand it)
Sounds dandy. Someone should do it.
>> [3354]
>> We're installing old versions of some RedHat packages. (I thought
>> we'd fixed this, did I just miss the mail in my scan?)
This is fixed. You missed the mail.
I don't have the time to work on anything below the level of what you
consider showstoppers.
Garry
