Home photo server, part 1: Server Setup, SCP and FTP

While there are many, many options out there for photo storage, if you are looking for a home storage solution that does NOT involve just plugging in your phone and dumping the pictures to your hard drive, you have to get a little technical. (By the way, if that is what you have to do, there is no shame in it. It is probably a lot safer doing that than letting Google hold all of your photos.)

The first thing I needed was a server. Granted, you could use just about anything these days, and there are a lot of open source/open hardware type solutions, but I was gifted an older, generation 1 Dell PowerEdge 1950 from a friend. Granted, it was made in 2006, but it still is 64 bit, has two quad core Xeon 2 GHz processors, and I loaded it with 24 GB of ram. You can get them on eBay now for about $60. A little overkill for this sort of thing, but the price was right! As a bonus, it supported hardware raid, and I put two 2 TB drives in a mirror array, so that 2 TB of space that was backed up.

From there I loaded CentOS 7 on it per the usual installation method, and updated the system. I also purchased an APC battery backup unit, a Back-UPS 1350. This would only hold the power on for about 15 minutes, but it would help for brown outs, and frequent “blips” where the power goes out for only a second or so, which is common where I live. Later I’ll have to do a post on setting up the auto-shutdown and controls, because that was rather interesting.

So the next thing I needed, if I wanted this to work, was a domain. I needed a way to contact my home computer from my cell phone, especially while not at home. Granted, you could set all of this up so when you come home your phone would automatically back up your photos, but I wanted to be able to do this from abroad. Thus enter No-ip.com. I’ve used them before, and it is great if you are looking for a cheap, cheap solution. Because it is free.

Granted, a free account your hostname will need to be manually renewed every 30 days, but they send you an email, and all you have to do is click the link to keep it active, so it is pretty easy. After creating an account, logging in, getting a dynamic IP address, then all I had to do was install the DUC software. DUC is the Dynamic Update Client software that allows:

“Remote access your computer, DVR, webcam, security camera or any internet connected device easily. Dynamic DNS points an easy to remember hostname to your dynamic IP address.” (noip.com)

All you have to do is download the source code and compile it. It went like this:

$ cd noip-2.1.9-1/
$ make
$ sudo make install

After entering my password, it ran through an installation script and asked me for my account name, password for the account, and which DDNS I wanted to associate with this computer. It is interesting, you can have several.

From here, it then became a matter of preference on how to continue. I toyed with several options on my Android phone for how to get the photos from the phone to the computer over the internet.  One of the first methods I tried was using scp, or secure copy over ssh. So, I installed ssh on my server.

# yum install ssh-server

# cd /etc
# cd ssh/
# ls
# nano sshd_config

I then edited the sshd_config to my liking, there are a lot of guides on this on the internet, so I wont belabor the point here. I will note that I use non-standard ports as a form of extra security, however slight that may be, so you may consider doing the same, but essentially it works as is once installed. Then I opened the ports in the firewall – I list the standard ports here, for ease of following along:

# firewall-cmd
# firewall-cmd –help\
# firewall-cmd –help
# firewall-cmd –add-port=22/tcp
# firewall-cmd –add-port=22/tcp –permanent

And that worked great. Unfortunately, scp is slow and can be cumbersome from an Android phone, especially since I didn’t find any apps that would sync my directories automatically (that were open source so I knew what was really being sync’ed). However, I found several open source options that would sync automatically via FTP. So I decided to install “very Secure FTP”, or vsftp, like so:

# yum install vsftpd

# cd /etc/vsftpd/

# ls

# nano vsftpd.conf

Again, I set it up to my needs, but you can check out this guide for ideas. I also needed to punch some holes in the firewall for the service and for both active and passive mode, since several Android apps would use either.

# firewall-cmd –add-port=21/tcp
# firewall-cmd –add-port=21/tcp –permanent
# firewall-cmd –add-port=20/tcp
# firewall-cmd –add-port=20/tcp –permanent

# firewall-cmd –permanent –add-port=40000-50000/tcp

And viola! All that was left was a quick restart of the processes:

# firewall-cmd –reload

# systemctl restart vsftpd

