In order to minimize maintenance, we decided to give tddium a try. It is a hosted CI service for Ruby (on Rails) projects.

Setup

Initial setup was quite painless and works as described on their webpage:

• sign up on the webpage
• install the tddium gem
• guided setup with the tddium tool, including github integration and email/campfire notification

For a regular rails app, this should have been it. In our case however, the tests wouldn’t even start as our sample app uses multiple databases. While initial install was a matter of minutes, at this point I began a multi-hour debug session, trying to figure out how to bend tddium to my will.

Debugging

The first problem was the Rails logger. Tddium seems to overwrite the standard logger with their own implementation that is not fully compatible with the standard Rails logger. In our case it doesn’t provide auto_flushing=. This, however, was easy to fix:

Rails.logger.auto_flushing = true if Rails.logger.respond_to?(:auto_flushing)

The next problem was a much bigger beast, multi database support. While the documentation roughly explains database setup and the use of hooks to add custom configuration, it took me quite some time to figure out how everything really works and how I could change the setup to suite my needs.

At this point I have to mention the slow feedback cycle tddium has, from running tddium spec to push code changes, to running the suite and seeing an error, it took 2 to 3 minutes. On the plus side I am happy tddium spec exists at all, this way you can easily run the suite on locally commited changes and don’t have to push to github all the time. Great for testing stuff.

So, after many failures I was finally able to come up with this solution:

There are two things to notice:

• I was only able to setup a 2nd database connection. Unfortunately the user is not permitted to create arbitray databases. In our case this was enough to get the code to load and the test suite to run.
• The socket entry is necessary for us but is not mentioned in the documentation. I extracted it from tddium’s database.yml.

At this point our test suite would run with two failing specs. In one case we actually executed code accessing the 2nd database. This was easy to fix in our specific case by rewriting the spec. The other problem was completely unrelated und not reproducable locally, some text saved to the database was not retrieved identically. We disabled this spec for now.

Conclusion

So far I am happy with tddium, it is a very lightweight CI service and in the general case, much easier to setup than a custom CI server. If we hadn’t have this multi-database setup, tddium would have been up and running within minutes. Pricing seems fair, although it lacks many features if compared to Jenkins CI. I am looking forward to its evolution and hope integration of our other apps will be smoother. :-)

Security on the product level

As agile developers, we optimize our code for flexibility, so we can change it easily at any point in time. In this world, security at the product level is nothing more than a feature to add whenever it makes sense. It becomes a matter of continuous risk management, which feature prioritisation is anyways.

We might start a new product without any security whatsoever, because who needs security when we have no clue how to solve our business logic problems in the first place? However, with each feature our risk profile changes and we have to reassess our situation. We better implement that login functionality before we go into public beta, but maybe it’s still ok to run without any encryption. Once we launch the product, we better protect our servers with TLS and encrypt sensitive data in the database.

Security on the code level

The story changes, however, when it comes to our daily coding practice. I consider security another code quality like good design or freedom from defects. Just as we use practices like TDD or Continuous Integration, we should use secure coding practices like input validation and output encoding. These practices need to be embedded in our daily practice. We have to make ourselves aware of the trust boundaries where we need to apply them.

What secure coding practices do you use? Let us know in the comments!

Every now and then I came across someone mentioning their move to a stand-up desk to counter the ill side-effects of sitting all day. One day I figured I’d give it a try, borrowed my girl friend’s ironing board, put some books on top and my laptop on top of those.

It didn’t take me much getting used to and I was quickly oscillating between ironing board and couch with my laptop. Happy as I was, at some point my girl friend needed her ironing board back, so I decided to upgrade to some kind of IKEA hack solution.

After discussing several options with my girlfriend, we settled on buying a second tabletop with some wooden legs to cut to proper length. While searching for the items, we came across the Lack side table for just 5 Eur. We quickly realised, that this was the perfect solution and bought two.

