Here is how to synchronize any Unix or Linux applications’ settings and data across multiple computers using Dropbox, SparkleShare, or other alternative and a little scripting.

1. Find the files of folders that your applications use. For example “~/.thunderbird” for Thunderbird, “~/.purple” for Pidgin, or “~/.mutt” for mutt. Be sure to back them up somewhere before trying this.
2. Move those folders to your synchronized folder. In my case it is stored in ~/sync/.
3. Install Ruby if you don’t have it.
4. Modify this script for your needs then run it. THIS WILL DELETE THE FILES FROM THEIR ORIGINAL LOCATION!

This script creates a symlinks where the applications will expect their files and folders to be to your sync directory. The synchronized applications work as expected as their settings and data get automatically uploaded to whatever online storage utility you use.

If I lose my home partition I still have a backup. If I want to use a computer at home and a computer at work I can do that and have the applications be in the same state. My bookmarks, IM logs, mail cache, accounts, and everything else shows up on every other synchronized machine. This type of linking is now integral to how I use a computer. I hope this benefits someone else as much as it has me.

I love Mutt. I love the power and flexibility it gives me over my email. Every so often, though, I run into little problems that I would not normally have on any other mail client.

One such problem manifested itself when I was tasked with setting up SPF and DKIM on my company’s mail servers. DKIM reported “no signature data” for every message I sent with Mutt. The resulting message had no DKIM signature attached.

After a few days of banging my head into the desk I realized that I had only been testing with Mutt. I did what I should have done from the beginning and sent a message with the mail command on the server itself. It was signed. Then I tried it with Thunderbird. That too worked. Happy that it was actually working I turned my attention to my sadistic mail client.

The problem was that I was using msmtp for my mail delivery. It’s a useful smtp client that makes sending messages with Mutt trivial without having to configure sendmail or postfix on your local machine. DKIM wasn’t signing the messages because msmtp was using the mail server as a relay. DKIM doesn’t like that.

Here’s the solution. Instead of using msmtp, replace the msmtp configuration options in your muttrc file with set smtp_url=”smtp://username:yourpassword@your.mail.server”. That will have Mutt sending directly through the SMTP server. More importantly, DKIM will sign them.

For nearly a year as of writing this I have been using my own crude replacement to Dropbox. It lacks some of the features that Dropbox and other “cloud storage solutions” offer but it does the one thing I need quite well. It synchronizes files between my home server and multiple computers and it does so (relatively) securely. Here’s what it does and doesn’t do and how to do it.

What it does:

• Securely synchronizes files between multiple computers and a central server over SSH
• Provides a public folder that I can link people to with any functional web server
• Has a web interface with AjaXplorer
• Keeps my data in my hands until my control

What it doesn’t do:

• Version control (yet)
• Sharing of individual folders with others
• Place my data in the hands of a questionable third party

What you need:

• A central server (preferably running some for of Linux or Unix) to hold the files
• One or more clients to sync with
• SSH client and daemon
• autossh
• Unison

First, set up the SSH daemon on the server AND the client machines. Then set up a public key for each client machine so they can log into the server without a password. After that, set up a public key for a reverse SSH connection from the server back to the client. This will be accomplished with SSH reverse tunnelling. Here is an example of this between one client machine and the server:

5559 is an arbitrary port chosen for the reverse tunnel to run on. Notice how from the  server you SSH to localhost and wind up back at your client machine. That is what SSH reverse tunnelling does and that is what will facilitate full two way encrypted transportation of files with Unison. After the public keys have been set up you should no longer be prompted for a password going either way. This will allow the process to be automated.

Next, I would recommend setting up autossh. This will allow the clients to maintain a persistent connection to the server. It will keep trying to re-establish the SSH connection if it fails. That would look like:

29001 is an arbitrarily chosen port that autossh uses for monitoring the connection. In my setup I have that command run whenever a new network connection is made. I also have it check if autossh is already running otherwise it will error out. That looks like this:

The heart of this setup is Unison. It is very good at syncing files locally and remotely. In my case I use it over SSH. It is very careful about not losing any data and will report a conflict rather than overwrite a file that it can’t merge. Unison must be installed on the server AND the clients and they must all be the same version. In my case, my clients run Arch but my server runs Debian stable. Because of this, I have to compile Unison on Debian to keep it updated as the version in the apt repositories is a bit outdated. The Unison command itself looks like this when ran on the server:

This by itself is not enough. We’re going to create a script will have the server sync with each client. It can be cronned to run every so often. Mine runs every 10 minutes. Don’t forget to update the variables for your setup.

That’s the bare basics. The server checks for connections to the clients at the ports you specify. If it finds them it runs Unison over SSH. I have tested this with 3 clients and over 7000 files at once during the initial sync. It was fast, lost no data, and had no conflicts. The end result is a folder I place data in that gets transferred to my server and sent to other clients.