And now I could use FTP apps on my Android phone to sync my pictures from my phone automatically to the home server! In case you are wondering, a great app for this is on F-Droid, the open source app repository of open source apps. It is called SyncTool, and it is very handy. It supports FTP sync one way, both ways, automatic scheduling or running jobs manually.

Wheeow, that was a long post, but now my photos were being automatically backed up. However, that’s only part of the story, because if I was convincing my wife to ditch Google Photos, I needed to also have a way to browse them online, share them, organize them, etc…. It was time for a web server. Guess we’ll cover that next.

Linux – keep it simple.

The Super Dimensional Fortress

A title like that suggests something between a B17 bomber (the “flying fortress”) and Superman’s hideout (” fortress of solitude “). Well this isn’t either, but it is pretty cool none the less. In talking about sdf.org, a group of 8+ enterprise servers running Unix that collectively make a super computing center that is freely available to the public for use.

There are some paid perks as well, but any user can sign up for a free account and get an ssh login to a private online account, complete with storage space, an email address, your own website URL (you have to create the website yourself, but they host it for you) and access to online games, old school “bboard” bulletin board coms, irc, and more!

With very reasonable one time or annual rates, you can also get DNS, server hosting, mailbox hosting, and other cool goodies. They also service dial up internet for a really reasonable rate (I think it is around $10/month). Certainly worth taking a look if you are at all geeky.

They boast around 40000 active users, so it looks like there are plenty of folks to chat or online game with. It is focused on sharing knowledge and generally helping educate people about technical things, as well as provide a means of access to services that might not be available elsewhere based on a users remote location. Most everything is designed around the terminal, since you log in via ssh, but paid memberships can also use some x11 services, which is pretty neat.

Their mission statement and a brief summary:


Welcome to the only all 64bit public access supercomputing center!

The Super Dimension Fortress is a networked community of free software
authors, teachers, students, researchers, hobbyists, enthusiasts and
the blind. It is operated as a federally recognised non-profit 501(c)7
and is supported by its members.

Our mission is to provide remotely accessible computing facilities for
the advancement of public education, cultural enrichment, scientific
research and recreation. Members can interact electronically with each
other regardless of their location using passive or interactive forums.
Further purposes include the recreational exchange of information
concerning the Liberal and Fine Arts.

Members have access to games, email, usenet, chat, bboard, gopherspace,
webspace, programming utilities, archivers, browsers, and more. The SDF
community is made up of caring, highly skilled people who operate behind
the scenes and in the underground to maintain a non-commercial INTERNET.

While we did initially start out on a single computer in 1987, the
SDF is now a network of 8 64bit enterprise class servers running
NetBSD realising a combined processing power of over 21.1 GFLOPS!

Our mass storage configuration is comprised of 60 spindles of mostly
36.4gb and a few 9.1gb SCA LVD SCSI drives using DIGITAL Storage Works
hotswap disk arrays. We have roughly 2 terabytes of storage online.

We are networked via two sprintlink T1s and a T1 to savvis. We do BGP
peering and try out best to load balance between the links via a CISCO
7xxx router/switch. We are using a 'swamp' class C 192.94.73 which has
basically been assigned to our site admin along with his class C back
when you could request one from the INTERNIC without much fuss.

The userbase is comprised of two major user groups: USERS and ARPA

'user' accounts are free and offer many features.
'arpa' accounts are permanent members and can vote on SDF features.

Supplemental ARPA privilidges include:

MetaARPA ('trusted' member privs (cron, tcp port forwarding))
TWEAK (tweakable and additional disk quota)
VPM (Virtual POP3 mailboxes)
DNS (Domain Name Service)
DBA (MySQL database access)
VHOST (Virtual Web hosting - includes VPM, DNS and DBA)
SERVER (Server process (mud, nameserver, et cetera))
MDNS (Dynamic DNS)
MLIST (Mailing List service)
DIALUP (over 10,000 numbers in the USA + Canada)

Sponsorship information can be found on our website or in the FAQ.

Bottom line: a super geek club that is super fun, even for those who are not super technically savvy. However, an above average computer skilset is required to make use of this system, one should at a minimum know how to use ssh. So head over to sdf.org and check it out!