These side tables mix perfectly with my Vika table, but together they are 10cm wider than the Amon tabletop. As described above, this wasn’t much of a problem for me, as I had positioned the Annefors a little to the side. This gave me an effective width of about 114cm to work with. So we cut the side table’s legs, left 2 of them a little longer to compensate for the missing tabletop on the side and there was my new stand-up desk. This is how it looks:

• On a global scale, use a catalog policy to ensure all your node catalogs obey the same basic rules.
• Use module specific features to specify behaviour in manifests, templates, custom functions, etc.
• Don’t repeat your manifests in your features, however. There’s no value in it.

This exercise verified my thoughts on some technical aspects of cucumber-puppet. The goal of this project should not be to provide step definitions for all kinds of scenarios, but instead provide basic helper methods that empower people to implement the steps they actually need. I want you to implement step definitions on your own, however, you shouldn’t have to dig through the puppet source to do so.

This was a great learning experience for me.

What do you think, is this going in a sensible direction? Are there any specific things you would like to see in the example project? Let me know in the comments!

While doing all this, I wondered about the merits of test-driven development. Weren’t my tests supposed to drive the design of my code? How come I only ever figured out something was wrong, when I saw the final code and its usage pattern? At that time I shrugged these thoughts off and attributed my problems to poor design skills.

A couple of iterations and days later I had again read lots of stuff about object oriented design, the SOLID principles, Tell, don’t ask, Test-Driven Development, you name it. At that point I suddenly noticed a correlation between some idiom in my tests and a breakage of the Law of Demeter in my code. I didn’t really believe in a connection between the two, but still I tweeted it.

Luckily David Chelimsky, the author of RSpec, noticed my tweet and inquired about my code. When discussing the issue, he pointed out that my Demeter violation was actually hinted at by some other characteristic of my tests, I was using and_return() in combination with a message expectation. This conversation primed my interest in test smells and off I went for more reading and watching conference presentations.

Slowly it dawned on me, what these people meant, when they say “Listen to the tests”. Tests have a form of elegancy of their own. When they lose this property, they are telling you about some broken design principle. Combining a message expectation with a stub, like I did in my code, hints at a violation of the Law of Demeter and the Tell, don’t ask principle. The problem with elegancy, however, is that you have to learn to detect it.

What have I learned from all this?

It looks as if test elegancy is not just a matter of taste, but there seem to be certain patterns to it:

• having a message expectation return a value hints at a violation of the Law of Demeter and the Tell, don’t ask principle (“mock actions, stub queries”)
• the more collaborators an object has, the higher the chance it does too many different things
• test setup should be simple, too many test doubles hint at a method that does too many different things
• write tests with only minimal requirements
  • explicitly require necessary modules, the list should be short (don’t just include all Rails, for example)
  • use strings as identifiers for test doubles, not constants, to keep collaborators out of the list of modules to load
• when using external libraries
  • put an interface in front and test it with focussed, state-based integration tests
  • now you can mock this interface in your unit tests, don’t mock the external library itself

Where do I go from here?

For me, it’s time to go through Growing Object-Oriented Software, guided by tests again. This time I won’t just read it superficially, however, but instead work through the text and examples more intensely.

What do you think of this? Does it make sense? Do you have any test smells to share? Let me know in the comments!

The main trick is to use an sqlite3 in-memory database so that cucumber-puppet won’t have to connect to any external database or mess with the filesystem too much. With the database in place, you can access exported resources through their model class Puppet::Rails::Resource. I used database_cleaner to ensure empty databases between scenarios. The only nuisance so far is, that puppet will want to create several directories with storeconfigs activated, so we have to manage a temporary directory.

Here is a sample usage of exported resources with cucumber-puppet:

I plan to add proper support for exported resources to cucumber-puppet in the future, but this blog post should be enough to get you started.

Was this blog post helpful to you? Do you have any ideas on improving cucumber-puppet? Let me know in the comments!

Unfortunately there is no good pomodoro timer availabe for my environment of choice (Linux and the awesome window manager), so I build one myself. The timer is based on a tea timer from Jörg Thalheim that you put into your rc.lua and add it to the widget list.

