The Linux Experiment

With the hardware sorted (bar some jiggery-pokery to get the ODD to SSD bay converter to fit properly), I set about deciding what I want this box to do.

The list I came up with looks like this:

• Media serving to my Kodi devices (2 Raspberry Pi systems, my android tablet, and a new Ubuntu PC I’m putting together for retro gaming with my kids)
• FTP – I like to use my NAS like my own personal cloud. My tablet can mount an FTP in its file browser just like any other folder. No sFTP support, though, unfortunately (and I don’t like any of the file browsers I tried which do).
• Transmission (or Deluge) – the main reason for swapping the 4GB of RAM out for 16GB
• SSH (obviously!)
• Dropbox and Google Drive – for when various apps and things integrate well with these mobile apps.
• Backup – the WD My Cloud EX4’s backup options are very poor.
• General file sharing with Windows and Ubuntu – Samba & NFS, naturally.
• Hosting & tinkering with other bits I might want to try & learn about – a website (for practise, not for public viewing), a git… who knows.

Being basically completely unfamiliar with most of this stuff, I was undecided between Ubuntu Desktop or Server for quite a while. Desktop obviously just has so much of this stuff already ready to go, it mounts things automatically, I can use the GUI as a fallback if something isn’t right, its just more like what I’m accustomed to. On the other hand, having the GUI running all the time will just use up unnecessary RAM  – granted I probably don’t have a shortage of that, but still…

In the end I installed both onto VMs on my Windows machine, made copies (so I had a clean version always ready to go without having to reinstall again), and started playing.

First up I wanted to sort how I was going to deal with my media backend. On my current setup I use the Kodi client on one of my PCs to manage a central SQL database. While it works, its a bit slow and rather inneficient, so I went looking for either a headless Kodi backend, or just a way to run it without the GUI. I found all sorts of ideas, builds and code , none of which I understand or feel like I could implement. After a discussion with a linux guru (one of my Uni lecturers) it was clear that my plan was probably not going to work; he had pointed out that he just runs his on DLNA, and that Plex seems to be quite good too. More research, and a question in /r/Kodi later, I had been pointed in the direction of Emby, a backend for Kodi without many of the limitations of Plex and DLNA. Installation was simple enough, but accessing the Web UI wasn’t. When I had setup the VMs I had just left their network settings as NAT; this, it turns out, makes accessing the network from the VM possible, but not accessing the VM from elsewhere on the network (includingother VMs on the same system). I did try to just change the settings in the VM to add a bridged adapter, but it didn’t work. Not knowing enough about networking on linux to fix this, I just went ahead and reinstalled, this time setting up the VM with two network adapters – one NAT and another bridged. This worked a treat, and after adding a few media files and installing Kodi on the Desktop VM, I was able to play videos no problem.

Next, for no particular reason, was getting NFS working. I found guides, forums, blogs etc (my Google-fu is pretty strong) and set about trying. I was sure it should be working, I’d installed nfs-kernel-server, added the entry into /etc/exports, setup the permissions, but I just couldn’t mount it in the Desktop VM – even though I could watch them through Kodi. I ended up having to ask Reddit’s linux4noobs sub. Simple answer… sudo /etc/init.d/nfs-kernel-server start … and instantly it mounted no problem. Turns out that Kodi was actually watching a transcoded stream from Emby, until I had NFS working. Thankfully Samba took less time and hassle to get working (surprisingly), and pretty soon I could access files across both linux and Windows. And there was much rejoycing.

At this point I was getting impatient (plus this microserver is taking up a chunk of space on my desk where I really ought to be doing uni work), so I quickly checked I knew how to setup a static IP, and turned my attention to the real thing.

Next Up:

Booting up The Box
Installing, reinstalling and shenanigans

This post was originally published on Nathanael’s site here.

Seems like I’m at it again, this time fixing Areca Backup on Ubuntu 16.04 (actually Linux Mint 18.1 in my case). For some reason when I download the current version (Areca 7.5 for Linux/GTK) and try and run the areca.sh script I get the following error:

tyler@computer $ ./areca.sh
ls: cannot access ‘/usr/java’: No such file or directory
No valid JRE found in /usr/java.

This is especially odd because I quite clearly do have Java installed:

tyler@computer $ java -version
openjdk version “1.8.0_111”
OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-2ubuntu0.16.04.2-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)

Now granted this may be an issue exclusive to OpenJDK, or just this version of OpenJDK, but I’m hardly going to install Sun Java just to make this program work.

After some digging I narrowed it down to the look_for_java() function inside of the areca_run.sh script located in the Areca /bin/ directory. Now I’m quite sure there is a far more elegant solution than this but I simply commented out the vast majority of this function and hard coded the directory of my system’s Java binary. Here is how you can do the same.

First locate where your Java is installed by running the which command:

tyler@computer $ which java
/usr/bin/java

As you can see from the output above my java executable exists in my /usr/bin/ directory.

Next open up areca_run.sh inside of the Areca /bin/ directory and modify the look_for_java() function. In here you’ll want to set the variable JAVA_PROGRAM_DIR to your directory above (i.e. in my case it would be /usr/bin/) and then return 0 indicating no error. You can either simply delete the rest or just comment out the remaining function script by placing a # character at the start of each line.

