Add Your Own Custom Log File to RSYSLOG Logging to /var/log/messages in 3 Steps (CentOS 7)

Step 1

Edit /etc/rsyslog.conf and add $ModLoad imfile to the MODULES section at the top. The resultant modules section should look like this:

#### MODULES ####

# The imjournal module bellow is now used as a message source instead of imuxsock.
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imjournal # provides access to the systemd journal
$ModLoad imfile
#$ModLoad imklog # reads kernel messages (the same are read from journald)
#$ModLoad immark  # provides --MARK-- message capability



Step 2

Create one configuration file in /etc/rsyslog.d for each custom log file you wish to be included in /var/log/messages. Each configuration file should look like this example from my addition of a shoutcast server log file to rsyslog. Obviously edit the file for your own log file.

# --
# /etc/rsyslog.d/sc_serv.conf
# --
$InputFileName /home/radio/bin/logs/sc_serv.log
$InputFileTag sc_serv
$InputFileStateFile sc_serv-file1
$InputFileSeverity info
$InputFileFacility local7
$InputRunFileMonitor
$InputFilePersistStateInterval 500

Step 3

Restart rsyslogd and test

# systemctl restart rsyslogd

# tail -f /var/log/messages

and you should see log lines from your external log file included in the /var/log/messages syslog file.

Secure Remote Logging to Central Log Server Using RSYSLOG on CentOS 6 / CentOS 7 and stunnel

Secure Remote Logging to Central Log Server via Encrypted stunnel Tunneling

Here is how I set up a secure remote rsyslog server on my VPS that accepts and records system logs from various clients on my home and cloud hobbyist networks.

The remote syslog server runs rsyslog daemon on CentOS 7, and the clients are a mixture of numerous operating systems, including Linux CentOS 6 and CentOS7, Windows, BSD, Routers running DD-WRT etc.

The basic idea is that local rsyslog daemons forward logs to stunnel also running locally. stunnel then forwards them to the remote server using a secure tunnel over TCP/IP. A peer stunnel daemon instance running on the remote server then forwards the incoming logs to the local rsyslog daemon on the remote server.

Server setup (CentOS 7)

In my setup, the server-side stunnel listens on port 65515 and forwards logs to rsyslog which listens on port 65514.

Install stunnel and add a script to start and stop it using the systemctl facility.

# yum install openssl stunnel

Add a file /usr/lib/systemd/system/stunnel.service with the following contents:

[Unit]
Description=SSL tunnel for network daemons
After=syslog.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/stunnel /etc/stunnel/stunnel.conf
ExecStop=/bin/kill -9 $(pgrep stunnel)

[Install]
WantedBy=multi-user.target




Add a file /etc/stunnel/stunnel.conf containing the following:

client = no
fips = no
cert = /etc/stunnel/stunnel.pem
[rsyslog]
accept = 65515
connect = 127.0.0.1:65514

Generate the server's certificate. The following will generate a certificate with an expiry of 100 years. Important: enter the fully qualified host-name of the server for the question "Common Name". Answer the questions the best you can or want to. I like to put in meaningful information for all the questions, including my real email address for the last question.

# cd /etc/stunnel

# openssl req -new -x509 -days 36500 -nodes -out stunnel.pem -keyout stunnel.pem

Generating a 2048 bit RSA private key

.............................+++

.+++

writing new private key to 'stunnel.pem'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [XX]:US

State or Province Name (full name) []:MD

Locality Name (eg, city) [Default City]:Germantown

Organization Name (eg, company) [Default Company Ltd]:Supratim Sanyal's Hobbyist Lab

Organizational Unit Name (eg, section) []:Basement Server

