From db418355792364a85659bae816eebe0de42d819c Mon Sep 17 00:00:00 2001 From: Rob Date: Sun, 17 Mar 2019 02:09:19 +0800 Subject: [PATCH] mirror cantonese + two more articles --- docs/backups.html | 90 +++++++++++++++++++++++++++++++++++++++++++++++++++++ docs/backups.txt | 76 ++++++++++++++++++++++++++++++++++++++++++++ docs/tunneling.html | 5 +-- docs/tunneling.txt | 5 +-- docs/wireguard.html | 69 ++++++++++++++++++++++++++++++++++++++++ docs/wireguard.txt | 59 +++++++++++++++++++++++++++++++++++ index.html | 17 +++++++--- 7 files changed, 312 insertions(+), 9 deletions(-) create mode 100644 docs/backups.html create mode 100644 docs/backups.txt create mode 100644 docs/wireguard.html create mode 100644 docs/wireguard.txt diff --git a/docs/backups.html b/docs/backups.html new file mode 100644 index 0000000..6a40510 --- /dev/null +++ b/docs/backups.html @@ -0,0 +1,90 @@ + + + + + + + + +

Simple Backups

+ +

Don't forget to make backups folks! I strongly argue against cloud backup services, because most of the time you have no clue how and where data is being backed up. Besides that, it's really not that hard to do it yourself. If you are not running a server with >1000 people, you would probably just do fine backing up your home directory. +

+

How to backup?

+ +

A simple backup archive of your home directory: +

+
+        $
+        $ tar --create  --file BACKUP.tar /home/rob
+
+

This creates a so-called tarball of your folder. Data from your home directory is written to BACKUP.tar. If you are not that familiar with linux, this is similar to the famous Windows zip file, but without compression. You might have encountered the tar.gz a few times. This is just like a tarball but compressed. We can add the option --auto-compress to compress. Tar automatically recognizes the extension of the file your are writing the backup to and compresses it accordingly. The first line creates a tar.gz file, the second one writes to a zip file. +

+
+        $ tar --create --auto-compress --file BACKUP.tar.gz /home/rob
+        $ tar --create --auto-compress --file BACKUP.zip /home/rob
+
+

Where to backup?

+

Good question. Some options: +

+ +

Option a is similar as the command described above. Just make sure your backup is not in the same folder. +

+

Option b, c are similar to each other. You can also use the option --directory to write the backup file to another partition or (external) hard drive. The following command writes a compressed tarball of my home directory to my external harddrive mounted out /media/externaldrive: +

+
+        $ tar --create --auto-compress \
+        --file /media/externalharddrive/BACKUP.tar.gz /home/rob
+
+

Option d. In this case we just simple copy the file (secure ssh copy) to another computer. + +

+        $ tar --create --auto-compress --file BACKUP.tar.gz /home/rob
+        $ scp BACKUP.tar.gz rob@1.2.3.4:/var/backups/
+
+ + +

When to backup?

+

Another good question. +

+ +

Option b is just manually typing in backup commands a few times a week. +For option c you can write a simple shell script (i.e. backup.sh) and put it in /etc/cron.daily. For example, the following script would write a daily backup (format like: BACKUP-2019-03-04.tar.gz) to a backup directory + +

+        #!/bin/bash
+        # write full backups to external drive 
+        BACKUP_OF_DIR=/home/rob
+        WRITE_TO_DIR=/media/external
+        DATE=$(date -I)
+
+        # if directory exist, create an archive
+        if [-d $WRITE_TO_DIR ]; then
+                tar --create --auto-compress --file $WRITE_TO_DIR/BACKUP-$DATE.tar.gz 
+        fi
+
+        # remove made backups older than 90 days
+        # TODO
+
+

Option d: TODO + +

So, option e would be some kind of trojan horse on your computer or device, continuously scanning folders, eating resources and uploading to the cloud. +

+

Final words

+

This article can be viewed as the basics of basics. Of course, there are many other ways to do backups. There are also a few security and performance issues involved. Nonetheless, when and where to backup are equal or even more important.

