Date: Thu, 22 Jan 2015 19:10:53 +0100 From: Willem Jan Withagen <wjw@digiware.nl> To: "freebsd-virtualization@freebsd.org" <freebsd-virtualization@freebsd.org> Cc: Conrad Rad <cse.cem@gmail.com> Subject: Re: How to connect ssh and /dev/nmdm devices Message-ID: <54C13D2D.40609@digiware.nl> In-Reply-To: <54BE94EC.1080806@redbarn.org> References: <CAG6CVpVt2gjZvHiLfruMXh-u0pBeF3Lc-_SGA%2BEY7E1fVmgKzg@mail.gmail.com> <5448305F.8010307@freebsd.org> <CAG6CVpUa4b5zFwN%2BBcD7OCYV9Xz8z9j9iRs721YYqFhvoJbOLA@mail.gmail.com> <54483712.8050007@freebsd.org> <54A9CAFB.1090902@digiware.nl> <54A9CC90.2020103@freebsd.org> <54AA4E32.1080303@digiware.nl> <54BE8434.3070901@digiware.nl> <54BE94EC.1080806@redbarn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2015-01-20 18:48, Paul Vixie wrote: > > >> Willem Jan Withagen <mailto:wjw@digiware.nl> >> Tuesday, January 20, 2015 8:37 AM >> >> >> >> What is the easiest way to "propagate" the full-duplex tty stream >> from a SSH-login to a /dev/nmdmXXXXA. > > somewhat expectedly, i use <http://www.freshports.org/sysutils/rtty/>; > for this. with a restricted shell, i can offer console access to guests > via ssh. "cu" also works, but lacks rtty's background logging. HI, I got several suggestions, and in the end I went for this one. Why? The code base is small and simple it does exactly what I required, no more, no less. Getting it to work requires a bit of careful configuration but one you've done that you end up with SSH users which can do multiple logins and all see the same console. Input and things all the same. So no exclusion because you've left your terminal open at work and went home. Nifty stuff. Basic install: 1) pkg install rtty. This populates the /usr/local/rtty tree. And that is where just almost everything happens. 2) In /usr/local/rtty/dev create links to the nmdm-devices you'd like to connect to the console: root@bhyve00:/usr/local/rtty # ls -l dev total 1 lrwxr-xr-x 1 root wheel 14 Jan 22 11:13 bh1101A -> /dev/nmdm1101B 3) Create a "shell" to connect to this console: root@bhyve00:/usr/local/rtty # cat bin/rtty-shell #!/bin/sh exec /usr/local/rtty/bin/console "$LOGNAME" # exec /usr/bin/cu -t -l /dev/nmdm1101A # exec /usr/bin/tip vm1101 exit And make it executable: root@bhyve00:/usr/local/rtty # ls -l bin/rtty-shell -rwxr-xr-x 1 root wheel 127 Jan 22 11:15 bin/rtty-shell As you can see you can use other commands as well, but both tip and cu are all about exclusive access. Trick here is that LOGNAME is what the user is using for login, and that is also the name of the device in ../dev to which he/she is connected. 4) Create the user in /etc/passwd: root@bhyve00:/usr/local/rtty # grep bh1101A /etc/passwd bh1101A:*:10001:10001:Bhyve dome remote access user:/home/bhyvedemo:/usr/local/rtty/bin/rtty-shell And put him in /etc/group to make things complete: root@bhyve00:/usr/local/rtty # grep bh1101A /etc/group bh1101A:*:10001: Group is needed for the rights on the socket-device in step 6. 5) Which also requires an entry in /etc/shells to work: root@bhyve00:/usr/local/rtty # grep rtty /etc/shells /usr/local/rtty/bin/rtty-shell 6) Having done all this the we need to make sure that the accessrights on the linked device are set correctly: root@bhyve00:/usr/local/rtty # cat owner/bh1101A.sock root:bh1101A This will prevent another user from hijacking a console which is not his, in case of access by other means. 7) Last ting to do is to start the server deamon that does the multiplexing/sharing stuff: /usr/sbin/daemon -cf /usr/local/rtty/bin/Startup Which you could dump into /etc/rc.local, or the more brave would write a rc.d compliant startup script. 8) Test: root@bhyve00:/usr/local/rtty # ssh bh1101A@localhost Password for bh1101A@bhyve00: Last login: Wed Jan 21 12:42:37 2015 from mail.ip6.digiware.nl FreeBSD 11.0-CURRENT (GENERIC) #19 r277452: Wed Jan 21 08:01:54 UTC 2015 Welcome to FreeBSD! connected (use (CR)~? for minimal help; also (CR)~q? and (CR)~s?) [authorized] [bh1101A@/dev/pts/4 connected] FreeBSD/amd64 (FreeBSD-11) (ttyu0) login: ======================== Even if the VM is not yet running you can connect to the server, and then start the VM, to all of its booting output. Or interact with the loader. It also works to actually install a VM from CD. Not that on 10.0 installs the default console is OFF, en needs to be edited in /etc/ttys to ttyu0 "/usr/libexec/getty std.9600" vt100 on secure or ttyu0 "/usr/libexec/getty std.9600" vt100 onifconsole secure For more recent relesase where init(1) understand onifconsole Probably there are some more things to do, like getting rtty and ssh to be silent on login, etc.... But these are the essentials. Rinse and repeat steps 2, 4 and 6 to create a new access. After which you net to restart the server to get it to learn a new device. And even though I'm a CLI junky .... Next step would to see if we can use all kinds of java(script) sshlibs to connect, so you can embed this in a management webconsole. Enjoy, --WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54C13D2D.40609>