Linux – keep it simple.

Porting Debian Linux to your cell phone part 3 of 3

If you are still with me, then you have already set up your phone to first boot Debian Linux, and then Linux will start Android in a chroot environment. Your phone is actually already running Debian Linux, just with Android being run and displayed on the screen. At any moment, you can actually stop or kill Android. At this point, you also have the power to mess Andriod up, so do be careful!

If you just tuned in, I recommend that you go back to the 1 of 3 for this post, as there is a lot of critical information you need.

Right now, you can SSH into your own Linux from the Android gui by using any ssh app to yourself as the local host, since our SSH deamon is running. What we want, though, is for your screen to display the Linux screen, instead of the Android that is running in a chroot environment.

A key part of all of this, is that Android, other than through services like SSH, does not know that Debian Linux exists and it does not have any control over the Linux system or functions. One problem with this is that Android may occaisionally crash due to memory problems, if your Linux environment is using too much RAM. Ironically, if you SSH into your Linux environment, you can use ps aux, or top to see all of Android’s running processes. Your Linux environment is now the ultimate root, because even Android doesn’t know it exists. You can log anything from Android and save it, you can stop any Android process. You have complete control over your Android system.

However, before making the “plunge” to a Linux only phone, you need a few details. The easiest way to get these is to do some research on your phone. Through SSH, run the ls command in your /dev folder, and look for “input”

$ cd /dev
$ ls |grep input


On my Samsung Captivate Glide, these are all the available inputs. But what are they? Well, there are several tools to check this. The easiest way, however, is to SSH into Linux, start x11vnc in Linux, and use an app like bvncfree in Android to bring up a visual screen to work with. How you need to do this is a bit tough to describe, because it is so dependent upon your phone and setup. However, if you are using my files, the user trondroid should have a shell script in the home folder for starting jwm in this fashion.

Another way is to start the XserverXDSL app in Android, and then startx in Linux through SSH. That should get you to the same place.

Either way, you should see something similar to this (although this screenshot was taken when I was using Debian Squeeze, rather than the new files, which are Debian Jessie) :


Once you have established a “visual” screen, you now should open up a terminal in your Linux screen. Remember, all input commands that you input right now are from the Android app you are using. That means the “mouse”, “click”, and “keyboard” are all virtual. You need to set up your real screen as a mouse, for motion and clicking. You also need to set up your physical buttons from your phone, and your keyboard if you have one. With your terminal open, use evtest, like so:

$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: STMPE_keypad
/dev/input/event1: mpu-accel
/dev/input/event2: sec_key
/dev/input/event3: sec_touchscreen
/dev/input/event4: proximity_sensor
/dev/input/event5: light_sensor
/dev/input/event6: HALL
/dev/input/event7: sec_touchkey
/dev/input/event8: compass_sensor

This even works on your home computer. For instance, here is my laptop:

$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: Sleep Button
/dev/input/event1: Lid Switch
/dev/input/event2: Power Button
/dev/input/event3: AT Translated Set 2 keyboard
/dev/input/event4: Logitech USB Optical Mouse
/dev/input/event5: SynPS/2 Synaptics TouchPad
/dev/input/event6: Video Bus
/dev/input/event7: ST LIS3LV02DL Accelerometer
/dev/input/event8: HDA ATI SB Mic
/dev/input/event9: HDA ATI SB Line
/dev/input/event10: HDA ATI SB Headphone
/dev/input/event11: HP WMI hotkeys
Select the device event number [0-11]:

But we will focus on the phone. Great! Now we know what event is what input! For instance, event3 is the touchscreen. Now we have something to work with. In my case, event0 is the physical keyboard, but those are rare these days.

You can also test those inputs, by choosing a number for the device, and then using that function. Here you can see me test the “menu key” on the keyboard:

Menu Key on keyboard
Event: time 25170.575766, type 4 (EV_MSC), code 4 (MSC_SCAN), value 8b
Event: time 25170.575844, type 1 (EV_KEY), code 139 (KEY_MENU), value 0
Event: time 25170.575854, ————– EV_SYN ————

