A brief note on 9vx and cpu, which might also be relevant for a few other things. Using 9vx as a cpu server has been mentioned a few times, but my attempts to actually get this working met with failure initially. I believe I have tracked down the issue - the remoteside() of cpu.c makes use of the kernel cap device via a call to the auth_chuid function, and the cap device is not available in 9vx, probably due to the single-user nature of it as a hosted environment. If we don't need to support multiple users, there is an easy way to get this work to work - just skip trying to change user.
cpu% diff /sys/src/cmd/cpu.c /sys/src/cmd/altcpu.c 590a591 > int factfd; 595,596c596 < if(auth_chuid(ai, nil) < 0) < return -1; --- > /* no cap device in 9vx so no auth_chuid, we are who we are */ 597a598,601 > factfd = open("/srv/factotum", ORDWR); > if(factfd >= 0) > mount(fd, -1, "/mnt", MREPL, ""); > newns(user, nil); /* this and above 3 lines replicate auth_chuid > behavior */ Because we aren't can't change user ID, using aux/listen as none isn't going to work. Instead, we need to run the listener as our user, and we can just put a factotum key in its namespace and leave out authsrv and keyfs. Assuming the above modification has been compiled and installed as altcpu, the following is all you need to do to allow drawterm/cpu access: term% auth/factotum term% echo 'key proto=p9sk1 dom=testdom user=glenda !password=password' >/mnt/factotum/ctl term% aux/listen1 -t tcp!*!17010 /bin/altcpu -R & Despite running as a trusted user, this should still be fairly secure because cpu demands authentication. Even without authsrv/keyfs, password-based authentication between the factotums works. Note however that if you get the password wrong, it fails with a botch message, so you have to redial if you typo your password. According to my limited testing so far, cpu from plan 9 and drawterm both work fine. This message was written in acme in drawterm to a 9vx elsewhere on the LAN. ~Mycroftiv 9gridchan.org