By default it lets you work for 20 minutes and then gives you a 5 minute pause. You can change these values in the code. The widget uses mouse button one to start the timer, mouse button 2 to stop the timer and mouse button 3 to reset the timer. It should be simple to add keyboard shortcuts as well.

The fun began, when I updated our gems and ran our specs for the first time. Well, actually I couldn’t because the RSpec rake tasks where missing. Google to the rescue, it turned out we had to add our test gems, like rspec-rails, to the bundler development group or rake wouldn’t load the corresponding targets. I had known about bundler groups, but never bothered to figure out, what they actually where intended for or how they worked.

With RSpec targets visible, I could finally run the test suite. Unfortunately it didn’t get very far before the first error struck. Some of the garb gem’s symbols where unresolvable. It turned out garb had gone through some major restructurings deprecating the way we use it. Not sure about those, I downgraded it to the old version we where using before, but the error prevailed. After some googling I finally found the reason, garb contains the file lib/support.rb which defines the missing symbols. Another gem, right_http_connection, also contains a file lib/support.rb. As it turned out, right’s file was loaded while garb’s wasn’t. The proposed solution was to downgrade to a previous version of right_http_connection that didn’t contain that file. Alternatively, it was proposed to load garb before right_http_connection. I played with my Gemfile, changing the order of entries and not requiring some gems, but I couldn’t get it working. So, with both gems downgraded, the test suite actually ran.

The lesson I learned in this case was, that a gem can be thought of as a namespace. There is absolutely no reason to leave this namespace and create a potential for collisions by providing files like lib/support.rb. Put your files into a subdirectory and be happy. If however, you feel there’s no way around providing a generic file like this, at least use a require statement with absolute pathname to not accidentaly refer to another, already loaded file.

The issue wasn’t over though. The test suite was running, but it showed strange ArgumentError: wrong number of arguments (1 for 0) on some of my own methods. A friend suggested a backtrace and so I learned about rspec -b. This showed the real problem deep in the garb gem. garb uses ActiveRecord’s camelize() method that seemingly was replaced by something different. This time the culprit turned out to be right_aws, which also defines a camelize method but with a different method signature. With the downgrade of right_http_connection, I had to downgrade right_aws as well. The older right_aws version however, was not rails 3 compatible and overwrote ActiveRecord’s camelize(). In this dilemma I decided to make right_http_connection a vendor gem and fix it locally so as to not collide with garb. I already had two other gems in vendor/gems as those needed trivial fixes as well.

At this point my gems where in a decent state, so I could run the test suite and fix a couple of minor issues, except for one. Again I got an argument error, but this time on one of my own methods called load(). On a mocked null object. How was that possible? Using Object#method it turned out my mock was somehow linked to ActiveSupport::Dependencies::Loadable which contains a load() method that was invoked. Explicitly stubbing load() on the mock object solved the issue, but I have yet to understand what is going on here.

The final problem was a deprecation notice from RSpec, that I was setting configuration values after defining examples. This was really strange, as all I was doing in spec_helper.rb was loading files from spec/support and setting configuration values afterwards. Just as it was supposed to work. I experimented a lot and finally came to the conclusion, that my support directory was fine and so I resorted to Google again. After a couple of pages I finally found the issue. RSpec doesn’t like it, when you mix require ‘spec_helper’ with require File.dirname(__FILE__) + ‘/../spec_helper’ as this leads to spec_helper.rb being loaded twice. Apparently this is the way require works. Once understood, I changed all require to be of the same form and had all my specs pass without further warnings.

The upgrade isn’t finished yet, I have to write more specs for some older code and actually test the running application. But for a first day the outcome wasn’t bad. I learned a lot and hope to have removed all major obstacles.

The book was an easy read, as it mostly contains anecdotes from Robert Martin’s life as a corporate programmer in the 70’s and 80’s, that are used to make a point about certain behaviours Robert Martin deems professional. As a consequence the book does not go into detail about actually becomming a professional programmer and overcomming the obstacles that thwart us. Instead I take the book as a collection of ideas the reader should think about and how to apply them in their daily work.