Common Name (eg, your name or your server's hostname) []:sanyalnet-cloud-vps2.freeddns.org

Email Address []: youremailhere@emaildomain.com

You should now see the newly generated certificate in the /etc/stunnel directory:

# ls -lrt

total 8

-rw------- 1 root root  105 Oct 26 20:54 stunnel.conf

-rw------- 1 root root 3278 Oct 26 23:04 stunnel.pem

Now configure the rsyslog system log daemon on this remote syslog server to listen to logs at the port indicated by connect line in the stunnel config file which you created above. Edit the file /etc/rsyslog.conf and look for, uncomment and adjust the following two lines (they were at around line 18 on my installation of CentOS 7):

# Provides TCP syslog reception

$ModLoad imtcp

$InputTCPServerRun 65514

The last configuration step is to open up the stunnel listening port to the external internet on the firewall. We also need rules to allow all traffic on the localhost (127.0.0.1) interface "lo" so that network traffic between stunnel and rsyslog flows internally over localhost. We then add firewall reject rules to reject everything else.

# iptables -A INPUT -i lo -j ACCEPT

# iptables -A OUTPUT -o lo -j ACCEPT

# iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 65515 -j ACCEPT

# iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited

# iptables -A FORWARD -j REJECT --reject-with icmp-host-prohibited

Of course, to make these rules permanent, I recommend you edit and add them to the default iptables startup rules file /etc/sysconfig/iptables, adjusting for any existing other rules you may already have. In particular, for security, make sure you do not open up the local rsyslog listening port 65514 on your firewall; this is important since rsyslog binds to all interfaces and there is no easy way to force it to bind to the localhost (127.0.0.1) interface.

We are done configuring the rsyslog server, and can now enable and start up stunnel, and restart rsyslog, for the changes to take effect.

# systemctl enable stunnel

Created symlink from /etc/systemd/system/multi-user.target.wants/stunnel.service to /usr/lib/systemd/system/stunnel.service.
# systemctl start stunnel
# systemctl restart rsyslog

Perform some basic validations to check if everything is working as expected. Verify the stunnel daemon is up and running:

# systemctl status stunnel

● stunnel.service - SSL tunnel for network daemons

   Loaded: loaded (/usr/lib/systemd/system/stunnel.service; enabled; vendor preset: disabled)

   Active: active (exited) since Wed 2016-10-26 22:57:49 UTC; 18min ago

 Main PID: 675 (code=exited, status=0/SUCCESS)

   CGroup: /system.slice/stunnel.service

           ├─696 /bin/stunnel /etc/stunnel/stunnel.conf

           ├─697 /bin/stunnel /etc/stunnel/stunnel.conf

           ├─698 /bin/stunnel /etc/stunnel/stunnel.conf

           ├─699 /bin/stunnel /etc/stunnel/stunnel.conf

           ├─700 /bin/stunnel /etc/stunnel/stunnel.conf

           └─701 /bin/stunnel /etc/stunnel/stunnel.conf

Oct 26 22:57:48 sanyalnet-cloud-vps2.freeddns.org systemd[1]: Starting SSL tunnel for network daemons...

Oct 26 22:57:49 sanyalnet-cloud-vps2.freeddns.org systemd[1]: Started SSL tunnel for network daemons.

Oct 26 23:16:00 sanyalnet-cloud-vps2.freeddns.org systemd[1]: Started SSL tunnel for network daemons.

Verify rsyslog is working with the changed configuration:

# systemctl status rsyslog

● rsyslog.service - System Logging Service

   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)

   Active: active (running) since Wed 2016-10-26 23:16:04 UTC; 2min 6s ago

 Main PID: 2756 (rsyslogd)

   CGroup: /system.slice/rsyslog.service

           └─2756 /usr/sbin/rsyslogd -n

Oct 26 23:16:04 sanyalnet-cloud-vps2.freeddns.org systemd[1]: Starting System Logging Service...

Oct 26 23:16:04 sanyalnet-cloud-vps2.freeddns.org systemd[1]: Started System Logging Service.

Verify that stunnel's startup activity is logged in the /var/log/secure logfile:

[root@sanyalnet-cloud-vps2 ~]# cat /var/log/secure

...
...
...

Oct 26 22:57:49 sanyalnet-cloud-vps2 stunnel: LOG5[675:140205220452416]: stunnel 4.56 on x86_64-redhat-linux-gnu platform

Oct 26 22:57:49 sanyalnet-cloud-vps2 stunnel: LOG5[675:140205220452416]: Compiled/running with OpenSSL 1.0.1e-fips 11 Feb 2013

Oct 26 22:57:49 sanyalnet-cloud-vps2 stunnel: LOG5[675:140205220452416]: Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP

Oct 26 22:57:49 sanyalnet-cloud-vps2 stunnel: LOG5[675:140205220452416]: Reading configuration from file /etc/stunnel/stunnel.conf

Oct 26 22:57:49 sanyalnet-cloud-vps2 stunnel: LOG5[675:140205220452416]: FIPS mode is disabled

Oct 26 22:57:49 sanyalnet-cloud-vps2 stunnel: LOG5[675:140205220452416]: Configuration successful

Verify the correct server network ports are open:

# netstat -pan | egrep "stunnel|rsyslog"

tcp        0      0 0.0.0.0:65514           0.0.0.0:*               LISTEN      2756/rsyslogd

tcp        0      0 0.0.0.0:65515           0.0.0.0:*               LISTEN      701/stunnel

tcp        0      0 127.0.0.1:65514         127.0.0.1:42938         ESTABLISHED 2756/rsyslogd

tcp        0      0 127.0.0.1:42938         127.0.0.1:65514         ESTABLISHED 701/stunnel

...

...

Client setup (CentOS 6)

In this example client running CentOS 6, we will configure the rsyslog daemon to forward all logs to the remote syslog server created above over a secure encrypted network link implemented by stunnel.

Install stunnel and add a script to start and stop it using the CentOS 6 service management facility.

# yum install openssl stunnel

Add a file /etc/init.d/stunnel with the following contents:

#!/bin/sh

#

# $Id: stunnel.init.in,v 1.0 2016/10/26 21:11:58 mschimek Exp $

# Startup script for the stunnel daemon, RedHat style.

# See http://supratim-sanyal.blogspot.com/2016/10/secure-remote-logging-to-central-log.html

#

# chkconfig: - 90 10

# description: stunnel daemon to establish encrypted secure network channel between two hosts

#

# Supratim Sanyal <supratim at riseup dot net>

#

. /etc/init.d/functions

prefix=/usr

exec_prefix=/usr

[ -x /usr/bin/stunnel ]  || exit 1