For a public folder set up a web server and point it at a specific folder within the synced directory on the server. I suggest trying out AjaXplorer for a web interface.

Obviously there is a lot of room for improvement. Git could replace Unison for the sake of version control. It would also be nice to get it working with inotify rather than having the server poll the clients. If you got this far, thanks for reading. I’m open to opinions and suggestions for improvements.

My first post on this blog was Simple Secure Screenshot Sharing for Ubuntu. This is an updated, much easier way to do it. Here are the requirements:

• Linux – Needs no explanation
• Dropbox – A great way to synchronize and share files. Dropbox makes sharing easy by providing a public link to anything that you place into Dropbox’s “Public” folder.
• ImageMagick – ImageMagick is a powerful command line image manipulation program. This is what will actually take the screenshots.
• xclip – A command line utility that allows you to copy to the clipboard from the commandline. It will be used to copy the public url from the Dropbox command line application and send it to the clipboard.

Install Dropbox, xclip, and ImageMagick then save this simple bash script to “~/bin/screenshare”:
#!/bin/bash #Set the path IMAGEPATH=~/Dropbox/Public/Screenshot.png #Save the screenshot to the path import -window root $IMAGEPATH #Get the url and send it the clipboard dropbox puburl$IMAGEPATH | xclip

This assumes that your Dropbox path is in ~/Dropbox. Don’t forget to make it executable with “chmod +x ~/bin/screenshare”.

To take a screenshot, from a command line, run dialog, or any other method of issuing commands type “screenshare”. Alternatively, you could map it to the Print Screen keyboard button. You should be now able to paste your shared screenshot from the clipboard.

Recently, I set up my lappy with Debian and awesome as the standalone window manager. I am partial to using network-manager but quickly realized that it relied on the gnome keyring manager to save wifi passwords. Without it, I would have to enter my password on every login.

I found the solution here. Start nm-applet like this in your .xinitrc file or your window manager’s respective startup configuration file.

dbus-launch nm-applet --sm-disable &

Many are aware of how to use find with xargs. For example, to remove those annoying .DS_Store files OS X leaves everywhere you can do:

find . -name .DS_Store -print0 | xargs -0 print rm -f

The key here is -print0 and -0 tells find and xargs to use the ascii null character instead of spaces. Recently I learned how to do something similar with locate as that command doesn’t have a -print0 option.

locate 'what_you_are_looking_for' -0 | xargs -0 rm -f

The -0 in the locate is equivalent to the -print0 in find.

Windows is special. This we all know. One of its most especially special tendencies is that it does not automatically run a file system check every so often. It’s easy enough to automate that on a single machine but what about an entire domain? Here’s a way I’ve thrown together to do just that.

First, download pstools from http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx and install it somewhere. For me my path is c:\bin\PsTools. Be sure to replace the path in the following command with where you install it.

Save it as a .bat file somewhere (c:\bin\chkdsk_whole_domain.bat in my case). Then you can go to the server’s Windows system scheduler and have it run whenever you like. Now all of the workstation computers will run chkdsk on their next reboot. That’s one less task you have to do manually!

This is a quick writeup of how I set up public wifi access at a small business. The method employs two routers sharing one cable modem connection. This allows a point of sale (POS) system and the public wifi to be on separate networks. This prevents anyone from trying to sniff out credit card transactions. It also uses some basic quality of service (QOS) settings to prevent people from hogging bandwidth from the POS system. Here’s what you will need to duplicate my setup.

Now for the setup.

1. Download and install the Tomato firmware onto the wireless router. Tomato makes a wireless router much more stable and adds features that you’ll never have with the stock Linksys firmware such as real time bandwidth monitoring, QOS settings, and much more. Carefully read and follow the instructions included in the download. If you do not know what you are doing you can brick your router so don’t skip reading the installation guide.
2. Attach the cable modem to the WAN port of the wired router with a patch cable.
3. Enable DMZ on the wired router and connect the DMZ port of the wired router to the WAN port of the wireless router with a regular network cable.
4. Attach the POS system to an available LAN port on the wired router.
5. Set the routers to be on different subnets. For example, set the IP of the wired router to be 192.168.1.1 and the IP of the wireless router to be 192.168.2.1. This will prevent DHCP conflicts.
6. Change the default admin passwords for both routers to something else.

At this point the setup should be working and all connected computers, wired and wireless, should have internet access. All that’s left is to enable some QOS setting to ensure the POS system will always have bandwidth. This step is optional but could save a headache later on in the event someone decides to abuse the wireless network.

