2009/11/19

WMU-6500FS - Print server installation

Introduction

Since I have one LPT printer and several computers at home I considered buing a print server for a long time. What reliably discouraged me however was the price - for example HP print server price starts at around 140$.
Unfortunately I haven't bought a router with USB ports like Asus WL-500W, but rather Linksys WRT54GL and so the printer sharing as described at DD-WRT wiki was not applicable in my case.
Then I noticed that there is a p910nd print daemon package available at the JoKer's site.
There was not much information about the installation on the Web and so I was pretty unsure but I decided to give it a try.

Note: Before you follow the steps I describe here, please, make sure your printer is compliant with the JetDirect technology.

Hardware installation

My HP LaserJet 1100 printer is not USB but LPT, so there is some USB to LPT reduction necessary.
I also realized that there is not a standard printer cable but rather a Mini Centronics cable used for the printer connection.

So it seemed that besides something like the USB to Parallel port adapter (14$) also another reduction like Centronics to Mini Centronics adapter (11$) was necessary (there is also a combo for 24$ so you can spare a buck ;).

Since I already had a standard printer cable the best choice for me was the ST Lab U-370 Dongle. For only 11$ does the job very well.
So that's it regarding to hardware installation.

Software installation

We download and install the p910nd print daemon (I use 0.92 version, I had no luck with the latest 0.93 version, I got /var/lock/subsys/p9100d file not found error).
Edit: now the problem with 0.93 is solved, see the discussion below
box# cd /mnt/C
box# wget http://mgb111.pradnik.net/addons/servers-print/p910nd-0.92-081017.tar
box# tar xvf p910nd-0.92-081017.tar
./sys/
./sys/etc/
./sys/man/
./sys/man/man8/
./sys/man/man8/p910nd.8
./sys/sbin/
./sys/sbin/p910nd
Now we are ready to plug the printer to USB port (suppose you use the USB1 port specifically) and run the daemon:
box# /mnt/C/sys/sbin/p910nd -b -f /dev/usblp0
We can see that the process is now up and running. The fact that it is named p9100d (instead of original p910nd) means that it is listening at port 9100.
box# ps | grep p910
  271 root        284 S   /mnt/C/sys/sbin/p9100d -b -f /dev/usblp0
 1863 root        216 S   grep p910
We can make sure it is actually listening at the port; when we run the network statistics to list all the ports all the processes are are listening for, newly we can see the jetdirect port.
box# netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
...
tcp        0      0 *:jetdirect             *:*                     LISTEN      
...
We can also look at the system log (with help of the dmesg command). There we can find something similar to the following:
box# dmesg
...
hub.c: new USB device 00:0a.0-2, assigned address 2
printer.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 1 proto 2 vid 0x067B pid 0x2305
...
When we retrieve the description string of the USB device, we get that there is a IEEE-1284 (parallel communication) controller made by the Prolific Technology Inc..
box# cat /proc/printer/usblp0
Prolific Technology Inc. IEEE-1284 Controller
0x18
Note that in case you have a USB printer you should probably expect somewhat more meaningful string like
Hewlett-Packard HP LaserJet 1005 series
Now we are ready to try some printing:
box# echo "printer test" > /dev/usblp0 
...
Initially I got the following error message:
bash: /dev/usblp0: Device or resource busy
... then I realized that there is a mini-lpd process running holding the device. mini-lpd is a small, non-queueing LPD implementation. I do not know why there is mini-lpd active on the box, I have not tried to make it work, I just killed it and used p910nd daemon instead:
box# killall mini-lpd
After that everything started to work.
To make the changes permanent, I have added add the following lines:
### printserv
killall mini-lpd
/mnt/C/sys/sbin/p910nd -b -f /dev/usblp0 &
to the /mnt/C/sys/etc/rc-local file.

Ok, that's it on the server side, let's look at the clients...

Client installation

Now it is time to install the print clients:
Windows XP
I presume you already have the printer installed locally, and so the only thing you need is to create a new port and set it up as a Standard TCP/IP Port: Now you select the box IP or network name: As a device type you choose the Hewlett Pacjkard Jet Direct: Here is a result page(SNMP not supported, RAW protocol, port 9100): Here we see the newly created port: And finally we are ready to print test page:
Ubuntu 9.10
In menu System/Administration/Printing we choose to create a new printer and in device selection choose Network Printer and AppSocket/HP JetDirect.In Host and Port fields we fill the box IP or network name and as port we use 9100: The next step is the Printer model and driver selection: Now we can specify the printer name and description: And finally we are ready to print test page:

Links



Read more...

2009/04/13

WMU-6500FS - Deluge 1.1.5

I just finished a build of the deluge 1.1.5. It is bit outdated (the 1.1.6 version is out now) but I had to solve some problems along the way which taken more time than expected. Once it was finished I did not find a morale to step one bugfix version further.

Build result

[binary] [file list]

Prerequisites

The same as for the previous version plus:
[patched python socket module] [tar 1.22] [bzip2 lib]

Uninstall

If you have the deluge-1.1.0 installed, you have to clean it up first (while preserve all the dependencies).
Stop the deluge daemon if it is running. You can do it via console:
box# deluge --ui=null
>>> halt
>>> quit
Thanks!

or forcibly:
box# killall deluged
Now uninstall the previous version:
dev# cd /mnt/C/
dev# ./filopack.sh --remove deluge-1.1.0
Configuration file .filopack/.config file found and used
Sure to remove deluge-1.1.0 locally at /mnt/C (y/n)?y
...
If you are not using the filopack packaging system, you can remove the previous version as follows:
box# cd /mnt/C/
box# wget http://filodej.ic.cz/filopack/.filopack/deluge-1.1.0.lst
box# xargs rm -f < deluge-1.1.0.lst

Update the system

Before we start installing the new version, we have to update the tar archiver. The one which is part of the busybox has an ugly bug corrupting file names in long paths.
box# ./filopack.sh --download bzip2-1.0.5
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package bzip2-1.0.5 from http://filodej.ic.cz ...
connected!

Length: 191 [text/plain]
connected!

Length: 40,244 [application/x-tar]

box# ./filopack.sh --install bzip2-1.0.5
...
box# ./filopack.sh --download tar-1.22
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package tar-1.22 from http://filodej.ic.cz ...
connected!

Length: 1,523 [text/plain]
connected!

Length: 625,455 [application/x-tar]

box# ./filopack.sh --install tar-1.22
...

For details about the bug see this section.
Also it may be necessary to download a patched version of python socket library, you can test your system as follows:
box# python -c 'import socket; print socket.gethostbyaddr("80.68.88.204")[2];'
Segmentation fault
... if you encounter the segfault, it is better to download and install the patched python socket library:
box# wget http://filodej.ic.cz/filopack/_socket.so
connected!

Length: 116,767 [text/plain]

box# mv sys/lib/python2.5/lib-dynload/_socket.so{,.backup}
box# mv _socket.so sys/lib/python2.5/lib-dynload/
Now the problem should be fixed:
box# python -c 'import socket; print socket.gethostbyaddr("80.68.88.204")[2];'
['80.68.88.204']
For details about this issue see this section.

Install

