Running Matlab through a ssh tunnel

It is (un)common in a Computer Center environment to run applications on a remote server and see the graphical output on the local machine. This is usually achieved using X11 forwarding over ssh.

I had to set up Matlab R2009a on a brand new SUN blade server and make it available to users through the SUN Global Desktop software. If I get it right, SUN's SGD merely passes X11 forwarding over ssh, over the http protocol. The big disappointment was that Matlab's interface was sooooo slow in a way that the program was practically unusable. I tried to pinpoint the problem by fine tuning SGD but this was not the case. Then I realized that accessing Matlab from SGD is the same as accessing it using X11 forwarding over ssh.

The first clue that Matlab's way to draw the interface sucks is that you cannot run it under a standards compliant window manager like XMonad or Awesome. The proposed hack:

$ export AWT_TOOLKIT=MToolkit

just segfaults on any recent (and old, afaik) linux distro (I think this is a java problem, well java sucks also). Another clue that something is wrong with Matlab's way to draw its interface is the warning message I got when I tried to run it on OpenSUSE 11.1:

libxcb: WARNING! Program tries to unlock a connection without having acquired
a lock first, which indicates a programming error.
There will be no further warnings about this issue.

I don't really understand the above warning but what I get is that Matlab's interface developers are doing ad hoc hacks or just don't really care about Matlab's functionality in Linux.

By googling for more than three days I finally realized that the problem is a combination of java and the X11 libraries. A lot of people under different setups reported the same problem with Matlab and the common fact was that everything was fine until they upgraded their linux distro to the latest version. So I decided to install CentOS 4 in a virtual machine and try this setup as a last resort. Fortunately Matlab R2009a runs just fine in CentOS 4 and its interface is bearable under ssh -X.

UPDATE: Finally it turns out to be a libraries problem. Matlab R2009a runs also fine in CentOS 5 as long as you install the "Legacy Software Support Libraries" in the "openmotif22-2.2.3-18.i386" package.

UPDATE (issue finally solved): I found a resolution for this problem! Just put a file called "java.opts" containing the Java option "-Dsun.java2d.pmoffscreen=false" into the directory *matlabroot*/bin/*system*/

VLAN handling on Cisco Switches

These notes appear on a scratch paper found on my desktop. They seem useful and I'll try to see that they are ok.
In order to add a vlan:

vlan database
vlan <id> name <name>
exit
show vlan name <name>

In order to add a port to an existing vlan:

conf t
interf <interface>
switchport mode access
switchport access vlan <vlan>

In order to delete a vlan:

vlan database
no vlan <vlan>
exit

I cannot understand the meaning of the following:

set vtp mode transparent
show vtp domain

Debian Lenny: How to disable ipv6

If you use good old IPv4 instead of IPv6 for your network connection and dont wanna play with iptables6 or leave ipv6 wide open, you should disable IPv6. In /etc/modprobe.d/aliases add two lines after the commented out line:

# alias net-pf-10 ipv6
alias net-pf-10 off
alias ipv6 off

You can safely wipe out any IPv6 reference in /etc/hosts and /etc/network/interfaces

Thanks to this article.

Network Card Bonding On CentOS

Today I had to setup a network bond on CentOS. These are the necessary steps. In the /etc/modprobe.conf file added the following:

alias bond0 bonding
options bond0 miimon=80 mode=1

mode=1 is for my active-backup setup witch is common to all the SUN blades I had to setup. In the /etc/sysconfig/network-scripts/ directory I created ifcfg-bond0 (fill according to your setup):

DEVICE=bond0
IPADDR=
NETMASK=
NETWORK=
BROADCAST=
GATEWAY=
ONBOOT=yes
BOOTPROTO=none
USERCTL=no

I changed ifcfg-eth0 to:

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
MASTER=bond0
SLAVE=yes

I also changed ifcfg-eth1 to:

DEVICE=eth1
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
MASTER=bond0
SLAVE=yes

Finally you have to restart networking:

$ service network restart

Many thanks to De Zordo Patrick

Debian Lenny: secure OpenLDAP traffic with SSL

I consider that you already have a database running. First of all enable ldaps in /etc/default/slapd:

SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:///"

The following creates a self-signed certificate valid for 10 years:

$ mkdir /etc/ldap/ssl
$ openssl req -new -x509 -nodes -out \
> /etc/ssl/ldap-cert.pem -keyout \
> /etc/ldap/ssl/ldap-key.pem -days 3650

Under /etc/ldap/slapd.conf (server configuration) add (somewhere between include entries and database entries):

TLSCertificateFile /etc/ssl/ldap-cert.pem
TLSCertificateKeyFile /etc/ldap/ssl/ldap-key.pem
TLSCACertificateFile /etc/ssl/ldap-cert.pem

In order to configure a client, under /etc/ldap/ldap.conf add at the end of the file:

URI ldaps://ldap.your.domain:636/
BASE dc=your,dc=domain
TLS_CACERTDIR /etc/ldap/ssl/

Don't forget to restart OpenLDAP:

$ /etc/init.d/slapd restart

Thanks to Sébastien Wains for his excellent article about CentOS.

How to create a bridge interface using a NIC bond

The following setup works fine on a Debian Lenny system. Notice also that the same setup on a Ubuntu 9.04 server causes a kernel panic!

The machine is a SUN blade server with two NICs. Each NIC is connected to a different switch in a redundant manner. These are the contents of the /etc/network/interfaces file:

auto lo
iface lo inet loopback

auto bond0
iface bond0 inet manual
slaves eth0 eth1
bond_mode active-backup

auto br0
iface br0 inet static
address 192.168.11.20
netmask 255.255.255.0
network 192.168.11.0
broadcast 192.168.11.255
gateway 192.168.11.1
bridge_ports bond0