[6559] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: new dialup testing

daemon@ATHENA.MIT.EDU (Mark W. Manley)
Thu Dec 10 15:13:06 2009

Date: Thu, 10 Dec 2009 15:12:49 -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: <2706d8dd0912101153u6c3a5fa5u3ea4e92307abfa3c@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.0912101512010.32528@green-arrow.mit.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1578274304-27851811-1260475970=: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-27851811-1260475970=:32528
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

Oddly enough, gvfs-fuse fell out of the packages that rw had installed, so 
it wasn't able to initialize the python libraries needed.  After 
reinstalling, the daemon was able to start.

Weird.  I don't remember uninstalling that.

On Thu, 10 Dec 2009, Evan Broder wrote:

> 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
>>>>>>
>>>>>
>>>>
>>
>
--1578274304-27851811-1260475970=:32528--

home help back first fref pref prev next nref lref last post