After we updated the system we are ready to install the new version:
box# ./filopack.sh --download deluge-1.1.5
Configuration file .filopack/.config file found and used
Retrieving package index... (Connecting to http://filodej.ic.cz)
Downloading package deluge-1.1.5 from http://filodej.ic.cz ...
connected!

Length: 89,430 [text/plain]
connected!

Length: 16,084,717 [application/x-tar]

box# ./filopack.sh --install deluge-1.1.5
Sure to unpack deluge-1.1.5 locally at /mnt/C (y/n)? y
...

Run daemon

Now we are ready to try the daemon, still it is necessary to use the LD_PRELOAD prefix or deluged.sh script:
box# deluged.sh
That's all. Following text just describes details related to the issues I solved. Nothing for ordinary users ;-)

Busybox tar bug

When I run the deluge client (console version) some commands was not properly interpreted:
box# deluge
>>> info
 * unknown command: info
>>> help
 * unknown command: help
I found out that any command is implemented in a separate python file:
box# cd sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg
box# ls deluge/ui/console/commands/
add.py          config.pyc   debug.pyc       help.pyc        __init__.pyc    quit.pyc    rm.pyc
add.pyc         connect.py   halt.py0000755  info.py0000755  pause.py        resume.py
add.pyc0000644  connect.pyc  halt.pyc        info.pyc        pause.pyc       resume.pyc
config.py       debug.py     help.py0000755  __init__.py     quit.py0000755  rm.py
... it seems there are some ill-named files in the command directory, and so the console does not know the commands at all.
Let's find all such corrupted files:
box# find . -name *0000*
./deluge/core/preferencesmanager.pyc0000644
./deluge/ui/console/commands/quit.py0000755
./deluge/ui/console/commands/help.py0000755
./deluge/ui/console/commands/halt.py0000755
./deluge/ui/console/commands/info.py0000755
./deluge/ui/console/commands/add.pyc0000644
./deluge/ui/gtkui/torrentdetails.pyc0000644
./deluge/ui/gtkui/queuedtorrents.pyc0000644
./deluge/ui/gtkui/filtertreeview.pyc0000644
./deluge/ui/webui/page_decorators.py0000755
./deluge/ui/webui/torrent_options.py0000755
./deluge/ui/webui/lib/egg_handler.py0000755
./deluge/ui/webui/lib/egg_render.pyc0000644
./deluge/ui/webui/lib/webpy022/db.py0000755
./deluge/plugins/Label-0.1-py2.5.egg0000644
./deluge/plugins/webuipluginbase.pyc0000644
./deluge/data/pixmaps/checking16.png0000644
./deluge/data/pixmaps/inactive16.png0000644
Let's look also in the deluge tar archive:
box# tar tjvf deluge-1.1.5.tar.bz2 | grep 0000
-rw-r--r-- 0/0     21100 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/core/preferencesmanager.pyc0000644
-rwxr-xr-x 0/0      1079 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/quit.py0000755
-rwxr-xr-x 0/0      2299 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/help.py0000755
-rwxr-xr-x 0/0      1125 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/halt.py0000755
-rwxr-xr-x 0/0      5296 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/info.py0000755
-rw-r--r-- 0/0      2036 2009-04-01 12:22:09 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/console/commands/add.pyc0000644
-rw-r--r-- 0/0     13688 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/gtkui/torrentdetails.pyc0000644
-rw-r--r-- 0/0      7346 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/gtkui/queuedtorrents.pyc0000644
-rw-r--r-- 0/0     13073 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/gtkui/filtertreeview.pyc0000644
-rwxr-xr-x 0/0      5062 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/page_decorators.py0000755
-rwxr-xr-x 0/0      3233 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/torrent_options.py0000755
-rwxr-xr-x 0/0      1553 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/lib/egg_handler.py0000755
-rw-r--r-- 0/0      1522 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/lib/egg_render.pyc0000644
-rwxr-xr-x 0/0     20480 2009-04-01 12:22:10 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/ui/webui/lib/webpy022/db.py0000755
-rw-r--r-- 0/0     38041 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/plugins/Label-0.1-py2.5.egg0000644
-rw-r--r-- 0/0      2982 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/plugins/webuipluginbase.pyc0000644
-rw-r--r-- 0/0       699 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/data/pixmaps/checking16.png0000644
-rw-r--r-- 0/0       595 2009-04-01 12:22:11 sys/lib/python2.5/site-packages/deluge-1.1.5-py2.5-linux-i686.egg/deluge/data/pixmaps/inactive16.png0000644
At a first glance it seem that the archive is corrupted but when I tried the same operation on my mirror system (on the PC) no corrupted file appeared in the archive.
The difference was that while on the mirror system I have the GNU tar 1.20 installed, on the box there is a busybox version containing tar utility:
box# which tar
/bin/tar
box# ls -l /bin/tar
lrwxrwxrwx 1 root root 7 2008-05-21 13:40 /bin/tar -> busybox
I decided to build the newest GNU tar version (1.22) and install it to the box. A new post containing the build procedure will follow. After the installation the problem disappeared.

Socket related crash

I am not sure whether it was new to this version, but after the installation from time to time I have experienced a weird crash of the deluge daemon. Also the Windows client did not respond for long time when was connected to the daemon running on the box. After some experimenting with the deluge log I decided to debug the daemon to find out what is going on.
I was running the gdbserver on the box:
box# LD_PRELOAD="/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0" gdbserver colinux:2345 `which python` `which deluged` -d
Process /usr/bin/python created; pid = 31831
Listening on port 2345
Remote debugging from host 192.168.1.102
...
Then I was ready to connect to the gdbserver from my mirror system:
deb# gdb `which python`
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux-uclibc"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) target remote storage:2345
Remote debugging using storage:2345
0x40000c90 in ?? ()
(gdb) cont
Continuing.
...
After some time when I was connecting and disconnectiong the windows client to the daemon the problem appeared:
[New Thread 32801]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 32801]
0x400a0fb0 in PyString_FromString (str=0xc7c3815b <Address 0xc7c3815b out of bounds>) at Objects/stringobject.c:108
108             size = strlen(str);
(gdb)
It was at the following stack:
(gdb) where
#0  0x400a0fb0 in PyString_FromString (str=0xc7c3815b <Address 0xc7c3815b out of bounds>) at Objects/stringobject.c:108
#1  0x407e8154 in gethost_common (h=0xbb9fdae8, addr=0xbb9fdb08, alen=128, af=2) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3048
#2  0x407e5825 in socket_gethostbyaddr (self=0x0, args=0x40f2f48c) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3273
#3  0x40094bd2 in PyCFunction_Call (func=0x405ac70c, arg=0x40f2f48c, kw=0x0) at Objects/methodobject.c:108
#4  0x400dcf1a in PyEval_EvalFrameEx (f=0x81f8624, throwflag=0) at Python/ceval.c:3573
#5  0x400de1e6 in PyEval_EvalCodeEx (co=0x405b94e8, globals=0x405b624c, locals=0x0, args=0x820022c, argcount=1, kws=0x8200230, kwcount=0, defs=0x405be518, defcount=1,
    closure=0x0) at Python/ceval.c:2836
