Use this to fix:
Kill rdpclip.exe using the TaskManager.
Start rdpclip.exe using Run.
The clipboard should work now again.
2018-04-27
Show Intel TurboBoost usage under Linux: tubostat
This monitors the current clock rate (in MHz) for each core and it also lists the TurboBoost settings depending on how many cores are used:
You may first need to install turbostat (for Ubuntu):
sudo apt-get install linux-tools-common
2018-03-20
Ctrl-Q and Ctrl-S do not work in GNU screen
If you find that pressing Ctrl-Q and Ctrl-S has no effect at all in a specific GNU screen terminal than you most likely have accidentally switched on XON/XOFF flow control by hitting Ctrl-A F. The symptom is that you cannot save using Ctrl-X Ctrl-S in Emacs, and you cannot use Ctrl-Q for quoted-insert in Emacs. The Ctrl-S and Ctrl-Q keys are silently ignored.
To make the Ctrl-S and Ctrl-Q keys work again you must disable flow control in screen: Press Ctrl-A F until "-flow" is displayed. Now the behavior should be back to normal: GNU screen no longer handles Ctrl-Q and Ctrl-S specially and passes these to the application.
To make the Ctrl-S and Ctrl-Q keys work again you must disable flow control in screen: Press Ctrl-A F until "-flow" is displayed. Now the behavior should be back to normal: GNU screen no longer handles Ctrl-Q and Ctrl-S specially and passes these to the application.
2018-02-22
Set terminal title (reset terminal title after it was scrambled by accidentally printing a binary file)
echo -ne "\033]0;SOME TITLE HERE\007"
2018-02-03
Encrypted backup disk on Linux
Problem: I would like to store a backup disk in a different physical place every now and then, just to be sure in case of severe incident like a fire etc. Different physical place means to give up the control where the disk goes: It might be stolen, or it might simply be lost, or it might be sold on ebay by accident. Ok, I totally made the ebay thing up. :-)
Solution: Keep the backup disk encrypted.
Whole disk encryption is not as secure as it sounds, due to the limitations of sector-wise access, but it is _way_ better than not encrypting the disk at all, and it usually provides solid confidentiality (meaning an attacker cannot read any information from the disk).
(There are nasty attacks on whole disk encryption, but they are all around an attacker writing stuff to the disk, modifying it contents in various ways. But if the encryption is done properly all of these attacks leave random garbage in the decrypted view of the disk.)
I am using 'plain dm-crypt' instead of LUKS since I do not need any of the LUKS features and it is very easy to set up and very easy to understand what happens.
I am also using the entire disk as one big partition, without a partition table. Encrypted partition tables do not make much sense in my opinion, and I only want one partition anyway.
If there was already (plain) data on the disk (e.g. an unencrypted backup) it is wise to erase that by overwriting the disk with random garbage:
shred -n 1 /dev/sdX
Create encrypted layer of the disk:
cryptsetup --cipher=aes-cbc-essiv:sha256 --key-size 128 --key-file=key.bin open --type plain /dev/sdX enc
(I am using aes-cbc-essiv:sha256 with just a 128 bit key since it seems sufficient for my purpose. If you are concerned that somebody might modify the contents of the disk you are better off with using aes-xts-essiv:sha256 with a 512 bit key, but I was not happy with the performance penalty for very little benefit (if any).)
The file key.bin contains the 16 byte (128 bit) binary AES key. I created it using:
head -c 16 /dev/random > key.bin
I keep the key.bin file in plain on my server since I am not nervous of it getting lost. People with access to the server are unlikely to want to decrypt the backup disk of the server since they have full access to the data (even full access to the data on the encrypted disk!) anyway. Of course it is necessary to keep a backup of this key in another physical place, e.g. printed on paper etc. Otherwise the backup disk is useless.
The plain view of the encrypted disk image is now available under /dev/mapper/enc.
Creating an ext4 filesystem on the encrypted disk:
mke2fs -m 0 -t ext4 /dev/mapper/enc
Mount encrypted disk:
mount /dev/mapper/enc /backup_disk
Now you can create a backup on /backup_disk.
When done, umount the disk and stop the encryption (which might flush a few sectors to the disk):
umount /backup_disk
cryptsetup close enc
Useful links:
https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption
https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
Solution: Keep the backup disk encrypted.
Whole disk encryption is not as secure as it sounds, due to the limitations of sector-wise access, but it is _way_ better than not encrypting the disk at all, and it usually provides solid confidentiality (meaning an attacker cannot read any information from the disk).
(There are nasty attacks on whole disk encryption, but they are all around an attacker writing stuff to the disk, modifying it contents in various ways. But if the encryption is done properly all of these attacks leave random garbage in the decrypted view of the disk.)
I am using 'plain dm-crypt' instead of LUKS since I do not need any of the LUKS features and it is very easy to set up and very easy to understand what happens.
I am also using the entire disk as one big partition, without a partition table. Encrypted partition tables do not make much sense in my opinion, and I only want one partition anyway.
If there was already (plain) data on the disk (e.g. an unencrypted backup) it is wise to erase that by overwriting the disk with random garbage:
shred -n 1 /dev/sdX
Create encrypted layer of the disk:
cryptsetup --cipher=aes-cbc-essiv:sha256 --key-size 128 --key-file=key.bin open --type plain /dev/sdX enc
(I am using aes-cbc-essiv:sha256 with just a 128 bit key since it seems sufficient for my purpose. If you are concerned that somebody might modify the contents of the disk you are better off with using aes-xts-essiv:sha256 with a 512 bit key, but I was not happy with the performance penalty for very little benefit (if any).)
The file key.bin contains the 16 byte (128 bit) binary AES key. I created it using:
head -c 16 /dev/random > key.bin
I keep the key.bin file in plain on my server since I am not nervous of it getting lost. People with access to the server are unlikely to want to decrypt the backup disk of the server since they have full access to the data (even full access to the data on the encrypted disk!) anyway. Of course it is necessary to keep a backup of this key in another physical place, e.g. printed on paper etc. Otherwise the backup disk is useless.
The plain view of the encrypted disk image is now available under /dev/mapper/enc.
Creating an ext4 filesystem on the encrypted disk:
mke2fs -m 0 -t ext4 /dev/mapper/enc
Mount encrypted disk:
mount /dev/mapper/enc /backup_disk
Now you can create a backup on /backup_disk.
When done, umount the disk and stop the encryption (which might flush a few sectors to the disk):
umount /backup_disk
cryptsetup close enc
Useful links:
https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption
https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
Monitor dd progress on Linux with old binutils
I recent was on an Ubuntu 14.04 machine, started a long running dd to clear a disk, and then wanted to monitor progress of this command to get an indication how long it would take.
In found that my binutils (dd) were too old for the dd status=progress feature.
Sending signal USR1 to dd prints its progress:
killall -USR1 dd
Alternatively you can just look at the write file descriptor of the dd process, e.g.:
In found that my binutils (dd) were too old for the dd status=progress feature.
Sending signal USR1 to dd prints its progress:
killall -USR1 dd
Alternatively you can just look at the write file descriptor of the dd process, e.g.:
grep pos /proc/4609/fdinfo/1
Abonnieren
Posts (Atom)