I found those chapters most intriguing, where Robert Martin talks about values and attitudes. He deems it unprofessional to compromise on quality or accepting unreasonable time frames. Instead it is the duty of a professional programmer to enter a discussion with the business, making sure it understands (the programmer’s) reality. Professionals actively seek compromises that are in the best interest of all parties involved.

Other chapters deal more with practices around coding and testing that don’t provide many new ideas for people with a background in agile methodologies and practices.

Overall I like this book and will probably come back to it every now and then. If I consider the value it provides, though it is much too expensive and I am happy I waited for a daily deal on it.

I used chronicle for about two years and finally got sick with a couple of things. Most importantly, I didn’t like the site’s design anymore so I needed something new. Chronicle is a static blog compiler, which didn’t quite fulfill my needs of building a complete site with a couple of static pages. Finally it is written in Perl, while I prefer coding (and patching tools written) in Ruby these days.

While the switch to Octopress was rather painless (sorry for fucking up the RSS transition), I missed an overview of all my categories.

Octopress is based on Jekyll which uses Liquid for templating. It took some time to get my head twisted around its parts, but I finally managed to write a plugin that lists all my categories with counts in the sidebar.

One of the first questions that came up was branching. We use git for version control of our source code, so branches are cheap and easy to use. Having played with Continuous Integration before however, I am aware that feature branches are disliked in the CI community. So when do branches make sense?

Let me start with a little background. We are a small distributed team, so pair programming is currently unfeasible. In order to maintain high quality standards (and as I am new to the team), my code is being reviewed before going live.

In order to encapsulate my work, I use private feature branches. These only exist on my local checkout and facilitate code reviews. While waiting for review, they give me the opportunity to add a quick bug fix or start working on a new feature in a separate branch. I see counter-arguments to feature branches as mostly concerning themselves with bigger teams, where conflict happens more easily.

When developing a new feature, I also use spike branches. These are private branches to quickly test an idea without any quality concerns. Once I see a sensible solution to my problem, I throw away the spike branch and reimplement the solution test-driven in my feature branch.

As we don’t have releases but deploy HEAD directly, we don’t use public release branches.

The idea is basically to work short bursts of time, usually 25 minutes and then rest for a couple of minutes, reading email, getting coffee…

I started using it at home for programming and learning some new tools. In the beginning I chose shorter intervals and longer breaks, slowly advancing to regular intervals. The Pomodoro Technique helped me focusing immensely. I stayed with my task and only checked Twitter or email in the breaks. When I was in flow I just skipped breaks and worked through two or three pomodoros.

When I applied the Pomodoro Technique at work, I soon found some limits of applicability, though.

I work as a sysadmin, where I have to deal with all kinds of task lengths from minutes to days. Working on small user requests and being interrupted all the time by users or colleagues doesn’t play well with Pomodoro. It works great however, when requests get slow and I am able to work on some bigger tasks. There, Pomodoro again helps me to focus on the task and keep distractions out of my mind.

A second scenario that didn’t play well with Pomodoro was Pairing. Working with a colleague on some bigger task, being interrupted by the Pomodoro timer felt counterproductive. There was enough energy between the two of us, that staying focused was no problem.

From my (limited) experiences I believe Pomodoro to be an effective technique for improving focus if working alone on a bigger task. It helps me get started and keep going. If working in different conditions, I still like to schedule regular breaks to limit exhaustion.

I started with plain Cucumber and wrote a scenario like this one:

1
2
3
4

Scenario: Uninstall ntpd on VM
  Given recipe "ntp"
  When I provision a new virtual machine
  Then package "ntp" should be purged

Having played with Cucumber and Puppet for a long time, I realised, that I was entering the old road of 1-to-1 map between test and implementation. My Chef recipe looked liked this:

1
2
3

package "ntp" do
  action :purge
end

