On 2015-01-20 18:48, Paul Vixie wrote:


Willem Jan Withagen <mailto:w...@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

_______________________________________________
freebsd-virtualization@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Reply via email to