random neuron misfires

I stumbled upon this recently and wanted to add it to the list of other HOWTOs I have on using rsync to back up your device or machine. I’m a BIG fan of rsync, and use it all the time for backing up Linux, BSD, Windows machines, tablets and pretty much everything.

Now, it’s drop-dead simple to back up your Android device over wireless, using an rsync app on the device, and talking to any rsyncd you’ve got set up to receive that data. The setup isn’t terribly intuitive using this specific app, but it does work really well.

I found an app called “Syncopoli” through F-Droid (a free alternative to the Google Play Store), and installed it as a means to try to back up my non-rooted Android device. On my rooted Android devices, I use Titanium Backup Pro, which works fabulously. Without root, you’re very limited in the permissions you have available to read and copy data onto and off of the device.

So, install Syncopoli, and then click the 3 dot menu in the upper-right corner of the app to access the “Settings” pane. In here, you’ll want to set your rsync username, password, any relevant keys or other data you need, and also the IP address of the rsync server. Since my rsync server resides on the same side of the LAN, I also checked the box to back up over WiFi only.

I’ll play with setting up a secure tunnel later, so I can back up to my rsync server over the live Internet.

Once the global settings are correctly configured for your environment, click the (+) sign in the lower-right corner to set up a sync profile. Here, you’ll specify what and where you want your data backed up.

Here’s where things get a little tricky. Initially, I thought it was looking for the IP of the Origin and Destination, but it’s actually looking for a path on the Origin side, and an rsync module on the Destination side. It’s not terribly intuitive, but after I figured that out and reconfigured my rsync server with a specific module (stanza) in rsyncd.conf to allow the Android to back up to, it started working.

To go back in and edit your profile, long-press the profile name and choose “Edit Profile” from the popup dialog.

I also went back into the global Settings and set some optimized rsync options (-avP –inplace –partial), and then clicked the “|>” play button in the upper-right to kick off the rsync job. Tapping on the profile after starting the job, I could then see the log on the client end of my Android device. It was these logs which helped me debug the errors initially with the connection and Origin/Destination paths being incorrect.

So my Origin ended up being /storage/extSdCard (my external media card in my Android device) and the destination was my “Android” module on the server. As I type this blog post, it’s pulled over 1,277 files and counting.

Quick, easy, fantastic and you don’t need root!

Playing more and more with Docker across multiple Linux distributions has taught me that not all Linux distributions are treated the same.

There’s a discord right now in the Linux community about systemd vs. SysV init. In our example, CentOS 7.x uses systemd, where all system services are spawned and started.

I am using this version of Linux to set up my own Docker lab host for tire-kicking, but it needs some tweaks.

I also wanted to see if I could use the Docker API from my Android phone, using DockerDroid, which (after configuring this) works famously!

Here’s what you need to do:

1. Log into your CentOS machine and update to the most-current Docker version. The version shipped with CentOS 7 in the repo as I write this post, is “docker-1.3.2-4.el7.centos.x86_64”. You want to be using something more current, and 1.4 is the latest. To fetch that (and preserve your existing version), run the following:

   $ su -
   # cd /bin && mv /bin/docker /bin/docker.el7
   # wget https://get.docker.com/builds/Linux/x86_64/docker-latest -O docker
   # systemctl restart docker
   # exit
   $ 
   

   Now you should have a working Docker with the right version (current). You can verify that:

   $ sudo docker version
   Client version: 1.4.1
   Client API version: 1.16
   Go version (client): go1.3.3
   Git commit (client): 5bc2ff8
   OS/Arch (client): linux/amd64
   Server version: 1.4.1
   Server API version: 1.16
   Go version (server): go1.3.3
   Git commit (server): 5bc2ff8

2. So far, so good! Now we need to make sure firewalld has a rule to permit this port to be exposed for external connections:

   $ sudo firewall-cmd --zone=public --add-port=4243/tcp --permanent
   $ sudo firewall-cmd --reload
   success
   

   You can verify that this new rule was added, by looking at /etc/firewalld/zones/public.xml, which should now have a line that looks like this:

   <port protocol="tcp" port="4243"/>

3. Now let’s reconfigure Docker to expose the API to external client connections, by making sure the OPTIONS line in /etc/sysconfig/docker looks like this (note the portion in bold):

   OPTIONS=--selinux-enabled -H fd:// -H tcp://0.0.0.0:4243
   

4. Restart the Docker service to enact the API on that port (if successful, you will not see any output):

   sudo systemctl restart docker

5. To test the port locally, install telnet and then try telnet’ing to the port on localhost:

   $ sudo telnet localhost 4243
   Trying ::1...
   Connected to localhost.
   Escape character is '^]'.
   
   HTTP/1.1 400 Bad Request
   
   Connection closed by foreign host.

   All looks good so far!

6. Lastly, install DockerDroid and configure it to talk to your server on this port:

   

Now you should be able to use DockerDroid to navigate your Images, Containers and API.

Good luck!