RETVAL=0

start(){

        echo -n $"Starting stunnel secure sockets tunnel daemon: "

        daemon stunnel

        RETVAL=$?

        echo

        touch /var/lock/subsys/stunnel

        return $RETVAL

}

stop(){

        echo -n $"Stopping stunnel secure sockets tunnel daemon: "

        killproc stunnel

        echo

        RETVAL=$?

        rm -f /var/lock/subsys/stunnel

        return $RETVAL

}

restart(){

        stop

        start

}

case "$1" in

        start)

                start

                ;;

        stop)

                stop

                ;;

        restart)

                restart

                ;;

        status)

                status stunnel

                ;;

        condrestart)

                [ -e /var/lock/subsys/stunnel ] && restart

                ;;

        *)

                echo $"Usage: $0 {start|stop|status|restart|condrestart}"

                RETVAL=1

esac

exit $RETVAL

Add the stunnel init script to the list of chkconfig managed init scripts, make it executable, and enable it, but do not start it yet.

# chmod +x /etc/init.d/stunnel
# chkconfig --add stunnel

# chkconfig stunnel on

# chkconfig --list stunnel

stunnel         0:off   1:off   2:on    3:on    4:on    5:on    6:off

# service stunnel status

stunnel is stopped

Add a file /etc/stunnel/stunnel.conf with the following contents, replacing <rsyslog-remote-server-hostname> with your actual fully qualified network-reachable remote syslog server hostname (or IP address):

client = yes

fips = no

[rsyslogd]

accept = 127.0.0.1:65514

connect = <rsyslog-remote-server-hostname>:65515

Note: you do not need a certificate on stunnel client side.

Edit the file /etc/rsyslog.conf and add the following at the bottom. If, however, you already have an existing forwarding rule for some other syslog server, insert the following lines below the existing $WorkDirectory but above the existing forwarding rule-sets.

$WorkDirectory /var/log # where to place spool files

# begin forwarding rule to stunnel port for passing on to VPS (see /etc/stunnel/stunnel.conf)

$ActionQueueType LinkedList

$ActionQueueFileName logs-spooled-4-VPS

$ActionResumeRetryCount -1

$ActionQueueSaveOnShutdown on

*.* @@127.0.0.1:65514

# ### end of the forwarding rule ###

Configuration is complete at this point. Start / restart the necessary daemons.

# service restart stunnel

# service restart rsyslog

Client setup (CentOS 7)

On a client running CentOS 7, we will configure the rsyslog daemon to forward all logs to the remote syslog server created above over a secure encrypted network link implemented by stunnel.

Install stunnel and add a script to start and stop it using the systemctl facility.

# yum install openssl stunnel

Add a file /usr/lib/systemd/system/stunnel.service with the following contents:

[Unit]
Description=SSL tunnel for network daemons
After=syslog.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/stunnel /etc/stunnel/stunnel.conf
ExecStop=/bin/kill -9 $(pgrep stunnel)

[Install]
WantedBy=multi-user.target

Enable the stunnel daemon (but do not start it yet):

# systemctl enable stunnel

Created symlink from /etc/systemd/system/multi-user.target.wants/stunnel.service to /usr/lib/systemd/system/stunnel.service.

Add a file /etc/stunnel/stunnel.conf with the following contents, replacing <rsyslog-remote-server-hostname> with your actual fully qualified network-reachable remote syslog server hostname (or IP address):

client = yes

fips = no

[rsyslogd]

accept = 127.0.0.1:65514

connect = <rsyslog-remote-server-hostname>:65515

Note: you do not need a certificate on stunnel client side.

Edit the file /etc/rsyslog.conf and add the following at the bottom. If, however, you already have an existing forwarding rule for some other syslog server, insert the following lines below the existing $WorkDirectory but above the existing forwarding rule-sets.

$WorkDirectory /var/log # where to place spool files

# begin forwarding rule to stunnel port for passing on to VPS (see /etc/stunnel/stunnel.conf)

$ActionQueueType LinkedList

$ActionQueueFileName logs-spooled-4-VPS

$ActionResumeRetryCount -1

$ActionQueueSaveOnShutdown on

*.* @@127.0.0.1:65514

# ### end of the forwarding rule ###

Configuration is complete at this point. Start / restart the necessary daemons.

# systemctl start stunnel

# systemctl restart rsyslog

Testing

Perform some basic validations to check if everything on the rsyslog and stunnel daemons on the client side are working as expected. Verify the stunnel and rsyslog daemons are up and running:

# service stunnel status

stunnel (pid  13781) is running...

# service rsyslog status

rsyslogd (pid  11285) is running...

Verify stunnel has connected at both the rsyslog port and peer stunnel on the remote server's port:

# cat /var/log/secure

Oct 26 20:57:53 dormarth stunnel: LOG5[10866:139787722659776]: stunnel 4.29 on x86_64-redhat-linux-gnu with OpenSSL 1.0.1e-fips 11 Feb 2013

Oct 26 20:57:53 dormarth stunnel: LOG5[10866:139787722659776]: Threading:PTHREAD SSL:ENGINE,FIPS Sockets:POLL,IPv6 Auth:LIBWRAP

