[6556] in Release_7.7_team
Re: new dialup testing
daemon@ATHENA.MIT.EDU (Mark W. Manley)
Thu Dec 10 14:09:48 2009
Date: Thu, 10 Dec 2009 14:09:38 -0500 (EST)
From: "Mark W. Manley" <mmanley@MIT.EDU>
To: Evan Broder <broder@mit.edu>
cc: Anders Kaseorg <andersk@mit.edu>, Nelson Elhage <nelhage@mit.edu>,
release-team@mit.edu, ops@mit.edu
In-Reply-To: <2706d8dd0912101105w15348817pe3bedfe52b78dee@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.0912101409270.32528@green-arrow.mit.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1578274304-1299607997-1260472179=:32528"
X-Spam-Score: -2.599
X-Spam-Flag: NO
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--1578274304-1299607997-1260472179=:32528
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
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
>>>>
>>>
>>
>
--1578274304-1299607997-1260472179=:32528--
