[LispM] Additional notes on VLM

[Dan Lentz]

I've been having some fun exploring Genera using the VLM lately; I thought
I'd throw a couple of notes out here because I've found that it's possible
to have a really good "lisp machine experience" in 2016 and I think it's a
really fun platform to hack on.  I apologize that these are nothing more
than notes are in a very rough form.  but I hope worth passing along and
I'm happy to answer any questions or clarify if there is interest.

- I think the VMware / virtual box approach is sufficient to do an install
and look around, but my experience is that this is unlikely to be a very
inspiring platform to see it from.   There are really significant
performance issues and very likely some compatibility glitches as well --
some of the integrated "demo" programs fail or run excruciatingly slow.

- I've been really happy running this on an Amazon t2.medium instance (4g,
2x Xeon cores).  Dual processor is nice because while one is tied up
running the (generally cpu bound) genera interpreter, the other is free to
service system services such as nfs, etc.  running genera "on the metal" is
actually really snappy.  The graphics demos are extremely fluid, much
faster than apparently any actual lisp machine, since some of them fly by
before you can make them out! :). I'm sure linode or some other KVM
virtualization host of your choice would work just as well.

- to have a useful configuration that runs "on the metal" and not using
software virtualization such as VMware, you will need to be able to "Save
World".  Out of the box, the Linux genera VLM has an XLIB incompatibility
that prevents one from doing this.  There is actually a fix for this.  I'm
not the author (or the "figure outer") so I'm not sure it's my place to
make the information public, but with luck maybe someone can be persuaded
to take the author out for a beer and share this knowledge! :).  A
persistent world allows you, for example, to retain the state of network
hosts or the services for statice DBFS filesystems you've defined.

- Ubuntu 14.04 LTS works really well.

- xinetd will let you configure the supporting network services on the
Linux host with "tcp wrapper" access control, limited to the address of
your VLM (10.0.0.2).  This is important, as these are not ports you want
open to the world.  In addition to using xinetd, you will probably also
want to install the "rsh-server" package and make the rsh, rexec, rlogin
services available to the VLM secured in this way.  This gives the lisp
machine the ability to Execute Commands remotely on the UNIX host.

- pay particular attention to configuring and ensuring access to the NIS
maps.  This process is documented in the existing "how to" pages, however
there are a couple of bumps in the road with the newer Ubuntu.  You will
need to additionally install the package "pam-unix", copy the
sample configuration file from /usr/share/pam-configs/unix to
/etc/pam.d/unix.  Then, edit that file, commenting out the "sha512" where
it occurs (twice).  Additionally, comment out "sha512" in
/etc/pam.d/common-password.  I'm not absolutely sure it's necessary but it
doesn't hurt.   After you finish these steps, you will need to run
pam-auth-update to register the changes.

-  although the prior step will enable the modern Ubuntu to accept UNIX
crypt passwords, I'm not exactly sure how to get the included "passwd"
program to _generate_ such a thing.  I didn't spend much time on this,
since I had access to an older UNIX box and I was able to simply paste the
password into the appropriate user's /etc/passwd entry.  As a quick sanity
check, this should be a short string of characters.  If you see the user
has an entry that just shows "x" for password, this means you still have
shadowed passwords (run pwunconv, grpunconv).  If it is long (continues to
the next line) then it is not a "crypt" password .

- getting a working X desktop on a hosted server:  install "ubuntu-desktop"
package and vnc4server.  If you want a more full featured desktop,
xfce4-session seems to work well;  gnome has problems with the lack of
accelerated graphics hardware.  Whatever your preference, you can configure
an X server display owned by a UNIX user account by editing
$HOME/.vnc/xstartup to include the appropriate initialization of the X
session.  This is also a very good place to start the genera binary as
well.

- using a VNC X server running locally on the host allows you to connect
and disconnect from a long-running remote instance with a a VNC client.
This works well (as opposed to using a $DISPLAY variable to do X remotely,
which just by its nature, is more problematic).

- A good VNC client will allow you to remap keys from the client side.
This may, in fact, be quite a lot easier than trying to deal too
extensively with xmodmap.

- there is a crontab token "@reboot" that is a very convenient hook to
start the VNC X server (and genera environment) as an ordinary user account
on system startup.   So, if you include a line like "@reboot vncserver
-geometry 1600x1200" and you have that users xstartup configured as
described above, you will have a lisp machine that starts up automatically
on reboot.

- vncserver allows you to create multiple display instances, each it's own
VNC port.  They can have arbitrary desktop sizes, and you can project
multiple genera desktops from the same running instance.  You can use this
to support login from multiple devices, multiple physical displays, or
various desktop resolution.  There is no problem supporting a couple of
thunderbolt displays' worth of desktop.  See the "Start X Screen :Display"
command and keyword option.  You will likely need to authorize connections
on the new display with "xhost + 10.0.0.2"

- to get a pretty display, you will want to compile the fonts and install
on the X client, which, in this case with VNC, means the Linux host.  The
fonts are distributed in #P"sys:site;" and the installation covered in the
Genera install docs.  But a couple of notes:  modern servers use a PCF
format (not snf) and the compiler command is probably named "bdftopcf".

- in order to get CL-HTTP up and running:  Edit the Namespace and add the
Internet domain name and root domain server address.   Edit the VLM host
object and add "HTTP TCP HTTP" service triple. Then execute
(sys:enable-services).  Now you can export URLs and start playing with
the CL-HTTP server.

Again, I apologize for the brevity and probable incoherence of these
notes.  I really want to thank everyone involved in making OpenGenera
available to the public.  It's really an interesting and tactile
environment to explore.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </archives/lispm/attachments/20160409/b2dae74e/attachment.html>