It is good that several of you are using your own Linux boxes for 730 work. But Linux installations out-of-the-box are typically not "open" enough for 730 projects. (The suggested solutions on this page do weaken security. This is not disastrous; Linux distros are becoming too paranoid ...) On this page, I am collecting the issues and solutions. If you find better solutions, send them to me and I will update this page.
Learn to use sudo and su. On Debian/Ubuntu/Knoppix,
apt-get is the
software (un)installer. Graphical versions: synaptic, adept,
kpackage. On RedHat and Fedora: yum.
RPC program numbers, network port numbers, ... are system wide resources -- not per user or per process separated entries. Before debugging your WhiteBoard RPC project, it is good idea to freshly reboot the host.
The X11 server runs on the machine that has the screen (and keyboard, and mouse, ...). X11 clients can run on the same host or some where else and network-connect to the server. The host running the clients may or may not have the screen etc.
For 730, X11 server should have been started without disabling listening
to TCP connections. Exactly how it should be started varies among
distributions. Generally speaking, search for "-nolisten" keyword
or DisallowTCP among kdm/gdm/X11 config files and delete it. List
all processes, and see what the arguments are to X. A "good" one
may look like this:
/usr/bin/X :0 vt7 -nr -auth /var/run/xauth/A:0-44n3ncFor gdm, check
/etc/gdm/gdm.schemas, /etc/gdm/custom.conf, /etc/gdm/gdm.conf.
For kdm, check /etc/kde4/kdm/kdmrc.
The X11 windows will show up on the screen defined by DISPLAY; echo $DISPLAY. The simplest,
in bash, is to do: export
DISPLAY=host-name:0.0 BTW, you can instead use IP addresses, as
in "127.0.0.1:0.0".
Example problem: client: openxwindow("localhost:0.0", ...) == -1, failed ;
Diagnosis: Disable authentication control over whose processes can open X11
windows. Solution:
xhost +
For fine grain control, read man xhost. If you are using, e.g. ssh -X tunnel,
the DISPLAY will have a different value. Be aware that 730 client.c has
a hard-coded display number: strcat(cd->xdisplaynm, ":0.0");
Install the X11 development libraries. Do the equivalent
of apt-get install libx11-dev
The host name lookups should be correct. This is a combination of
/etc/hosts and how you set up DNS. E.g., if ":0.0" works but
"localhost:0.0" does not, the problem is with your /etc/hosts
file. Entries in /etc/hosts.deny cause connections to
be refused. Understand what is in /etc/resolv.conf
You will benefit from installing
sshd, smbd, nmap, traceroute
Learn to log into a remote server "without password" but with automated authentication and encryption: http://www.cs.wright.edu/~pmateti/Courses/233/Labs/Network/NetworkLab.html#ssh
We use rpcinfo as a diagnostic command. On Ubuntu, it is
located in /usr/sbin/. Before you start any of WhiteBoard processes, do
rpcinfo
-p and make a note of what is listed. After starting
WhibeBoard processes, check rpcinfo -p shows.
rpcbind -w -i This program is the portmapper; a few years ago, it was named rpc.portmap.
Example problem: "Cannot
register service: RPC: Unable to receive; errno = Connection
refused unable to register (WhiteBoardServer,
WhiteBoardServerVersion, ...)." Diagnosis: RPC portmapper is missing.
Solution: Install nfs-kernel-server. This will install NFS, but as a
side-effect installs RPC support.
Example problem: "Cannot register service: RPC: Authentication error;
why = Client credential too weak unable to register (registryProg, registryVers,
...)" Diagnosis: We need rpcbind to be running in the insecure mode. Solution: List all processes, and see what the arguments are to rpcbind.
If it is just rpcbind -w, kill that process and restart
it as rpcbind -w -i. This solves it for just this session.
Permanent solution: Find the config file for rpcbind, and fix the options.
On Ubuntu, /etc/init/portmap*.conf, /etc/init/rpc*.conf.
rpcgen program exists for practically all OS. But, its generated
code can look very different from what is generated in Linux.