[FreeNX-kNX] FreeNX 0.4.0 "SambaXP Edition" released

Fabian Franz FabianFranz at gmx.de
Tue May 10 22:30:14 UTC 2005

Hash: SHA1

The Internet 4th May, 2005:

The FreeNX Team is proud to release FreeNX-0.4.0. It is code-named 
"SambaXP Edition" for two reasons:

 * its first public announcement happened during the SambaXP 
   Conference in Goettingen/Germany.

 * this version utilizes for the first time Samba to support
   file sharing between NX client and FreeNX server.

FreeNX 0.4.0 sports several new feature and fixes for all bugs found 
in 0.3.1.


1. Overview
2. Features in detail
3. Fixes in detail
4. Download
5. Next plans

1. Overview

New major features include:

        - Full filesharing support via Samba.
        - Sound support via ESD/artsd.
        - Printing support via Samba and a separate userspace cupsd for
          each user session.

Additionally FreeNX now is feature complete in regard to configuration 
variables present in node.conf.

New miscellaneous features include:

        - "nxloadconfig --check" to check for correct settings.
        - Support for utmp/wtmp/lastlog database as users log in.
        - Forward to commercial NoMachine NX server via destination port.
        - 7 different levels of logging facility.
        - SESSION_LOG_CLEAN for debugging help.
        - ENCRYPTION can be forced by the NX Server.
        - DEFAULT_X_WM now supported; can start window manager of choice.

New fixes include:

        - stderr is redirected correctly to loglevel 7.
        - SSH is correctly detected in nxsetup.
        - More compatible functions for porting purposes.
        - Fixed some possible race conditions to prevent failed sessions.

Fixes against version 0.3.1 include:
        - Many fixes for more overall stability in session negotiation.

The file node.conf.sample is now completely cleaned up and documented. 
Please take a look at it to learn how to tweak and fine-tune your FreeNX 

2. Features in detail

Full filesharing support via Samba
- ----------------------------------

This means that you can share specific directories from your NX Client 
Machine (Windows or Linux) with the help of Samba to a remote NX Server.

Note: This feature does not require a running Samba daemon (smbd) on the 
FreeNX server.

If smbmnt is correctly setup (i.e. suid root) and smbmount and smbumount 
are both installed, filesharing should work "out of the box".

Just select the shares to be shared with the remote system in NX Client 
and off you go.

Sound support via ESD/artsd
- ---------------------------

Sound support is implemented via esd or artsd.

This feature requires esd and/or artsd installed on the FreeNX server.

Whether esd or artsd is used is automatically determined by the NX client. 
If you use the NoMachine NX client on a Windows or a Mac OS X machine, the 
FreeNX server will use esd. If you use the NX client on Linux, the FreeNX 
server will use artsd for sound forwarding.

The solution that lets sound "just work" with all applications is using 
the well known wrapper applications artsdsp and esddesp. artsd is part of 
the "arts" software package of most Linux distributions. esddesp is part 
of the "esound" package of most Linux distributions.

However, a bug in esd may prevent the correct function. To have this work 
with esd you may need to install a patched version of esd. This is 
explained in a mail to the FreeNX-kNX mailing list:


To get sound in your FreeNX sessions, just enable several configuration 
variables and you are done. Extract from node.conf:

   # FreeNX with ENABLE_ESD_PRELOAD="1" will automatically try to setup
   # the sound with the help of the esd media helper.
   # Currently ESD will be used just by the Windows NX Client.
   # Be sure that $ESD_BIN_PRELOAD is in your path, does exist and work
   # before enabling this directive.
   # FreeNX with ENABLE_ARTSD_PRELOAD="1" will automatically try to setup
   # the sound with the help of the artsd media helper.
   # Currently ARTSD will be used just by the Linux NX Client.
   # Be sure that $ARTSD_BIN_PRELOAD is in your path, does exist and work 
   # before enabling this directive.

Sound applications will then directly use /dev/dsp and are redirected by
artsdsp or esddsp to the real sound server.

Printing support via Samba and a userspace cupsd
- ------------------------------------------------

It was a tough fight against the time, but initial printing support could 
be successfully added just before the feature freeze.

To enable printing support via Samba and the userspace CUPS daemon you 
must first setup the NX Client to share a printer that is locally known
to the NX Client. 

Then when you are connected to the remote FreeNX session, a dialog will 
prompt you to select a driver for your printer.

Following that, FreeNX starts a new cupsd process in userspace. This new
process binds to a port different to 631 (and above 1024). The port number
used is "9000 plus the number for the NX display".

Therefor, any CUPS client command (lp, lpadmin, lpoptions, lpstat, lpc,
lpq) can directly connect to that cupsd by using the environment variable


This means if your FreeNX session runs on display :1006, you would list 
your printers on that CUPSd like that:

   IPP_PORT=10006 lpstat -p

Your list of completed jobs would be listed like:

   IPP_PORT=10006 lpstat -W completed -o

The use of commandline printing might sound quite complicated. Be happy 
- -- there is a better way for those of you using KDE in their FreeNX 


Setting ENABLE_KDE_CUPS="1" allows FreeNX to directly write to your 
NX user's $KDEHOME/share/config/kdeprintrc and automatically sets up
printing with KDE in the right way. As a result you should see this 
info in the kprinter dialog [expanded view mode] on the lower edge
"Server localhost:10006" instead of "Server localhost:631".

You can change the IPP_PORT setting also with the kprinter GUI, should
the auto-setup not have worked for you:

   1. Click on "System Options..." (lower edge button row)
   2. Click onto "CUPS server" 
   3. Fill in "Server Information" with "Host: localhost" and "Port:
      10006" (or whatever port is appropriate for you)
   4. Confirm with "OK".

