Home Photo Server, Part 3: https, keys, and certificates

In the continuing saga of the Google Photos alternative, by running a home server with Dynamic Domain Name Service (DDNS), very secure FTP (vsftp), and an Apache web server coupled with Piwigo, we’ve automated the entire process of getting the photographs I take with my phone all put on the server and view-able by those we share it with. And, to God be the glory, it even works! But there are still a few more steps to consider, and today I’d like to look at a more secure interface with https.

So, for https, one of the big things you need to have secure http (the language of the web), is a public/private key pair, for assymetric encryption, and a digital certificate, certifying that those keys are in fact yours. There are a couple of ways to do this on the cheap. Of course, you could pay for a domain name and certificate from a company (like VeriSign and others). Or, you can go with a free certificate from Let’s Encrypt. The only problem that I had with them is that they didn’t seem to support DDNS. Perhaps further research is required. But, if you are using a static IP address, with a domain name, then you certainly can do these options.

Another option, no matter what the use, is self generating your certificate. Now, we do have to clarify, most browsers will warn the user that something is wrong when they go to your web page because the certificate is not signed by a “trusted” source. However, since, in my case, my wife and I are the only ones who log in, I think we can trust our own certificate. The benefit to having your own certificate verses not having one is that now we can use https. If we add the certificate as trusted to the browser, then we will be able to know that we are still talking to our own server, as long as the certificate doesn’t change.

First thing we need is mod_ssl:

# yum install mod_ssl

Once that installs, we need to make a directory for our keys and set the permissions:

# mkdir /etc/ssl/private
# chmod 700 /etc/ssl/private

And of course, generate the keys themselves, as well as set Diffie-Hellman parameters on them for more security:

# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/apache-selfsigned.key -out /etc/ssl/certs/apache-selfsigned.crt
# openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
# cat /etc/ssl/certs/dhparam.pem | tee -a /etc/ssl/certs/apache-selfsigned.crt

Then, we need to tell Apache, our web server, to use our certificates:

# nano /etc/httpd/conf.d/ssl.conf

Edit as appropriate to point to your new keys and certificate. You can also make a forced redirect to have all http traffic be redirected to https:

# nano /etc/httpd/conf.d/non-ssl.conf

In the file, write this, but replace with your server name:

<VirtualHost *:80>
ServerName yourServerName
Redirect “/” “https://yourServerName&#8221;

Now you need to punch a few holes in the firewall for https traffic….

# firewall-cmd –add-service=https
# firewall-cmd –runtime-to-permanent

And restart everything:

# systemctl restart httpd.service

# firewall-cmd –reload

Now you should be able to check out your website via https! Here you can see the warning message I get for my self generated certificate.


Linux – keep it simple.

Home photo server, part 2: Apache, phpAlbum, and Piwigo

Last time we talked about how to set up the domain name with DDNS for free, and then using very secure FTP, vsftp, and SyncTool (the Android app) to automatically move photos from your phone to your home server. But that’s only half of the battle. One of the big perks to using Google Photos is that you can browse them anytime from anywhere. You can share them with friends, make comments on them, and other socially related things. We need a way to do that from our home server, too.

There are many, many methods to accomplish this, and I tried several, but I’d like to point out two options that worked really well, were simple to use and set up, and used little to no JavaScript. There are several reasons why one might not want to use JS, like security, etc., but I’ll save that for another post. The two best options were phpAlbum, which is 100% JS free, and Piwigo, which only uses JS for some display themes, I chose one without it and it seems to work just fine.

Either way, I needed a web server, so I installed Apache.

# yum install httpd

# systemctl enable httpd

#firewall-cmd –add-port=80/tcp

# firewall-cmd –add-port=80/tcp –permanent

Right out of the box, you could browse to my web server. Of course, it was insecure and it only displayed the main page. I’ll break down adding certs and making it TLS and SSL compliant in another post. I was ready to set up my router, make sure you route that traffic to your server! Since that is rather router specific, you’ll have to look that up on your own, but there are tons of guides on it. Now it was time to install a photo gallery web server.

So, first on the list, I tried phpAlbum. It worked great and seems to be a good fit, provided that you have a smaller photo collection. One big plus is that it doesn’t need a MySQL database or anything. The only downside: once I surpassed 8000 photos, and numerous folders, it seemed to not be able to keep up. So, for a short time I got around this by setting up multiple web pages, each running a unique instance of phpAlbum, each with it’s own set of photos. This was simple, really, I made one for a couple of years worth, and one for the next 3 or 4 years, and then had a main web page that linked to the different ones. This is a bit tedious and cumbersome though, but wasn’t too bad if you have a lot of static images.

Since it is so simple, and has a good installation guide, which you can read here, I’ll be very brief about how I set this up. You can also click here for a phpAlbum demo.

# yum install php php-xml php-mbstring php-gd

# yum install ImageMagick

# yum install unzip zip

After downloading the latest phpAlbum zip from their website, unzip it and edit config_change_it.php to your needs with nano or vi, basically by setting the data directory and the photo directory, and rename it config.php. Now copy the entire directory to /var/www/html. So in my setup, it was /var/www/html/phpAlbum/ with all of the files in it.

