Unmemorable Memories

Here’s a trick to inject environment variables to a Unix login session.

1. become root
2. set the environment variables you would like to inject
3. kill the inetd daemon
4. restart the inetd daemon

What happens is that inetd inherits all of the environment variables that are set when it starts up. When it spawns other services like telnet, these environment variables are inherited by those services. In the case of telnet, it sets these for the user’s shell.

The user will wonder where did these variables come from? It’s not in the user’s .cshrc, .login or .profile files. It’s not from any shell initialization files in the home directory or in /etc.

Of course this only affects daemons started by inetd. If you’d like to set these for ssh users, make ssh start from inetd as well. Unless of course sshd cleans up its environment before invoking login.

This works on Solaris 9. I have not tried it on any other Solaris versions,or any Linux for that matter.

This was discovered by accident when I could not figure out why I had some environment variables set upon login using telnet, when I could not find where they were being set.

This is probably a bug in inetd. Inetd should clean up the environment prior to exec’ing the requested service.

-- Posted in Geeks Paradise

A few months ago, my responsibilities at work required that I carry a laptop computer with me. I was given an IBM Thinkpad T43 laptop computer. It’s a decent system, with ample processing power, disk space and memory. Sadly it runs Windows XP. Since I work a lot with Sun customers I needed to install Solaris 10 on the laptop. However Solaris does not cut it as a desktop system, let alone a portable. Most of the software I need is in Solaris, my main complaint is the lack of support for hibernation. The laptop cannot go to sleep in Solaris, or if it does it will never wake up (unless you power cycle it).

My ambition was to run Mac OS on this laptop. Since Apple sells intel based systems, MacOS should theoretically run on intel based computers, provided the hardware was supported.

After a bit of searching I found lots of documentation at www.osx86project.org. But nothing I found was straighforward for my particular hardware. After some tinkering here’s the process that worked for me:

0. Use partition magic to shrink the windows partition to give enough space for MacOS (20 GB)
1. Boot Debian Linux on the laptop using a Debian install CD.
2. Press Alt-F2 after the system has finished detecting the devices
3. Press Enter. You will get a shell prompt.
4. fdisk /dev/ide/host0/bus0/target0/unit0/disk
5. create a new primary partition
6. Set the partition type to AF
7. Reboot with the MacOSX CD
8. Run Disk Utility to format new partition
9. Go through the MacOSX install process

Soon I was greeted with the familiar MacOS X login screen.

Initial tests showed good performance (except for graphics and sound which tended to be a bit choppy).

It turns out the Network Adapter (Broadcom NetXtreme Gigabit Ethernet) on the T43 is not supported yet.
The wireless adapter (Intel(R) PRO/Wireless 2200BG) is also unsupported.

Without access to a network, an OS is pretty much useless.

So I scrapped this idea, installed vmware under windows, and created a virtual machine that ran MacOSX. It’s slow, but it works.

Someday, I’ll have a laptop that runs all my favorite OSs. It could be this IBM thinkpad or it could be an Apple MacBook/MacBook Pro running Solaris, Linux, MacOS, and Windows XP. It’s only a matter of time.

-- Posted in Geeks Paradise

Introduction
SMTP Athentication (SMTP-AUTH) is a feature that allows one to have an SMTP server that can be used by authorized parties on the internet. The idea is to allow only authorized users to use the SMTP server as a relay. Users that have not authenticated themselves may only use the SMTP server to deliver mail to domains managed by that SMTP server. They cannot use it to relay to other domains.

This document describes how to enable SMTP-AUTH with Sendmail on Debian 3.1.
SMTP Authentication uses SASL and TLS. Debian comes with a version of sendmail that has TLS and SASL support. It also comes with SASLv2. One would naturally expect that since all the pieces are there, it should work right out of the box. Well it doesn’t. The reason is that there are SASL plugins that are missing from Debian 3.1

Pre-requisites
There are a few packages that are required for this

1. sendmail
2. sendmail-base
3. sendmail-bin
4. sendmail-cf
5. sendmail-doc
6. sasl2-bin
7. libsasl2-modules
8. libssl0.9.7
9. openssl

Configure SASL for sendmail

echo “pwcheck_method: saslauthd” > /usr/lib/sasl2/Sendmail.conf
echo “mech_list: EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN” >> /usr/lib/sasl2/Sendmail.conf

mkdir -p /var/run/saslauthd

Create the OpenSSL certificates

mkdir -p /etc/mail/certs
cd /etc/mail/certs
openssl req -new -x509 -keyout cakey.pem -out cacert.pem -days 365

: Enter your password for smtpd.key.
: Enter your Country Name (e.g., “DE”).
: Enter your State or Province Name.
: Enter your City.
: Enter your Organization Name (e.g., the name of your company).
: Enter your Organizational Unit Name (e.g. “IT Department”).
: Enter the Fully Qualified Domain Name of the system (e.g. “server1.example.com”).
: Enter your Email Address.

