9front
OK, u9fs for media sharing from unix to #9front is kicking my butt. I am using the "stock" binary from ports on #OpenBSD.
Cpu server / drawterm access are working on #plan9 Glenda has a password and keys and all. I deliberately chose p9sk1 for the keys in factotum to enable legacy protocols since, as far as I can tell, u9fs only knows that.
Added this to /etc/services (from FreeBSD's equivalent):
9pfs 564/tcp #plan 9 file service
9pfs 564/udp #plan 9 file service
Added this to /etc/inetd.conf:
9pfs stream tcp nowait root /usr/local/sbin/u9fs -D -a p9any -l /var/log/u9fs /media
I opened TCP/564 in pf.conf for good measure - tho I think inetd does this? Anyway,
pass out proto tcp to any port 564
pass in proto tcp to any port 564
u9fs.keys is in place on OpenBSD and it has exactly 3 lines only with password/username/host. Can confirm inetd is OK and u9fs process is running.
However, on 9front:
cpu% 9fs 192.168.1.101
post...
srv net!192.168.1.101!9fs: mount failed: unknown user
cpu%
Same result if I run it manually with srv and mount -c
Logs on OpenBSD side for u9fs don't show anything (wish "verbose logging" were actually verbose and logged something..)
What am I missing?!
CARTER AND REAGAN DISPUTE VIEWS ON ARMS POLICY
#unix_surrealism #funhole #plan9 #9front #iwp9 #art #comic #poster #news #netflix #linux #werc #glenda
(1) I was able to get vmx up and running,
(2) data which I extracted from tar backups cannot be removed because some letters were converted into question mark signs,
(3) MBR on one of disks has vanished, but disk is recognized and mounted be l*nux.
Remember, this OS is not for stupid people.