Next, chmod 777 the cache, data, and photo directory inside your folder, so you can write to it with other users (the uploading functions). Then:

# chown -R apache:apache /var/www/html/phpAlbum

so your web server can own it (since I’m using Apache as the web server). Now all you have to do is navigate to http://yourDomainNameIPaddress/phpAlbum and you will be greeted by a login, to which the default is admin and admin for the username and password. Once your in, it will ask you a few questions, and you can be up and running in a few minutes! It worked really great, like I mentioned earlier, when I had a smaller photo collection (under 8000 for me, but your mileage may vary).

Since it was struggling with more photos, I decided to switch to Piwigo. You can check out a demo of it here. There is a really, really great guide on TecMint, that I drew from when putting this together, but it was relatively simple. Start by installing the dependencies – note that a lot of these were already installed for phpAlbum, and I’m not 100% sure you need all of these, but this is what I installed:

# yum install php php-xml php-mbstring php-gd wget unzip zip ImageMagick python python-tk python-psyco mariadb-server php-mysqlnd

Now you need to enable and set up your MySQL/mariaDB:

# systemctl enable mariadb

# mysql -u root -p
MariaDB [(none)]> create database piwigo;
MariaDB [(none)]>grant all privileges on piwigo.* to ‘piwigouser’@’localhost’ identified by ‘pass123’;
MariaDB [(none)]>flush privileges;
MariaDB [(none)]>exit

# systemctl restart httpd

Be sure to use your own usernames and passwords. I don’t recommend the defaults! Then you need to download Piwigo and unzip it, placing it in your Apache web server root directory. After you put it in place, you need to set the proper read and write permissions, as well as ownership:

# wget http://piwigo.org/download/dlcounter.php?code=latest -O piwigo.zip
# unzip piwigo.zip
# cp -rf piwigo/* /var/www/html/
# chown -R apache:apache /var/www/html/
# chmod -R 755 /var/www/html/
# chmod -R 777 /var/www/html/_data/

# systemctl restart httpd
# systemctl restart mariadb

Now it’s up to you how you want to handle moving the pictures we automatically uploaded to the server into the Piwigo directory. For instance, you can have your photos upload from your phone to your home directory, and then make a cron job or script, or manually put them into your Piwigo directory. One benefit of this is deleting blurry or useless photos. I like this option best, but that’s my opinion.

Another option is to set the /var/www/html/galleries photo permissions to be writable/readable by others, or add your user to the group and upload your photos directly to it. I tried this as well, and it works good, too. Either way, now all you have to do is use your web browser to navigate to your server, and you should see the Piwigo first login/setup screen.

Choose your options, such as language, etc., tell Piwigo what the MySQL/MariaDB is called and what that password is, and you should be up and running in no time! Now you can log into the web interface as the admin user (that you just set) and start choosing themes, uploading photos with the web app, or syncing the galleries folder for the photos you put there via FTP or moved manually or scripted.


In this screenshot, you can see the light theme that I went with, and how there are some photos available for the public to see. If I log in, then I can see the rest of the pictures:


You can have more users and give each user access to certain files, folders, or groups. Groups is nice because you can give “family” the option to see this, and “friends” the option to see that. You can control everything from the web admin screen:


Another plus to Piwigo is that there are several Android apps out there, some paid, some free, some open source. So there are options, but quite honestly the web browser of Android works great, since Piwigo has two theme settings, one for desktop browsing, and one for mobile browsing as well. So you can have two different themes, one for each desktop and mobile, to maximize what works best for you.

There’s still a few things to cover though. Right now, it is only using port 80 for unsecure web traffic. We definitely want to use secure http on port 443, so we will cover certificates and security next.

Linux – keep it simple.

Wondershaper: The wonder of shaping your internet traffic!


I always end my posts with “Linux – keep it simple.” And today is one of those great days when I am using a really well made, simple, Linux tool: Wondershaper.

Wondershaper allows you to “throttle” network traffic on any interface to a desired capped speed. So, for instance, if you need to have one computer upload videos, like I am today, you will probably max out your upload speeds. The problem with this is that your wife/family/friends/office workers, etc., whomever you share internet with, will suddenly be unable to surf the web.

Or perhaps you are syncing the Android source code, and it is taking up all of your download bandwidth, making it impossible for you to watch a movie on your Vudu/Roku/name your device player.

So, if you want to have a simple to use command line tool to restrict or limit traffic on one of your Linux computers, here it is:

# wondershaper eno1 1000 500

That’s it. The name of the program is wodershaper and the arguments are: interface, download speed, and upload speed. In this case, I want wondershaper to try to throttle traffic for that machine on interface “eno1” to be 1000 kb/s down, and 500 kb/s up. Here is the expanation from the man pages for it:

wondershaper [ interface ] [ downlink ] [ uplink ]
Configures the wondershaper on the specified interface, given
the specified downlink speed in kilobits per second, and the
specified uplink speed in kilobits per second.

