Wednesday, September 17, 2014

Running transmission as a different user

Sometimes things should just be easier. One config file, restart, done. This time I faced quite a different daemon so I though I'll share since it took me a while to figure it out. It's about the transmission-daemon running as a different user.

The why?
I need to download files from the Internet using BitTorrent protocol (like Ubuntu ISO for example) and I'd like to do that using a computer that's serving as my home server.

What's difficult?
First of all there's no place in any of the configuration files to tell you which user is it going to be that's running the daemon. That secret is safely guarded inside /etc/init.d/transmission-daemon. You'll find this kind of line:


So you'd think that's all then. We change it to something like


and life's easy. Well, not exactly. If you try to do this you'll see that transmission-daemon tries to start but fails rapidly. To diagnose what's wrong you'll want to use this daemon in foreground mode like this

transmission-daemon -f --config-dir /var/lib/transmission-daemon/info --log-debug

But that'll only tell you that there are permission issues and that some files that apparently may even have permissions like 666 on folders that will have 777 permissions will still not be out of reach. The problem lies in the default configuration of the daemon. It keeps it's configuration data in /var/lib/transmission-daemon/info however it's customary to store such information in /etc which Ubuntu and Mint do. And so there's a /etc/transmission-daemon/settings.json with the ownership of debian-transmission and it's then linked to the place where Transmission awaits it (/var/lib/transmission-daemon/info/settings.json)

The solution
So here's what I did. I first stopped the deamon or else my configuration file would get overwritten. Then I changed the ownership of the entire structure of /var/lib/transmission-daemon to nobody:nogroup like so

chown -R nobody:nogroup /var/lib/transmission-daemon

Then I removed the /var/lib/transmission-daemon/info/settings.json link and replaced it with the /etc/transmission-daemon cusine:

sudo mv /etc/tranmission-daemon/settings.json /var/lib/transmission-daemon

and I updated the ownership of that file again:

chown -R nobody:nogroup /var/lib/transmission-daemon/info/settings.json

That's it! Transmission now runs as user nobody:nogroup creating new files and folders as nobody:nogroup and life is easier again

Monday, September 8, 2014

Migrating a project from Google Code to GitHub

Recently I've grown very impatient to the progress being made to psi-probe. I use it at work and wherever else I can because it is a fantastic piece of software but the fact that the last commit was around 6 months ago leads me to understand that the project is simply dead.

The original author assured me that he's got major interest in keeping this project alive but it seems he's got no time to do so. Also keeping the project maintained with Subversion these days seems a bit too vintage for me. And so I decided to migrate the whole thing to GitHub.

Migrating the repository itself is quite simple and there's more than one tutorial on the Internet to help you out with it. The major thing that needs to come out at the end is a repository with git tags (not Subversion ones), git branches (same as Subversion ones) and an .gitignore file containing the set of things you'd like to not care for.

Migrating issues is also not very difficult once you have all the tools in place. is your biggest friend. As with any friend there's love and there's hate involved. Basically the tool does everything properly up until some damn comment contains some god forsaken character in which case the whole thing blows up in your face.

Traceback (most recent call last):
  File "./", line 387, in
  File "./", line 288, in process_gcode_issues
    add_comments_to_issue(github_issue, issue)
  File "./", line 120, in add_comments_to_issue
    body = u'_From {author} on {date}_\n\n{body}'.format(**comment)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 362: ordinal not in range(128)

There are 2 places where a similar problem causes the tool to stop working. The other one is at the addition of an issue. I've worked around by catching that error and providing some dummy text like "Unable to import comment". I'll later on modify that comment by hand and using the Copy/Paste method I'll bring it on the level.

To keep the numbering of issues the same as on Google Code I needed to create some dummy issue because someone deleted issue nr 1 and the importer doesn't recognize this fact and skips the creation of the first, missing issue. Fortunately enough it's quite easy what the first issue should contain in a migration project like that so I used that to my advantage :)

Anyways.. If you'd like to see the Psi Probe flurish again you can always post me a thank you card for all the hard work I'm doing :) Or better yet post a pull request with fix to one of the 100+ issues imported from the original project - the choice is yours!

Happy coding!