[Addition March 15th, 2020: I was so excdited about me getting this to run that I forgot about security!. After a good night’s sleep I added a few words about running emsrv as another user than root]

Installation of VA Smalltalk on Linux has become so incredibly nice since version 9.0 all that’s needed is to download the deb (for debian or ubuntu and its forks like Mate) or rpm tar from Instantiations, unpack it (using tar -xvzf) it and run the vainstall with an install option like this:

  • vainstall manager if you want the emsrv and a fresh library
  • vainstall admintools if all you need is emsrv and emadmin
  • vainstall [standalone] for a complete installation of both the development environment and the manager library and admin tools on that machine

The basics are there…

The installation script, however, only installs all you need and creates all links and such, so that you can run emsrv by

/usr/local/VASmalltalk/9.2.1x64/bin/emsrv

…but that might not be enough. We want autorun!

For our needs, we want to have the server start emsrv on boot time without any interaction. So we needed to set emsrv up as a service on ubuntu. And it turns out this is quite easy, but things have changed quite a bit since my last description of doing the same thing on openSuSE a few years ago.

Enter systemd, which is the current system daemon on Ubuntu. This may sound scary, but in fact setting emsrv up as a service on Ubuntu is easy.

All you need to do is add a file named emsrv.service to /etc/systemd/system

[Unit]
Description=The EMSRV Va Smalltalk Library Manager
After=network.target

[Service]
Type=forking
# don't run emsrv as root!
User=emsrvuser
ExecStart=/usr/local/VASmalltalk/9.2.1x64/bin/emsrv

[Install]
WantedBy = multi-user.target

This file defines a new service (called a Unit) in systemd and tells the system that this new unit can only be started after the network is available. Take special note of the Type=forking line in the [Service] section. Without this, emsrv will not be started and will be reported as dead by systemctl status.
Please make sure you also add the Install section, otherwise you’ll get errors on startup.

Of course you can set all kinds of options for emsrv (like log file location, password etc.) by providing startup options in the ExecStart command.

Then there is one last step to perform:

systemctl enable emsrv.service

Almost there

After reboot, emsrv will be running and you cann access your mgr921.dat through emsrv. If you (like us) want the machine to act as a server in you lan, you have to make sure your firewall allows connections to port 4800 (or the port you configure on startup of emsrv). In ubuntu this is easy: ufw allow 4800. You can, of course also add a service name and use it for the firewall. I’ll leave that as an exercise for you.

Are you there?

There are several ways to find out if the emsrv service is running. The first options that come to mind are (h)top and pgrep. But also systemctl will tell you a lot about emsrv:

Security – don’t run emsrv as root

What I just showed makes the emsrv server run as root. This may not be the best of possible ideas for a number of reasons. So the next step will be to create a Linux user with limited rights to run emsrv (most importantly: limit this users access rights to folders on the machine, this user should not need too many rights and almost no access rights other than the path(s) where manager files (libraries) reside).

Remember: if you have an image that connects to this server through envy, you can always open a file browser on the server for reconnecting to a Library, exporting code etc. This way, an attacker can find out about your directory structures and possibly even create/delete files.

systemd has a User= parameter in the emsrv.service file’s [Service] section.