2. Enable QOS in the Tomato settings on the wireless router.
3. Under the QOS “Basic Settings” page set the inbound and outbound limits to be a little less than the values from the speed test. In my case I left a quarter of the upload and download bandwidth for the POS system just to be on the safe side.
4. Save your settings. Confirm the settings work by running separate speed tests for each router. The speed for the wireless router should go only to what you set the limit to be.

That’s it! The total cost of this setup is easily less than $100 and in my experience has been very reliable. DO NOT FOLLOW THE BELOW ADVICE I was new to Arch at the time and didn’t know that you had to run “ck-launch-session nm-applet” to get it work as a normal user. iwconfig only running as root is not a bug as I described, but rather a lack of knowledge at the time on my part. I’m leaving the original post below for archive’s sake. Original Post Recently I’ve gotten into Arch Linux. Its flexibility, documentation, and well thought out method of configuration make it an excellent distro. I’ve also been running it primarily on my Dell Mini 9 netbook. This computer has a pesky BCM4312 wireless card from Broadcom. Here’s how I dealt with it. Criticism and suggestions welcome. This is assuming that you’re using Network Manager. The b43 drivers just don’t work with WEP or WPA making it pretty much useless. First install the broadcom-wl drivers. Then install Network Manager. Now you’ll probably notice that still nothing seems to work; not even iwconfig or any of the other command line wireless tools. The problem appears to be a bug where anything related to wireless networking with the broadcom-wl driver only works as the root user. A quick workaround for this is to enter visudo in the command line and add %wheel ALL=NOPASSWD: /usr/bin/nm-applet at the end of the file. Save and close. Reboot. That should get you up and going at least as far network manager is concerned. My final solution for this is to just replace the wireless card with something more Linux friendly. I hope this helps. VirtualBox is one of my favorite Virtualization tools. While my primary OS is Linux I still need to visit Windows from time to time to test in IE, Safari, or to use some specific oddball program. The latest versions of VirtualBox starting with version 3.2 has a new feature that makes these trips to Windows a little less painful. Many are aware of VirtualBox’s seamless mode. For those who aren’t see this video to understand what it is. While seamless mode is old news, what isn’t is the ability to launch applications in the guest operating system directly from the host with the VBoxManage command line tool. For example, running Linux as the host OS and Windows XP as the guest I can launch IE with the command "VBoxManage guestcontrol execute "Windows XP" "C:\Program Files\Internet Explorer\iexplore.exe" --username windowsusername Replacing “windowsusername” with the username you use to log in to the Windows guest and “Windows XP” with the name you gave your guest OS in VirtualBox. Arguments can also be passed to the program being launch in the guest OS with the –arguments flag. For example ﻿VBoxManage guestcontrol execute "Windows XP" "C:\Program Files\Internet Explorer\iexplore.exe" --username windowsusername --arguments "http://google.com" While this is all well and good, it is not exactly convenient. In your respective desktop environment it would be relatively simple to create a launcher that can execute this command but it falls short on truly integrating it with the OS. What about the ability to right click on a file on your host desktop and have it open in it’s respective Windows based program. Using Windows notepad as a simple example, here’s how to do just that. First, be sure that you have the VirtualBox guest additions installed. Then, in your VirtualBox settings, create a permanent shared folder in your guest OS to your host’s home directory. This will give it the access it needs to open files from your host’s file system. After that, in “/usr/local/bin” create an executable bash script named “notepad” and paste into it this code. #!/bin/bash oldPath=${1//\/home/\/\/VBOXSVR} newPath=${oldPath//\//\\} VBoxManage guestcontrol execute "Windows XP" "C:\Windows\notepad.exe" --username windowsusername --arguments "$newPath"

This simple script takes the full file path that gets passed in and converts it to a valid Windows path. What goes in as “/home/username/Desktop/test.txt” would become “\\VBOXSVR\username\Desktop\text.txt”. The path then gets passed to the guest OS’s program for opening. Save that file and don’t forget to give make it executable with

chmod +x /usr/local/bin/notepad

In your respective desktop environment (mine is Gnome) create a file called test.txt on your desktop and associate the command “/usr/local/bin/notepad” to it. With Gnome this is done by right clicking on the file, clicking “Properties”, going to the “Open With” tab and clicking the “Add” button. An “Add Application” dialog will pop up. In that window, expand the “Use a custom command” dropdown and enter “/usr/local/bin/notepad” into the textfield provided. Then click the “Add” button then the “Close” button.

To get the full effect, put your guest OS into seamless mode then right click on “test.txt” on your desktop, mouse over “Open With”, then click on “notepad”. If you did everything correctly the Windows notepad should launch with the contents of “test.txt”. Here’s a video of the whole thing put together.

This example can be applied to any Windows program. With a little modification, the script can be applied to other guest operating systems as well.