Raspbian is based on Debian. Upgrading it to the latest version is done the same way as upgrading a normal Debian distribution. To not make this my shortest blog ever, I’ll show how I upgrade one of my Raspberry Pi.
The upgrade to release N is performed by starting the process release N-1. For each upgrade:
Update current release
Prepare configuration for next release
Validate result of upgrade
Update your current Raspbian
sudo apt-get update
sudo apt full-upgrade
Prepare configuration for next Raspbian version
Edit repository files and change the distribution name to stretch or buster, depending from where you are upgrading from. A list of releases for Raspbian can be found at the Wikipedia page.
sudo vim /etc/apt/sources.list
To update to stretch:
deb http://archive.raspbian.org/raspbian stretch main contrib non-free rpi
To update to buster:
deb http://archive.raspbian.org/raspbian buster main contrib non-free rpi
You may have more repository servers configured. For instance, check the content of the file: /etc/apt/sources.list.d/raspi.list.
Make sure to enable IPv6 support.
sudo apt update
sudo apt dist-upgrade
Sample output for update to stretch
Sample output for update to buster
sudo apt autoremove
Validate result of upgrade
After running the above commands again, they should not report any more updates or dependencies.
sudo apt dist-upgrade
Check Debian version
The entries for version and codename should now match your targeted release. For buster, it is:
After setting up a DHCP server on a Raspberry Pi running Linux I get working leases for my clients. However, these are not static. It can happen that my smartphone gets a new IP address the next it connects: 192.168.0.161 instead of 192.168.0.160. For some clients I want to make sure they always use the same IP. This can achieved with ISC DHCP Server by registering a static lease for a specific MAC.
I’ll use my soundbar for the rest of this blog as an example. The MAC of the network card is bc:30:d9:2a:c9:50. I want to always assign the IP 192.168.0.152 to the soundbar.
Find out client data
To find out the client data like MAC and current lease, check the DHCP server log. Or take a look at the back of the device or its settings to find out the MAC. For the DHCP server log on assigned leases:
sudo systemctl status isc-dhcp-server.service
The last line shows that the DHCP server assigned an IP to a client and shows also the MAC address.
DHCPACK on 192.168.0.152 to bc:30:d9:2a:c9:50
Let’s make sure the MAC bc:30:d9:2a:c9:50 always gets the IP 192.168.0.152.
sudo vim /etc/dhcp/dhcpd.conf
This is the DHCP server configuration file. I already configured it for a subnet 192.168.0.x where the server is assigning leases for the IP addresses in the range of 192.168.0.150 to 192.168.0.240.
Inside the subnet configuration, I have to add a configuration for the soundbar for IP 192.168.0.152.
To activate the new configuration, make either DHCPD load the new configuration from file, or restart the service.
sudo systemctl restart isc-dhcp-server.service
Check the status of the service.
sudo systemctl status isc-dhcp-server.service
The assigned leases can be found in the dhcpd.leases file. All leases assigned are listed here, including the mac address, IP address, start and end time of the lease. If all works out as planned, the soundbar will be in there with the static IP.
My internet provider is Unitymedia. Their default router comes with a DHCP server. Honestly, it’s one of the worst products I ever had to work with. My private network is 192.168.0.x. The DHCP server of the Unitymedia box is distributing from time to time leases for 192.168.192.x. Changing my private network to 192.168.192.x one is not working, as then the DHCP server picks another address range. Advise from Unitymedia help desk was to reboot the box, which, of course, won’t solve the problem. Because of this error, some of my devices are in a different network: Chromecast won’t work, broken internet connection on smartphones, etc.
I do have a Raspberry Pi (RP) in 24/7 use. My idea is to run my own DHCP server on the RP. This not only solves the DHCP problem, but also gives me more control over the DHCP configuration.
This installs ISC DHCP server. As you can see in the output, starting the DHCP server failed.
sudo systemctl status isc-dhcp-server.service
The error is simply caused because the DHCP server is not configured. Let’s change that.
Several parameters must be activated and configured.
sudo vim /etc/dhcp/dhcpd.conf
Activate DHCP server
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
This configures what IP address are going to be distributed. My private network is 192.168.0.x with the router on 192.168.0.1. As DNS you can use whatever you want, as an example I am using Google DNS servers.
This will give DHCP clients an IP address between .150 and .240, with router .1, Google DNS and sets the domain name to my own.
Deactivate old DHCP server
To not have the DHCP server provided by Unitymedia box still issuing wrong IP address, I am going to deactivate the service via the web interface.
Start DHCP server
After installing and configuring the new DHCP server on RP and deactivating the one from the router box, it’s time to start the new DHCP server.
To see if a IP address is assigned, use this command:
sudo systemctl status isc-dhcp-server.service
Putting my Android device into flight mode and back makes it connect to Wifi again and obtain a new IP address via DHCP. In the DHCP status log, I can see the DHCPDISCOVER from the Android device and that it got the IP address 192.168.0.150 assigned.
As my Mac always got the wrong IP assigned, I changed it to manual configuration. Change the mode to DHCP, apply and deactivate / activating Wifi.
And my soundbar that got a strange IP address assigned by the Unitymedia router box? Works too!
Chromcast streaming shows the SoundBar is now in the same network.
Recently I had the problem that running apt-get update stalled while trying to connect to an IPv6 address. For instance, on a Raspberry Pi, the update process stalls while trying to connect to archive.raspberrypi.org. All other connections worked fine. Looking at the console output, a difference was that apt was trying to connect to an IPv6 address.
The problem was caused by:
100% [Connecting to archive.raspberrypi.org (2a00:1098:0:80:1000:13:0:8)]
A quick internet search showed that you can force apt to not use IPv6 and only IPv4. As the download worked for IPv4, this seems like a reasonable workaround.
You can pass a parameter to disable IPv4 to apt-get, or write it to apt config file to make it persistent.
Create a new configuration file. This makes it easy for you to keep the change during updates and to know that you configured this.
sudo vim /etc/apt/apt.conf.d/99disable-ipv6
Insert Acquire::ForceIPv4 "true";
To disable IPv6 just once while calling apt, the parameter is Acquire::ForceIPv4=true.
sudo apt-get -o Acquire::ForceIPv4=true update
Loading the package data from archive raspberrypi.org is now ignored and apt-get update works again.
OpenVPN uses certificates to authenticate the server and clients. Therefore, the client needs to have a valid client certificate. This certificate needs to be issued by the CA server that also issued the certificate of the OpenVPN server. In my case, this server is installed together with the OpenVPN server on the AWS EC2 instance. The process to create the client certificate is the same as with the server certificate, only the certificate type must be client, or: TLS Web Client Authentication. This is done by specifying the client parameter in the generate certificate request command.
Depending whether or not easy-rsa or any other tool to generate a certificate request is available on the client, the request can be generated directly on the client. The vantage by creating the request on the client is that the private key will stay on the client. In my example, I’ll make use of the already available infrastructure on the OpenVPN server and generate the client request and certificate on the server and copy later the generated artifacts over to the client.
Create client certificate
Log in to the CA (OpenVPN) server and issue a client certificate request. The name of the client will be client1. Note that you can use a different name, like the FQDN of the client.
sudo ./easyrsa gen-req client1
As with the server certificate, give a passphrase and common name.
Next: sign the client1 certificate by the CA.
sudo ./easyrsa sign-req client client1
You need to confirm the signing request by entering yes and informing the pass phrase of the CA certificate.
The client certificate is now issued.
Private key: easy-rsa/pki/private/client1.key
Public certificate: easy-rsa/pki/issued/client1.crt
Move these files to the OpenVPN client.
OpenVPN client Installation
The client going to connect to the OpenVPN server running on AWS EC2 is a Raspberry Pi. The RP uses a Debian based Linux, therefore apt is used to install software. On the RP, install OpenVPN. Easy-rsa is not needed, as the CA is running on the EC2 instance.
sudo apt-get update
sudo apt-get install openvpn
Create a openvpn directory. Can be in /etc/ or in your user’s home. Put the client’s public certificate and privte key there. To use HMCA for additional security, copy the ta.key file from the server there too.
Copy the OpenVPN sample client configuration to your openvpn directory and edit the file client.conf.
cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf .
Adjust the following lines to point to the correct server (AWS EC2) and local certificates and key. Example:
remote server.domain.com 1194
tls-auth /home/tobias/openvpn/ta.key 1
The tls-auth parameter is needed in case the server is configured to use HCMA. The shared key ta.key from the server is needed for this to work.
Start OpenVPN client
To start the OpenVPN as client, run the executable and pass the path to the configuration file as parameter.
You need to provide the pass phrase of the client1 private key.
The client will automatically connect to the OpenVPN server defined in the client.conf file (remote parameter) and the given port (1194). Make sure that on AWS EC2, this port is accessible for the client.
If all works, the client connects to the server and gets an internal IP assigned.
Recently I got some new hardware that I will use to run some useful software. To use the software from anywhere, I’ll need to have remote access. As I cannot do DMZ or port forwarding with my new internet provider, I decided to connect my home server using VPN to a access machine running on AWS.
The AWS EC2 Linux computer will serve as my entry point. Services running on the RP at home connected via VPN can be accessed from EC2. Other computers at my home cannot be accessed, as the IP is different and no route is configured.
This setup comes with several architectural questions to solve:
How to ensure the communication is secure?
How to guarantee the tunnel is up?
How to enable access from EC2 to the services running on the client?
The client must be assigned the same IP for the services be accessible from EC2
How to give access to the services from the internet?
The three top question will be answered in my next blogs about how to set up OpenVPN server and client. The first question is the easiest to answer: by using a VPN solution. I am going to use OpenVPN and this blog is about how to setup OpenVPN. I’ll cover the installation on the EC2 instance and on the Raspberry Pi, as well as the initial setup with the certificates, server and client configuration and how to connect. Starting the client and server as service keeps them running and in case the connection fails, an automatic reconnect is attempted. The EC2 instance can access the services running on the client automatically. The last two questions will be answered sometimes later.
Install OpenVPN on EC2
The OpenVPN software is available in yum on EC2 Linux AMI. You may need to enable the REPL repository. I assume you did this already. The packages to install a openvpn and easy-rsa.
sudo yum update
sudo yum install openvpn easy-rsa
This will also install a public key to install a package and ask for your permission to do so.
The easy-rsa package is needed to set up a certificate authority. In case you do have a CA available, you can use your CA to generate the certificates used by OpenVPN. For those that do not have a CA available, take the easy-rsa functionality.
The command above installs easy-rsa 3.x. With 3.x, the way how to use easy-rsa and to set up a CA and issue the certificates changed. You can see in detail how to use easy-rsa 3.x at the documentation available at the GitHub project site.
OpenVPN uses certificates, and easy-rsa issues those certificates. Basically, you have two components of easy-rsa to deal with:
Configuration of OpenVPN is put and read from /etc/openvpn. Easy-rsa software should be in a separate folder, like /home/ec2-user/easy-rsa, but to keep all in one place I’ll put easy-rsa inside the /etc/openvpn directory.
Note: for real productive usage, don’t do this. Separate easy-rsa executables and config files.
Copy easy-rsa to your selection location. For this, first find out where easy-rsa is installed.
repoquery -l easy-rsa
Location is /usr/share/easy-rsa/3.0.3. I’ll copy these files to /etc/openvpn/easy-rsa.
Follow the steps outlined at the easy-rsa git site. For the following steps, go into the directory where easy-rsa is installed.
sudo ./easyrsa init-pki
This will create the CA certificate to sign certificate requests. In other words: whoever gets access to the private key of the CA created in this step, can create new valid OpenVPN clients for your setup. Take care of the CA certificate and key.
sudo ./easyrsa build-ca
You’ll need to enter:
PEM pass phrase
The passphrase is used to unlock the private key and is an additional level of security. Even when someone gets a copy of the private key of your CA, without the pass phrase the key is not usable. The common name is used to identify the CA. I used the FQDN of my web server. After execution these two commands, the CA is initialized and can be used to issue certificates.
Generate Diffie-Hellman parameters.
sudo ./easyrsa gen-dh
Generate OpenVPN server certificate
The OpenVPN server needs a certificate issued by the CA to identify itself against the clients. This is a nice “feature” when using PKI. Server and client can validate the other side. Both need just to trust the CA certificate for this. The difference between the two certificates (client and server) is the included type. This is done by including an additional value in the certificate specifying the type of certificate:
TLS Web Server Authentication for the server and
TLS Web Client Authentication for the client
Which kind of certificate is going to be issued is specified by the easy-rsa command when creating the certificate request.
Generate certificate request
Create a certificate request containing the identity information of the server and let this request be signed by the CA. By specifying the server parameter, the request is for a server and the CA will include the value TLS Web Server Authentication in the extension.
sudo ./easyrsa gen-req server
As with the CA certificate, inform a pass phrase that adds additional security to the private key and a common name to uniquely identify the server. I used server as CN. Of course, it could also have been openvpn.mydomain.com or something else.
Send the request to the CA and sign it to issue a valid certificate. With that, the CA information is added to the CA, making it official and clients that connect to OpenVPN server will know if they can trust the server. Only when trust is verified, a connection will be established between the server and client.
sudo ./easyrsa sign-req server server
You’ll need to confirm the request by typing yes and the pass phrase.
The following certificate is needed to harden the overall security of OpenVPN. As OpenVPN is using TLS, it makes sense to add HMAC to validate integrity of the packages received. For this to work, a shared secret key is needed. This key will be written to a file named ta.key.
Take a sample configuration file as a template. Can be found in the doc folder of openvpn. The sample configuration file for the server is server.conf, and for the client, client.conf.
ls -1 /usr/share/doc/openvpn-2.4.4/sample/sample-config-files/
Copy server.conf to /etc/openvpn and edit the file.
sudo cp /usr/share/doc/openvpn-2.4.4/sample/sample-config-files/server.conf /etc/openvpn/
sudo vim /etc/openvpn/server.conf
Adjust the path to the ca, cert, key and dh files
These parameters inform OpenVPN where the certificates and Keys are stored. The CA cert ca.crt is used to validate the client certificates. They must be issued by this CA. The server.crt and server.key are used by the OpenVPN server to encrypt traffic and authenticate itselfs against clients. Diffie hellman dh.pem is used to provide Perfect Forward Secrecy.
Start OpenVPN server
To start the OpenVPN server and to test the current setup, run the following command:
sudo openvpn /etc/openvpn/server.conf
During startup, you need to provide the passphrase of the server certificate.
If all works, OpenVPN starts without erros: Initialization Sequence Completed. After this, the server is waiting for clients to connect.
If someone is reading my blogs for the last years you may remember that I have once written about setting up OpenVPN for accessing SUP on AWS. That blog was all about Windows and is outdated. I wrote it in 2012. But, as I published it once at SAP Community Network, it is not available anymore. SAP lost it during their last migration.
In the technical architecture of my blog site, the WordPress site with my blogs is hosted on a Raspberry Pi in my living room, while external access is through a reverse proxy hosted on Amazon EC2. If now the reverse proxy on EC2 cannot reach my Raspberry Pi, a 503 error message is given.
The root cause can be that the Raspberry Pi is turned off, there is no Internet connection available for some reason (power outage, provider problem), or something else. In case this happens, EC2 reverse proxy will throw an error and try to show the Apache standard 503 error page. The web page used to display the 503 is the same for all Apache installations worldwide. Giving your users a more personalized message can be a nice touch. For instance, including a statement that you are aware of the issue, it won`t take long to get solved, or a better explanation of what happened.
For this to work, you need to have
A custom 503.html file and
Configure Apache to use this web page.
Create custom 503 file
This is up to you. Internet and Google are your friend.
Apache has the ErrorDocument directive. For an HTTP error code you specify a HTML file to be shown. Make the 503 HTML file created by you in the above section available on the web server.
Important: the document root of Apache is /var/www/html. For accessing the file, the browser will call the URL /error/503.html. Reference it in the Apache configuration.
sudo vim /etc/httpd/conf/httpd.conf
ErrorDocument 503 /error/503.html
You are done in the case of a normal web server setup. The configuration shown so fare won`t work for a reverse proxy. A reverse proxy will forward all requests to the backend server, including the request for the 503 document. To not forward /error/503.html to the backend, put /error/ in a exception list. With this, every request to /error/ won`t be forwarded by Apache, and instead be served from the local web server. To exclude /error/ from the ProxyPass rule, add:
ProxyPass /error/ !
This exclusion must be before the other ProxyPass directives. A somewhat more complete example of a Apache configuration:
2016 is history. As I have done in last year, I will use the start of a new year to look back at my private blog to see if my experiment is still on track. 2016 was the first year my blog was up and running for a full year. It feels to me like the site is running for longer than 21+ months, but the two year live mark is yet to be reached.
No hardware changes occurred in 2016, the site is still running on the same Raspberry Pi 2 I migrated to in 2015. To ensure a better uptime, an APC UPS is powering the device, as well as other devices like my LibreElec powered HTPC and my RAID 5. What changed is the overall architecture. I started 2016 with a RP2 in my home, giving direct access to the web server on port 443. In march, my provider decided to block port 443 due to abnormal activities. To still be able to provide access to my site via a normal HTTP port, I decided to use a small Linux machine on AWS that will act as my public reverse proxy. Therefore, now my site is publicly available via AWS, while the content is still hosted on my local RP2. Costs for this setup? Around 6$ per month for Amazon.
The TLS certificate was originally provided by StartSSL, but after they proved to not understand how trust works    , I switched over to letsencrypt. I consider this a change for the good: great community, easy installation process, open, high level of security for the certificate and I must change the certificate every three months.
I adjusted my TLS configuration to make the site more secure, even when I do not have actual content there that demands TLS: it`s just a blog site. No confidential data available, no log on for users, no transactions, etc. But in 2016 having a good TLS configuration is not negotiable. It’s easy to do, costs nothing, and browser vendors are going to enforce TLS more and more. So: there are no excuses for not having my site on TLS. SSL Labs gives my site an A rating:
With 2016 ending, I now have 208 blogs published. 8 are still in draft mode.
In 2016, I wrote and published a total of 70 blogs. I republished some old blogs I once wrote for SCN with a reference link to the original post of my at SCN. These are not part of the 70 blogs written in 2016. 70 also means 6 blogs per month. Why did I publish the old blogs again on my site? I did this mainly to regain control over my content and not to be troubled the next time the original blog content is affected by an upgrade at a site I do have no control over. I still have content at SCN that was broken in the migration in 2012 and that content is lost. I still have some blogs to convert and bring over to my site, but don`t expect too much. Most of the old content exists only at SCN and without the correct formatting, consider this content gone. At least it’s for old technology stuff, no one should be affected.
To monitor the usage of my blogs I use Piwik. Version 3.0 was released at the end of 2016, but I had not the time to update my 2.x installation. The update will be done in the first weeks of 2017. As I do not request users to log on to my site to be able to view content, the data Piwik gathers in regards to users are higher than the actual user count. If the same user access a blog via smartphone, private laptop and work computer, it will count as three unique users. I still think it gives a good overview of the usage number, as in most cases you use one device to surf the web. As most content in focused on SAP technical stuff, my main user group for sure is using the same computer (their work environment) to access my content. Piwik also does magic and can track the same user over several IPs, so when the IP of a user changes (using same browser), this user counts as one unique user.
My blogs were visited by 11.441 unique visitors, in total I had 14977 visitors. This implies that most visitors come to my site once to find a solution to a SAP problem and then never come back. I guess this means their problem was solved The visitors generated 22603 page views. For a site that has only 208 blogs, and a very limited navigation, 22k page views is not bad.
The usage numbers get impressive when I compare them to 2015.
Short: all KPIs go up. I basically doubled the unique visitors and page views, and the number of visitors exploded. I do not think that I can perform better in 2017.
An interesting chart is the page views over the last 6 months. SCN 3.0 was launched around October 2016. Guess when October starts in the below chart.
While I had a significant number of users coming from SCN in 2015, this got less and less in 2016. Once given because I almost stopped blogging on SCN. But after October the referrers from SCN stopped almost completely. Now users are coming mostly from Google, or from LinkedIn when I share a blog post there. What the chart shows is that the number of page visits almost doubled “thanks” to SCN 3.0.
The reported countries chart matches last year data and gives a good overview where SAP is used.
Africa is close to non-existent. Same for Latin America. Argentina generated 100 page visits, Chile 73, Bolivia 7, and so on. Sum the numbers up and it’s still not half the visits I got from Brazil. From that point it makes sense to focus on Brazil for SAP related topics.
From the browser side, Chrome and Firefox lead, mobile users do exist. Not a big surprise, most content is related to work, and most people still work from a laptop / computer and not from a mobile device. This is reflected in the top 3 operating systems. Windows dominates the corporate world.
Last thing to show is traffic. How much traffic is transmitted? Reminder: RP2 is in my living room, my provider is unfortunately NET, so I only get low bandwidth and an 80GB traffic limit (yes, I already tried Vivo, etc., but they do not offer cable internet at my home). To get the data out of the logs, nothing easier than Kibana.
Total GB sent in 2016: almost 20 GB.
Images contributed with 13 GB to this. The rest is then text, JS, CSS, etc.
A total of 1.2 million requests.
This ends my look back at 2016. From now on my focus is on 2017. Lets hope that 2017 is even better from the usage point of view than 2016. Some points outlined above are on my to-do list for the next weeks. For sure I must keep blogging to attract enough readers.
After installing GateOne on my Raspberry Pi 2 Debian system, I can log on to SSH via HTTP and browser. But only from my internal network, as the external accessible port is blocked by Apache. To add GateOne from outside, I either can disable Apache (no, won`t do it) or make GateOne accessible through Apache. I`ll use Apache as a reverse proxy for this.
Note: you`ll need Apache 2.4 for this, as GateOne uses Websocket for communication, and this is included only ootb with Apache 2.4.
I won`t use a subdomain for this example, so no new Apache virtual host will be use. This means that I have to use a URL prefix to access GateOne. The prefix is: /ssh. This must be configured in the GateOne configuration file:
sudo vim /opt/gateone/server.conf
Change the parameter url_prefix and restart GateOne
url_prefix = "/ssh"
To be able to access GateOne from external, the URL of the external server must be added to origin. In my case, this means that www.itsfullofstars.de is added.