Re: [9fans] 9vx - Plan9

This is a discussion on Re: [9fans] 9vx - Plan9 ; > Works impressively well here. Even snarf/paste between host and 9vx is > working. > > Did only the 9 kernel need modifications or did the applications > binaries need to be recompiled as well? > > --vs Seconded; everything ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Re: [9fans] 9vx

  1. Re: [9fans] 9vx

    > Works impressively well here. Even snarf/paste between host and 9vx is
    > working.
    >
    > Did only the 9 kernel need modifications or did the applications
    > binaries need to be recompiled as well?
    >
    > --vs


    Seconded; everything works beautifully except that I'm not getting
    any network devices, it seems.

    John



  2. Re: [9fans] 9vx

    > Seconded; everything works beautifully except that I'm not getting
    > any network devices, it seems.


    Perhaps

    bind -b '#I' /net

    That should be happening automatically, but hey, you never know.
    If files in /net exist, could you give more details?

    > Did only the 9 kernel need modifications or did the applications
    > binaries need to be recompiled as well?


    The user binaries are unmodified native 386 binaries.

    Russ



  3. Re: [9fans] 9vx

    > Seconded; everything works beautifully except that I'm not getting
    > any network devices, it seems.


    there's not access to the network device per ce, but the network works
    fine for me. this is what i needed to do to connect to plan 9
    networks

    1. edit /lib/ndb/auth and /lib/ndb/local as appropriate.
    2. rm /net/cs; ndb/cs
    3. auth/factotum
    4. cpu -h $host

    - erik



  4. Re: [9fans] 9vx

    On Fri, Jun 27, 2008 at 10:12 PM, erik quanstrom wrote:
    > there's not access to the network device per ce, but the network works
    > fine for me. this is what i needed to do to connect to plan 9
    > networks
    >
    > 1. edit /lib/ndb/auth and /lib/ndb/local as appropriate.
    > 2. rm /net/cs; ndb/cs
    > 3. auth/factotum
    > 4. cpu -h $host


    Same recipe works here. But I've no idea why the rm /net/cs is
    necessary - can anyone put me out of my misery?
    -sqweek


  5. Re: [9fans] 9vx

    > Same recipe works here. But I've no idea why the rm /net/cs is
    > necessary - can anyone put me out of my misery?


    There are a bunch of rough edges that need to be fixed.
    This is one of them. 9vx provides a #I/cs so that you
    can do things like hget without starting cs. But it can't
    translate auth domains via /lib/ndb, which factotum
    needs it to do. So you have to start the more full-featured
    ndb/cs, but that mounts itself on /net using MAFTER
    (a bug, if you ask me). Because I knew I couldn't get
    a fix to ndb/cs into the distribution in time, I made the
    #I/cs file removable.

    Originally, the reason for providing #I/cs was to provide
    access to host DNS lookups, just like it does in drawterm.
    Now that there is a separate #I/dns (that ndb/cs will use),
    it might be that the right thing to do is just toss away #I/cs
    so that termrc will start a real one.

    Another rough edge, if anyone wants a challenge, is that
    gs goes into an I/O-free loop after reading the first 4k of
    /sys/lib/ghostscript/gs_init.ps. (I deleted gs from the 9vx
    tar file to save space, so you'll have to run against a
    distribution tree instead.)

    Russ



  6. Re: [9fans] 9vx

    now that you've explained the cs issue things are much clearer. i can
    confirm that I have successfully booted a 9vx terminal off a remote
    plan9 server using a small modification to factotum.

    the original boot process failed with:

    password:
    !
    authentication failed (auth_proxy rpc write: bootes: Connection
    refused), trying mount anyways
    boot: mount /: fossil authCheck: auth protocol not finished
    9vx panic: boot process died: unknown

    and the change simply sidesteps factotum using cs to figure out
    who/what to dial, instead just using IP addresses.

    here's the hack:

    9grid% yesterday -d util.c
    diff /n/dump/2008/0630/sys/src/cmd/auth/factotum/util.c
    /sys/src/cmd/auth/factotum/util.c
    33c33
    < return authdial(net, authdom);
    ---
    > ;//return authdial(net, authdom);

    9grid%

    now compile 8.factotum and copy it as 9vx/src/9vx/factotum.9 and recompile 9vx.

    unfortunately with a terminal booted thusly i no longer have /mnt/term


  7. Re: [9fans] 9vx

    > now compile 8.factotum and copy it as 9vx/src/9vx/factotum.9 and recompile 9vx.

    err, make that vx32/src/9vx/factotum.9. i'm compiling against the
    latest mercurial, but there's not reason why it shouldn't just work
    with .11 and .10


  8. Re: [9fans] 9vx

    > 9grid% yesterday -d util.c
    > diff /n/dump/2008/0630/sys/src/cmd/auth/factotum/util.c
    > /sys/src/cmd/auth/factotum/util.c
    > 33c33
    > < return authdial(net, authdom);
    > ---
    >> ;//return authdial(net, authdom);

    > 9grid%


    Does it work to set csremoved=1 in src/9vx/devip.c instead?

    > unfortunately with a terminal booted thusly i no longer have /mnt/term


    bind '#Z' /mnt/term

    Russ



  9. Re: [9fans] 9vx

    > Does it work to set csremoved=1 in src/9vx/devip.c instead?

    I can confirm that this works, with the benefit of using secstore
    instead of prompting for my password.


  10. Re: [9fans] 9vx

    >> Does it work to set csremoved=1 in src/9vx/devip.c instead?
    >
    > I can confirm that this works, with the benefit of using secstore
    > instead of prompting for my password.


    Okay, done. Thanks.

    Russ



+ Reply to Thread