Another great tool is called xev, again, open up a terminal and use it like this:

$ xev

ButtonRelease event, serial 33, synthetic NO, window 0x1e00001,
root 0x26f, subw 0x0, time 156984900, (175,123), root:(228,195),
state 0x100, button 1, same_screen YES

MotionNotify event, serial 33, synthetic NO, window 0x1e00001,
root 0x26f, subw 0x0, time 156985076, (177,123), root:(230,195),
state 0x0, is_hint 0, same_screen YES

There is also xinput, here is an output from my computer:

$ xinput test-xi2
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech USB Optical Mouse id=9 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Sleep Button id=8 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]
↳ HP WMI hotkeys id=12 [slave keyboard (3)]
EVENT type 13 (RawKeyPress)
device: 3 (10)
detail: 54

cEVENT type 14 (RawKeyRelease)
device: 3 (10)
detail: 54

EVENT type 13 (RawKeyPress)
device: 3 (10)
detail: 40

The overall idea, though, is that you need to open up an x session, so you can then see what x inputs are matched to which event. Once you have all of this information, you can edit the /etc/X11/xorg.conf file to match. Here is the one I made for the Samsung Captivate Glide:

Section “ServerLayout”
Identifier “Layout0”
Screen “Screen0”
InputDevice “touchscreen” “CorePointer”
InputDevice “keyboard”
InputDevice “mediakeys”
InputDevice “frontkeys”

Section “Monitor”
Identifier “Monitor0”
ModelName “Monitor Model”
DisplaySize 800 480

Section “InputDevice”
Identifier “touchscreen”
Driver “evdrv”
Option “Device” “/dev/input/event3”
Driver “multitouch”

Section “InputDevice”
Identifier “keyboard”
Driver “evdev”
Option “Device” “/dev/input/event0”
Option “CoreKeyboard”
Option “XkbRules” “xorg”
Option “XkbModel” “pc105”
Option “XkbLayout” “us”

Section “InputDevice”
Identifier “keyboard”
Driver “evdev”
Option “Device” “/dev/input/event8”
Option “XkbRules” “xorg”
Option “XkbModel” “pc105”
Option “XkbLayout” “us”

Section “InputDevice”
Identifier “mediakeys”
Driver “evdev”
Option “Device” “/dev/input/event2”

Section “InputDevice”
Identifier “frontkeys”
Driver “evdev”
Option “Device” “/dev/input/event7”

Section “Device”
Identifier “Card0”
Driver “fbdev”
Option “fbdev” “/dev/graphics/fb0”
Option “Rotate” “left”
Option “VertRefresh” “60”

Section “Screen”
Identifier “Screen0”
Device “Card0”
DefaultDepth 16
SubSection “Display”
Depth 16

Notice how you must declare a screen, a monitor, and then the card that controls it. /dev/graphics/fb0 is the framebuffer that you got the other day, if you were following along with these posts. You will also notice, that for each section, a driver is declared. The drivers used here are generic drivers. You may have different hardware, and use different drivers. So, if one doesn’t work, google the xorg.conf section and the word drivers to see some of the different drivers available. You may even need proprietary drivers specific for your device. Like I said though, these generic drivers worked great for me. So I would try those first.

Once you have your drivers and xorg.conf file all set, it is time to take the plung. Be sure to back up your system first. Remember, TWRP or CWM are your freinds, as they work outside of all of the other work you are doing. So you can always start over or go back to something else.

Now, go back to your /etc/rc.local file. It should say:

#!/bin/sh -e
# rc.local
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will “exit 0” on success or any other
# value on error.
# In order to enable or disable this script just change the execution
# bits.
# By default this script does nothing.

# Start the ssh client, in the event you need it.
/etc/init.d/hostname.sh start
/etc/init.d/ssh start

# Clean up bad crash before starting x server.
# /sbin/busybox mkdir -p /tmp/.X11-unix/remove
# /sbin/busybox rmdir /tmp/.X11-unix/remove
# /sbin/busybox rmdir /tmp/.X11-unix/