You do need to run this as root to have access to control the device interfaces, but this program works beautifully. It is especially handy when working with virtual machines that you wish to limit!

Linux – keep it simple.

Minimodem: Sending digital information via analog sound!

In my free time I have been involved in a little side project involving sound, data, and communications. The end goal is to transmit data wirelessly via a cellular phone by using audio during a phone call. I know, quite a mouthful and a pretty interesting project. My “theory to practice” project is just in the beginning stages, but I have had some fun so far and thought I would share. Ultimately, I know that the theory of it is sound, but in practice will never be practical. There is a reason that most of us have moved away from dial up modems!

So I needed a tool to convert an input to an audio sound, and a quick search online led me to minimodem. This program is really cool! It allows the user to input something, which is converted to a sound, output through the speakers, and can be input via microphone on another computer and converted back into data. I downloaded from the repository, it is readily available in Debian.

# aptitude install minimodem -y

You also may need to start pulseaudio if it is not already started. Do this as a normal user.

$ pulseaudio –start

Once it was installed, I then got to work using it at the transmitting computer:

$ minimodem -t 300

After you press enter, you now are going to transmit anything you type at a baud rate of 300. Whatever you type will be translated into an audible tone that sounds like the old dial up modems. On the receiving computer, you type:

$ minimodem -r 300

Note that the number is the baud rate. Technically, you could set the baud rate to just about anything, however, it recommends under 1200 at the developer website due to noise interference. So now, as I type things like “hello” and press enter, that is then displayed on the receiving computer. At least, it was supposed to. I realized that I needed to adjust the microphone and speaker settings. This actually took a while. Too much gain, and the signal would break up with errors in it. Too little gain, and you wouldn’t receive anything. Audible transmissions were doing pretty well, but not at a faster baud rate than 250.

The audible tone is also really annoying to listen to for any length of time. So I scrounged around and found an audio cable, and plugged one computers headphone jack into the other computers microphone jack. This not only allowed me to work in silence, but it also reduced background noise, static, and increased the speed. I could now receive and transmit at a baud rate of 1200 which really sped things up!

Now that the connection was working fairly solid, I could then play with delivery. Rather than hand typing messages, I used a pipe to direct input into minimodem:

$ man minimodem |minimodem -t 1200

Which gave me an output of:

$ minimodem -r 1200
### CARRIER 1200 @ 1200.0 Hz ###
.*….5(1) MINIMODEM(1)

minimodem – software audio Bell-type or RTTY FSK modem

minimodem –tx [options] {baudmode}
minimodem –rx [options] {baudmode}
……….. (abreviated) ……………….

Great! Now I felt like I was really getting somewhere! As you can see from the picture, I had some fun with another program called jp2a, which converts pictures into ascii text. This allowed me to send myself pictures over my new found communication medium. As you can see, I utilized xterm with a black background to really help the pictures stand out.

Sender: $ jp2a debian_vs_ubuntu.png |minimodem -t 250
Receiver: $ xterm -fg red -bg black
Receiver: $ minimodem -r 250

In case you are wondering, I did try the –color option to jp2a, but the characters do not come out at all that way over minimodem.

As far as I can tell, minimodem doesn’t take anything other than text and converts it into a signal and back again. So I now needed a way to convert things into text so I could pass them over minimodem. I thought an easy one might be xxd, which converts files into hex. I decided to try it out locally before transmitting.

$ xxd flags.gif
0000000: 4749 4638 3961 db00 2b02 b300 00ff ffff GIF89a..+…….
0000010: 0033 ffcc 0066 ffff 00ff 0066 ffcc 0000 .3…f…..f….
0000020: 66ff 0000 ffff cc33 ffff 3300 33cc 0066 f……3..3.3..f
0000030: ccff 0000 ff00 33cc 0033 0000 0021 fe15 ……3..3…!..
0000040: 4749 4620 536d 6172 7453 6176 6572 2056 GIF SmartSaver V
0000050: 6572 312e 3100 2c00 0000 00db 002b 0200 er1.1.,……+..
0000060: 04fe f0c9 496b 0835 57c0 bbff 6028 8e64 ….Ik.5W…`(.d
0000070: 596a 68aa 3e66 ebbe b0c7 b681 51df caad Yjh.>f……Q…
……….. (abreviated) ……………….

$ xxd flags.gif | xxd -r > stillflags.gif

That was a success. It essentially made a copy of the file. So I decided to try it with minimodem:

Sender: $ xxd flags.gif |minimodem -t 1200
Receiver: $ minimodem -r 1200 | xxd -r > flags.gif

Unfortunately it didn’t work. After transmitting and receiving, the file was not readable. So I made several attempts with text files and found a few slight problems. First, if there is any noise, then errors appear in the text. Second, when sending information, minimodem appears to append some sort of character set at the beginning of the transmission. Something that tells the receiver to “pick up”. Somewhat like a calling card or signature, minimodem marks the transmission. So, I will have to play with it to see if I can choose a setting that allows me not to have that, or to have a delay afterword, which could also be programmed on the other end.

Either way, it has been really fun trying this out so far. I look forward to playing with it some more.

Linux – keep it simple.