In this situation I remembered a blog post from Antony Marcano where he argues for a Goal -> Task -> Action approach to writing scenarios. This way it should be simpler to find an adequate level of abstraction by hiding concrete actions in step implementations.

In my case purging the package is even below the action level. I want to specify that the ntp daemon should not be running and leave it to the implementation, i.e. the chef recipe, how to get there. This is an improved scenario:

1
2
3
4

Scenario: don't run ntpd on a virtual machine
  Given recipe "ntp"
  When I provision a new virtual machine
  Then "ntpd" should not be running

This is much better, as it decouples the Cucumber feature from the configuration management details. If I ever need the ntp package installed for whatever reason, but ensure the service being disabled, the scenario won’t break as it would have in the first case. I could probably even switch from Chef to Puppet with minimal efforts.

Let’s assume we have a class with two parameters:

1
2
3

class dns ($nameserver1, $nameserver2) {
  ...
}

cucumber-puppet provides a sample Given step to specify the behaviour of this class in steps/puppet.rb (NOT updated automatically):

1
2
3
4
5
6

Given a node of class "dns" with parameters:
  | name        | value      |
  | nameserver1 | ns.foo.com |
  | nameserver2 | ns.bar.com |
When I compile the catalog
...

This will create a node with just the dns class and both parameters set according to the table.

For those not following me on Twitter, I have since released version 0.1.0 of cucumber-puppet, which supports all features mentioned in my presentation.

The most important change we see, is a vastly improved focus on finishing work. Unfortunately we don’t have numbers to back this up, but everyone on my team agrees that the kanban board with its WIP limits and visualization of work helps immensely. There is a downside however, some people see this as additional pressure. Work is no longer hidden, but always clearly visible on the board, so people see what needs to be done next and cannot just slack as easily as in the old days.

Our board changed almost every month, as we optimized the design in our monthly retro meetings. I spare you the details, but we still use a pretty basic design with columns Backlog (MMF or Milestone), Planning (MMF -> Tasks), WIP and Done.

Being a sysadmin team, we often have people come to us, asking for implementation of some small project that still takes time to do properly. In the old days, we would just take the project and try to implement it on the side. These days, we have a prioritized project backlog and ask people to join in a discussion on our kanban board about where their request fits in. Interestingly, most people don’t take this opportunity! I consider this a good thing, as it helps us focus on important projects instead of nice-to-have ones. When people do come to our board, they see what else we have in our pipeline and usually agree to some sensible prioritization.

Historically we never did much project planning, so when we introduced Kanban, we started with ad-hoc planning. We ran into several issues with this approach:

• At our company, people can work from home some time of the week. With only a physical kanban board, they had a hard time figuring out what to do next.
• We had no place to store project artifacts.
• There was not enough information on our post-its for people to actually having an idea what the card was about.
• Management began asking questions about project performance.

Most of these problems where addressed by amending our physical kanban board with an issue tracker called redmine. This allowed us to store much more information with an issue and finally led to a point where we even were able to estimate t-shirt sizes for our tasks and delight management with some kind of sensible reporting (keeping it as minimal as possible). We are still looking for the sweetspot of electronic issue tracking, however. How much information can and should we collect in the issue upfront and how much information should be pulled by the worker on demand?

Besides redmine we have a legacy ticketing system for user requests. Infected with the pull virus, we applied some minor changes that allowed a quasi-pull workflow when dealing with requests. Before, each new ticket was assigned to one person and then pushed elsewhere if necessary. Now we can easily see which tickets are not being worked on and pull them in case of a bottleneck.

A side effect of all this was my introduction to systems thinking. I only started exploring this field recently, so there are not many results yet. It was reassuring to see, though, that our failure demand is usually around 10%.

Despite all the positive effects, we are still struggling with commitment to the Kanban way of working. Practice still heavily depends on a champion being around.

After playing with existing tools like Ohad Levy’s Manitest, I stumbled upon Cucumber and wrote some glue code, so that I could write cucumber features for my manifests.

