Forwarding web traffic

This can come in very helpful when switching servers and wanting to avoid any downtime while the updated DNS entries propagate over 48 hours through the Internet. This is esp. important for websites with

  1. Make sure you meet the requirements. You need:
    1. Your old server has to be a Linux / Unix based server, so that rinetd can be installed.
    2. root access to your old server for installing rinetd
  2. Copy over your websites and databases. You might want to put community websites into maintenance mode first because it's impractical and spammy to write hundreds of users an e-mail saying they should not add content over the next half an hour …
  3. Install rinetd. On your old server, execute (assuming Debian or Ubuntu): apt-get install rinetd
  4. Configure rinetd. For web traffic, the following lines in /etc/rinetd.conf are enough (see the docs for details, and use your new server's IP address instead of of course):  80  80 443 443
  5. Stop your webserver. So, do something like service apache2 stop. rinetd can only work successfully if nothing else is connected to the ports it shoud bind to. If there is something else listening, it will result in no redirections and a huge rinetd log file containing messages like 22/Mar/2013:19:35:47 0 (null) 0 0 0 accept-failed – [source].
  6. Start rinetd. That's simply service rinetd restart.
  7. Test it. If your websites still work, they are now served by the new server, since you disabled the webserver on the old one.
  8. Change your DNS records. To make everyones requests switch to the new server, point your sites DNS records to the new server.

Forwarding e-mail traffic

You can now migrate e-mails with a similar approach, something along these lines:

netstat -t -l -p
service courier-imapd stop
service courier-imaps stop
service courier-pop3d stop
service courier-pop3s stop
service postfix stop

Then add more forwarding rules in /etc/rinetd.conf – in my case I now have these in total:

# any private mail system         24   24
# SMTP         25   25
# Secure SMTP         26   26
# HTTP         80   80
# POP3        110  110
# IMAP        143  143
# HTTPS        443  443
# IMAP over TLS        993  993
# POP3 over TLS        995  995

And finally restart rinetd to make it pick up the new config:

service rinetd restart

Alternative approaches

  • Using iptables. It also is about redirecting traffic at NAT / TCP level. However, this it is more difficult to understand and to configure, since it is meant as a full-featured software firewall.
  • Using remote databases. If all your sites support using a database on a different host (Drupal, WordPress etc. all can do that), you can do it as follows. The advantage is, you can move your sites one by one, so can take time to iron out any issues on the new server without having to prepare that for all sites at once (which would mean copying over databases twice, once to test and once to take in new changes). A disadvantage of this is that it only works for websites, not for e-mails. Step by step:
    1. Put your site in maintenance mode for a short time.
    2. Move your site and its database over to the new server.
    3. Test your site on the new server by bending DNS at your own machine (edit /etc/hosts if you are on Linux).
    4. Edit your site configuration on your old server to use the remote databases on the new one.
    5. Optionally (if your site has user-generated files), set up an rsync / scp / ftp synchronization job to push or pull new and updated files to the new server, called by a cron job every 15 minutes or so.
    6. Disable maintenance mode again and test if the site on the old server still works (remember to disable DNS bending again!).
    7. Adapt your DNS configuration to point  to the new server. After 48 hours at latest, nobody will access the old server any more.


You can follow all the steps of the official HowTo "The Perfect Server – Ubuntu 13.04 (Apache2, BIND, Dovecot, ISPConfig 3)". To get it to work afterwards on Ubuntu 13.10, use these additional steps:

  1. Switch to a .vhost naming scheme for Apache2 site configurations. In Apache2 2.4, only the sites-enabled/*.conf files will be loaded automatically, missing out ISPConfig's /etc/apache2/sites-enabled/*.vhost. Usually we would rename them to .conf, but because .vhost files are also generated automatically for every website created in ISPConfig, we instead adapt what Apache2 loads. Because that is less work than adapting the source code of ISPConfig. Note in the following commands, both for sites and further down for config snippets, that it's important to keep the original apps.vhost and ispconfig.vhost included at the start of the site inclusion process, so let's keep the "000-" and "100-" prefixes used by ISPConfig [source].
    1. In /etc/apache2/apache2.conf, replace line "IncludeOptional sites-enabled/*.conf" with "IncludeOptional sites-enabled/*.vhost".
    2. mv /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/000-default.vhost;
    3. mv /etc/apache2/sites-enabled/000-default.conf /etc/apache2/sites-enabled/000-default.vhost;
    4. rm /etc/apache2/sites-enabled/000-apps.vhost;
    5. mv /etc/apache2/sites-available/apps.vhost /etc/apache2/sites-available/000-ispconfig-apps.vhost;
    6. ln -s ../sites-available/000-ispconfig-apps.vhost /etc/apache2/sites-enabled/000-ispconfig-apps.vhost;
    7. rm /etc/apache2/sites-enabled/000-ispconfig.vhost;
    8. mv /etc/apache2/sites-available/ispconfig.vhost /etc/apache2/sites-available/000-ispconfig.vhost;
    9. ln -s ../sites-available/000-ispconfig.vhost /etc/apache2/sites-enabled/000-ispconfig.vhost;
  2. Move and rename the ISPConfig Apache2 config file. In addition, the ISPConfig .conf files which are also present actually contain configuration information and not vhost directives for sites, so a2ensite and a2dissite cannot handle them. They are now expected in /etc/apache2/conf-available, to be handled by a2enconf and a2disconf. So let's rearrange things a bit to solve this (note that we use a ".local" suffix to indicate local configuration additions, not provided via OS packages):
    1. rm /etc/apache2/sites-enabled/000-ispconfig.conf;
    2. mv /etc/apache2/sites-available/ispconfig.conf /etc/apache2/conf-available/000-ispconfig.local.conf;
    3. a2enconf 000-ispconfig.local;
  3. (optional) Fix a2ensite and a2dissite. Due to our transition to the ".vhost" naming scheme for Apache2 site configurations, a2ensite / a2dissite do not work any more because they expect a .vhost suffix. Not too bad because one will enable and disable most sites within ISPConfig anyway. However, we can also repair this by supplying a local alternative with a fix in the source code:
    1. cp /usr/sbin/a2ensite /usr/local/bin;
    2. ln -s a2ensite /usr/local/bin/a2dissite;
    3. In file /usr/local/bin/a2ensite, replace line 60 "$sffx   = '.conf';" with "$sffx   = '.vhost';".
    4. Ensure with which a2ensite and which a2dissite that your local alternatives are in use now.
    5. Unfortunately, this fix only works for sites not handled by ISPConfig. To also handle those created by ISPConfig, one has to find a solution for the fact that ISPConfig creates the symlinks with a "100-" prefix while the site configurations in sites-available/ miss this. The simplest is to provide an alternative with that prefix in sites-available/ as well, using something like:
      ln -s /etc/apache2/sites-available/;
  4. Fix a syntax error about directory options. Apache would now complain about a syntax error: "Either all Options must start with + or -, or no Option may." So add a "+" character before all options missing a "+" or "-" prefix in:
    /etc/apache2/sites-available/000-ispconfig-apps.conf line 30
    /etc/apache2/sites-available/000-ispconfig.conf line 20
  5. Remove the NameVirtualHost directives. They don't really hurt, but are effectless and deprecated in Apache 2.4, generating warnings when restarting Apache. So remove them from:
    /etc/apache2/sites-available/000-ispconfig.conf line 8
    /etc/apache2/conf-available/000-ispconfig.conf lines 53 and 54
  6. Reload the Apache configuration.
    service apache2 reload;
  7. Test ISPConfig and configure it. If you have enabled SSL for the ISPConfig site during the installation configure script, try visiting your server's FQDN at port 8080 in your browser (like browsing to Initial username and password are "admin" and "admin" – remember to change them immediately. The remaining configuration happens from inside the ISPConfig 3 panel.

We needed a fast, dedicated server to solve optimization problems. So let's install COIN-OR CBC (the MLP optimization solver we use). We start from a stock Ubuntu 13.10 machine, as it will happen to you when deploying on Amazon EC2 Spot Instances, like we do.

The easiest way to get COIN-OR OS and CBC installed on a common Linux platform is to install the "full release" binary packages, which contain the binaries from all major COIN-OR projects. Just download the latest COIN-OR-*.tgz package from the CoinAll repo, unpack it, and link the files in its bin/ subdirectory into your path with something like ln -s bin/* /usr/local/bin/.

However, we want to install from source here, which gives us some advantages (mostly following reasoning found here):

  • The most important reason is that COIN-OR cannot distribute GPL-licenced source or binaries with its code. It includes download scripts for these however. So to get goodies like ASL (the AMPL input format library we desperately need for CBC here), GMPL, command completion, command history, Haskell libraries etc. one has to install from source.
  • The installation uses the Debian package management system for simple modifications, updates and removal. (Some COIN-OR packages are available in the Ubuntu archives, but not all from the COIN-OR distribution – not OS for example, which we need here. Also these packages tend to be a bit outdated.)
  • We can optimize COIN-OR to our needs with the many compilation options of COIN-OR. For example, enabling multi-threading for the CBC solver, or optimizatios for specific CPUs / hardware.
  • Bug fixes can be incorporated immediately instead of waiting for a new COIN-OR release.

How to install all major COIN-OR packages from source, according to the CoinAll distribution build notes and the guidlines from the T. K. Ralphs presentation:

  1. Install some needed developer tools. Note that csh is needed for DyLP/doc/build_dylpdoc, which is called in make distclean for example.
    sudo apt-get install patch make pkg-config wget subversion checkinstall csh gcc g++ gfortran
  2. Install some libraries needed by some COIN-OR packages. (matplotlib is needed for the GiMPy tests to complete.)
    sudo apt-get install python-matplotlib
  3. Download the latest stable version. This probably will get you the latest maintenance release, so probably currently 1.7.4 as seen in the CoinAll list of binaries.
    svn co CoinAll-1.7
  4. Add necessary and desires third-party source code. Some code could not be included into the COIN-OR distribution because of licence incompatibility (for example with the GPL). But COIN-OR provides nice download scripts to add these components:
    1. Add the MUMPS public domain linear solver. If present, it will be used in the compilation of Ipopt. If not present, Ipopt will be compiled without solvers, which will cause make test fail for Ipopt with a message like "selected linear solver ma27 not available" [source].
      cd ~/CoinAll-1.7/ThirdParty/Mumps
    2. Add Glpk. This is needed by CBC in order to read GMPL input – that's exactly what we need, since it is the only way to use an algebraic modeling language for comfortable, high-level input to CBC. GMPL (also called MathProg) is actually a subset of the widespread AMPL [source], so many models in AMPL should also be expressable with it.
      cd ~/CoinAll-1.7/ThirdParty/Glpk
    3. Add the ASL library. Without this being present, CBC would be built without AMPL .nl input format support – trying to call it with a .nl file would then result in an error "nl file specified locally but ASL not present". But we want to have the nice simple AMPL input format. So to get it included, we do according to the CBC FAQ:
      cd ~/CoinAll-1.7/ThirdParty/ASL
    4. Add BLAS. Adding Blas (andLapack, see below) to CBC gives better numerical stability to CBC's LP solver [source, p.5] – whatever that means. Blas is also needed for compiling one of the other COIN-OR projects; it can be added with apt-get install libblas3 libblas-doc libblas-dev but let's keep here with the mechanism supplied by COIN-OR to get the latest version:
      cd ~/CoinAll-1.7/ThirdParty/Blas
    5. Add Lapack. Second component in addition to Blas for improving the numerical stability of CBC. To add it:
      cd ~/CoinAll-1.7/ThirdParty/Lapack
    6. (optional) Add METIS. METIS is a library for graph partitioning, and I don't know if CBC can profit from it. But since it's the last of the ThirdParty packages that are free to use for all, let's go ahead:
      cd ~/CoinAll-1.7/ThirdParty/Metis
  5. Configure it all. In the configure command below, the LDFLAGS=-Wl,--no-as-needed; is to solve problems caused probably by some library symbols now being versioned in current versions of Ubuntu. These problems show up with error messages saying "undefined reference to dlopen, dlclose, dlerror, dlsym". The LDFLAGS setting is a solution from the ipopt mailing list, and while it works for me I don't quite understand it. It is only needed for ./configure in the sub-projects OS, DyLP and IPopt. But it does not hurt to apply it globally, so for simplicity we do just that. Also, we configure CBC to support parallel execution. This is done by adding the --enable-cbc-parallel compile-time option [source]. Again, it does not hurt to add it to the global ./configure, it will only affect CBC (and should result in a line "Cbc multithreading enabled" in build/Cbc/configure.log).
    mkdir ~/CoinAll-1.7/build;
    cd ~/CoinAll-1.7/build/;
    ../configure --enable-gnu-packages --enable-cbc-parallel -C --prefix=/usr/local/share/coin-or LDFLAGS=-Wl,--no-as-needed;
  6. Compile it all.
    cd ~/CoinAll-1.7/build/;
    make -j 2;
  7. Adapt the tests for a headless server. Some tests will fail without an X Server. We run this on a headless server, so we have to modify the tests (or use Xvfb, but that is a hack as well …).
    1. In ~/CoinAll-1.7/GiMPy/test/, remove line produce_graphs() (actually the very last one).
    2. Solve a similar problem with ~/CoinAll-1.7/GrUMPy/test/
    3. TODO There may be more issues like this. I did not finish trying to get all tests to run.
  8. Run the tests. (Might still fail at some point when used on a headless server, as per the last point. But you will get through with most at least.)
    make test;
  9. Create a directory for the installation.
    sudo mkdir /usr/local/share/coin-or
  10. Create a Debian package and install it. Installing is included in the following command if all works well. In total, it can take a while, 20 minutes even, depending on your machine. I named mine coinor-coinall.
    sudo checkinstall make install;
  11. Put the binaries into the path. Because this is not done by the installation. Let's use symlinks:
    cd /usr/local/bin && sudo ln -s ../share/coin-or/bin/* .

TODO The packages built this way can be installed on any Ubuntu 13.10, 14.04 or perhaps newer version, but they miss to list some dependencies, so these should be added manually in the "checkinstall make install" step. Until then, make sure to provide the packages yourself with:

sudo apt-get install gfortran

These are the instructions for installing a generic NEOS server, which you can use for many purposes.

WARNING: These instructions guide you through a successul installation of NEOS itself, but stop there. NEOS is not usable without adding one or more solvers, and for that you have to develop one XML config file and one wrapper script each. These are not provided within the NEOS server software package, not even for open source solvers like COIN-OR CBC. For that reason, I finally abandoned NEOS and moved to the 12 years newer and much cleaner COIN-OR Optimization Services (OS) alternative solution. (The last NEOS 4.0 release is from 2002-10-25, while COIN-OR OS is in active development and meant to be the "next-generation NEOS server" [source].) Also NEOS turned out to be really messy, old Perl software with confusing and inconsistent documentation, so that it is a pain to work with it. You have been warned. Proceed at your own risk 🙂

You can test the NEOS interface by using the public NEOS server, as we did too. So installing your own NEOS server is only reasonable when you want to avoid overloading their servers and / or prohibit all your job submissions from becoming public, as happens with the public NEOS server.

Choosing a machine for your server

For our purposes, using Amazon EC2 Spot Instances seems the most economic and scalable solution. For Economy App, we are starting with one of the CPU power optimized c1.medium instances. It is available more or less permanently for 0.028 USD/h in the South America data center (sa-east-1) – that's 20 USD/month when running full-time, while we only need it to run 25% of the time at first.

As our userbase will grow, we will quickly need a lot or calculation power, and then have to care for where to get it economically. And there's lots of optimization potential – see the initial CloudHarmony cloud hosting comparisons, and their current cloud hosting benchmarks for example.

Installing the NEOS server 4.0

Here we are exploring how to install it on a Linux server (Ubuntu 10.13, to be exact), based on the original installation instructions. It is assumed that your web server and the NEOS server will run on the same machine (else, see this hint). We also assume that you start with only one server – NEOS can handle multiple workstations running solvers though [source].

  1. Download NEOS. Download and extract one of the NEOS server packages. The newst is NEOS server 4.0 from 2002-10-25. (Except you want to go for NEOS server 5.0 from 2005, which however appears largely undocumented.) So for example, do:
    cd /var/local/;
    sudo wget;
    sudo tar -xzf server-4.0-102502.tar.gz;
    sudo mv server-4.0 neos;
    sudo rm server-4.0-102502.tar.gz;
  2. Provide the directory structure. You have to create web-accessible directories for CGI files and public web pages and a kind of NEOS workspace directory [source]. The latter is called "directory for variable-length files", and if web-accessible, will make all job submissions to your NEOS server public [source]. In our case, we create these directories below the NEOS installation base dir (originally server-4.0). The workspace dir and document root dir are siblings, so job submissions will not be public.
    sudo mkdir /var/local/neos/cgi-bin/ /var/local/neos/htdocs/ /var/local/neos/workspace/;
  3. Adjust file ownership. Change file ownership rights to the user who will install and run the NEOS server. For our Ubuntu 13.10 AMI running as an Amazon EC2 Spot Instance, we use for example:
    sudo chown -R ubuntu:ubuntu /var/local/neos;
  4. Provide Mail. The NEOS Makefile expects a program Mail (yes, caps M), which in old times was used for an extended version of mail [source]. Let's at least provide mail as a surrogate and see if that works:
    apt-get install mail && sudo ln -s $(which mail) /usr/local/bin/Mail
  5. Configure NEOS. Execute make and answer its config questions according to the NEOS FAQ instructions:
    cd /var/local/neos/config && make
  6. Configure crash recovery. Configure NEOS so it will be automatically restarted via cron when it crashes. For that, execute the following command as the user who should run the NEOS server (but if crontab -l shows you have a crontab already, edit it manually since the following command would replace it): crontab /usr/local/neos/crontabfile.
  7. Install legacy libs. The NEOS server restart script uses, a legacy Perl library. This creates a warning about being deprecated and imminent removal from the next major release, so we resolve that warning by installing the library which will provide it in the future: sudo apt-get install libperl4-corelibs-perl.
  8. Start your NEOS server.
  9. Check that the NEOS server is running. Just check in ps aux output that the above command started the, and daemons successfully [source].
  10. Confirm that the XML-RPC interface to your server works. By default it resides at port 3333, you configured it with make above. For that, just visit that URL with a browser (something like ). If it works, the NEOS server will server you a message like this:
    your-server-name: ERROR: "Host:" is not recognized by this server.
  11. Install and configure a web server. It will serve the NEOS web interface. In this case, we use lighttpd.
    1. Install lighttpd.
      sudo apt-get install lighttpd
    2. Enable CGI. Enable the CGI module that you will use to serve the NEOS Perl application:
      sudo lighty-enable-mod cgi
    3. Don't serve CGI files as source! A little security optimization for the NEOS server files: in /etc/lighttpd/lighttpd.conf, change this line
      static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
      to this
      static-file.exclude-extensions = ( ".php", ".pl", ".fcgi", ".cgi" )
    4. Add a configuration section for the NEOS server. This goes to /etc/lighttpd/lighttpd.conf (in vhost style though it's our only site).
      $HTTP[“host”]  =~ "" {
        server.document-root = "/var/local/neos/htdocs"
        alias.url += ( "/cgi-bin" => "/var/local/neos/cgi-bin/" )
        $HTTP[“url”] =~ "^/cgi-bin" {
            cgi.assign = ( ".cgi" => "" )

      [References: nixCraft lighttpd setup for Perl programs; lighttpd Configuration File Options reference.]
    5. Reload the lighttpd configuration. Execute: sudo service lighttpd force-reload
    6. Adjust file permissions. We need to give the web server user (by default www-data for lighttpd) read and write permissions to some directories:
      cd /var/local/neos;
      sudo chown -R :www-data .;
      sudo chmod g+r+w htdocs/jobs workspace/spool/WEB workspace/databases workspace/tmp
    7. Test the web interface. Make sure that the NEOS web interface works by visiting the base URL in a browser. It would be for the above case. Also visit to make sure your CGI config works.
  12. Configure your system so that the NEOS server will be started at system start. This is especially relevant when using an Amazon EC2 spot instance, since these are occasionally shut down and restarted depending on your bid pricing (and yes, this means system shutdown, not virtual machine hibernating). For that add the following to the content of /etc/rc.local (and disable the default exit 0 if still present):

Registering solvers at your NEOS server

Your NEOS server 4.0 is installed now, but so far it does not have any knowledge about what solvers are available and how to contact them. The NEOS Solvers FAQ explains the process of registering solvers; see also this short list of steps and the HelloNEOS example.

The problem is that the configurations for registering all the solvers of the public NEOS server are all missing – not included in the NEOS server software as they are considered parts of the installation. You would have to write a complex XML file and a wrapper script to (for example) make your NEOS server talk to the free software COIN-OR CBC solver.  In the time needed for this, you can just as well install the alternative solution COIN-OR OS, which comes already pre-configured for being used with CBC. Which is why I abandoned using NEOS at this point.

Installing a solver and making it talk to your NEOS server

At this point your NEOS server knows how to talk to the CBC solver, but neither is your CBC solver installed nor did we add anything to let it know how to talk back to the NEOS server. So let's do both of this now.

(Note: You might see the neos-comms packages for download. However, do not use these. Reasoning: These files are from 1998, while code with equivalent functionality is available inside the latest NEOS 4.0 2002-10-25 server package. That code is clearly newer and better, with comments and all. The neos-comms package contained a neos-comms-4.01/bin/client file that is not available in the new code, but seemingly is just an added start script for the comms daemon and Tcl/Tk interface that got now integrated into the daemon and Tcl/Tk application themselves.)

  1. Start the comms daemon. This is the "Communications daemon" which has to run on the solver workstation (same machine in our case) and mediates between the NEOS server on one side and the solver (here CBC) on the other. It can be started with the "Communications GUI", available as a Tcl/Tk application within the NEOS server software installation. For details, see comms-help.txt (also available within the equivalent place in your NEOS server installation).

Links to NEOS documentation

AWS CLI is the Amazon Web Services command line interface tool, the new unified utility to manage your cloudy Amazon things.

People are usually told to install it with pip install awscli (including in the official docs), but this is a hateable solution for Linux package system fans because

  • You get one more package system (pip, for Python packages) where you have to care for updates, and where you will forget just that. Not that it would be any worse than having own package management systems already for Firefox add-ons, Chrome extensions, Gnome extensions, Ruby gems, Drupal modules, and WordPress plugins. All of that is just plain bad. Grrrr.
  • You no longer have a single point of control and overview for what software is installed on your system.

So, let's try installing the AWS CLI from packages. Fortunately, there are fairly recent (awscli 1.2.9, from 2014-01) packages for upcoming Ubuntu 14.04 (Trusty Tahr). We are on Ubuntu 13.10 however, but we can fix it by adapting these instructions for Debian to our situation:

  1. Add a package source for Ubuntu trusty, by adding a line like this (with your Ubuntu mirror) to the bottom of /etc/apt/sources.list:
    deb trusty main universe
  2. Create a preferece for Ubuntu trusty packages that will allow to install them when specifying the distribution, but will not select them automatically even when the version is newer than the local one. For that, create a file /etc/apt/preferences.d/ubuntu-trusty.pref with the following content:
    Package: *
    Pin: release a=trusty
    Pin-Priority: 200
  3. Install awscli and its dependencies: sudo apt-get update; sudo apt-get install -t trusty awscli.

You are ready to use it now (try aws --version). Note that they include the functional equivalent of the Amazon EC2 CLI tools, and many more Amazon CLI tools – you will very probably not need to install any Amazon specific CLI tools any more, regardless of what outdated how-tos are telling you.

Also see Amazon's official AWS CLI documentation.


This issue started to occur right after installing Ubuntu 13.10 on a ThinkPad T61 with an "Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)" according to lspci. So, whenever I do one of these:

  • adjust volume with the hardware volume silence / up / down buttons, only while not in a Skype call
  • adjust volume with an equivalent software mixer feature, only while not in a Skype call

the effect is this:

  • the next Skype call will be completely silent (both output and input do not work)
  • the Skype call after that will play a randomized variant of rattling noise for output, while input probably works fine (judged by the level bar indicator); interestingly, the closing sound of the Skype call will play correctly, which indicates that only one of the audiostreams is not initialized correctly (the Gnome sound settings panel shows that two are in use during a call)
  • the Skype call after that will play also the output, but with lots of stuttering in between
  • the Skype call after that will play the output correctly, and the input will also work fine

For this to be repeatable, allow for some 3-5 seconds of separation between calls. At times, these four steps will also be reduced to three, or the "rattling noise" or "stuttering" step could also occur two or more times.

In addition, there is a similar problem with Skype chats. Whenever I do one of these:

  • send a message

the effect is this:

  • a randomized variant of permanent, rattling noise (the "message sent" sound will not be sent)

This noise will persist also through Skype calls initiated afterwards. It will (in most cases) change when sending another message, and after some messages will also completely disappear again. The surefire way to make it disappear is though when your chat partner sends you a message.


The reason for this behavior is that Ubuntu 13.10 ships with PulseAudio 4.0, and Skype does not properly support that so far [source].

The proper solution is to simply install Skype from the Canonical Partner repositories (so, not by manually downloading a Skype .deb via its website). It contains a patch to the skype.desktop file that starts Skype now with a proper workaround as "env PULSE_LATENCY_MSEC=60 skype" [source].

However, if like me you're used to start applications via the Alt+F2 mini-terminal, you might even have this patched Skype package installed, and it has still no effect to fix your audio in Skype. As you probably want to keep starting Skype by hitting Alt+F2 and typing skype, here is a way to do so:

  1. Createa file /usr/local/bin/skype, with the following content:


    # Workaround for the Skype incompatibility with PulseAudio 4.0, as explained in
    # This is already installed in the Ubuntu Saucy Skype package from Canonical Partner repos, however their
    # solution of prepending an environment variable in the .desktop file is not used when starting Skype
    # via the Alt+F2 mini-terminal. To apply the solution for that too, we need this file to supersede the normal
    # Skype command. Use "which skype" to confirm that the skype command afterwards indeed refers to
    # /usr/local/bin/skype instead of /usr/bin/skype.

    env PULSE_LATENCY_MSEC=60 /usr/bin/skype

  2. Give proper execution rights to that file.
  3. Check with which skype to make sure Skype is now called from /usr/local/bin/skype instead of from /usr/bin/skype.

There are also some dirty workarounds (here mentioned only to learn something about Skype and Pulseaudio, not to use them):

  1. Do not use volume buttons except when in a Skype call. This is not practical of course.
  2. Disable Skype sound events for "Call Connecting" and "Chat Message Sent", and maybe all others. This can be done in the Skype "Options -> Notifications" menu item. This however can result in Skype calls falling completely silent, and this will also not fix itself in the next call then. (It can however be fixed, right during the call even, by playing some seconds of sound from a different application.)
  3. Create the permanent random noise, then mute it via the "System Sounds" stream. This works as follows:
    1. Disable the "System Sounds" PulseAudio stream by going to the Gnome Sound Settings dialog, there to tab "Sound Effects" and set "Alert Volume: Off". Alternatively, in Skype go to "Options -> Sound Devices -> Open Pulse Audio Volume Control -> Playback", and click the "Mute audio" button for stream "System sounds".  In both cases, you will notice that the Skype sound channel in the "Applications" tab (if there is one, usually only after step 2) also goes silent, and with it the Skype notifications in chats, and your volume level adjustment feedback sound goes silent as well (explanation see below).
    2. Let Skype create a sound mess. You have to create that permanent random noise, either by using the "send chat message" technique from above (with a notifocation sound enabled of course), or by test playing any notification sound via Skype's "Options -> Notifications -> Test Event" button. (You can not use the random noise generated by a Skype call with broken audio from above.)
    3. Now do whatever you want in Skype, the problem with corrupted sound in calls will not appear any more, even when using volume adjustments in between of calls.
    4. You have to repeat step 2 after a restart of Skype. (The muting of the System Sounds stream stays active after Skype quits because it is not a Skype feature; however Skype is only immune against creating corrupt audio in calls once it has corrupted the System Sounds audio by executing step 2.)

Explanation Attempt

Let me try a little explanation (just from observations, I do not know how PulseAudio works internally): The problem of Skype seems to be that it cannot properly write to the "System Sounds" stream if another application has written to it in between (including the feedback sounds of the volume change buttons). When Skype tries to write to the System Sounds stream in this situation, it results in that noise (as exemplified by the "send chat message" case). Or for some reason, it can also result in all Skype sounds being muted, and on second try in that noise (as exemplified by the phone call example; it's really due to the notification sounds played at the start of the phone call, since there is no such problem when disabling the notification sounds).

So, the third workaround above works by letting Skype try (creating the noise), but muting that noise away (before or afterwards). As Skype's attempt to write to the channel never returns, it is blocked and Skype has to use a different (newly created) channel for the notification sounds when starting a phone call, as can be seen in the "Applications" tab of Gnome sound settings. That might be why now, playing the notification sound no longer results in corrupted audio. That indeed Skype tries permanently to write to the System Sounds channel (and only creating noise doing so) can be recognized from the fact that the noise stops when Skype exits: then, at last, it stops its desperate attempts of writing to System Sounds.

Other Issues: Silent Input and Output

Muted input. For some reason, at times it happens that Skype shuts off the microphone input when exiting. (This is possibly related to letting Skype access ones input mixer levels in its options dialog.) It can be fixed by going into the Gnome Sound Settings dialog, to tab "Input", and switching "Input volume" off and on again. When you see the input level bar moving when sound is present, all is well again.

Muted output. In other cases (as seen above), Skype output might be completely muted, while still working for other applications. Playing any sound from another application will fix this. And probably, going to Gnome Sound Settings and switching "Output volume" off and on again will also help.

Checkvist is a nice, web-based ouline editor. Since it uses a hierarchical content structure, and a mindmapping software like Freemind does the same, interfacing between them can work well in theory. There are some quirks and tips though that we will explore here in practice.

I selected Checkvist among alternative solutions for the following reasons:

  • Work fast with large amounts of text. Large amounts means here something like 400k characters (400 pages A4), which Freemind can handle easily. The web-based, open source mindmapping tool Wisemapping for example was only able to work with some few pages of text before getting sluggish).
  • Unlimited lists, list items and other features in the gratis version. In contrast, Workflowy is also nice but offers only 250 free list items per month … .
  • Collaborative editing in the free version. Because that is what I need it for: a real-time collaborative interface for some content I developed so far in Freemind mindmaps.
  • Public sharing in the free version.
  • Comfortable importing from Freemind 1.0. In contrast, Wisemapping for example would support only imports from Freemind 0.9 directly, so you would need Freemind 0.9 installed as well to copy, paste and save your Freemind 1.0 mindmap in 0.9 format before uploading it.

How to import Freemind content into Checkvist

  1. You can only import plain text. No icons, colors, HTML rich text formatting of nodes etc., but you do not have to remove them before either.
  2. Make sure you do not have multiple paragraphs of text in any one node. Because the second and following paragraphs would start without indentation in the text version, leading to hierarchy level errors during the import. So, split every node that currently has multiple paragraphs using this technique:
    1. Position the node selection at the root node of the branch you want to export.
    2. Do "Navigate -> Unfold All" (Ctrl + Shift + End).
    3. Do "Edit -> Select Visible Branch" (Ctrl + Shift + A).
    4. Do "Format -> Use Plain Text". This will convert bulleted and numbered lists into normal paragraphs, as else "Split Node" would not be able to break them up.
    5. Do "Tools -> Split Node".
    6. Do "Navigate -> Fold All" (Ctrl + Shift + Home).
  3. Copy the content you want to import. Select all nodes you want to appear on the first level after the import, and do "Edit -> Copy" (Ctrl + C).
  4. In Checkvist, select "Import" and paste the clipboard content.
  5. Click "Import tasks". It will import your Freemind content as indented text.