#6  0x400dd6d0 in PyEval_EvalFrameEx (f=0x82000e4, throwflag=0) at Python/ceval.c:3669
#7  0x400dda59 in PyEval_EvalFrameEx (f=0x81e77d4, throwflag=0) at Python/ceval.c:3659
#8  0x400de1e6 in PyEval_EvalCodeEx (co=0x405c13c8, globals=0x405b602c, locals=0x0, args=0x406200b0, argcount=4, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:2836
...
a crash in PyString_FromString seems to be just a consequence, let's look up a bit:
(gdb) up
#1  0x407e8154 in gethost_common (h=0xbb9fdae8, addr=0xbb9fdb08, alen=128, af=2) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3048
3048                            tmp = PyString_FromString(*pch);
(gdb) list
3043
3044            /* SF #1511317: h_aliases can be NULL */
3045            if (h->h_aliases) {
3046                    for (pch = h->h_aliases; *pch != NULL; pch++) {
3047                            int status;
3048                            tmp = PyString_FromString(*pch);
3049                            if (tmp == NULL)
3050                                    goto err;
3051
3052                            status = PyList_Append(name_list, tmp);
(gdb) print h
$1 = (struct hostent *) 0xbb9fdae8
(gdb) print *h
$2 = {h_name = 0xbb9f9b00 "filodej.doma", h_aliases = 0x40172891, h_addrtype = 2, h_length = 4, h_addr_list = 0xbb9f9aec}
(gdb) print h->h_aliases
$3 = (char **) 0x40172891
(gdb) print *h->h_aliases
$4 = 0xc7c3815b <Address 0xc7c3815b out of bounds>
... It seems that a host entry should contain an array of strings - aliases - but this array is apparently corrupted - it causes a crash of the C string -> Python string conversion routine. Let's look who is responsible for filling the array:
(gdb) up
#2  0x407e5825 in socket_gethostbyaddr (self=0x0, args=0x40f2f48c) at /usr/local/src/Python-2.5.2/Modules/socketmodule.c:3273
3273            ret = gethost_common(h, (struct sockaddr *)&addr, sizeof(addr), af);
(gdb) list
3268            PyThread_acquire_lock(netdb_lock, 1);
3269    #endif
3270            h = gethostbyaddr(ap, al, af);
3271    #endif /* HAVE_GETHOSTBYNAME_R */
3272            Py_END_ALLOW_THREADS
3273            ret = gethost_common(h, (struct sockaddr *)&addr, sizeof(addr), af);
3274    #ifdef USE_GETHOSTBYNAME_LOCK
3275            PyThread_release_lock(netdb_lock);
3276    #endif
3277            return ret;
The gethostbyaddr seems as a good candidate. At first I wondered whether the function is thread safe (see the following text about uClibc thread safety), but after further debugging I have found out that the apparently thread safe variant gethostbyaddr_r is called in my case, so there should be not threading issue there.
(gdb) cont
Continuing.
[New Thread 1024]
Breakpoint 2 at 0x407e574c: file /usr/local/src/Python-2.5.2/Modules/socketmodule.c, li
Pending breakpoint "socket_gethostbyaddr" resolved
[New Thread 19476]
[Switching to Thread 19476]

Breakpoint 2, socket_gethostbyaddr (self=0x0, args=0x40f27ccc) at /usr/local/src/Python
3229            if (!PyArg_ParseTuple(args, "s:gethostbyaddr", &ip_num))
...
(gdb) next
3252            Py_BEGIN_ALLOW_THREADS
(gdb) next
3255            result = gethostbyaddr_r(ap, al, af,
(gdb) next
3272            Py_END_ALLOW_THREADS
(gdb) print buf
$12 = "À¨\001eè\232?½", '\0' <repeats 16 times>, "filodej.doma\000.in-addr.arpa", '\0' <repeats 16333 times>, "@"
(gdb) next
3273            ret = gethost_common(h, (struct sockaddr *)&addr, sizeof(addr), af);
(gdb) print *h
$14 = {h_name = 0xbd3f9b00 "filodej.doma", h_aliases = 0x40172891, h_addrtype = 2, h_length = 4, h_addr_list = 0xbd3f9aec}
(gdb) print h->h_aliases
$15 = (char **) 0x40172891
(gdb) print *h->h_aliases
$16 = 0xc7c3815b <Address 0xc7c3815b out of bounds>
... after some googling I found some hints in the following forum.
Actually it seem there were two related bugs: the first in gethostbyname_r seems to be fixed now, steps to simply reproduce the problem:
box# python -c 'import socket; print socket.gethostbyname_ex("wh0rd.org")[2];'
['80.68.88.204']
... it was ok in my case, it seems to be fixed in 0.9.27 version.
The second bug is in gethostbyaddr_r function. The step to reproduce is following:
box# python -c 'import socket; print socket.gethostbyaddr("80.68.88.204")[2];'
Segmentation fault
... it crashes on my box. Given you have the Python installed, you can test your configuration the same way.
For the solution I decided not to patch or upgrade the uClibc but rather make a workaround in the python socket library. Zeroing the structure prior to the gethostbyaddr_r call should be enough. Let's modify the python Modules/socketmodule.c file. In the PySocket_gethostbyaddr functon there is a hp_allocated structure we are going to reset to zeroes. Just before the gethostbyaddr_r call we add the following code:
#if   defined(HAVE_GETHOSTBYNAME_R_6_ARG)
        memset((void *) &hp_allocated, '\0', sizeof(hp_allocated));
        result = gethostbyaddr_r(ap, al, af,
                &hp_allocated, buf, buf_len,
                &h, &errnop);
... and rebuild and re-pack the python package:
deb# cd /usr/local/src/Python-2.5.2
deb# make
case $MAKEFLAGS in \
*-s*) LD_LIBRARY_PATH=/usr/local/src/Python-2.5.2::/mnt/C/sys/lib:/mnt/C/sys/X11/lib CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \
*) LD_LIBRARY_PATH=/usr/local/src/Python-2.5.2::/mnt/C/sys/lib:/mnt/C/sys/X11/lib CC='gcc -pthread' LDSHARED='gcc -pthread -shared' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \
esac
running build
running build_ext
db.h: found (4, 3) in /mnt/C/sys/include
db lib: using (4, 3) db-4.3
/mnt/C/sys/include/sqlite3.h: version 3.5.8
INFO: Can't locate Tcl/Tk libs and/or headers
building '_socket' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/local/src/Python-2.5.2/./Include -I/mnt/C/sys/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/Python-2.5.2/Include -I/usr/local/src/Python-2.5.2 -c /usr/local/src/Python-2.5.2/Modules/socketmodule.c -o build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/socketmodule.o
gcc -pthread -shared -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/socketmodule.o -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -L/usr/local/lib -L. -lpython2.5 -o build/lib.linux-i686-2.5/_socket.so
building 'nis' extension
gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/usr/local/src/Python-2.5.2/./Include -I/mnt/C/sys/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/local/src/Python-2.5.2/Include -I/usr/local/src/Python-2.5.2 -c /usr/local/src/Python-2.5.2/Modules/nismodule.c -o build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/nismodule.o
gcc -pthread -shared -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes build/temp.linux-i686-2.5/usr/local/src/Python-2.5.2/Modules/nismodule.o -L/mnt/C/sys/lib -L/mnt/C/sys/X11/lib -L/usr/local/lib -L. -lnsl -lpython2.5 -o build/lib.linux-i686-2.5/nis.so
*** WARNING: renaming "nis" since importing it failed: dynamic module does not define init function (initnis)
running build_scripts
box# make install
...
deb# cd /mnt/C/
deb# ./filopack.sh -R --pack python-2.5.2
...

Build process

The build process was identical to 1.1.0 version, I just had to create .pth link file in order to be able to remove the duplicate directories:
 
dev# cd /mnt/C/sys/lib/python2.5/site-packages
dev# echo "./deluge-1.1.5-py2.5-linux-i686.egg" > deluge.pth

dev# cd /mnt/C/
dev# ./filopack.sh --pack deluge-1.1.5
Remove all the "site-packages/deluge/" sub-paths (they seem to be redundant) and re-pack the package once more.

Read more...

2009/03/26

Port forwarding & Remote desktop connection (updated)

Overview

In the company I am working as a developer we have relatively flexible rules how to organize working time (some workdays we can work from home assuming we are online and easily accessible by other team members). On the other side there are strict IT rules and firewall settings complicating the remote access.
The e-mail access and even the remote desktop access is officially possible just via a web portal provided that you withstand a tedious login process and unbearable refresh rate (not speaking of an odd interference with skype).
Thus we faced a challenge how to overcome the strict firewall settings and open up a direct (and swift) remote desktop access. Finally we succeeded, and in this post I am going to share the method with you, having possibly similar problems.

Info sources

[Secure remote access of a private network]
[Port forwarding for Remote Desktop]
[Unix man pages: ssh(1)]
[Concurrent Remote Desktop Sessions in Windows XP SP2]
[Speed up SSH X11 forwarding]
[SSH port forwarding]

Configuration

At home I have a PC workstation with Windows XP and laptop with Linux Ubuntu 8.04, both computers behind the Linksys router WRT54GL with DD-WRT firmware version 2.4.
In the office I have a PC workstation with Windows XP behind a firewall. The firewall is administered by the IT department (residing abroad) and developers have no way of configuring it.
The office firewall is configured that there are no incoming ports open and there are just a few outgoing: 80 (http), 119 (nntp), 1863 (msnp) and maybe few others I do not know of.
The goal is to find a way how to enable Remote desktop connection across the Internet in both directions.
We decided to use SSH port forwarding feature. Since the port 22 standardly used for SSH access is not forwarded on the firewall even for outgoing connections we had to use another port - 119 was our choice.
In following text I use port 119, actually it is specific to this specific scenario, given there is another firewall configuration, port selection has to be done correspondingly.

Homeward connection

This direction is a simpler one, since there are at least some ports open on the firewall for outgoing connections.
We have the following:
  • Home internet connection with public IP address
    • as an alternative you can use a dynamic DNS service (like dynDNS or similar) but also need a port forwarding for at least port 119 activated by your ISP
  • Home router with SSH access activated, but configured to listen on port 119
    • In case you have no router you can have SSH service/daemon (configured for port 119) running directly on your computer
  • Home PC with OS Windows (XP Professional version, the Home version has a limited remote access) - Terminal services listening standardly on port 3389
  • Home Laptop with OS Linux (Ubuntu Hardy 8.04) - VNC server screen 1 listening on port 5901
  • Office PC with OS Windows XP (not sure if the Professional version is necessary for the Terminal Serveces client) with VNC viewer installed.
Steps to establish the remote desktop connection:
  1. Launch SSH client configured with following command line:
    ssh.exe -L 3391:workstation:3389 -L 5951:laptop:5901 -i .ssh\id_rsa <user>@<home-ip> -p 119
    ... which means:
    • Connect to the remote host with IP <home-ip> (our Home public IP or DNS name) via port 119 as a user <user>
    • Forwarding local port 3391 to port 3389 of remote host "workstation"
    • Forwarding local port 5951 to port 5901 of remote host "laptop"
  2. In order to connect to the Windows machine launch the Terminal services client:
    mstsc.exe /v:localhost:3391
  3. In order to connect to the Linux machine launch the VNC viewer:
    vncviewer.exe localhost:5951
And that's it. Following schema demonstrates the whole situation:

This was a simpler direction (according to the firewall configuration). The more complicated one follows...

Connection towards Office

This direction is a more intricate one, simply because we are trying to go "against" the firewall, it is configured to disallow any incoming connection. So if we cannot connect to the office computer (sitting behind the firewall) what about turning over the problem to the previous (already solved) one? We could possibly be contacted by our office computer instead of trying contact it ourself.
But we still need some way to initiate the whole connection process. After all must be at least some how to pass through the firewall. If there is such facility, we could use it as our trigger (Surely there is such a facility - a good old e-mail ;-).
Now we have the following:
  • Office PC with OS Windows XP (XP Professional version, the Home version has a limited remote access) - Terminal services listening standardly on port 3389 and Outlook client running with a custom e-mail rule starting the connection (we can define a rule for specific sender address, subject or body containing some "magic" string etc).
    • Obviously any other e-mail client (with e-mail rules) can be used. Or it is possible to use another utility running as an OS service - this way it would be possible to contact the computer even when no user was previously logged in.
  • We still need an internet connection with public IP address or at least 119 incomming port forwarding (remember, even when we are connecting to the office - actually our ofice is contacting us ;)
  • Home router with SSH access activated, but configured to listen on port 119. Also we need to have the Office Workstation's rsa key added to the list of router's Authorized keys.
  • Home PC with OS Windows XP (not sure if the Professional version is necessary for the Terminal Serveces client). We can send the initiating e-mail by hand or prepare a script automating the whole connection process (I am using a python script since it can be used on Linux machine as well).
  • Home Laptop with OS Linux (Ubuntu Hardy 8.04) - can be used as a Terminal services client as well.
Steps to establish the remote desktop connection:
  1. From either workstation or laptop we send an initiating e-mail (containing a "magic" pattern)
  2. Outlook client running on the Office Workstation receives the e-mail, recognizes the pattern and initiates the actual connection with Home router with following command line:
    ssh.exe -R 3393:localhost:3389 -i .ssh\id_rsa <user>@<home-ip> -p 119
    ... which means:
    • Connect to the remote host with IP <home-ip> (our Home public IP or DNS name) via port 119 as a user <user>
    • Use the specified identity file (private key) for RSA authentication (this can be used for all ssh sessions but in this case it is necessary - we cannot use the interactive password authentication method in this case ;)
    • Forwarding port 3391 of the remote host (Home router) to local port 3389.
  3. On either workstation or laptop we connect to the router with following command line:
    ssh.exe -L 3391:localhost:3393 <user>@router
    ... which means:
    • Connect to the router (via standard port 22) as a user <user>
    • Forwarding local port 3391 to router's 3393 port
  4. Establish the remote desktop connection to the Office Workstation.
    • From Windows: MSTSC.EXE /v:localhost:3391
    • From Linux: rdesktop localhost:3391 -u <user> -d <domain> -p -
Following schema demonstrates the whole sequence of events:
Note: not all steps are always necessary. The tunnel between Office Workstation and Home router can sometimes last for several days (while sometimes is spontaneously interrupted - it probably depends on a quality of Internet connection) and so it is not necessary to send the initiating e-mail anytime we want to connect to the office. So usually the first thing I do is to open the SSH connection to the router (step 3), determine whether there is the existing office connection (e.g. via ps command I look at the number of dropbear and sh instances) and if so proceed directly to the step 4.

Update - significant simplification


At the time I initially wrote this post I did not know why it was not possible to connect to the router's forwarded port from another host. That was why I created actually two tunnels (Office PC -> Router<- Home PC) when I was connecting remotely to the office.
After some time I have found some more info in this regard: Client side:
As a security precaution, modern versions of ssh forbid other computers on the internet from connecting to the forwarded port (...) unless you explicitly allow it with the "ssh -g" flag
Server side:
If the client is not configured to accept inbound SSH connections, this can be done with remote port forwarding on an outbound connection. (For OpenSSH, note that you may need to set "GatewayPorts yes" in "sshd_config" to achieve on the server what "ssh -g" would do on the client (allow any host to connect to the forwarded port).
Then I found some more info indicating that it does not work for DropBear even when properly configured (here and here):
The reason that the direct login to remote forwarded port doesn't work is - "dropbear binds remote port forwardings to the loopback address. This prevents other remote hosts from connecting to forwarded ports." To fix it, you can recompile dropbear for your router.
I did not want to rebuild dropbear for my router (I do not even have a build toolchain for it) so I kept trying. Finally I realized that when I explicitly use the actual hostname for my router (router in my configuration) instead of localhost (as used by default) on the remote port forwarding command line, it does the trick:
So - on the Office PC command line - instead of former:
ssh.exe -R 3393:localhost:3389 -i .ssh\id_rsa @ -p 119 
Now I am using:
ssh.exe -R router:3389:localhost:3389 -i .ssh\id_rsa @ -p 119 
... and after this change it is possible to connect to the tunnel not only from the router itself but from any other machine in the network.
I did not consider possible security implications, after all I am just a simple user in this regard, so it is up to you to decide which approach better fits your needs, please, don't blame me then.

Steps to establish the remote desktop connection:
  1. From either workstation or laptop we send an initiating e-mail (containing a "magic" pattern)
  2. Outlook client running on the Office Workstation receives the e-mail, recognizes the pattern and initiates the actual connection with Home router with following command line:
    ssh.exe -R router:3389:localhost:3389 -i .ssh\id_rsa <user>@<home-ip> -p 119
    ... which means:
    • Connect to the remote host with IP <home-ip> (our Home public IP or DNS name) via port 119 as a user <user>
    • Use the specified identity file (private key) for RSA authentication (this can be used for all ssh sessions but in this case it is necessary - we cannot use the interactive password authentication method in this case ;)
    • Forwarding port 3389 of the remote host with hostname router" (Home router) to local port 3389.
  3. On either workstation or laptop we establish the remote desktop connection to the Office Workstation as follows:
    • From Windows:
      MSTSC.EXE /v:router
    • From Linux:
      rdesktop router -u <user> -d <domain> -p -
Following schema demonstrates the whole sequence of events:

NX accelerated RDP

@TBD


Read more...

2009/01/18

WMU-6500FS - Deluge 1.1.0

The new deluge version is here!

Build result

[binary] [file list]
If you don't have the previous version (deluge-1.0.5) installed, follow the previous deluge post, install all the prerequisites and dependencies and come back here for the rest. Note that the deluge-1.0.5-gcclibs package is valid even for deluge-1.1.0, so don't get confused with its misleading name.
On the other hand if you have the deluge-1.0.5 installed, you have to clean it up first (while preserve all the already installed dependencies).

Stop the deluge daemon if it is running. You can do it via console:
box# deluge --ui=null
>>> halt
>>> quit
Thanks!

or forcibly:
box# killall deluged
Now uninstall the previous version:
dev# cd /mnt/C/
dev# ./filopack.sh --remove deluge-1.0.5
Configuration file .filopack/.config file found and used
Sure to remove deluge-1.0.5 locally at /mnt/C (y/n)?y
...
If you are not using the filopack packaging system, you can remove the previous version as follows:
box# cd /mnt/C/
box# wget http://filodej.ic.cz/filopack/.filopack/deluge-1.0.5.lst
box# xargs rm -f < deluge-1.0.5.lst
It is likely that deluge developers preserved the compatibility of configuration and the following step is not necessary, I just to be sure delete the configuration as well:
box# mv ~/.config/deluge{,.del}
Now we are ready to install the new version:
box# ./filopack.sh --install deluge-1.1.0
Sure to unpack deluge-1.1.0 locally at /mnt/C (y/n)? y
...
Now we are ready to try the daemon, still it is necessary to use the LD_PRELOAD prefix or deluged.sh script - now updated in order to support parameters (like -d for example) - see this post on mascat for details - if we are lucky, everything runs smoothly:
box# deluged.sh

Default GUI

It is possible to set a default GUI (if you prefer other than predefined GTK GUI):
box# deluge --set-default-ui=console
The default UI has been changed to console
It is nice that now it is not necessary to modify the configuration by hand (like it is described here).

Remote access

The CLI ui has been renamed from null to console. Notice that it is necessary to use LD_PRELOAD prefix just for daemon and GTK GUI, there is no need to use it for the console UI).
We can use it for enabling the remote access (we have to restart the daemon in order to make the change active):
box# deluge --ui=console
>>> config --set allow_remote True
>>> halt
>>> quit
Thanks!

box# deluged.sh

Authentication

Another new feature is the user authentication. For details see [Authentication] and [ThinClient settings]. Without adding a username and password to ~/.config/deluge/auth configuration file you won't be able to remotely connect to the daemon nor event see whether the daemon is running (which is a nice).

Edit: since the ~/.config/deluge/auth file initially does not contain trailing newline the instructions did not work, now it is updated appropriately
box# echo -n -e "\n<username>:<password>" >> ~/.config/deluge/auth
Be sure to append to the file, in case you rewrote the file you won't have been able to connect to it locally, since it initially contains a localclient record. If you accidentally rewrite the file, you can just delete it, restart the daemon and a ui (e.g. the console) and the default file containing localclient authentication info is created for you.

Web GUI

If you want to use the Web GUI (and new Ajax UI seems pretty good to me), now it is not necessary to run the web client on the same machine as daemon. Via the Web GUI you can connect to any daemon you want (not just localhost). Not sure whether I personally utilize it, but it seems to me like a nice feature.

That's all folks.
(The following text is just a (boring) build protocol, totally unnecessary for ordinary users ;-)

Build sequence

It was about the same like in previous version so just in short:

Remove the previous version:
dev# cd /mnt/C/
dev# ./filopack.sh --remove deluge-1.0.5
Configuration file .filopack/.config file found and used
Sure to remove deluge-1.0.5 locally at /mnt/C (y/n)?y
...
Init the timestamp for the new one:
dev# ./filopack.sh --init  deluge-1.1.0
Configuration file .filopack/.config file found and used
Timestamp written to file .filopack/deluge-1.1.0.ts
Download and extract the source:
dev# cd /usr/local/src
dev# wget http://download.deluge-torrent.org/source/1.1.0/deluge-1.1.0.tar.bz2
...
04:37:59 (55.28 KB/s) - `deluge-1.1.0.tar.bz2' saved [2196924/2196924]

dev# tar xjvf deluge-1.1.0.tar.bz2
dev# cd deluge-1.1.0
Setup the include and library paths:
dev# export CFLAGS=-I/mnt/C/sys/include/boost-1_35
dev# export LDFLAGS=-L/mnt/C/sys/lib
Add the missing define:
nano libtorrent/include/libtorrent/socket.hpp

      #ifndef IPV6_V6ONLY
      #define IPV6_V6ONLY 26
      #endif

I did not find the libtorrent/src/memdebug.cpp, so undefining the content of this file is not necessary anymore.

Build the code and install the binaries:
dev# python setup.py build
...
dev# python setup.py install --prefix=/mnt/C/sys/
...
Try to run the daemon:
dev# deluged
dev# /usr/bin/python: can't resolve symbol '__cxa_pure_virtual'
... issue wit h unresolved symbol is still the same. As a workaround the LD_PRELOAD prefix can be used. Let;s create scripts for it:
dev# echo LD_PRELOAD=\"/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0\" deluged \"\$@\" > /mnt/C/sys/bin/deluged.sh
dev# chmod +x /mnt/C/sys/bin/deluged.sh 
dev# echo LD_PRELOAD=\"/usr/lib/libssl.so.0.9.7 /usr/lib/libboost_filesystem-gcc41-mt-1_35.so.1.35.0\" deluge \"\$@\" > /mnt/C/sys/bin/deluge.sh
dev# chmod +x /mnt/C/sys/bin/deluge.sh 
Now the daemon runs ok:
dev# deluged.sh
Let's try the GTK client:
dev# deluge --version
1.1.0
dev# deluge
...
  File "/mnt/C/sys/lib/python2.5/site-packages/deluge-1.1.0-py2.5-linux-i686.egg/deluge/ui/gtkui/common.py", line 

45, in get_logo
    size, size)
gobject.GError: Unrecognized image file format
ChangeAs a fix we can change the extension:
dev# sed -i 's/deluge.svg/deluge.png/g' /mnt/C/sys/lib/python2.5/site-packages/deluge/ui/gtkui/common.py
dev# deluge
Touch related files with older timestamps (in order to include them to the package):
dev# find /mnt/C/sys -path "*deluge*" -type f -exec touch {} \;
Then we are ready to create the package:
dev# cd /mnt/C/sys
dev# ./filopack.sh --pack deluge-1.1.0
...
I noticed that there was duplicity after the installation which made the package twice as big as was necessary: It seems to me that whole directory tree /mnt/C/sys/lib/python2.5/site-packages/deluge-1.1.0-py2.5-linux-i686.egg/deluge was redundant - directory /mnt/C/sys/lib/python2.5/site-packages/deluge had a similar content (including the huge libtorrent.so). I just dropped the former one and everything seems ok and package has 16MB (compared to 31MB).

Read more...

2009/01/06

Cooperative Linux step by step

Introduction:

This post provides a step by step tutorial how to download, install and configure CoLinux with Debian 4.0 file system image. Also the installation of GNOME desktop environment and NX server is covered. As a result we get a graphic Linux environment cooperatively running on the Windows hosting system. It can be seen as an alternative to a conventional "dual boot" configuration - but with both systems running at the same time.


Info sources:
[CoLinux Homepage] [CoLinux Wiki]

[Debian notes] [Debian filesystem image] [More available filesystem images] [Howto install coLinux (and Ubuntu Hardy) on Win XP]

Download and installation


CoLinux binary
You can download binary here.
In my case it was the stable version 0.7.3 (kernel 2.6.22.18) ... coLinux-0.7.3.exe
(an alternative could be the development version 8.0 (kernel 2.6.22.18) ... devel-coLinux-20081130.exe, see this page for details).

Selected components: During the installation the WinPcap (The Windows Packet Capture Library) is installed. It can be downloaded here.

I choose stable WinPcap 4.0.2 (an alternative could be WinPcap 4.1 beta4). We can download (some of) available filesystem images directly during the installation: TAP network adapter is installed (dear Microsoft, sure we want to continue the installation ;-) Now the TAP adapter is installed (but not connected): We have to configure the private IP address of the host system (windows):

Installation paths:
CoLinux binary: c:\programs\coLinux
Filesystem images: c:\programs\coLinux\images

Configure (Windows side)


Config file
We create a new configuration file (just modify the installed example.conf):
C:\> cd programs\coLinux
C:\programs\coLinux> copy example.conf debian.conf
        1 file(s) copied.
C:\programs\coLinux> notepad debian.conf
Now we can specify root image, swap file and possibly other mount points and also define two ethernet devices - one for pcap bridge and second for TAP adapter:
...

# File contains the root file system.
# Download and extract preconfigured file from SF "Images for 2.6".
cobd0="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.1gb"
cofs1=c:\
cofs2=d:\

# Swap device, should be an empty file with 128..512MB.
cobd1="C:\programs\coLinux\images\swap_file.1gb"

# Tell kernel the name of root device (mostly /dev/cobd0,
# /dev/cobd/0 on Gentoo)
# This parameter will be forward to Linux kernel.
root=/dev/cobd0

# Additional kernel parameters (ro = rootfs mount read only)
ro

# Initrd installs modules into the root file system.
# Need only on first boot.
initrd=initrd.gz

# Maximal memory for linux guest
#mem=64

# Slirp for internet connection (outgoing)
# Inside running coLinux configure eth0 with this static settings:
# ipaddress 10.0.2.15   broadcast  10.0.2.255   netmask 255.255.255.0
# gateway   10.0.2.2    nameserver 10.0.2.3
#eth0=slirp

# pcap bridge for internet connection (outgoing)
eth0=pcap-bridge,"Local Area Connection",<an-artificial-mac-address>

# Tuntap as private network between guest and host on second linux device
eth1=tuntap

# Setup for serial device
#ttys0=COM1,"BAUD=115200 PARITY=n DATA=8 STOP=1 dtr=on rts=on"

# Run an application on colinux start (Sample Xming, a Xserver)
# exec0=C:\Programs\Xming\Xming.exe,":0 -clipboard -multiwindow -ac"
Swap file
Also you have to create a swap file, here is how to create it, or if you are lazy like me, you can download one from this site (user Gniarf provides also other interesting info).

Configure (Linux side)

Start colinux daemon:
C:\programs\coLinux> colinux-daemon.exe @debian.conf
Cooperative Linux Daemon, 0.7.3
Daemon compiled on Sat May 24 22:36:07 2008

PID: 3268
error 0x2 in execution
error launching console
daemon: exit code 8200c401
daemon: error - CO_RC_ERROR_ERROR, line 49, file src/colinux/os/winnt/user/exec.c (16)
We did not install the generic console so we have to explicitly say we want to launch the NT console:
C:\programs\coLinux> colinux-daemon.exe -t nt @debian.conf
...
Login as root (a default password is "root"):
login as: root
root@10.0.2.2's password:
Linux debian 2.6.22.18-co-0.7.3 #1 PREEMPT Sat May 24 22:27:30 UTC 2008 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Change the root password
deb# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Network
For easy to use the network is pre-configured for "slirp":
deb# ifconfig
eth0      Link encap:Ethernet  HWaddr 22:01:76:23:42:12
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:59 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:20682 (20.1 KiB)  TX bytes:0 (0.0 b)
          Interrupt:2

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
We change it to dual-ethernet mode (one for uoutide world connection and other for private network between guest and host system):
deb# nano /etc/network/interfaces

Comment out the following:

    # The primary network interface (slirp)
    auto eth0
    iface eth0 inet static
       address 10.0.2.15
       broadcast 10.0.2.255
       netmask 255.255.255.0
       gateway 10.0.2.2

And replace it with following:

    # The primary network interface
    auto eth0
    iface eth0 inet dhcp

Then there is the following:

    # Second network (tap-win32)
    #auto eth1
    #iface eth1 inet static
    #   address 192.168.0.40
    #   netmask 255.255.255.0

... leave it as is (or remove it) and add the following:

    auto eth1
    iface eth1 inet static
       address 10.0.2.2
       network 10.0.2.0
       netmask 255.255.255.0
       broadcast 10.0.2.255
Now save the file and reboot:
deb# reboot
...
We should see now on the Windows side that the TAP adapter is connected: After we login to linux, we can examine the new network configuration:
deb# ifconfig
eth0      Link encap:Ethernet  HWaddr <an-artificial-mac-address>
          inet addr:192.168.1.196  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17220 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11031 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:24760203 (23.6 MiB)  TX bytes:770417 (752.3 KiB)
          Interrupt:2

eth1      Link encap:Ethernet  HWaddr 00:FF:68:B7:70:00
          inet addr:10.0.2.2  Bcast:10.0.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2238 (2.1 KiB)  TX bytes:0 (0.0 b)
          Interrupt:2

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Packaging system
Now (we are connected to the internet) it is time to update the package system and upgrade installed packages:
deb# apt-get update
...
deb# apt-get upgrade
The following packages will be upgraded:
  bsdutils cpio debconf debconf-i18n debian-archive-keyring dpkg e2fslibs
  e2fsprogs findutils initscripts libblkid1 libc6 libcomerr2 libgnutls13
  libpam-modules libpam-runtime libpam0g libss2 libuuid1 lsb-base mount nano
  perl-base sysv-rc sysvinit sysvinit-utils tar tzdata util-linux
29 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 12.3MB of archives.
After unpacking 1786kB disk space will be freed.
Do you want to continue [Y/n]? Y
...
Mount table
Now we can modify the mount table:
deb# nano /etc/fstab
... add the following if you want to mount C: and D: windows drives (we made it available as cofs devices in debian.conf file):
cofs1            /mnt/c         cofs    defaults,noatime  0      0
cofs2            /mnt/d         cofs    defaults,noatime  0      0
Of course you can add anything you want, for example I wanted to make a cifs mount to a NAS directory:
//storage/filodej   /mnt/storage/filodej   cifs defaults,credentials=/etc/storage.smbpass 0 0
The storage-filodej.smbpass is a file readable just by root and containing a username and his password:
deb# cd /etc
deb# echo "username=filodej" > storage.smbpass
deb# chmod 600 storage.smbpass
deb# echo "password=<filodej-password>" >> storage.smbpass
deb# cat storage.smbpass
username=filodej
password=<filodej-password>
Now we have to create corresponding mount point directories:
deb# cd /mnt
deb# mkdir c
deb# mkdir d
deb# mkdir --parents storage/filodej
Test the mount table:
deb# mount -a
mount: wrong fs type, bad option, bad superblock on //storage/filodej,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
It seems I forgot to to install the samba file system:
deb# apt-get install smbfs

Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  libkrb53 libpopt0 samba-common
Suggested packages:
  krb5-doc krb5-user smbclient
The following NEW packages will be installed:
  libkrb53 libpopt0 samba-common smbfs
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 3232kB of archives.
After unpacking 7827kB of additional disk space will be used.
Do you want to continue [Y/n]? Y
...
During the installation we have to specify the Domain/Workgroup name and decide whether to use WINS settings from DHCP (and install dhcp3-client package).

Now the command:
deb# mount -a
... works as expected.

Install CoLinux as a Windows Service

We need to be able to access the running linux system somehow. I am using mostly the SSH for that purpose.
First we have to install ssh daemon it on the linux system:
deb# apt-get install ssh
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  libedit2 libssl0.9.8 openssh-blacklist openssh-client openssh-server
Suggested packages:
  ssh-askpass xbase-clients rssh molly-guard
The following NEW packages will be installed:
  libedit2 libssl0.9.8 openssh-blacklist openssh-client openssh-server ssh
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
Need to get 5779kB of archives.
After unpacking 12.7MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
...
Setting up ssh (4.3p2-9etch3) ...

deb# eth0: duplicate address detected!
The duplicate address detected! issue is described here.
I have associated the <an-artificial-mac-address> with static-DHCP assigned IP but the warning stil does persist. If anyone knows the solution, please let me know!

Anyway the ssh daemon is now up and running and we are able to connect to the linux system via ssh (on the host machine we can use either eth0 public IP or better the eth1 private IP). Now we are ready to create a windows service and run the colinux as a service.

The detailed guide for the service creation can be seen here. The following command does the job:
C:\programs\coLinux> colinux-daemon @debian.conf --install-service "coLinux-Debian"
Cooperative Linux Daemon, 0.7.3
Daemon compiled on Sat May 24 22:36:07 2008

daemon: installing service 'coLinux-Debian'
daemon: service command line: "c:\programs\coLinux\colinux-daemon.exe" @debian.conf --run-service "coLinux-Debian"
daemon: setting restart options
daemon: service installed.
Now we can start colinux daemon as a service:
C:\programs\coLinux> net start "coLinux-Debian"

The coLinux-Debian service was started successfully.

Linux administration


Create a new user
[Add user howto]
deb# adduser --home /home/filodej --ingroup users filodej
Adding user `filodej' ...
Adding new user `filodej' (1001) with group `users' ...
Creating home directory `/home/filodej' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for filodej
Enter the new value, or press ENTER for the default
        Full Name []: Filodej
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [y/N] y
Install sudo
[linux sudo command]
deb# apt-get install sudo
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  sudo
0 upgraded, 1 newly installed, 0 to remove and 36 not upgraded.
Need to get 162kB of archives.
After unpacking 406kB of additional disk space will be used.
Get:1 http://ftp.debian.org etch/main sudo 1.6.8p12-4 [162kB]
Fetched 162kB in 1s (95.8kB/s)
Selecting previously deselected package sudo.
(Reading database ... 25225 files and directories currently installed.)
Unpacking sudo (from .../sudo_1.6.8p12-4_i386.deb) ...
Setting up sudo (1.6.8p12-4) ...
No /etc/sudoers found... creating one for you.
Let's look at the sudoers definition file:
deb# cat /etc/sudoers
# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults        env_reset

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL
Now we can make the new user sudoer:
deb# visudo
...
Let's look at the result:
deb# cat /etc/sudoers
# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults        env_reset

# Host alias specification

# User alias specification
filodej    ALL=(ALL) ALL

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL) ALL

Resize the root filesystem

[Expanding root filesystem howto]

I decided for the most reliable way.
First we look at the current filesystem:
deb# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cobd0             1031064    197876    780812  21% /
tmpfs                   387996         0    387996   0% /lib/init/rw
udev                     10240        16     10224   1% /dev
tmpfs                   387996         0    387996   0% /dev/shm
cofs1                156280288  44298800 111981488  29% /mnt/c
cofs2                156280288    240400 156039888   1% /mnt/d
//storage/filodej     10175328   2711828   7463500  27% /mnt/storage/filodej
Now we halt the system (if we are logged as a normal user, we have to use sudo):
deb# sudo halt
...
Broadcast message from root@debian (pts/2) (Wed Dec 10 05:11:48 2008):

The system is going down for system halt NOW!
On windows we now go to the images directory:
C:\> cd programs\coLinux\images

C:\programs\coLinux\images> dir
 Volume in drive C has no label.
 Volume Serial Number is F488-7A65

 Directory of C:\programs\coLinux\images

01/06/2009  21:49    <DIR>          .
01/06/2009  21:49    <DIR>          ..
01/06/2009  20:29     1,072,693,248 Debian-4.0r0-etch.ext3.1gb
03/27/2008  19:59        40,795,971 Debian-clean.1gb.bz2
12/22/2008  22:32     1,073,741,824 swap_file.1gb
               3 File(s)  2,187,231,043 bytes
               2 Dir(s)  124,332,199,936 bytes free
Now make a backup copy of the old filesystem:
C:\programs\coLinux\images> copy Debian-4.0r0-etch.ext3.1gb Debian-4.0r0-etch.ext3.1gb.tmp
        1 file(s) copied.
Create a new (empty) file (e.g. 8GB in this case):
C:\programs\coLinux\images> fsutil file createnew Debian-4.0r0-etch.ext3.8gb 8589934592
File C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.8gb is created
Let's list the images directory again:'
C:\programs\coLinux\images> dir
 Volume in drive C has no label.
 Volume Serial Number is F488-7A65

 Directory of C:\programs\coLinux\images

01/06/2009  22:02    <DIR>          .
01/06/2009  22:02    <DIR>          ..
01/06/2009  13:07     1,072,693,248 Debian-4.0r0-etch.ext3.1gb
01/06/2009  20:29     1,072,693,248 Debian-4.0r0-etch.ext3.1gb.tmp
01/06/2009  22:02     8,589,934,592 Debian-4.0r0-etch.ext3.8gb
03/27/2008  20:59        40,795,971 Debian-clean.1gb.bz2
01/06/2009  22:02                 0 fsutil
12/22/2008  22:32     1,073,741,824 swap_file.1gb
               6 File(s) 11,849,858,883 bytes
               2 Dir(s)  114,669,043,712 bytes free
Now we can modify the debian.conf configuration file as follows:
C:\programs\coLinux\images> cd ..

C:\programs\coLinux> notepad debian.conf
Add the two newly created file images as block devices:
# File contains the root file system.
# Download and extract preconfigured file from SF "Images for 2.6".
cobd0="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.1gb"
cobd3="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.1gb.tmp"
cobd4="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.8gb"
cofs1=c:\
cofs2=d:\
Now we can boot the colinux up and login as root:
C:\programs\coLinux> colinux-daemon.exe -t nt @debian.conf
...
debian login: root
Password:
...
deb#
Now we check if the the copy of the old filesystem is clean:
deb# e2fsck /dev/cobd3
e2fsck 1.40-WIP (14-Nov-2006)
/dev/cobd3: clean, 8967/131072 files, 53582/261888 blocks
If we now try to check the empty image, we (presumably) get the error:
deb# e2fsck /dev/cobd4
e2fsck 1.40-WIP (14-Nov-2006)
Couldn't find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/cobd4

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
Let's copy the raw data from the old image to the new:
deb# dd if=/dev/cobd3 of=/dev/cobd4
2095104+0 records in
2095104+0 records out
1072693248 bytes (1.1 GB) copied, 110.632 seconds, 9.7 MB/s
Now we can check the filesystem (-f will force checking even if filesystem is marked clean):
deb# e2fsck -f /dev/cobd4
e2fsck 1.40-WIP (14-Nov-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/cobd4: 8967/131072 files (0.6% non-contiguous), 53582/261888 blocks
Let's resize the filesystem from 1GB to 8GB:
deb# resize2fs -p /dev/cobd4
resize2fs 1.40-WIP (14-Nov-2006)
Resizing the filesystem on /dev/cobd4 to 2097152 (4k) blocks.
Begin pass 1 (max = 56)
Extending the inode table     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/cobd4 is now 2097152 blocks long.
... and check it again:
deb# e2fsck -f /dev/cobd4
e2fsck 1.40-WIP (14-Nov-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/cobd4: 8967/1048576 files (0.6% non-contiguous), 82374/2097152 blocks
Now we are almost done and can halt the system:
deb# halt
In windows we can modify the debian.conf configuration file again:
C:\programs\coLinux> notepad debian.conf
Remove the two newly block devices and change the root file system to Debian-4.0r0-etch.ext3.8gb:
# File contains the root file system.
# Download and extract preconfigured file from SF "Images for 2.6".
#cobd0="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.1gb"
cobd0="C:\programs\coLinux\images\Debian-4.0r0-etch.ext3.8gb"
cofs1=c:\
cofs2=d:\
Now we can boot the colinux up and login:
C:\programs\coLinux> colinux-daemon.exe -t nt @debian.conf
...
debian login: root
Password:
...
deb#
Now we can inspect the free space we have:
deb# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cobd0             8256952    197876   7723532   3% /
tmpfs                   387996         0    387996   0% /lib/init/rw
udev                     10240        16     10224   1% /dev
tmpfs                   387996         0    387996   0% /dev/shm
cofs1                156280288  44281916 111998372  29% /mnt/c
cofs2                156280288    240400 156039888   1% /mnt/d
//storage/filodej     10175328   2711828   7463500  27% /mnt/storage/filodej
We are done for now, if everything goes fine we can possibly delete both the original image and its temporary copy.

GNOME installation

[HOWTO: Minimal Debian Install (GNOME/KDE)]
[Installing x server]
You have to decide what display manager and Desktop environment to install.

Following table shows the numbers of packages and download and intallation sizes for "core" and "full" variations of mainstream environments GDM/GNOME and KDM/KDE:

# packages Archive size Additional disk space
xorg 109 54.6 MB 143 MB
xorg + gnome-core 274 142 MB 461 MB
xorg + gnome 472 300 MB 931 MB
xorg + kde-core 208 120 MB 318 MB
xorg + kde 543 312 MB 830 MB

I decided to try "full" GNOME installation:
deb# apt-get install xorg gnome
...
0 upgraded, 472 newly installed, 0 to remove and 0 not upgraded.
Need to get 300MB of archives.
After unpacking 931MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
...
... during the relatively lenthy process of the installation (on my machine it was 30 minutes for downloading and 15 minutes of installation) the xserver-xorg is configured and we are asked for desired screen resolutions. We are going to uninstall this package anyway so I do not think the settings we choose have any significant effect.

After the installation is finished we can inspect the free space:
debian:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cobd0             8256952   1430612   6490796  19% /
tmpfs                   387996         0    387996   0% /lib/init/rw
udev                     10240        16     10224   1% /dev
tmpfs                   387996         0    387996   0% /dev/shm
cofs1                156280288  44284428 111995860  29% /mnt/c
cofs2                156280288    240400 156039888   1% /mnt/d
//storage/filodej     10175328   2711828   7463500  27% /mnt/storage/filodej
... and see that (as expected) the amount of used space on the root filesystem actually risen by approximately 1.2 GB.

NX server

[NX technology] [FreeNX] [A look at NoMachine NX] [NoMachine NX server free edition] [Installing NoMachine NX server] [NX keyboard shortcuts]
The following is written about the licensing model of NX technology on wikipedia:
NoMachine uses the GNU General Public License for the core NX technology, while at the same time offering non-free commercial NX server[2] and client products for Linux, Microsoft Windows, Solaris, Mac OS X and embedded systems.

Due to the free software nature of NX, the FreeNX project was started in order to provide the wrapper scripts for the GPL NX libraries. FreeNX is developed and maintained by Fabian Franz.

FreeNX server
At first I tried to install the FreeNX on my Laptop with Ubuntu installation but did not succeed. I used this and this tutorial, everything went fine, the only thing that did not work was the shadow session from windows client.
Every time I was connecting in shadow mode from windows client, nxagent on server side crashed:
Dec 19 17:08:23 notas kernel: [53641.720283] nxagent[5639]: segfault at 0000002c eip 080e9137 esp bff23b50 error 6
I tried to uninstall compiz (as someone advised) but it did not help. Maybe it was due to the client/server version incompatibility (I have used newer version of NoMachine windows client). As a result I decided to try the NoMachine NX server (free edition). It is limited for only two users or two simultaneous connections to the server, but this limitation was not so significant for me.

NoMachine NX server
If you are using "full" GNOME installation then the first thing I would recommend to do is to install the CUPS print server. The reasons are described here (the issue was not necessarily connected with NX server, but also NX server complained when the CUPS was not installed):
deb# apt-get install cupsys
...
Now we can proceed to the actual installation.

The NX Free Edition for Linux can be downloaded from this page. The release I am using is 3.3.0-8.

For the installation of NX server I have followed this tutorial.
We will need three packages: nxclient, nxnode and nxserver:
deb# cd /tmp
deb# wget http://64.34.161.181/download/3.3.0/Linux/nxclient_3.3.0-3_i386.deb
...
Length: 3,859,966 (3.7M) [application/x-debian-package]
...
deb# wget http://64.34.161.181/download/3.3.0/Linux/nxnode_3.3.0-3_i386.deb
Length: 6,251,244 (6.0M) [application/x-debian-package]
deb# wget http://64.34.161.181/download/3.3.0/Linux/FE/nxserver_3.3.0-8_i386.deb
...
Length: 6,717,880 (6.4M) [application/x-debian-package]
...
First we have to install the client (even if we are was not going to use it):
deb# dpkg -i nxclient_3.3.0-3_i386.deb
Selecting previously deselected package nxclient.
(Reading database ... 53454 files and directories currently installed.)
Unpacking nxclient (from nxclient_3.3.0-3_i386.deb) ...
Setting up nxclient (3.3.0-3) ...
Showing file: /usr/NX/share/documents/client/cups-info

 CUPS Printing Backend

 The NX Client set-up procedure detected that your "IPP CUPS" printing
 backend doesn't allow printing from the NX session. In order to have
 printing support in your NX system, you need to set proper permissions
 on the IPP backend. Please execute:

   chmod 755 /usr/lib/cups/backend/ipp
Ok, let's do what we are told:
deb# chmod 755 /usr/lib/cups/backend/ipp
Then the nxnode has to be installed:
deb# dpkg -i nxnode_3.3.0-3_i386.deb
Selecting previously deselected package nxnode.
(Reading database ... 55884 files and directories currently installed.)
Unpacking nxnode (from nxnode_3.3.0-3_i386.deb) ...
Setting up nxnode (3.3.0-3) ...
NX> 700 Starting: install node operation at: Tue Jan 06 12:08:11 2009.
NX> 700 Autodetected system 'debian'.
NX> 700 Install log is '/usr/NX/var/log/install'.
NX> 700 Checking NX node configuration using /usr/NX/etc/node.cfg file.
NX> 700 Inspecting local CUPS environment.
NX> 700 Generating CUPS entries in: /usr/NX/etc/node.cfg.
NX> 700 Installation of version: 3.3.0-3 completed.
NX> 700 Showing file: /usr/NX/share/documents/node/cups-info

     CUPS Printing Backend

     The NX Node setup procedure could not detect your "CUPS"
     installation: either CUPS  is not installed on your system
     or it was installed in a non-standard path. CUPS is needed
     in order to enable printing support in your NX system.
     Please note that you can enable  printing support for your
     NX system at any time; to do this make sure  that you have
     CUPS installed then run:

       /usr/NX/scripts/setup/nxnode --nxprintsetup 

     to specify the location of the CUPS root path.
... the CUPS related warning is hopefully not there if you have the CUPS server installed. If the warning is still there, the solution is simple:
deb# /usr/NX/scripts/setup/nxnode --nxprintsetup
NX> 701 Starting: nxprintsetup operation at: Mon Jan 05 13:14:31 2009.
NX> 701 Inspecting local CUPS environment.
NX> 701 Generating CUPS entries in: /usr/NX/etc/node.cfg.
NX> 701 CUPS configuration updated.
The last step is to install the nxserver itself:
deb# dpkg -i nxserver_3.3.0-8_i386.deb
Selecting previously deselected package nxserver.
(Reading database ... 56081 files and directories currently installed.)
Unpacking nxserver (from nxserver_3.3.0-8_i386.deb) ...
Setting up nxserver (3.3.0-8) ...
NX> 700 Installing: server at: Tue Jan 06 12:09:23 2009.
NX> 700 Autodetected system: debian.
NX> 700 Install log is: /usr/NX/var/log/install.
NX> 700 Creating configuration file: /usr/NX/etc/server.cfg.
NX> 723 Cannot start NX statistics:
NX> 709 NX statistics are disabled for this server.
NX> 700 Version '3.3.0-8' installation completed.
NX> 700 Showing file: /usr/NX/share/documents/server/install-notices

Server keys

The initial login between client and server happens through a DSA key
pair, i.e. a couple of specially generated cryptographic keys, called
the private key and the public key, which allow you to establish a
secure connection, by means of SSL encryption, between NX client and
NX server.

The public part of the key-pair is provided during the installation
of the server, while the private part of the key-pair is distributed
together with the NX Client. This ensures that each NX client is able
to authenticate to the server and to start the procedure for autho-
rizing the user and negotiating the session.

If you want to create a virtual private network (VPN) instead, you
need to generate a new DSA key-pair and distribute the private part
of the key-pair to those NX clients you want authenticated to the NX
server. More information on how to generate and distribute a new DSA
key-pair is available at:

http://www.nomachine.com/ar/view.php?ar_id=AR01C00126

Creating Users

NX is configured to allow access from any system user, as long as
valid credentials are given to the user for the SSH login. NX pro-
vides an alternative authorization method, allowing system admin-
istrators to determine which users are given access to the NX fun-
ctionalities. This works by implementing a separation between the
system password and the NX password, so that, for example, it is
possible to forbid remote access to the system by any other means
except via NX and use the NX tools to implement effective accounting
of the system resources used by the user, or to share NX passwords in
an external database.

To activate the NX user and password DBs, you will have to edit the
NX server configuration file by hand or use the NX Server Manager
Web tool available for download on the NoMachine Web site at:

http://www.nomachine.com/download-manager.php

Session Shadowing and Desktop Sharing

The session shadowing functionality allows you to share NX sessions
running on the node. The desktop sharing functionality instead, gives
access to the native display of the X server as if you were in front
of the monitor. By default you can access sessions in interactive mode
and upon authorization of the session owner. You can modify this beha-
viour by tuning the server configuration according to your needs, for
example by allowing access to sessions in view-only mode, or connecting
to either a suspended session or the local display via the Desktop
Manager login window.

Load Balancing

NX Advanced Server provides support for multi-node capabilities and
load balancing. In its current implementation, NX server can only
manage accounts on the host machine, so to grant access to the node
running remotely, you will need to create the user account directly
on the remote node host by issuing the NX node commands as root user.
You will also need to add the NX Server public DSA Key to the node to
allow this server to connect to the node running on the remote host.

Documentation

For further information on how to manage the configuration of your
NX system, please refer to the System Administrator's Guide available
on the NoMachine Web site at:

http://www.nomachine.com/documentation/admin-guide.php

The NoMachine Team.

NX> 700 Bye.

NX Client for Windows
NX Client for Windows can be downloaded from this page. Its installation is straightforward.

NX Connection wizard
With help of the NX connection wizard we can create a new session (if we are on local machine we can use the private TAP ethernet address): Here we choose a desktop environment (Gnome in this case) and a resolution: In advanced configuration we can modify everything we setup so far and much more: If we are on local machine I would recommend to disable image compression (icons and images then look better): We save the session settiongs and proceed to login dialog: The first time we are asked to story the RSA fingerprint (there is SSH running under the covers): Now we are succesfully connected to a new Gnome session:

Issues

X server start failure at boot time

When we reboot from the console we realize that X server is (unsuccesfully) started during the boot process: Actually we do not need xserver running on the coLinux side, we are going to connect via the NX server or use an X server running on the Windows side. As a solution we can uninstall the unnecessary gdm and xserver-xorg.

I admit that this install/uninstall approach seems weird, but currently I do not know a better solution, when I tried to just install the gnome without xorg the nxclient connection did not succeed. If someone with better knowledge of GNOME/X server/NX server dependencies knows a better approach, please, let me know.

Anyway, let's remove the GDM for now:
deb# apt-get remove gdm
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  fast-user-switch-applet gdm gdm-themes gnome gnome-desktop-environment
0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded.
Need to get 0B of archives.
After unpacking 17.4MB disk space will be freed.
Do you want to continue [Y/n]? Y
(Reading database ... 52440 files and directories currently installed.)
Removing gnome ...
Removing gnome-desktop-environment ...
Removing fast-user-switch-applet ...
Removing gdm-themes ...
Removing gdm ...
Stopping GNOME Display Manager: gdm.
... and also the xserver:
deb# apt-get remove xserver-xorg
Reading package lists... Done
Building dependency tree... Done
The following packages will be REMOVED:
  xorg xserver-xorg xserver-xorg-core xserver-xorg-input-all
  xserver-xorg-input-evdev xserver-xorg-input-kbd xserver-xorg-input-mouse
  xserver-xorg-input-synaptics xserver-xorg-video-all xserver-xorg-video-apm
  xserver-xorg-video-ark xserver-xorg-video-ati xserver-xorg-video-chips
  xserver-xorg-video-cirrus xserver-xorg-video-cyrix xserver-xorg-video-dummy
  xserver-xorg-video-fbdev xserver-xorg-video-glint xserver-xorg-video-i128
  xserver-xorg-video-i740 xserver-xorg-video-i810 xserver-xorg-video-imstt
  xserver-xorg-video-mga xserver-xorg-video-neomagic
  xserver-xorg-video-newport xserver-xorg-video-nsc xserver-xorg-video-nv
  xserver-xorg-video-rendition xserver-xorg-video-s3
  xserver-xorg-video-s3virge xserver-xorg-video-savage
  xserver-xorg-video-siliconmotion xserver-xorg-video-sis
  xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-tga
  xserver-xorg-video-trident xserver-xorg-video-tseng xserver-xorg-video-v4l
  xserver-xorg-video-vesa xserver-xorg-video-vga xserver-xorg-video-via
  xserver-xorg-video-vmware xserver-xorg-video-voodoo
0 upgraded, 0 newly installed, 44 to remove and 0 not upgraded.
Need to get 0B of archives.
After unpacking 19.3MB disk space will be freed.
Do you want to continue [Y/n]? Y
...
...and reboot to make sure the boot-up startx problem is gone.

Screensaver draining the CPU
The default GNOME screensaver "Floating Debian" was relatively CPU greedy. I disabled it and choose the "Blank screen" ( Desktop -> Preferences -> Screensaver ).

Gnome stopped responding
Initially I ran the GNOME and had not the CUPS server installed. Everything went fine but after few days a problem emerged. When I logged in desktop environment after some time (typically couple dozens of seconds) it stopped responding.
When I tried to start gnome session directly from console (using XMing server), there was the same problem, but fortunately the following warning appeared on the console just about the same time the desktop stopped responding:
deb# gnome-session
...
** (gnome-cups-icon:6107): WARNING **: Could not start the printer tray icon, because the CUPS server could not be contacted.
The issue is very similar to this (unresolved) one.
It is likely that the issue is not connected with NX server, but it is a coincidence that also the NX server installation complained about the fact that the CUPS server was not installed.
As a solution I decided to install the CUPS server:
deb# apt-get install cupsys
Reading package lists... Done
Building dependency tree... Done
The following extra packages will be installed:
  cupsys-common libslp1 poppler-utils
Suggested packages:
  cupsys-bsd cupsys-driver-gutenprint cupsys-driver-gimpprint
  foomatic-filters-ppds xpdf-korean xpdf-japanese xpdf-chinese-traditional
  xpdf-chinese-simplified cups-pdf hplip slpd openslp-doc
Recommended packages:
  cupsys-client smbclient foomatic-filters
The following NEW packages will be installed:
  cupsys cupsys-common libslp1 poppler-utils
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 2604kB of archives.
After unpacking 12.1MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
...
The installation complained about non-multicasting kernel, but hopefully it will not be a big problem:
To reduce network traffic use a IP multicast enabled kernel

The kernel version that you are currently running does not appear to     
support IP multicast. OpenSLP will continue to work even without
multicast support in the kernel by using broadcasts. However, broadcasts 
are less efficient on the network, so please consider upgrading to a
multicast enabled kernel.


Missing fonts
When I run emacs the following error appeared:
deb# emacs
Warning: Cannot convert string "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" to type FontStruct
Warning: Cannot convert string "-*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1" to type FontStruct
... and the emacs application looked as follows:
The XOrg configuration seemed ok:
deb# cat /etc/X11/xorg.conf | grep FontPath
        FontPath        "/usr/share/fonts/X11/misc"
        FontPath        "/usr/share/fonts/X11/cyrillic"
        FontPath        "/usr/share/fonts/X11/100dpi/:unscaled"
        FontPath        "/usr/share/fonts/X11/75dpi/:unscaled"
        FontPath        "/usr/share/fonts/X11/Type1"
        FontPath        "/usr/share/fonts/X11/100dpi"
        FontPath        "/usr/share/fonts/X11/75dpi"
        FontPath        "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType"
... the font paths really exist and contain the corresponding fonts:
deb# find /usr/share/fonts/X11/ -name *helv*
/usr/share/fonts/X11/100dpi/helvB08.pcf.gz
/usr/share/fonts/X11/100dpi/helvB10.pcf.gz
/usr/share/fonts/X11/100dpi/helvB12.pcf.gz
...
Really, there were some fonts matching the font name patterns:
deb# xlsfonts -fn '-*-helvetica-medium-r-*-*-*-120-*-*-*-*-iso8859-1'
-adobe-helvetica-medium-r-normal--12-120-75-75-p-0-iso8859-1
-adobe-helvetica-medium-r-normal--12-120-75-75-p-0-iso8859-1
-adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
-adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso8859-1
deb# xlsfonts -fn '-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*'
-adobe-courier-medium-r-normal--12-120-75-75-m-0-iso8859-1
-adobe-courier-medium-r-normal--12-120-75-75-m-0-iso8859-1
-adobe-courier-medium-r-normal--12-120-75-75-m-70-iso8859-1
-adobe-courier-medium-r-normal--17-120-100-100-m-100-iso8859-1
Finally the solution (or at least workaround, since I initially thought it should not be necessary) was to download the additional fonts for nxclient (windows side) from NoMachine site. It helped in my case, although I don't fully understand why it was necessary, see the note from the NoMachine site:
NOTE: The additional fonts are only needed when running very old Unix applications, requiring the use of client-side fonts. All recent Unix applications use fonts stored on the server, that are fully supported by NX.


Microsoft TrueType fonts
With default settings some websites (like Reddit) render in fonts without antialiasing. The page with such fonts looks like follows:
In font mapper settings you can probably do many things about it, but I am not expert in this area. What worked for me was to install the fonts I am used to - the msttcorefonts package.
In order to be able to install the fonts, you have to extend your sources.list to provide access to non-free packages. For detailed explanation see this post.
After the successful installation the same site looks as follows:

Read more...