+ + + diff --git a/docs/backups.txt b/docs/backups.txt new file mode 100644 index 0000000..74882da --- /dev/null +++ b/docs/backups.txt @@ -0,0 +1,76 @@ +Simple Backups +******** + +Don't forget to make backups folks! I strongly argue against cloud backup services, because most of the time you have no clue _how_ and _where_ data is being backed up. Besides that, it's really not that hard to do it yourself. If you are not running a server with >1000 people, you would probably just do fine backing up your home directory. + +How to backup? +============ + +A simple backup archive of your home directory: + + $ + $ tar --create --file BACKUP.tar /home/rob + +This creates a so-called *tarball* of your folder. Data from your home directory is written to BACKUP.tar. If you are not that familiar with linux, this is similar to the famous Windows zip file, but without compression. You might have encountered the _tar.gz_ a few times. This is just like a tarball but compressed. We can add the option --auto-compress to compress. Tar automatically recognizes the extension of the file your are writing the backup to and compresses it accordingly. The first line creates a tar.gz file, the second one writes to a zip file. + + $ tar --create --auto-compress --file BACKUP.tar.gz /home/rob + $ tar --create --auto-compress --file BACKUP.zip /home/rob + +Where to backup? +=========== +Good question. Some options: + + * to another folder: if you screw up editing some files in your current working directory + * to another partition: if you screw up your filesystem on your current partition + * to another drive: if your current drives gets toasted, i.e. mechanical failure. + * to another computer: if you accidentily burn your house down + * to many other computers, aka the cloud: if you want to make sure your data is backed up, but besides that also saved forever and being spread amongst many places around the world, vulnerable for whatever law is set by those countries. + +Option a is similar as the command described above. Just make sure your backup is not in the same folder. + +Option b, c are similar to each other. You can also use the option --directory to write the backup file to another partition or (external) hard drive. The following command writes a compressed tarball of my home directory to my external harddrive mounted out /media/externaldrive: + + $ tar --create --auto-compress \ + --file /media/externalharddrive/BACKUP.tar.gz /home/rob + +Option d. In this case we just simple copy the file (secure ssh copy) to another computer. + + $ tar --create --auto-compress --file BACKUP.tar.gz /home/rob + $ scp BACKUP.tar.gz rob@1.2.3.4:/var/backups/ + + +When to backup? +============ +Another good question. + + * never + * rarely (or manually) + * scheduled, cronjobs + * on change, inotify + * always + +Option b is just manually typing in backup commands a few times a week. +For option c you can write a simple shell script (i.e. backup.sh) and put it in _/etc/cron.daily_. For example, the following script would write a daily backup (format like: BACKUP-2019-03-04.tar.gz) to a backup directory + + #!/bin/bash + # write full backups to external drive + BACKUP_OF_DIR=/home/rob + WRITE_TO_DIR=/media/external + DATE=$(date -I) + + # if directory exist, create an archive + if [-d $WRITE_TO_DIR ]; then + tar --create --auto-compress --file $WRITE_TO_DIR/BACKUP-$DATE.tar.gz + fi + + # remove made backups older than 90 days + # TODO + + +Option d: TODO + +So, option e would be some kind of trojan horse on your computer or device, continuously scanning folders, eating resources and uploading to the cloud. + +Final words +============= +This article can be viewed as the basics of basics. Of course, there are many other ways to do backups. There are also a few security and performance issues involved. Nonetheless, when and where to backup are equal or even more important. diff --git a/docs/tunneling.html b/docs/tunneling.html index ab0dbfc..16d8836 100644 --- a/docs/tunneling.html +++ b/docs/tunneling.html @@ -12,8 +12,9 @@

This page lists tutorials and sample code.

diff --git a/docs/tunneling.txt b/docs/tunneling.txt index b52d4ef..711447a 100644 --- a/docs/tunneling.txt +++ b/docs/tunneling.txt @@ -3,7 +3,8 @@ VPN and tunneling This page lists tutorials and sample code. -* : A simple setup with tinc as a gateway -* : Similar setup as the above with fastd. +* : A simple setup with tinc as a gateway. +* : Similar setup as the above with fastd. +* : Similar setup as the above with wireguard. * Strongswan: A mobike setup (not published). diff --git a/docs/wireguard.html b/docs/wireguard.html new file mode 100644 index 0000000..7ef3822 --- /dev/null +++ b/docs/wireguard.html @@ -0,0 +1,69 @@ + + + + + + + + +

Wireguard gateway setup

+ +

WireGuard securely encapsulates IP packets over UDP. You add a WireGuard interface, configure it with your private key and your peers' public keys, and then you send packets across it. It's that easy. Compared to OpenVPN, Ipsec, or even tinc, this is by far the easiest to configure. +

+
+ +

Adapted from a mail conversation
+So in this particular setup we have a listening server and a client. +The client tunnels all IP requests (wildcard 0.0.0.0/0) through the wireguard interface. +The server only allows accept connections from one IP (and furthermore checks if the key is OK). +

+

Generate public and private keys for client and server

+ +

The following cmd will create a private key with a corresponding public key. +Create these for both the server and your client. +