Oct 26 20:57:53 dormarth stunnel: LOG5[10866:139787722659776]: 500 clients allowed

Oct 26 20:58:00 dormarth stunnel: LOG5[10872:139787722655488]: rsyslogd accepted connection from 127.0.0.1:44734

Oct 26 20:58:00 dormarth stunnel: LOG5[10872:139787722655488]: connect_blocking: connected 64.137.228.122:65515

Oct 26 20:58:00 dormarth stunnel: LOG5[10872:139787722655488]: rsyslogd connected remote server from 10.42.2.2:46658

Verify the network ports that you expecting are indeed in use:

# netstat -pan | egrep "rsyslog|stunnel"

tcp        0      0 127.0.0.1:65514             0.0.0.0:*                   LISTEN      13781/stunnel

tcp        0      0 127.0.0.1:49450             127.0.0.1:65514             ESTABLISHED 11285/rsyslogd

tcp        0      1 10.42.2.2:58520             64.137.228.85:65515         SYN_SENT    13781/stunnel

tcp      499      0 127.0.0.1:65514             127.0.0.1:49450             ESTABLISHED 13781/stunnel

Finally, send something to local logger and verify you can see it on the remote server. On the server:

# tail -f /var/log/messages

On the client host:

# logger "`date` tunnel test"

and verify on the server you see the "<date> tunnel test" line in the remote syslog file:

Oct 27 02:35:08 dormarth rumtuk: Thu Oct 27 02:35:08 UTC 2016 tunnel test

If you have the wireshark package installed, you may also want to run tshark on the stunnel port to verify the messages are indeed going across encrypted. For example, on the server, here is the traffic on port 65515 when the same logger command as above is repeated on the client:

# tshark -i ens33 | grep 65515

Running as user "root" and group "root". This could be dangerous.

Capturing on 'ens33'

80  64 5.467663041 108.31.178.247 -> 64.137.248.212 TCP 161 fjdmimgr > 65515 [PSH, ACK] Seq=1 Ack=1 Win=160 Len=107

 65 5.467829924 64.137.248.212 -> 108.31.178.247 TCP 54 65515 > fjdmimgr [ACK] Seq=1 Ack=108 Win=497 Len=0

 69 6.097558428 108.31.178.247 -> 64.137.248.212 TCP 161 fjdmimgr > 65515 [PSH, ACK] Seq=108 Ack=1 Win=160 Len=107

 70 6.097749638 64.137.248.212 -> 108.31.178.247 TCP 54 65515 > fjdmimgr [ACK] Seq=1 Ack=215 Win=497 Len=0

199 190 19.123101437 108.31.178.247 -> 64.137.248.212 TCP 157 fjdmimgr > 65515 [PSH, ACK] Seq=215 Ack=1 Win=160 Len=103

191 19.123287145 64.137.248.212 -> 108.31.178.247 TCP 54 65515 > fjdmimgr [ACK] Seq=1 Ack=318 Win=497 Len=0

405

How to Build Your Own Digital DEC MicroVAX 3900 Running OpenVMS VAX VMS Operating System: SIMH on CentOS 7 Running OpenVMS/VAX 7.3

This is a recap of how I got myself a beautiful MicroVAX 3900 running OpenVMS 7.3 in an emulated SIMH environment on CentOS 7 Linux, connected over DECNET to the global HECNET (a Hobbyist DECNET), and over TCP/IP to the Internet.

CHAPTER 1: BUILDING TOOLS AND TEST DRIVING SIMH

In this chapter, we will build the tools we need and test drive SIMH by bringing up a OpenVMS/VAX 7.1 MicroVAX 3900 system, purely as a walk-through exercise. We will discard this installation for the real OpenVMS/VAX 7.3 in the following chapters.

You should already have a complete gcc/make compile-build-link environment installed. In addition, install the following packages:

# yum install libpcap-devel bridge-utils p7zip net-tools screen openvpn wireshark tcpdump iptraf SDL SDL-devel wget

-----
Note: On Debian-based Raspbian for Raspberry Pi (this or a close variation should also work for recent MX Linux,  Ubuntu and derived systems, like Linux Mint):

# apt-get install libpcap-dev bridge-utils p7zip net-tools screen reptyr openvpn wireshark tshark tcpdump iptraf libsdl2-2.0 libsdl2-dev libsdl2-ttf-dev wget binutils-doc make autoconf automake libtool flex bison gdb uml-utilities stunnel4 vde2 libvdeplug2 libvde-dev vde2-cryptcab libvdeplug-dev tree ipcalc iotop xpra dos2unix gawk coreutils
-----

I could not find tunctl for CentOS that we should have in our toolset, so I built it from the source.

# yum install docbook-utils
# mkdir tunctl
# cd tunctl
# wget -O tunctl-1.5.tar.gz 'http://downloads.sourceforge.net/project/tunctl/tunctl/1.5/tunctl-1.5.tar.gz?r=https%3A%2F%2Fsourceforge.net%2Fprojects%2Ftunctl%2Ffiles%2F&ts=1475117052&use_mirror=heanet'
# tar xvzf tunctl-1.5.tar.gz
# cd tunctl-1.5
# make
# make install


