January 15, 2021
Setting up a Linux server to host VxWorks
I am doing this on a Fedora 32 system.
Some aspects of this may be unique to Fedora.
I am doing this in order to boot a MC68040 based VME card,
namely a MVME167 board. This requires that the 167 board has
VxWorks boot proms installed (it does, and this was done long
ago) and that the NVRAM has been configured for VxWorks.
These boards were shipped with battery encapsulated NVRAM chips,
and after all this time, most of the batteries have long since
gone dead. We have replaced these chips with EEPROM devices,
which should be the subject of another set of pages.
This is bulletproof, but inflexible. These chips must be
"burned" in a prom burner, the 167 does not have the circuitry
to support modifying them in circuit. As a result I will go
through some contortions to support the boot setup that is
in these chips.
Serial console
I use a USB to serial adapter along with picocom to
connect to the serial console.
The baud rate should be 9600 and the following command
should do the trick:
picocom -b 9600 /dev/ttyUSB0
NVRAM setup
My board has the following setup:
boot device : ei
processor number : 0
host name : hacksaw
file name : /home/vwuser/mmtcell/vxWorks
inet on ethernet (e) : 128.196.100.14:ffffff00
host inet (h) : 128.196.100.19
user (u) : vwuser
flags (f) : 0x0
target name (tn) : mmtcell
startup script (s) : /home/vwuser/mmtcell/startup.cmd
This requires a definite setup on the server side.
In particular, we dedicate a user "vwuser" to own and
host all the files needed to boot VxWorks.
Also note that fixed IP numbers are used.
No DHCP or even BOOTP on these old machines.
A trick to give our server the required IP
You can ignore this section if you are able to give your
boot server the IP number required by the NVRAM setup.
I put the following command into /etc/rc.d/rc.local.
Since this is Fedora, I use the idiotic "eno1" for my
ethernet device. Most systems will use "eth0".
ip addr add 128.196.100.19/24 brd + dev eno1 label eno1:vxworks
After issuing this command, I see:
ifconfig -a
eno1:vxworks: flags=4163 mtu 1500
inet 128.196.100.19 netmask 255.255.255.0 broadcast 128.196.100.255
ether 90:2b:34:ff:55:ff txqueuelen 1000 (Ethernet)
device interrupt 20 memory 0xf7d00000-f7d20000
Along with adding the above line to rc.local, you will need to add
the IP numbers for the two machines to the /etc/hosts file.
DNS is not part of the game in the isolated system I am working
with.
# The following are to support VxWorks booting
128.196.100.19 hacksaw
128.196.100.14 mmtcell
Installing and starting a rsh server
In general, I set up my server to use rsh to serve the boot images
and startup.cmd script. It is also possible to use ftp, see below.
My system is running Fedora, so to install this and
start the various services I do:
dnf install rsh-server
dnf install rsh
systemctl restart rsh.socket
systemctl restart rlogin.socket
systemctl restart rexec.socket
Note two things. One is that this used to be handled by xinetd and files
within /etc/xinetd.d -- this is no longer the case.
The second is that it seems to be necessary to run all three of this
services for any one of them to work.
It seems to be sort of an all or nothing family
affair that I don't understand.
I install rsh also (the client), just for use in troubleshooting.
For initial testing, I disable my firewall via:
systemctl stop iptables.service
rsh localhost
Doing this should prompt you for your password and then log you in.
Once you are done testing and want to make this a permanent part of
your server whenever it boots up, do:
systemctl enable rsh.socket
systemctl enable rlogin.socket
systemctl enable rexec.socket
Installing and setting up an ftp server
This is simpler than using rsh, but some believe it is less secure.
It is as secure as your passwords would probably be the truth, and
the comparison is fairly moot, both need to be behind tight firewalls
as they are antique protocols.
su
dnf install ftp vsftpd
firewall-cmd --add-service=ftp --permanent
firewall-cmd --reload
systemctl start vsftpd.service
systemctl enable vsftpd.service
You will also need to set up a user and password that matches the boot settings
in your vxworks machines. The "ftp" package is the client, you should use it from some other
machine to verify operation.
Firewall ports
I used to manipulate this using iptables and hand editing files.
Now it is possible and perhaps desireable to use firewalld and firewall-cmd.
You will need to open up TCP port 514, as well as the entire range
of TCP ports 1011-1023 to use rsh. For initial testing, I am just
turning off my firewall altogether via:
systemctl stop iptables.service
This would not be a good idea if your server is on the internet and
not behind some departmental firewall or router.
A user for vxworks (vwuser)
This could be done in any number of ways.
The thinking here is that these rsh family protocols are old
and from days when security was not such an intense concern.
Limiting access from a machine to a single user seems like a good plan.
useradd vwuser
This user does not need a password, and the current linux useradd does not
give one to a user, so it is impossible for this user to login, which is good.
It is all about the .rhosts file. In my case I make /home/vwuser a link to
/u1/vwuser (which is on another partition). All the files there get backed
up, and are owned by a regular user. The user "vwuser" simply needs to read
them, and won't be able to write, modify, or delete files, unless the group
or world permissions allow such a thing, which is hardly likely.
The .rhosts file
As a start, create ~/.rhosts with contents like the following:
localhost vwuser
Do the above with your own name (in your own home directory) when you
are troubleshooting. It is also vital that this has restricted
permissions, like so:
su
cd /home/vwuser
chown vwuser:vwuser .rhosts
chmod 600 .rhosts
After doing this, "rsh localhost date" should work without a password.
You can also do more global things using /etc/hosts.equiv, but I think
this is a BAD idea, as it makes all users trusted between two machines.
I only want the vwuser user to be trusted in order to boot vxworks.
Troubleshooting
Suppose you get this all set up, and then see something like this
on the serial console:
Attaching network interface ei0... done.
Attaching network interface lo0... done.
Loading... Permission denied.
Error loading file: errno = 0x250002.
Can't load boot file!!
A look at the end of /var/log/secure shows:
Jan 24 10:20:40 trona rshd[2045]: pam_rhosts(rsh:auth): denied access to vwuser@mmtcell as vwuser
This is encouraging in a way, it shows that the rsh protocol is at least trying to work and
that packets are moving between the two machines. This problem turned out to be ownership
and permissions on the .rhosts file. It was owned by user tom, but needed to be owned by
user "vwuser".
Success
[VxWorks Boot]: @
boot device : ei
processor number : 0
host name : hacksaw
file name : /home/vwuser/mmtcell/vxWorks
inet on ethernet (e) : 128.196.100.14:ffffff00
host inet (h) : 128.196.100.19
user (u) : vwuser
flags (f) : 0x0
target name (tn) : mmtcell
startup script (s) : /home/vwuser/mmtcell/startup.cmd
Attaching network interface ei0... done.
Attaching network interface lo0... done.
Loading... 406892 + 49488 + 25026
Starting at 0x20000...
Attaching network interface ei0... done.
Attaching network interface lo0... done.
NFS not included.
Loading symbol table from hacksaw:/home/vwuser/mmtcell/vxWorks.sym ...done
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]] ]]]] ]]]]]]]]]] ]] ]]]] (R)
] ]]]]]]]]] ]]]]]] ]]]]]]]] ]] ]]]]
]] ]]]]]]] ]]]]]]]] ]]]]]] ] ]] ]]]]
]]] ]]]]] ] ]]] ] ]]]] ]]] ]]]]]]]]] ]]]] ]] ]]]] ]] ]]]]]
]]]] ]]] ]] ] ]]] ]] ]]]]] ]]]]]] ]] ]]]]]]] ]]]] ]] ]]]]
]]]]] ] ]]]] ]]]]] ]]]]]]]] ]]]] ]] ]]]] ]]]]]]] ]]]]
]]]]]] ]]]]] ]]]]]] ] ]]]]] ]]]] ]] ]]]] ]]]]]]]] ]]]]
]]]]]]] ]]]]] ] ]]]]]] ] ]]] ]]]] ]] ]]]] ]]]] ]]]] ]]]]
]]]]]]]] ]]]]] ]]] ]]]]]]] ] ]]]]]]] ]]]] ]]]] ]]]] ]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]]]] Development System
]]]]]]]]]]]]]]]]]]]]]]]]]]]]
]]]]]]]]]]]]]]]]]]]]]]]]]]] VxWorks version 5.1.1
]]]]]]]]]]]]]]]]]]]]]]]]]] KERNEL: WIND version 2.4
]]]]]]]]]]]]]]]]]]]]]]]]] Copyright Wind River Systems, Inc., 1984-1993
CPU: Motorola MVME167. Processor #0.
Memory Size: 0x1000000. BSP version 1.0.
hacksaw:bash: /home/vwuser/mmtcell/startup.cmd: No such file or directory
Unable to open startup script /home/vwuser/mmtcell/startup.cmd
->
The message about being unable to open the startup script makes sense
because I have not put that file in place yet.
Using vxworks
Once it boots up, you can continue to use the serial console via picocom.
Alternately you can log in using rsh over the network, which is usually
more convenient. To do this, you need to create a vxworks user and
password. You could use the vwuser user, but what I do is to add a line
like the following to the startup.cmd file:
loginUserAdd "tom", "xyzxyzxyzQ"
Creating the password string is a topic for another page.
This lets me do "rlogin mmtcell" and I get prompted for a password
(which needs to work with the encrypted string in the startup file.
Once I am in, I need to do this:
iam "vwuser"
Since user "tom" does not have a .rhosts file that allows access by
the vxworks system, or he probably shouldn't.
Firewalls and ports
You will need to open up TCP port 514, as well as the entire range
of TCP ports 1011-1023 to use rsh.
Typically rsh uses just port 1022.
I do this by hand editing the /etc/sysconfig/iptables file,
but you may prefer to use some GUI firewall manager.
The ports used by the rsh family of services are:
- The rshd service listens on port 514.
- The rlogin service listens on port 513 (but you don't care).
- The rexec service listens on port 512 (but you don't care).
Have any comments? Questions?
Drop me a line!
Adventures in Computing / tom@mmto.org