#Method to locate matching JREs
look_for_java() {
JAVA_PROGRAM_DIR=”/usr/bin/”
return 0
# IFS=$’\n’
# potential_java_dirs=(`ls -1 “$JAVADIR” | sort | tac`)
# IFS=
# for D in “${potential_java_dirs[@]}”; do
#    if [[ -d “$JAVADIR/$D” && -x “$JAVADIR/$D/bin/java” ]]; then
#       JAVA_PROGRAM_DIR=”$JAVADIR/$D/bin/”
#       echo “JRE found in ${JAVA_PROGRAM_DIR} directory.”
#       if check_version ; then
#          return 0
#       else
#          return 1
#       fi
#    fi
# done
# echo “No valid JRE found in ${JAVADIR}.”
# return 1
}

Once you’ve saved the file you should be able to run the normal areca.sh script now without encountering any errors!

This post originally appeared on my personal website here.

There is no denying that the installation process for the Barry project sucks. That said, the promise of having the ability to sync my blackberry with a linux-based calendar application like Mozilla’s Thunderbird or the Evolution mail client kept me working at it through the wee hours of the night. The Barry site at Sourceforge provides not one, not two, but four Debian packages (which rely on an additional two undocumented packages), that need to be downloaded and installed in a specific and undocumented order:

1. libbarry0_0.15-0_i386.deb (sourceforge)
2. barry-util_0.15-0_i386.deb (sourceforge)
3. libglademm-2.4-1c2a (debian.org)
4. barrybackup-gui_0.15-0_i386.deb (sourceforge)
5. libopensync0 (debian.org)
6. opensync-plugin-barry_0.15-0_i386.deb (sourceforge)

With the packages installed, I launched a terminal and used the auto-complete feature to find the command barrybackup. At first, I couldn’t figure out what it’s syntax was, until I realized that it doesn’t need any arguments, because it simply launches a GUI (that doesn’t appear anywhere in my Applications menu) that lets you back up your device databases:

Well, thats a handy utility, assuming that it is also capable of restoring the backups to the device. I shied away from trying the restore feature, as I didn’t have access to a Windows box with which to fix the device should the worst happen.

I’m currently using Mozilla’s Thunderbird (re-branded in Debian as Icedove) as my primary mail client, along with the Lightning calendar plugin, and would be thrilled if I could synchronize it with my Blackberry. You’ll note that libopensync and a Barry opensync plugin were both a part of the installation process; having never used libopensync, I had a tough time figuring out how to make them cooperate.

The opensync page on Wikipedia lead me to install the multisync-tools package, which claims to be able to “synchronize calendars, address books and other PIM data between programs on your computer and other computers, mobile devices, PDAs or cell phones. It relies on the OpenSync  framework to do the actual synchronisation.” I have PIM data that I would like to sync! I have the OpenSync framework! We’re on a roll!

Finally, I installed the multisync-0.90 GUI and opensync-plugin-evolution v0.22-2 opensync plugin packages, which should have allowed me to sync between the Evolution mail client and my phone. I chose to try the process with this software first, as a plugin for Thunderbird was not immediately available. Unfortunately, when attempting to sync, I got this message:

Surprisingly, it was the evolution plugin that failed to connect

Useful? Sort of. The Add button let me set up a Blackberry profile with both the barry and evolution plugins, but no matter how I tweaked the settings, I couldn’t get the evolution plugin to connect to my PIM data. Further, after making a synchronization group and adding plugins to it, I couldn’t find a way of replacing a plugin with a different one.

Sick of the limited GUI, I moved on to try KitchenSync, the KDE-based alternative. While it was uglier, I found it to be a far more useful front-end, and managed to get it to sync my device calendar and contacts with my filesystem:

This process exported all of the calendar and contact information from my Blackberry to a folder full of vCalendar and vContact files on my machine. Now if only I could get Thunderbird to read these files.

After a bit more looking around on the OpenSync webpage, I found a link to these guys, who claim to have programmed an opensync plugin called libopensync-plugin-mozilla-0.1.6 that allows Thunderbird and Lightning to talk to the OpenSync manager. They provide the plugin as a tarball that contains a *.so binary file and a sample *.xml configuration file… but no instructions on how to install them.

Thouroughly lost, I turned to the #opensync channel on freenode.net for help. Until they see fit to help me out, I’m taking a break from this. No sense in giving myself a heart attack out of extreme frustration.

Edit: I got some help from the members of the #opensync channel, who recommended that I drop the mozilla-sync.so file into the /usr/lib/opensync/plugins/ directory. While this didn’t immediately allow OpenSync to see the plugin, I noticed that every other plugin in the directory has an associated *.la configuration file. So I fabricated my own *.la file, and tried again. That didn’t work either.

The members of the channel then recommended that I try downloading the source code directly from the creators. I did as much, and found that it didn’t include a configure or make script, but just the source code. Not knowing how to proceed, I attempted to follow these instructions, which entailed downloading another 20 or so packages, including the sunbird-xpcom-devel package, which again lacks documentation on how to proceed with installation.

Lacking that package, and again frustrated beyond belief, I decided to drop the issue for another hour or so and do some math homework. That’s right, I chose to do math homework over playing with my computer, because this process has been that frustrating.

It doesn’t help that this entire process seems to be aimed at installed BlueZync, and not the opensync-mozilla-plugin. What the hell is going on here?