Create a user named openvms to run your VAXServer. Set a secure password. Add the user to the wheel group so that sudo is available for the user.

# useradd openvms
# passwd openvms
# usermod -aG wheel openvms

Then logout of root and login to the openvms account you just created. We will build the VAXServer using this user all the way until the time we need special root privileges again for networking at a privileged port.

Find, download and extract the latest version of SIMH. SIMH is being actively developed and the latest version is always available at github. The most current release is available as a zip file download.

$ mkdir simh
$ cd simh
$ wget https://github.com/simh/simh/archive/master.zip
$ unzip master.zip
$ cd simh-master
$ pwd
/home/openvms/simh/simh-master

Now we are ready to build the Vaxen. Build with networking enabled, TUN/TAP TAP device support and large disk support (see here for explanations of the command line parameters to make):

$ make USE_READER_THREAD=1 USE_TAP_NETWORK=1 USE_INT64=1 vax vax780 pdp11

If everything worked, you should see something like this and the build was successful. Note that the build log below is from my Ubuntu 14 server and it includes the VDE (virtual distributed ethernet) as well tun/tap support because the corresponding libraries were installed. 

We now have a MicroVAX 3900 (the "vax" and "microvax3900" binaries are identical copies of the same simulator created by the make script), AND a VAX-11/780!

$ ls -l BIN
total 4832
-rwxrwxr-x 1 openvms openvms 1595295 Oct  9 02:03 microvax3900
-rwxrwxr-x 1 openvms openvms 1595295 Oct  9 02:03 vax
-rwxrwxr-x 1 openvms openvms 1753059 Oct  9 02:04 vax780

If you are having difficulties building the SIMH VAX binaries, download a snapshot of my simh directory from google drive.

I will use the "vax" binary simulator for the MicroVAX 3900 for the rest of this tutorial. Perhaps the procedure on the VAX 11/780 is similar; I do not know yet.

Create a directory tree under your login directory to run your Vax in and copy over the binaries.

