[9fans] pnp factotum from linux to plan 9: site-specific passwordfailures. - Plan9

This is a discussion on [9fans] pnp factotum from linux to plan 9: site-specific passwordfailures. - Plan9 ; I can't get into bell-labs.com if p9p factotum is running. Kill factotum, I can get in. On the failure case, I get the continually repeated password prompt. I have this problem with some, but not all, cpu servers. Kill p9p ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: [9fans] pnp factotum from linux to plan 9: site-specific passwordfailures.

  1. [9fans] pnp factotum from linux to plan 9: site-specific passwordfailures.

    I can't get into bell-labs.com if p9p factotum is running. Kill
    factotum, I can get in. On the failure case, I get the continually
    repeated password prompt. I have this problem with some, but not all,
    cpu servers.

    Kill p9p factotum, all is well.

    What's a sensible way to debug this?

    thanks

    ron


  2. Re: [9fans] pnp factotum from linux to plan 9: site-specificpassword failures.

    > I can't get into bell-labs.com if p9p factotum is running. Kill
    > factotum, I can get in. On the failure case, I get the continually
    > repeated password prompt. I have this problem with some, but not all,
    > cpu servers.
    >
    > Kill p9p factotum, all is well.


    If instead of killing p9p factotum, you run

    echo delkey | 9p write factotum/ctl

    does that clear up the problem? I wonder if perhaps
    factotum has a bad key and is not overriding it when
    you type the correct password.

    > What's a sensible way to debug this?


    After a few iterations of the repeated password prompt,
    it would be nice to know what

    9p read factotum/ctl

    prints, specifically whether there are multiple keys for
    the auth domain that you are trying to get into.

    Russ




  3. Re: [9fans] pnp factotum from linux to plan 9: site-specificpassword failures.

    On Tue, May 27, 2008 at 8:14 AM, Russ Cox wrote:
    >> I can't get into bell-labs.com if p9p factotum is running. Kill
    >> factotum, I can get in. On the failure case, I get the continually
    >> repeated password prompt. I have this problem with some, but not all,
    >> cpu servers.
    >>
    >> Kill p9p factotum, all is well.

    >
    > If instead of killing p9p factotum, you run
    >
    > echo delkey | 9p write factotum/ctl


    [rminnich@xcpu ~]$ echo delkey | 9p write factotum/ctl
    [rminnich@xcpu ~]$ echo delkey | 9p write factotum/ctl
    9p: write error: found no keys to delete

    run and get same problem.


    > After a few iterations of the repeated password prompt,
    > it would be nice to know what
    >
    > 9p read factotum/ctl


    [rminnich@xcpu ~]$ 9p read factotum/ctl
    key dom=cs.bell-labs.com proto=p9sk1 role=client user=rminnich !password?
    [rminnich@xcpu ~]$

    so there's something in there, but not repeated.

    thanks

    ron


  4. Re: [9fans] pnp factotum from linux to plan 9: site-specificpassword failures.

    > run and get same problem.

    Factotum provides a log file that was intended to be
    a list of interesting events. While the log file was
    implemented, nothing was being logged to it.

    I have added log statements tracing the important
    events in factotum and p9sk1 in particular.

    cd $PLAN9/src/cmd/auth/factotum
    cvs up # or hg pull -u
    mk install

    Then restart your factotum, and run drawterm and
    "9p read factotum/log" in separate windows.
    You'll have to interrupt "9p read" when you're done,
    since it blocks waiting for more log messages.

    Russ



  5. Re: [9fans] pnp factotum from linux to plan 9: site-specificpassword failures.

    [rminnich@xcpu ~]$ 9p read factotum/log
    keyfetch role=client proto=p9sk1 dom=ca.sandia.gov user? !password?
    convneedkey role=client proto=p9sk1 dom=ca.sandia.gov user? !password?
    addkey proto=p9sk1 role=client dom=ca.sandia.gov user=rminnich !password?
    adding key: proto=p9sk1 role=client dom=ca.sandia.gov user=rminnich !password?
    convneedkey returning
    keyfetch proto=p9sk1 user? dom=ca.sandia.gov
    using key dom=ca.sandia.gov proto=p9sk1 role=client user=rminnich !password?
    p9skclient: gettickets: Connection timed out

    I am assuming our cpu server is misconfigured somehow?

    Kill factotum, it all works.

    thanks

    ron


  6. Re: [9fans] pnp factotum from linux to plan 9: site-specificpassword failures.

    > p9skclient: gettickets: Connection timed out

    Aha! Factotum uses ndb (the library, not the program)
    to map from auth domain to auth server. If it can't find
    a mapping, it tries to use the auth domain as a machine
    name directly. Unless your auth server's machine name
    is ca.sandia.gov, you need to edit $PLAN9/ndb/local to
    add an entry:

    authdom=ca.sandia.gov
    auth=your-auth-server.sandia.gov

    There are examples in that file already.

    Too many examples.

    Sadly, it appears that my own local changes (entries
    for cs.bell-labs.com and pdos.csail.mit.edu, and a
    reference to a non-existant file=cox-home) leaked
    into the distribution. I've removed them (no real harm
    done), but perhaps the entry for cs.bell-labs.com was
    no longer correct, which would explain your other problem.

    Russ



  7. Re: [9fans] pnp factotum from linux to plan 9: site-specificpassword failures.

    On Wed, Jun 4, 2008 at 10:33 AM, Russ Cox wrote:
    >> p9skclient: gettickets: Connection timed out

    >
    > Aha! Factotum uses ndb (the library, not the program)
    > to map from auth domain to auth server. If it can't find
    > a mapping, it tries to use the auth domain as a machine
    > name directly. Unless your auth server's machine name
    > is ca.sandia.gov, you need to edit $PLAN9/ndb/local to
    > add an entry:
    >
    > authdom=ca.sandia.gov
    > auth=your-auth-server.sandia.gov
    >
    > There are examples in that file already.
    >
    > Too many examples.


    Thanks russ, this did the fix!

    authdom=sandia.gov
    auth=192.168.18.13


    ron


+ Reply to Thread