[6558] in Release_7.7_team
Re: new dialup testing
daemon@ATHENA.MIT.EDU (Evan Broder)
Thu Dec 10 14:54:06 2009
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.00.0912101409270.32528@green-arrow.mit.edu>
Date: Thu, 10 Dec 2009 14:53:51 -0500
Message-ID: <2706d8dd0912101153u6c3a5fa5u3ea4e92307abfa3c@mail.gmail.com>
From: Evan Broder <broder@MIT.EDU>
To: "Mark W. Manley" <mmanley@mit.edu>
Cc: Anders Kaseorg <andersk@mit.edu>, Nelson Elhage <nelhage@mit.edu>,
release-team@mit.edu, ops@mit.edu
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Flag: NO
X-Spam-Score: 0.00
Content-Transfer-Encoding: 8bit
Ok, thanks. We decided to pass -o nonempty to FUSE at startup so that
it'll just shadow the contents of /mit like any other mountpoint.
FUSE's justification for not doing that by default are fairly tenuous,
and not deleting things seems strictly better than deleting things.
The specific ticket is <http://debathena.mit.edu/trac/ticket/461>,
although that won't tell you anything I haven't.
As per our standard testing policy, the fix will sit in our testing
repository for a couple of days, and then we'll deploy it to our
primary apt repository.
- Evan
On Thu, Dec 10, 2009 at 2:09 PM, Mark W. Manley <mmanley@mit.edu> wrote:
> Sorry, it's /etc/init.d/athena-ws, not update-ws.
>
> -MM
>
> On Thu, 10 Dec 2009, Evan Broder wrote:
>
>> Huh - I'm not sure why anything would have ever ended up in /mit - if
>> the automounter is running correctly, all of the /mit symlinks are
>> part of the PyHesiodFS FUSE filesystem, and should vanish when it gets
>> unmounted.
>>
>> We can definitely add logic in the startup script to clean it out,
>> though. I don't see /etc/init.d/update-ws on any of the Linux or
>> Solaris Athena 9 machines I can get into, though - where did that come
>> from?
>>
>> - Evan
>>
>> On Thu, Dec 10, 2009 at 1:58 PM, Mark W. Manley <mmanley@mit.edu> wrote:
>>>
>>> It appears that it failed to start because old attach points were still
>>> in
>>> /mit when the system rebooted:
>>>
>>> root@ringworld:/etc/init.d# /usr/bin/pyhesiodfs /mnt
>>> fuse: mountpoint is not empty
>>> fuse: if you are sure this is safe, use the 'nonempty' mount option
>>> Traceback (most recent call last):
>>> File "/usr/bin/pyhesiodfs", line 226, in <module>
>>> main()
>>> File "/usr/bin/pyhesiodfs", line 223, in main
>>> server.main()
>>> File "/usr/lib/python2.6/dist-packages/fuse.py", line 713, in main
>>> main(**d)
>>> fuse.FuseError: filesystem initialization failed
>>>
>>> It appears that the same logic that was in /etc/init.d/update-ws to clean
>>> out /mit isn't present on this system, so it failed to start.
>>>
>>> Was this a deliberate change from Athena 9?
>>>
>>> -MM
>>>
>>> On Thu, 10 Dec 2009, Evan Broder wrote:
>>>
>>>> Right. Also, even if attach on linerva fails because he doesn't have
>>>> tokens, you would still be able to chdir into your homedir because of
>>>> the automounter, so long as your homedir was system:anyuser l. But it
>>>> doesn't look like the automounter is running on ringworld - why not?
>>>>
>>>> - Evan
>>>>
>>>> On Thu, Dec 10, 2009 at 1:33 PM, Anders Kaseorg <andersk@mit.edu> wrote:
>>>>>
>>>>> On Thu, 10 Dec 2009, Mark W. Manley wrote:
>>>>>>
>>>>>> That's the same behavior of Linerva.
>>>>>
>>>>> Linerva gives you a clear warning message in this case.
>>>>>
>>>>> WARNING: You have no valid Kerberos tickets.
>>>>> See http://debathena.mit.edu/ssh
>>>>>
>>>>> Nelson was complaining that this warning did not appear on ringworld,
>>>>> although he told me that it did appear when he tried again, so *shrug*.
>>>>>
>>>>> Anders
>>>>>
>>>>
>>>
>