"nxloadconfig --check" to check for correct settings
- ----------------------------------------------------

This is just a useful utility to check if all settings in node.conf are 

Support for utmp/wtmp/lastlog database about user logins
- --------------------------------------------------------

One of the most frequently requested features recently was an ability 
to store session information about user logins into utmp/wtmp/lastlog.

NX has now configuartion directives to enable that:

   # If enabled writes entries via the COMMAND_SESSREG program
   # into utmp/wtmp/lastlog database.
   # Note: You have to make sure that you add the nx user to the
   #       utmp or tty group or how its called on your system
   #       before this directive works.

Forwarding to a commercial NoMachine NX server via destination port
- -------------------------------------------------------------------

As some of you are aware, we support the parallel installation and usage 
of a FreeNX and commercial NoMachine NX server on the same box, with a 
choice for users to connect to either of both.

This was implemented by using "freenx.my_username" (for a FreeNX session) 
or "my_username" (for a NoMachine NX session) in the NX Client setup. 

This method did work quite well, but there were several problems with not 
cleanly terminated sessions occurring.

Because this feature is an absolute need for everyone evaluating both 
FreeNX and NoMachine NX at the same time, we have come up with a better 

This solution complements/replaces the previous one. 

You can now forward NX sessions based on the destination port.

This means you f.e. SSHD configure to run on port 22 as well as on port 
23 (does anyone still use telnet?) and let FreeNX forward all connections 
on 22 to the commercial NoMachine server:

   # To just forward connections to the NoMachine server, which connect 
   # to a certain port enable the following two directives.
   # Note: You need to let SSHD listen to several ports to make use of
   #       this directive.

7 levels of logging facility
- ----------------------------

Many users felt that the NX Server log was much too verbose. Well, it is 
cleaner now:

To enable logging of warnings do for example:

   # This directives controls the verbosity of the server-wide log.
   # 0: No Logging
   # 1: Errors
   # 2: Warnings
   # 3: Important information
   # 4: Server - Client communication
   # 5: Information
   # 6: Debugging information
   # 7: stderror of some applications
   # Before turning logging on, please make sure that NX_LOGFILE is
   # writeable for the "nx" user

SESSION_LOG_CLEAN for debugging help
- ------------------------------------

With this directive we can finally save session data for debugging 

This means if you got a not working session startup you want to enable 
this directive to check if for example nxagent failed to start or to 
just tar it all up and send it in to me to take a look at it.

   # This directive controls if the temporary session directory
   # ($HOME/.nx/C-<hostname>-<display>-<session_id>) should be kept
   # after a session has ended. A successfully terminated session will
   # be saved as T-C-<hostname>-<display>-<session_id> while a failed
   # session will be saved as F-C-<hostname>-<display>-<session_id>.

ENCRYPTION can be forced by the NX Server
- -----------------------------------------

Do you want your users to use encryption, but they always forget to set 
the flag in NX Client?

Just use the following:

   # If enabled forces the user to use encryption. This will bail out
   # if the user does not have encryption enabled.

DEFAULT_X_WM now supported; can start window manager of choice
- --------------------------------------------------------------

DEFAULT_X_WM is a configuration directive, which is mirroring the 
NoMachine node.conf (but it seemed to have no effect there). We liked 
the idea and made a new feature out of it for unix-custom mode.

To enable startup and kill of kwin for your unix-custom session use:

   # The command binary for the default window manager. It is run when 
   # a 'unix-custom' session is requested by the NX Client and an 
   # application to run is specified. By default it is set to "twm". If
   # you don't have twm in the default path or if you want to use another
   # window manager, you have to set it to the absolute file name of the
   # command binary you want to use.
   # FreeNX: To enable this feature set ENABLE_DEFAULT_X_WM="1"
   #         If ENABLE_DEFAULT_X_WM_KILL is set the WM is terminated
   #         after the started application finishes. Else FreeNX will
   #         wait for the window manager to complete.

3. Fixes in detail

Stderr is redirected correctly to loglevel 7
- --------------------------------------------

Previously some output of applications was wrongly redirected to 
/dev/null. This is now fixed and will correctly be redirected (when
using the respective NX_LOG_LEVEL).

SSH is correctly detected in nxsetup
- ------------------------------------

The SSH startup script is called in /etc/init.d/sshd for SuSE, but "ssh"
for other distributions. nxsetup now checks for both:


and if anyone of that exists starts it. If you know of any other names 
this could be called, please tell me.

More compatible functions for porting purposes
- ----------------------------------------------

The function getparam was written in bash, which some systems did not 
like. This function does now use a more portable approach with awk.

Fixed some possible race conditions to prevent failed sessions
- --------------------------------------------------------------

Recently there were some race conditions spotted. These could lead to 
errors like '"NX>" found in remote options string' and a successfull 
startup of the session was prevented. This should be fixed now.

4. Download

You can download FreeNX 0.4.0 from the usual server:


5. Next plans

We plan a FreeNX 0.5.0 release to coincide with LinuxTag in Karlsruhe
(see www.linuxtag.org). At least a preview version should be available
by then. These are the planned changes:

  - NoMachine 1.5.0 components support
  - Some "secret" new features

NoMachine recently released a first snapshot for the upcoming 1.5.0
OpenSource/GPL components. FreeNX 0.5 will support the NoMachine 1.5.0
components, but there is a lot of work needed to do so.

The "secret" features will revolutionize the way you are working with 
your data and network, but I won't say more ;-).

Have fun!

For the FreeNX Team,
Version: GnuPG v1.2.4 (GNU/Linux)


More information about the FreeNX-kNX mailing list