In my first round of testing, I wrote features like this one:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Feature: Setup Amanda client
  In order to backup my servers
  As an admin
  I want my servers to be setup as amanda clients

  Scenario: Setup remote access
    Given a node of class "amanda::client"
    When I compile the catalog
    Then there should be a resource "File[/operator/.amandahosts]"
    And the file should contain "amanda.no.domain operator"
    And the file should have a "group" of "operator"
    And the file should have a "mode" of "0400"
    And the file should have an "owner" of "operator"
    And the file should require "Package[amanda-client]"
    And the state should be "present"

  ...

If you compare this to the puppet code being tested

1
2
3
4
5
6
7
8

file { "/operator/.amandahosts":
  content => "amanda.no.domain operator",
  ensure => present,
  group => "operator",
  mode => 0400,
  owner => "operator",
  require => Package["amanda-client"],
}

you will notice, that the scenario is basically a reimplementation of the puppet code. This doesn’t make much sense.

To start over, I collected my actual problems when developing manifests in order to think of a more sensible approach to writing Cucumber features.

1. catalog does not compile

   • syntax errors
   • missing template files (locally or in repository)

2. catalog compiles, but cannot be applied

   • unreachable or non-existent resources are referenced (before, notify, …)
   • missing file sources in repository

3. catalog applies but is faulty

   • faulty files due to empty manifest variables or wrong values
   • missing dependencies between resources (wrong order, missing service restarts after config file changes, …)
   • files are installed without ensuring directory creation beforehand

In order to deal with these issues, I first expanded cucumber-puppet to permit defining a host by its YAML node file. This way local (on my development machine) catalog compilation can be verified easily. For remote catalog compilation, I added a step ensuring files and templates are checked into git. Finally I added a step to ensure resolvability of all referenced resources. Looks like issues 1 and 2 are solved. :-)

Catalogs can now be verified like this:

1
2
3
4
5
6
7
8
9
10
11
12

Feature: General catalog policy
  In order to ensure applicability of a host's catalog
  As a manifest developer
  I want all catalogs to obey some general rules

  Scenario: Compile and verify catalog for host test
    Given a node specified by "features/yaml/test.no.domain.yaml"
    When I compile its catalog
    Then compilation should succeed
    And all resource dependencies should resolve
    And all file sources should exist in git repository
    And all file templates should exist in git repository

My new way of writing cucumber features thus is to move away from single resources and instead concentrate on the BDD principle of Outside-In specification. Above feature specifies a generic policy regarding catalog compilation. This specification could be augmented with rules like each file should have group, mode and owner set explicitly or each file written to directory “/etc/apache2” should require “Package[apache2]”.

This new approach does not solve all issues mentioned above, there is still more than enough room for manually verifying catalogs on real target hosts, but it is in my opinion much more useful than my first attempt.

cucumber-puppet is currently in alpha-testing.

Installation

cucumber-puppet comes packaged as a gem

1

$ gem install cucumber-puppet

or can be cloned from github

1

$ git clone http://github.com/nistude/cucumber-puppet.git

Usage

Initial setup

Before writing your first feature, you have to setup the infrastructure in your Puppet directory.

1
2

$ cd puppet
$ cucumber-puppet-gen world

This installs some example step definitions for cucumber to ./features/steps/ and ensures the cucumber-puppet glue code is available. You can adapt cucumber-puppet to your needs in ./features/support/hooks.rb.

Writing features

cucumber-puppet assumes you have your Puppet manifest organized in modules and does the same with your feature files.

1

$ cucumber-puppet-gen feature foo bar

generates ./features/modules/foo/bar.feature from the standard template. Use this file to write your feature and add missing step definitions to files in ./features/steps/.

A feature might look like this:

1
2
3
4
5
6
7
8
9

Feature: cucumber-puppet
  In order to run my puppet manifest's test suite
  As an admin
  I want the cucumber-puppet gem installed

  Scenario: Install cucumber-puppet
    Given a node of class "cucumber-puppet"
    When I compile the catalog
    Then gem "cucumber-puppet" should be "installed"

Running features

To run above feature, execute

