Delete data on a disk

If you want to give away a computer and you want to really delete the data on the hard drive, you can use dd under Linux. Start a live linux from a USB drive (for example Ubuntu) on the computer where you want to erase the disk.

First, find out which partitions you have. A basic way of doing this is by using fdsik:

sudo fdisk -l

Most distributions will have a graphical editor which makes it easier to see what is going on. In gnome this will be gparted, in KDE KDE partition manager. There are surely other tools around. But it does not really matter, all you need is to know the name of the partition which you want to erase. In my case it is /dev/sda4.

Now we will use dd (“disk dump”) to write random information to this partition on top of the existing information. This is the command:

sudo dd if=/dev/urandom of=/dev/sda4 bs=65536 status=progress

The parameter of (“output file”) is the hard disk partition we want to write to. You do not want to mess up and take the wrong partition. The is no “undo”. Check this parameter twenty times. The parameter if (“input file”) is used to set the data which should be written. In our case, we use /dev/urandom which is a generator for random numbers. status=progress will enable some output on the command line which tells us what is happening. If you forget this parameter, there will be no output and you will have no idea if 1 byte has been written in the last hour or 200 GB. Setting the block size (bs) to something larger than the default 512 bytes is also very highly recommended. The difference in the time the command needs to run may be huge. I use 64k in the example which worked fine for me. If you want to determine the optimal block size for your system, I suggest this article: Tuning dd block size by Danny Guinther.

Anaconda and environments (basics)

TLDR: Install Anaconda NOT into your path, then do:

ln -s ~/anaconda3/bin/activate ~/bin/activate
source activate
conda create --name myenv
conda activate myenv
python

Long version: Install Anaconda. In the process you will be asked whether you want to edit your .bashrc to setup Anaconda. Answer NO!!

You will still need to add the Anaconda executables into your path to make Anaconda work. The easiest solution that does not destroy your system is to link the activate script somewhere in your path. I do this in a folder ~/bin which is always on my path:

ln -s ~/anaconda3/bin/activate ~/bin/activate

Now call

source activate

The text (base) will be prepended to your prompt and the Anaconda binaries will be in your paths. This should be more or less equivalent to what happens when you call conda init, but without changes to your .bashrc. You could now call python and it should print “[GCC 7.3.0] :: Anaconda, Inc. on linux” instead of your default operating system python.

If you don’t do anything, you have the base environment activated. First thing you want to do, is create a new environment and activate it. Then you can install your few packages into it and work with this environment. The advantage is, that you can throw away this environment if anything goes wrong and start from scratch easily.

These are the most important commands for dealing with environments (in my examples myenv is used as a name for the environment, but of course you can use a better one):
– List all available environments: conda info --envs
– Create an environment: conda create --name myenv
– Delete an environment with all contained packages: conda remove --name myenv --all
– Activate an environment: conda activate myenv
– Deactivate the current environment: conda deactivate
– List all packages installed in the current environment: conda list
– Install a package into the current environment: conda install packagename
– Delete a package from the current environment: conda remove packagename

When you start python with python from an activated environment, you will have all packages in this environment available to you.

Anaconda destroys Plasma

I just started my computer. Plasma did not start. I only saw the message “Could not start D-bus. Can you call qdbus-qt5?”. No. I cannot call this! I don’t have a working desktop!

What I managed to do was start a session with a different desktop environment and then search the internet for a solution. Will the error message, you will quickly find that “Anaconda update breaks KDE if it’s added to PATH”. Yes! I installed Anaconda the last time I used this computer! So I removed the lines it had added to my .bashrc and everything worked again.

Note to self: Do not add Anaconda to your PATH. Do not let it edit your .bashrc (which it does when you use conda init). Stupid snake!

Redirect http to https with nginx

Create two server environments, one for port 80 (http) and one for port 443 (https). Have the http environment do nothing but redirect to the other one:

server {
        listen 80;
        listen [::]:80;
        server_name yesterdayscoffee.de www.yesterdayscoffee.de;
        return 301 https://$server_name$request_uri;
}
server {
        listen 443 ssl;
        listen [::]:443 ssl;

... all the rest of your configuration

}

HTTPS with LetsEncrypt and nginx

First install Certbot on your computer using the instructions at https://certbot.eff.org/

Then you can create a certificate for the page www.yesterdayscoffee.de (with and without www) like this:

certbot -d yesterdayscoffee.de -d www.yesterdayscoffee.de --manual --preferred-challenges http certonly

During the proces, you will be asked to create a file with a specific content at a specific location on your web server (this is for the option http, there are other ways of proving that you control the domain). Once you have done this and everything is fine, the certificate will be created.

The certificate consists of a bunch of files in a location the certbot tells you. You will probably need to put two files on the server: The private key in privkey.pem and the certificate file fullchain.pem. As a location, the folder /etc/letsencrypt/live/ is suggested.

Now you have the certificate, the next step is to tell the web server to use them for your web page. We are using nginx with the configuration file for our web page yesterdayscoffee.de at the default location /etc/nginx/sites-available/. The only thing to do is to add the port 443 for the https protocol and specify the location of the certificate files. These are the lines:

listen 443 ssl;
listen [::]:443 ssl;

ssl_certificate /etc/letsencrypt/live/www.yesterdayscoffee.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.yesterdayscoffee.de/privkey.pem;

Restart nginx for the changes to take effect with:

sudo /etc/init.d/nginx restart

You may need to tell your firewall to open the https port for nginx:

sudo ufw allow 'Nginx HTTPS'

That’s it! Now it should work. Coming up: How to redirect http to https and how to renew certificates (which with letsencrypt you have to do every 90 days).

Copying changes into your branch (`rebase`)

Situation: You create a branch newfeature from develop at point X to develop your super cool new feature. You do some commits in your branch. Meanwhile there have been some changes in develop that you want to have in your new branch. To do this, rebase your branch. Basically, this replays every commit in your branch on top of the current state in the branch you do the rebase against. Do a rebase as follows:

$ git checkout develop
Switched to branch 'develop'
$ git pull
...
$ git checkout newfeature
Switched to branch 'newfeature'
$ git rebase develop
First, rewinding head to replay your work on top of it...
Applying: intermediate commit

Before doing this, you need to commit or stash all your changes. During the rebase, if there are conflicts, you need to resolve them one by one for every commit in your branch. You can simplify conflict resolution in one of two ways: use the flag -Xours to always take the version in the branch that you are rebasing against (develop in our example); or use the flag -Xtheirs to always take the version in your branch.

When there are conflicts, you need to resolve them. To resolve a conflict, edit the file that has the conflict and remove all places indicated by <<<<<. Then add all the modifications to the staging area. You can commit, but you do not have to. For things that you know they will be resolved later on anyway, you can also chose git rebase --skip to ignore the problem (e.g., if a file was deleted in your branch and edited in the other and you know you copied the new file into your branch in a later commit). At the end, there may be things you need to commit to finalize the merge, then the rebase is complete. Don’t forget to push the result to your remote branch!