openssl req -nodes -new -x509 -keyout sendmail.pem -out sendmail.pem -days 365

: Enter your Country Name (e.g., “DE”).
: Enter your State or Province Name.
: Enter your City.
: Enter your Organization Name (e.g., the name of your company).
: Enter your Organizational Unit Name (e.g. “IT Department”).
: Enter the Fully Qualified Domain Name of the system (e.g. “server1.example.com”).
: Enter your Email Address.

openssl x509 -noout -text -in sendmail.pem
chmod 600 ./sendmail.pem

Configure Sendmail

1. Create the SASL sendmail configuration file

mkdir -p /etc/mail/sasl (if it doesn’t already exist)

Create /etc/mail/sasl/sasl.m4 with the following contents

dnl ### do SMTPAUTH
define(`confAUTH_MECHANISMS’, `LOGIN PLAIN DIGEST-MD5 CRAM-MD5′)dnl
TRUST_AUTH_MECH(`LOGIN PLAIN DIGEST-MD5 CRAM-MD5′)dnl

2. Configure the TLS settings for Sendmail
edit /etc/mail/tls/starttls.m4
look in the file for the following settings and change them as follows:

define(`confCACERT_PATH’, `/etc/mail/certs’)dnl
define(`confCACERT’, `/etc/mail/certs/cacert.pem’)dnl
define(`confSERVER_CERT’, `/etc/mail/certs/sendmail.pem’)dnl
define(`confSERVER_KEY’, `/etc/mail/certs/sendmail.pem’)dnl
define(`confCLIENT_CERT’, `/etc/mail/certs/sendmail.pem’)dnl
define(`confCLIENT_KEY’, `/etc/mail/certs/sendmail.pem’)dnl

3. Configure main sendmail config file
edit /etc/mail/sendmail.mc
ensure that the following lines are in the file (after the first include)

include(`/etc/mail/tls/starttls.m4′)dnl
include(`/etc/mail/sasl/sasl.m4′)dnl

4. Rebuild the sendmail configuration

cd /etc/mail
make

5. modfy /etc/default/saslauthd to ensure that saslauthd will run at startup

Ucomment the “#START=yes” line from that file by removing the ‘#’ mark.

6. Start saslauthd

/etc/init.d/saslauthd start

7. restart sendmail.

/etc/init.d/sendmail reload

SMTP-AUTH test

telnet localhost 25
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
220 localhost ESMTP Sendmail 8.13.4/8.13.4/Debian-3; Thu, 23 Feb 2006 11:33:14 -0500; (No UCE/UBE) logging access from: localhost(OK)-root@localhost 127.0.0.1
ehlo localhost
250-localhost Hello root@localhost 127.0.0.1, pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250-STARTTLS
250-DELIVERBY
250 HELP

if you see the 250-AUTH line then all is well.

To test the authentication
References

1. http://howtoforge.com/howto_sendmail_smtp_auth_tls

-- Posted in Geeks Paradise

Recently I updated my Ubuntu installation. After the update many of my java applications stopped working. Any java application that attempted to display something via X11 terminates with the following error:

current locale is not supported in X11, locale is set to CX locale modifiers are not supported, using default

You can google for possible solutions, which I did. This problem is also discussed in detail in the Ubuntu Forums.

They claim that this bug is known and has been fixed.

Well it isn’t. I tried all the other suggestions for the fix, but none of them work for me.

I have two solutions:

1. Run it in a 32-bit chroot environment (see this link. But this gets pretty annoying if you have a lot of different executables. Then I might as well ditch this 64-bit OS and install the 32-bit one.
2. Hack the 32-bit libX11.so.6.2 library. Keep reading if you are interested in this hack.

The Hack

1. Create a backup of /usr/X11R6/lib32/libX11.so.6.2
2. Edit /usr/X11R6/lib32/libX11.so.6.2 in the emacs editor (any other binary editor should work)
   • search for the string /usr/X11R6/lib/X11/locale
   • replace it with /usr/X11R6/l32/X11/locale
3. Save the file and exit emacs
4. Go to the /usr/X11R6 directory
5. Create a symlink called l32 that points to lib32 in that same directory
6. Go to the /usr/X11R6/lib32/X11/locale directory
7. Create symlinks here to all the files (except lib) that exists in /usr/X11R6/lib/X11/locale
8. You’re done

After applying this hack, my 32-bit java programs now run without complaining about locales.

Why this hack works
Since none of the workarounds and fixes I’ve found in Google and the Ubuntu Forums worked for me, I decided to do some strace’ing myself.

Strace showed that the program was opening /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2. Now I know that the Java I installed is a 32-bit executable, and this library is a 64-bit binary. So my guess is that the linker fails to link with this library. To test my hypothesis, I replaced this library (after creating a backup of course) with the one from /usr/X11R6/lib32/X11/locale/lib/common/xlcUTF8Load.so.2 (the 32-bit counterpart). Just this simple operation, fixed my problem. However it introduces another one: all other 64-bit X applications complained about my locale (although they continued to work). I had to come up with a way to have both types of applications working.

I restored the original xlcUTF8Load.so.2 to keep my 64-bit X applications happy. Now I needed a way to get my 32-bit applications to link with the 32-bit xlcUTF8Load.so.2 library.

From the strace output, I compiled a list of all the X libraries that the application opened. Then I searched those libraries for the string “/usr/X11R6/lib/X11/locale”. The culprit was libX11.so.6.2.

I needed to modify this library to look at /usr/X11R6/lib32/X11/locale in order for it to find the correct version of xlcUTF8Load.so.2. Simply replacing ‘lib’ with ‘lib32′ will not work since it will change the size of the library, and mess up whatever offsets are setup in that library. I needed to replace ‘lib’ with an equal length string that points to the correct place. So I replaced it with ‘l32′, then created a symlink called l32 which points to lib32 in /usr/X11R6.

After doing this, I tested my application, and it continued to fail. What was going wrong? Further strace output showed that the app was no longer linking xlcUTF8Load.so.2. The strace output also showed a bunch of open() failures for files that lived in /usr/X11R6/l32/X11/locale. Those files exist in /usr/X11R6/lib/X11/locale. So by creating symlinks to all those files, the behavior of the application was restored (it once again discovered that it needed xlcUTF8Load.so.2).

Now all my java programs work again without sacrificing the functionality of my 64-bit X applications. And possibly other 32-bit X11 applications will also work with proper locale support.

Update: I have made additional hacks to get acroread to work.
1. create a symlink called /usr/l32 pointing to /usr/lib32
2. modify the libraries found in /lib32, /usr/lib32, and /usr/X11R6/lib32 to use /usr/l32 instead of /usr/lib
* /usr/lib32/libglib-2.0.so.0.400.7
* /usr/lib32/libgdk_imlib.so.1.9.14
* /usr/lib32/libgtk-1.2.so.0.9.1
* /usr/lib32/libgtk-x11-2.0.so.0.400.10
* /usr/lib32/libgdk_pixbuf-2.0.so.0.400.10
** change to this is tricky. Look for gtk-2.0 followed by “/etc” then change gtk-2.0 to g32-2.0
** copy /etc/gtk-2.0 to /etc/g32-2.0 and modify the gdk-pixbuf.loaders and gtk.immodules files inside the /etc/g32-2.0 to point to /usr/lib32 versions of the files
3. modify /lib32/tls/libc-2.3.2.so
** change /usr/lib/gconv to /usr/l32/gconv
** change /usr/lib/gconv/gconv-modules.cache to /usr/l32/gconv/gconv-modules.cache
4. modify /usr/lib32/libpango-1.0.s0.0.1000.0
** change /usr/lib to /usr/l32
** change /etc/pango to /etc/pgo32
** copy /etc/pango to /etc/pgo32
** modify /etc/pgo32/pango.modules to change /usr/lib into /usr/lib32

Update 2: I have upgraded to dapper (6.06 LTS). My hacks broke in this version because the libpango-1 library uses /var/lib/pango/pango.modules. The fix is to modify /usr/lib32/libpango-1.0.so.0.1201.2 and replace all occurances of /var/lib/pango with /var/lib/pgo32, then create a directory called /var/lib/pgo32 and copy the contents of /var/lib/pango into /var/lib/pgo32. Then edit /var/lib/pgo32/pango.modules and replace all occurances of “/usr/lib” with “/usr/lib32″.

-- Posted in Geeks Paradise

“We have no internet!” were the words that Chris uttered last night. I thought it was just one of those temporary outages that I occasionally experience from my Internet Service Provider. But just to satisfy my curiosity, I checked my system, checked the modem, checked the cabling, everything was fine. As I suspected, my ISP was having problems. What I didn’t realize is the gravity of the problem. This morning my internet connection was still non-functional.

My ISP, istop.com has been in dispute with Bell Canada over the tarriffs that Bell charges them. A few months ago, I suffered an 8 hour downtime because Bell had disconnected their service to my ISP. I should have switched ISPs then. But I have such a forgiving attitude, I decided to give istop a chance and continue with their service.

Tonight the inevitable happened. It seems they will be down for good. All of a sudden, their name, Istop, has a new meaning.

This morning was spent scrambling for an ISP that can put me back online ASAP. My new provider, start.ca, not only has a better name, they got me online within two hours of signing up! In comparison, every other ISP I contacted said I would need to wait 5-7 business days for service to be activated.

In hindsight, I should have learned from my past experience and switched ISPs the first time Bell cut off their services. I guess to be bitten once was not enough for me. I had to get bitten twice.

-- Posted in Geeks Paradise