# Start the x server, warning, if the touchscreen or keypad doesn’t work
# then you cannot escape without killing power!
#/usr/bin/startx &
#export USER=root
#vncserver :5000

exit 0

And change the last part to say this:

# Start the x server, warning, if the touchscreen or keypad doesn’t work
# then you cannot escape without killing power!
/usr/bin/startx &
#export USER=root
#vncserver :5000

exit 0

Now you have told it to startx on the next startup. If all goes well, reboot your phone, and you should see the XFCE desktop. If not, then you need to figure out how to edit the xorg.conf file to make it work right. You may also need to uncomment the lines about rmdir /tmp/.X11-unix, and the other lines like it, if your xserver ever crashes.

I have noticed several variants, especially on Android 4.4 and newer, that it will startx, but also start Android. You will see one normally, and then a small, pink version of the other overlayed on part of the screen. Almost like a picture in picture TV, but very dificult to understand or use. In these cases, you may need to add a command to kill surfaceflinger, or stop zygote to get Android to “clear out”. You actually could just skip Android altogether, but having the chrooted Android is great for playing with making phone calls, etc, as I do not know how to do that from Linux yet.

If you made this work then you do have some pretty good Linux skills, if I may be so bold. This is not an easy task, and not for the faint of heart. So great job! Now it is up to you to improve upon this and make it useful. Who knows, you might be giving Ubuntu Touch a run for the money!

Linux – keep it simple.


AndFTP and JuiceSSH

I would like to start off by stating the obvious. I am not an app expert. I am not an SSH expert. I am a simple guy who just needs simple, functional tools. In this case, both of these tools were well crafted by their designers, and have become indispensable tools to me in my trade.

When it comes to SSH sessions run on the go from my phone, using the onscreen keyboard, JuiceSSH is my go to app. The interface is very slick and user friendly. The font and colors are easy to read, and I love that tapping on the screen brings up the special key bar. This bar has all the regulars, like CTRL, TAB, |, etc., and really comes in handy. The screen rotation works, with scaling, so it will keep everything in view. I like it so much in fact, that it is the only app I use for SSH sessions. Except when I need to download or upload something via SCP.

SCP is of course secure copy, the ability to use the cp (copy) command over SSH to upload or download a file. Obviously, there are better ways to move files, such as SFTP. In some cases, however, it is not feasible because the server in question isn’t set up for that. As long as you can SSH to a Linux server, then you can use SCP to transfer files back and forth.

Thus enter AndFTP. This is the handiest SCP tool I have found for Android! Believe me, I’ve tried several. VX ConnectBot, for instance, does SCP file transfers, but you have to hand type the files FULL path to upload or download. That gets pretty tedious when the path is something like:


So it is much easier to use a tool such as AndFTP. It does all of the typing for you, and presents a graphical browser interface for you to work with. While it still isn’t drag and drop, it sure is handier than typing! The interface has you select files, and then press the upload/download button at the top of the screen. Clicking on a folder opens it, and pressing the “..” buttons at the top of each directory moves you up a level in the folder tree. At the bottom of the screen, you can see it send text commands to the server. Pretty handy for a simple fellow like me.

Linux – Keep it simple.

Real World Example: Setting up a dynamic IP for remote ssh sessions – for free!

Yet another Real World Example (RWE)! I know it has been a while since I have posted one of these, but it is better late than never, right?

The situation: An undisclosed party needed a way to log into their Linux computer from anywhere. Particularly from their home computer, or their cell phone while on the go. This is pretty handy, as an admin can log in, restart/start/stop services, and check on status without driving back to the office. They also didn’t want to spend any money for services, or purchase any new equipment, it just wasn’t in their budget.

The Solution:

The first thing that we had to discuss was what kind of connection they needed. In this case it was an SSH session, which is great as far as bandwidth and setup. However, this scenario would work just as well for Xrdp, vnc, ftp, etc., it just helps that in this case it was a “simple” fix that would be quick to set up.