1

$ cucumber-puppet features/modules/foo/bar.feature

and see it complain about missing step definitions. Add these to .rb files in ./features/steps/.

If you have any questions or feedback, feel free to leave a comment or email me at cucumber-puppet at erisiandiscord.de.

Recently we started noticing failed puppetd runs from time to time. Cause of the problem was, that our puppet clients turned out to be running in batches, so every 30 minutes our puppetmaster suffered a huge load spike.

Having read R.I.Pienaar’s Scheduling Puppet with MCollective blog post, I figured I needed a similar solution. Installing MCollective crossed my mind for a moment, but it seemed overkill. Instead I came up with the following simple, pragmatic solution.

I restart each puppetd process at a host specific time, thus spreading them reasonably well across puppet’s run interval.

The crucial component is my external node classifier, which I use to calculate the host specific time. It’s a ruby script that knows about all our machines and is easily able to compute a nodes rank, in our case based on the hostname, modulo 30, puppet’s run interval. This rank is used to terminate a cronjob restarting puppetd daily.

Lets look at an example. Say you have hosts a.foo.com, b.foo.com and c.foo.com, then their rank would be 0, 1 and 2 respectively. On host a.foo.com, the cronjob would run at 11:00, on b.foo.com at 11:01 and on c.foo.com at 11:02. (I chose the window between 11:00 and 11:30, as I figured most people would be at work at that time and thus their desktop PCs switched on.)

As you can see, the result is far from perfect, but still quite impressive:

I know, load graphs are mostly useless, but it’s all the data I have ATM. ;)

Where 4 cores couldn’t handle load spikes, 2 cores are evenly used and I might even get by with just 1.

I would very much like to see some kind of scheduling support in the puppetmaster, organizing clients for maximal spread.

As session shadowing unlocks a potentially running screensaver, it is only suited for accessing PCs in locked offices or at home. In an open office environment, only an independen NX session makes sense. This, however, has a drawback as well. Many desktop applications like Firefox or OpenOffice do not easily permit running multiple instances concurrently. Thus you have to close these programs before starting them in the other session (local desktop session or remote NX session). This gets quite annoying.

For people working in an open office environment, a combined solution is needed, that uses the same session locally and remotely, while not opening it to passersby. This means all programs are running inside an NX session and the user starts nxclient even when locally logging in to the machine. The rest of this blog post will deal with the peculiarities of this local setup.

Nxclient has two technical drawbacks preventing it from running stand-alone:

1. At least in my setup (Ubuntu 9.10 with GDM), it doesn’t grab keyboard focus.
2. Nxclient forks nxssh for the actual session handling and ends itself, thus closing the local desktop session.

To work around the first issue, a window manager is needed. This should be as minimal and lightweight as possible so as not to interfere with whatever is running inside the NX session (think keyboard shortcuts or mouse gestures). I chose fvwm2 with a minimal configuration, stripping it of virtually all its functionality. I even chose to not lock the screen from fvwm2 but instead lock the session from within NX. This way NX users and regular users, with only a local desktop session, share the same screensaver configuration.

A natural workaround for the second issue would be to start fvwm2 after nxclient and keeping it in the foreground. This way, a user would have to explicitly exit fvwm2 to logout. To make the window manager as transparent as possible, it would be much nicer, to terminate the session once nxssh is terminated. This can be accomplished with fvwm2 running in the background and a loop, waiting for nxssh to finish.

Putting it all together, this is how to setup an nxclient-only session with GDM on Ubuntu 9.10:

• install fvwm2
• install nxclient
• install support files

1
2
3

$ sudo install -o root -g root -m 644 nxclient.desktop /usr/share/xsessions
$ sudo install -o root -g root -m 755 nxsession /usr/local/bin
$ sudo install -o root -g root -m 644 nx.fvwm2 /etc

• login with GDM, choosing NX Client as session (you might have to restart gdm first)
• configure nxclient for fullscreen mode
• use CTRL-ALT-T to disconnect from the NX session, terminating nxclient