$ cd
$ mkdir vax
$ cd vax
$ mkdir bin
$ mkdir data
$ cd bin
$ pwd
/home/openvms/vax/bin
$ cp ~/simh/simh-master/BIN/* .
$ ls -l
...
-rwxrwxr-x 1 openvms openvms 1595295 Oct  9 02:13 microvax3900
-rwxrwxr-x 1 openvms openvms 1595295 Oct  9 02:13 vax
-rwxrwxr-x 1 openvms openvms 1753059 Oct  9 02:13 vax780
...

Copy the processor boot ROM that comes with SIMH to the data directory:

$ cd ../data

$ cp ~/simh/VAX/ka655x.bin .

At this point, we need a OpenVMS installation CD image to test our installation. To do a quick test, for now grab and un-compress the OpenVMS VAX 7.1 Operating System ISO from vaxhaven.com CD image archive. I have no idea of legality of the the distribution - it showed up on a simple google search for OpenVMS VAX ISO.

$ wget http://vaxhaven.com/cd-image/AG-QSBWB-BE.iso.zip
$ unzip AG-QSBWB-BE.iso.zip
$ ls -l AG-QSBWB-BE.ISO
-rw-rw-r-- 1 openvms openvms 410521600 Feb  6  2013 AG-QSBWB-BE.ISO

Go back to the bin directory and create a simulator initialization file vax.ini with the following contents:

Now we fire up the MicroVAX 3900 with the drives and the OpenVMS Installation CD ROM attached to it.

$ sudo ./vax

Ignore the following network card related error for now; we will configure the network card later.



Eth: Must specify actual tap device name (i.e. tap:tap0)
./vax.ini> attach xq eth0
File open error

You should see this below it.

KA655-B V5.3, VMB 2.7

Performing normal system tests.

40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..

24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09..

08..07..06..05..04..03..

Tests completed.

>>>

Type in 

show dev

to see the devices attached:

>>>show dev

UQSSP Disk Controller 0 (772150)

-DUA0 (RA92)

-DUA1 (RA92)

-DUA2 (RA92)

-DUA3 (RRD40)

UQSSP Tape Controller 0 (774500)

-MUA0 (TK50)

-MUA1 (TK50)

-MUA2 (TK50)

-MUA3 (TK50)

Ethernet Adapter 0 (774440)

-XQA0 (08-00-2B-AA-BB-CC)

>>>

Boot from the CD ROM by typing in "boot dua3":

>>>boot dua3

(BOOT/R5:0 DUA3

  2..

-DUA3

  1..0..

%SYSBOOT-I-SYSBOOT Mapping the SYSDUMP.DMP on the System Disk

%SYSBOOT-W-SYSBOOT Can not map SYSDUMP.DMP on the System Disk

%SYSBOOT-W-SYSBOOT Can not map PAGEFILE.SYS on the System Disk

   OpenVMS (TM) VAX Version X6NO Major version id = 1 Minor version id = 0

PLEASE ENTER DATE AND TIME (DD-MMM-YYYY  HH:MM)  29-SEP-2016 01:17

Configuring devices . . .

Now configuring HSC, RF, and MSCP-served devices . . .

Please check the names of the devices which have been configured,

to make sure that ALL remote devices which you intend to use have

been configured.

If any device does not show up, please take action now to make it

available.

Available device  DUA0:                            device type RA92

Available device  DUA1:                            device type RA92

Available device  DUA2:                            device type RA92

Available device  DUA3:                            device type RRD40

Available device  DYA0:                            device type RX02

Available device  DYA1:                            device type RX02

Available device  MUA0:                            device type TK50

Available device  MUA1:                            device type TK50

Available device  MUA2:                            device type TK50

Available device  MUA3:                            device type TK50

Enter "YES" when all needed devices are available: yes

%BACKUP-I-IDENT, Stand-alone BACKUP V7.1; the date is 29-SEP-2016 01:19:04.12

$ 

Go ahead and install OpenVMS 7.1 just to test everything configured so far works, before we go to the next phase - obtaining OpenVMS Hobbyist Program membership and an official OpenVMS 7.3 operating system distribution along with numerous layered products for no cost licenses for hobbyists.

$ BACKUP/IMAGE/VERIFY DUA3:VMS071.B/SAVE_SET DUA0:

%BACKUP-I-STARTVERIFY, starting verification pass

%BACKUP-I-PROCDONE, operation completed.  Processing finished at 29-SEP-2016 01:45:21.10

If you do not want to perform another standalone BACKUP operation,

use the console to halt the system.

If you do want to perform another standalone BACKUP operation,

ensure the standalone application volume is online and ready.

Enter "YES" to continue: NO

Press Ctrl-E to get the SIMH prompt, then type in exit.

Now run ./vax again and boot from the first hard disk (dua0) instead of the CD-ROM (dua3).

sudo ./vax

VAX simulator V3.9-0

NVR: buffering file in memory

RQ: unit is read only

Eth: Must specify actual tap device name (i.e. tap:tap0)

./vax.ini> attach xq eth0

File open error

KA655-B V5.3, VMB 2.7

Performing normal system tests.

40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..

24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09..

08..07..06..05..04..03..

Tests completed.

>>>B DUA0:

(BOOT/R5:0 DUA0

  2..

-DUA0

  1..0..

%SYSBOOT-I-SYSBOOT Mapping the SYSDUMP.DMP on the System Disk

%SYSBOOT-W-SYSBOOT Can not map SYSDUMP.DMP on the System Disk

%SYSBOOT-I-SYSBOOT Mapping PAGEFILE.SYS on the System Disk

%SYSBOOT-I-SYSBOOT SAVEDUMP parameter not set to protect the PAGEFILE.SYS

   OpenVMS (TM) VAX Version BI71-6NO Major version id = 1 Minor version id = 0

           OpenVMS VAX V7.1 Installation Procedure

                         Model: VAXserver 3900 Series

                 System device: RA92 - _DUA0:

                   Free Blocks: 2877504

                      CPU type: 10-01

* Please enter the date and time (DD-MMM-YYYY HH:MM)

I have made the complete SIMH MicroVAX 3900 OpenVMS 7.1 installation snapshot available for download from my google drive. The download links are at the bottom of this post.

You can go on to the next step, or play around a bit. Our basic SIMH installation works and tested out well; we will now have to obtain the OpenVMS 7.3 installatation ISO images and licenses from Hewlett Packard Enterprise (HPE), setup an ethernet tap, and connect to DECNET and the Internet.

CHAPTER 2: OpenVMS And Layered Products for Free: Downloads from the Official OpenVMS Hobbyist Program

First, head over to the Connect Worldwide website and obtain a free individual membership. You will need your Connect Worldwide Customer ID for the next step.

Once you have your Connect Worldwide Customer ID, visit the HPE OpenVMS Hobbyist Registration website to sign up as a hobbyist using your Connect Worldwide membership.

A very friendly person from the OpenVMS Customer Lab (openvmscustomerlab at hpe dot com) will get in touch with you over email. You will be given access to a FTP server to grab the Hobbyist KITs including OpenVMS 7.3 operating system and layered products from. You will also be emailed some License PAK files that are super long and will cover everything you will possibly want to play with.

Collect all the stuff from the FTP server and License PAK emails and keep them ready for use.

CHAPTER 3: Creating a TUN/TAP Pseudo Network Device and Bridging to the Host Network Interface

The XQ Network emulator included with SIMH puts the network card into promiscuous mode, grabs all traffic and drops the traffic it does not need. What this means is if you configure your SIMH XQ ethernet card to use your real NIC, you will not be able to see your VAX from the host server.

The popular solution to this, as mentioned in 0readme_ethernet.txt, is to create a TUN/TAP pseudo network interface tap0 for the host to create a TAP device for the simulator and then bridge or route packets between the TAP device and the real network interface. We have already installed the necessary tools at the beginning of chapter one.

We will create a directory and deploy a shell script to set up the bridge and the tap for use by SIMH.

$ cd /home/openvms/vax
$ mkdir tap-setup
$ cd tap-setup
$ vi tap-setup.sh

Insert these lines into the script tap-setup.sh. Adjust according the name of your NIC (ens33 in my case), save and exit:

Make it executable:

$ chmod a+x tap-setup.sh

Start Bridge and Tap at Boot Using Script

We want to set this bridge and tap up every time we reboot. Login as root and edit the file /etc/rc.local and add this line at the bottom so that it is executed at boot time:

/home/openvms/vax/tap-setup/tap-setup.sh > /var/log/tap-setup.log 2>&1

Then reboot your CentOS server and when it comes back, log back in as root. Execute the ip addr command. You should see bridge br0 created bridging your physical NIC (ens33 in my case) having your original IP address, netmask and gateway as well as a tap interface tap0 created along with extra taps for use elsewhere.

# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
    link/ether 00:50:56:95:5a:1f brd ff:ff:ff:ff:ff:ff
3: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN qlen 500
    link/ether 16:e9:ed:25:00:d2 brd ff:ff:ff:ff:ff:ff
4: tap1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN qlen 500
    link/ether 76:b9:e6:ba:00:e2 brd ff:ff:ff:ff:ff:ff
5: tap2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN qlen 500
    link/ether 8e:20:7f:9b:e0:a4 brd ff:ff:ff:ff:ff:ff
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:50:56:95:5a:1f brd ff:ff:ff:ff:ff:ff
    inet 64.137.182.230/24 brd 64.137.182.255 scope global br0
       valid_lft forever preferred_lft forever

We are now ready to install our final OpenVMS VAX 7.3 Operating System on the SIMH MicroVAX 3900. Logout from the root account and log back in to the openvms account.

Verify the TUN and BRIDGE Kernel Modules are now loaded

# lsmod | egrep "tun|bridge"
bridge                119601  0
stp                    12976  1 bridge
llc                    14552  2 stp,bridge
tun                    27141  3

Verify there is traffic on the bridge. Press Ctrl-C to exit from tshark.

# tshark -i br0

Running as user "root" and group "root". This could be dangerous.

Capturing on 'br0'

  1 0.000000000 108.31.82.24 -> 64.137.182.230 TCP 60 42708 > ssh [ACK] Seq=1 Ack=1 Win=251 Len=0

  2 0.161652786 Cisco_af:61:f5 -> PVST+        STP 64 RST. Root = 32768/482/00:05:73:af:61:fc  Cost = 0  Port = 0x8106

  3 0.446823209 64.137.182.109 -> 64.137.182.255 NBNS 92 Name query NB WPAD<00>

  4 0.492364006 Vmware_95:44:58 -> Broadcast    ARP 60 Who has 64.137.182.1?  Tell 64.137.182.148

  5 0.501408607 64.137.182.230 -> 108.31.82.24 SSH 198 Encrypted response packet len=144

  6 0.572193861 64.137.182.230 -> 108.31.82.24 SSH 262 Encrypted response packet len=208

  7 0.607704813 108.31.82.24 -> 64.137.182.230 TCP 60 42708 > ssh [ACK] Seq=1 Ack=353 Win=256 Len=0

...
...

^C

Chapter 4: Install and Configure OpenVMS VAX 7.3

Once you have collected all the goodies from the Hobbyist program (which you did in Chapter 2), go ahead and install OpenVMS/VAX 7.3 using the VAXVMS 073 OS ISO disk included in the Hobbyist KIT. This comes in the file VAXVMS 073 OS ISO.zip that you have FTPd from a special Hobbyist-only FTP area access to which will be provided by the OpenVMS Customer Lab under the OpenVMS Hobbyist program.

Unzip the VAXVMS 073 OS ISO.zip file and put the extracted VAXVMS 073 OS ISO.zip file under the ~/vax/data directory. Then adjust the vax.ini (template here) initialization file under ~/vax/bin file to mount the ISO on the CD ROM drive:

attach -r rq3 ../data/OpenVMS VAX 073 OS.iso

As before, start up the Vax using

$ pwd
/home/openvms/vax/bin
$ sudo ./vax

and boot from the CD ROM

>>>BOOT DUA3

Enter the date and restore the OpenVMS 7.3 save set to DUA0:

(BOOT/R5:0 DUA3
  2..
-DUA3
  1..0..
%SYSBOOT-I-SYSBOOT Mapping the SYSDUMP.DMP on the System Disk
%SYSBOOT-W-SYSBOOT Can not map SYSDUMP.DMP on the System Disk
%SYSBOOT-W-SYSBOOT Can not map PAGEFILE.SYS on the System Disk
   OpenVMS (TM) VAX Version X7G7 Major version id = 1 Minor version id = 0
%WBM-I-WBMINFO Write Bitmap has successfully completed initialization.
PLEASE ENTER DATE AND TIME (DD-MMM-YYYY  HH:MM)  29-SEP-2016 19:11

Configuring devices . . .
Now configuring HSC, RF, and MSCP-served devices . . .

Please check the names of the devices which have been configured,
to make sure that ALL remote devices which you intend to use have
been configured.

If any device does not show up, please take action now to make it
available.


Available device  DUA0:                            device type RA92
Available device  DUA1:                            device type RA92
Available device  DUA2:                            device type RA92
Available device  DUA3:                            device type RRD40
Available device  DYA0:                            device type RX02
Available device  DYA1:                            device type RX02
Available device  MUA0:                            device type TK50
Available device  MUA1:                            device type TK50
Available device  MUA2:                            device type TK50
Available device  MUA3:                            device type TK50

Enter "YES" when all needed devices are available: YES
%BACKUP-I-IDENT, Stand-alone BACKUP T7.2; the date is 29-SEP-2016 19:13:00.56
$ BACKUP/IMAGE/LOG/VERIFY DUA3:VMS073.B/SAVE_SET DUA0:
%BACKUP-I-STARTVERIFY, starting verification pass
%BACKUP-I-PROCDONE, operation completed.  Processing finished at 29-SEP-2016 19:15:03.19
If you do not want to perform another standalone BACKUP operation,
use the console to halt the system.

Press Ctrl-E to get to the SIMH prompt and type EXIT to exit the emulator.

Now restart the emulator, and boot from the hard disk DUA0.

$ sudo ./vax

and boot from the DUA0 disk:

>>>BOOT DUA0

Continue on and install OpenVMS, along with DECnet Plus and TCP/IP Services for OpenVMS which are also included on the CD image for OpenVMS VMS 7.3. Here is what I saw when I booted the first time from the hard disk DUA0 after restoring the image save set from the CD ROM.

CHAPTER 5: AN IMPROVED VAX.INI

Here is an improved version of vax.ini that lives in the vax/bin directory along with the simh "vax" executable. This version of vax.ini causes the Vax to autoboot and exits the emulator when the Vax shuts down. The first time you run vax using this vax.ini, it will still ask for the boot device, but when you shut the Vax down the first time, it will remember the default boot device (DUA0) for the next time.

CHAPTER 6: CONNECT TO HECNET - THE HOBBYIST DECNET

As mentioned in the HECNET website,  HECnet is a global DECnet that connects different people across the world who play around with different machines that have the DECnet protocol suite. Once you have DECnet Phase IV or DECnet Plus installed on your SIMH VAX, reach out to the contact person (currently Johnny Billquist <bqt at update dot uu dot se>) and ask for a area code and node number. Also download and compile the DECnet to IP bridge that you will need to connect to HECnet.

Login to the openvms account on your SIMH Host server, and:

$ pwd
/home/openvms
$ cd vax
$ mkdir hecnet-bridge

$ cd hecnet-bridge
$ wget http://www.update.uu.se/~bqt/bridge.tar
$ tar xvf bridge.tar
$ make

Now you have the bridge program built. We need a configuration file. We can copy and edit the template Johnny included in the tarball.

$ cp bridge.conf.orig bridge.conf

and edit bridge.conf it o that it looks like mine below:

! This is the bridge configuration file.

!

! Comments start with a '!'. Empty lines are ignored. The file

! is re-read on a SIGHUP.

!

! *************************************************************

!

! The bridge section defines all sources and destinations for

! this bridge program.

!

! Packets will not be accepted from other sources than these,

! and these destinations are used in the different options

! further down.

!

! If a name starts with tilde '~', that host is considered a passive

! host, and no packets will be transmitted to it unless packets are

! received from it. A timeout of 120 sec is used to consider the

! host active.

!

[bridge]

!<name> <ip>:<port>

! or

!<name> <etherdevice>

!

!local tlp0

!local eth0

local tap0

!update tempo.update.uu.se:4711

update psilo.update.uu.se:4711

!

! The DECnet section specify which bridges to send DECnet packets

! that appear on the local ethernet.

!

[decnet]

!<name>

!

local

update

!

! The LAT section specify which bridges to send LAT packets

! that appear on the local ethernet.

!

[lat]

!<name>

!

local

update

Start the bridge up in it's own detached screen:

$ sudo screen -S bridge -m -d /home/openvms/vax/hecnet-bridge/bridge -d /home/openvms/vax/hecnet-bridge -p 4711

Make it persistent across re-boots. Edit the file /etc/rc.local and add a line at the bottom to start the bridge up at boot time:

screen -S bridge -m -d /home/openvms/vax/hecnet-bridge/bridge -d /home/openvms/vax/hecnet-bridge -p 4711

If you use iptables as your firewall, open up UDP port 4711 and restart iptables using systemctl restart iptables. Here is my /etc/sysconfig/iptables:

#/etc/sysconfig/iptables
*filter
:INPUT ACCEPT [341:22721]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [201:20785]
# (Tuklu) Basic Network Exploit Protection from syn flood, nul, christmas and fragmented packets
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j DROP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP
-A INPUT -f -j DROP
# (Tuklu) Accept connections on these ports
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 23 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 110 -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 143 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 465 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 993 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 995 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 4190 -j ACCEPT
# HECnet
-A INPUT -p udp -m udp --dport 4711 -j ACCEPT
# --
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT

If everything works, you should be able to see the public contents on MIM - a real-life and connect over DECnet to the hundreds of hobbyist systems - Vaxen, Alphaservers and PDP series computers - listed in MIM::NODENAMES.TXT (also on the internet here).

DOWNLOADS

Complete OpenVMS 7.1 Installation Snapshot on MicroVAX 3900 SIMH Simulator