The second thing that we needed was a way to establish the address of the computer in question. We will refer to the computer that they wish to connect to as the server, and we will refer to the gadget that they are using to connect as their cell phone or home computer. We needed a way to tell the cell phone the ip number of their remote server. Since they do not have a staic WAN IP address assigned to their router, they do not have a hard and fast “set” WAN IP address that does not change, instead they have the dynamically assigned IP address that gets changed potentially every time they connect to the internet, or every DHCP renewal to their router, etc.

The best answer to this problem would be to pay for a static IP address and assosiated Dynamic Name Services (DNS) so that you have a hostname that you type into your home computer or cell phone which always leads to your server. Ths service actually cost money, and hense would be outside of their budget.

So how did we solve this issue? Well, enter No-IP for free ( http://www.noip.com/free ), which is an internet based company that has a few very handy tools to do just that. As we will see from the following, setup was really easy, and FREE. By free, they mean, FREE. Which is pretty nice these days. Now, they do have upgrade options which are not free, but the basic package is completely free.

The first thing that we had to do was register an account for them. Once registered, we added a “hostname” for them. They have many to choose from, such as “myhostname.ddydns.org” and “myhostname.zapto.net”. We will not discuss their actual choice to protect the innocent, but for this example I will continue with myhostname.zapto.net.

Second, we set up the computer with their DUC (dynamic updater client) which we downloaded from their website. It comes as a tar file, which we unzipped, and then we ran make install to put the files where they needed to be. It was really pretty simple and had a few straitforward questions in the config file, as well as instructions on how to start and stop the service, and how often it should update.

This DUC tool is what makes it all work. The DUC tool finds out what your router’s dynamic (changing) WAN IP address is at any given moment, and sends a packet to the No-IP server to tell it your present dynamic IP address. So when you connect to myhostname.zapto.net, it is actually asking No-IP’s server what the current WAN IP address is for your server. Pretty slick trick actually.

Once that was done, we of course needed to do the basics, such as installing the SSH server. In this case we chose to:

$ sudo apt-get install openssh-server

Which istalled OpenSSH Server. Now I don’t want to get too deep into the details of their setup, for security purposes, but I will cover the basics here. I highly recommend that you choose an arbitrary port other than 22 for your SSH connections, to help trick those who do wrong from attempting the connection. It may even be wise to pick a port that is used for something else. For the remainder of this explanation, though, I will explain what we did using the standard SSH port 22.

For security reasons, you should also not allow root logins, but rather use a special user who can then sudo or switch user to root with a password. This double door password feature will likely save your bacon if someone gets in. You should also use an obscure username, not something like admin, ssh, maintenance, or server. Finally, you should have a really complicated password, one that is as complicated as you can remember. In this case, we actually had to change their password to something a little tougher, because theirs was too short and a dictionary word, which is bad. Also be sure to properly set up your firewall, which is something we will not talk about here.

The next step on the bucket list was to configure the router. Which has several smaller steps, but which were easy to manage locally. Their server already had a static IP on the Local Area Network, but if you are setting this up for yourself, say at home, be sure to give your server a local static IP address from your home router. This is usually done based on the server’s mac address. In this case, consider it

After all that, we were down to the final step, which is to configure the router for port forwarding. Most routers have a web gui that is fairly intuitive, and you will need a guide for your router to complete this step. In this case, we assigned anything coming in on port 22 to be forwarded to the local IP address of the server computer, or Note that the :22 means to send it to port 22 of the local computer.

Now the setup was done and it was time to test it. Which I did from my cell phone. Having an Android phone running SlimLP (5.1.1) I used an app called JuiceSSH. It is a really great app that is well constructed, looks snazzy, and works flawlessly. It also allows screen rotation, and even has special keys such as tab and ctrl. So in the app, I chose to set up a new connection to myhostname.zapto.net, port 22, with the appropriate username and credentials. Once I clicked connect, I was greeted by some scrolling information about echanging keys, passwords, etc., and eventually the remote server’s command prompt. Success!

All told, that was a pretty simple fix for a complex problem! Not to mention it was completely free. One down side to the free option, however, is the need to renew your free hostname every 30 days. That’s a pretty easy trade off for the free service though. Also, the free package only includes 3 dynamic addresses. So if you want to do this for a large business, you are better off with a paid package.

Linux – Keep it simple.