+
+        umask 077
+        wg genkey | tee private.key | wg pubkey > public.key
+
+

My configuration files are as follows:

+ +

A server with a virtual IP 172.16.16.1 (you can use any local LAN IP) is listening on port 51820. +Right now, it only accepts connection from one peer (172.16.16.2). Traffics from other peers or with invalid keys are dropped. +The server config is as follows +

+
+        [Interface]
+        Address = 172.16.16.1/24
+        ListenPort = 51820
+        PrivateKey = xxxxxxxx
+
+        [Peer]
+        PublicKey = xxxxxxxxxxxxxx
+        AllowedIPs = 172.16.16.2/32
+
+

On the client side, we have a client with virtual IP 172.16.16.2. As for the peer, we have set a wildcard with 0.0.0.0/0. The endpoint +is our server. All traffic is sent through this tunnel (except for maybe LAN traffic). +

+
+        [Interface]
+        Address = 172.16.16.2/32
+        PrivateKey = xxxxxxxxx
+        DNS = 8.8.8.8
+
+        [Peer]
+        PublicKey = xxxxxxxxxxxxxx
+        Endpoint = 1.2.3.4:51820
+        AllowedIPs = 0.0.0.0/0
+        PersistentKeepalive = 21
+
+

Running

+

You can start and stop your client/server with the wg-quick tool (if you compile by yourself, remember to build this tool as well) + +

+        wg-quick up wg0.conf
+        wg-quick down wg0.conf
+
+ + diff --git a/docs/wireguard.txt b/docs/wireguard.txt new file mode 100644 index 0000000..e7d0669 --- /dev/null +++ b/docs/wireguard.txt @@ -0,0 +1,59 @@ +Wireguard gateway setup +===== + +WireGuard securely encapsulates IP packets over UDP. You add a WireGuard interface, configure it with your private key and your peers' public keys, and then you send packets across it. It's that easy. Compared to OpenVPN, Ipsec, or even tinc, this is by far the easiest to configure. + +-------------- + +*Adapted from a mail conversation* +So in this particular setup we have a listening server and a client. +The client tunnels all IP requests (wildcard 0.0.0.0/0) through the wireguard interface. +The server only allows accept connections from one IP (and furthermore checks if the key is OK). + +Generate public and private keys for client and server +*********** + +The following cmd will create a private key with a corresponding public key. +Create these for both the server and your client. + + umask 077 + wg genkey | tee private.key | wg pubkey > public.key + +My configuration files are as follows: +************ + +A server with a virtual IP 172.16.16.1 (you can use any local LAN IP) is listening on port 51820. +Right now, it only accepts connection from one peer (172.16.16.2). Traffics from other peers or with invalid keys are dropped. +The server config is as follows + + [Interface] + Address = 172.16.16.1/24 + ListenPort = 51820 + PrivateKey = xxxxxxxx + + [Peer] + PublicKey = xxxxxxxxxxxxxx + AllowedIPs = 172.16.16.2/32 + + +On the client side, we have a client with virtual IP 172.16.16.2. As for the peer, we have set a wildcard with 0.0.0.0/0. The endpoint +is our server. All traffic is sent through this tunnel (except for maybe LAN traffic). + + [Interface] + Address = 172.16.16.2/32 + PrivateKey = xxxxxxxxx + DNS = 8.8.8.8 + + [Peer] + PublicKey = xxxxxxxxxxxxxx + Endpoint = 1.2.3.4:51820 + AllowedIPs = 0.0.0.0/0 + PersistentKeepalive = 21 + +Running +******** +You can start and stop your client/server with the wg-quick tool (if you compile by yourself, remember to build this tool as well) + + wg-quick up wg0.conf + wg-quick down wg0.conf + diff --git a/index.html b/index.html index a9f357f..b78132a 100644 --- a/index.html +++ b/index.html @@ -26,7 +26,7 @@ -

Hi! I'm mr_woggle, but some people call me Rob. I like simple things. Simple code, simple servers, etc. This website is mostly used for email and personal articles / programming projects. Please scan the tag below to contact me. +

Hi! I'm mr_woggle, but some people call me Rob. I like simple things. Simple code, simple servers, etc. This website is mostly used for email and personal articles / programming projects. Please scan the tag below to contact me, or just send a mail to robin at robinkrens dot nl.

Docs

@@ -38,13 +38,19 @@
  • How to backup
    • -
  • Chinese learning +
  • Linux stuff
    • + -
  • Linux stuff + +

    Chinese

    + +

    Servers and Playgrounds

    Personal