Helpful git tips

So chatting with a colleague about some git tricks this week I discovered that not everyone was aware you could change the bash prompt to give certain git status, such as branch, and things like if you’re in merge/am/bisect modes etc. I’ve had the pieces in my .bashrc for so long I had literally got to the point it was assumed functionality that every one has enabled.

The following snippet is what I have in my ~/.bashrc:

# git branch display
source /usr/share/git-core/contrib/completion/git-prompt.sh
export GIT_PS1_SHOWDIRTYSTATE=true
export GIT_PS1_SHOWUNTRACKEDFILES=true
export PS1='[\[\e[0;32m\]\u\[\e[0m\]@\[\e[0;35m\]\h\[\e[0m\] \W\[\e[0;33m\]$(__git_ps1 " (%s)")\[\e[0m\]]\[\e[0;32m\]\$ \[\e[0m\]'

And with that you get a more useful prompt that looks like the prompt below, in this case merging bits, for all git repos with added colours too!:

[peter@localhost linux (master *+|MERGING)]$

Increasing a libvirt/KVM virtual machine disk capacity

There’s a bunch of howto’s on the internet for increasing the size of a virtual disk of a VM. Of course the best is to use the very useful libguestfs-tools options but there’s been some improvement in tools like sfdisk so I thought I’d document what I did for reference using tools I already had installed.

First shutdown the VM. Once it’s shutdown you need to work out where the disk is located. As this VM is running from my local machine and is just using a raw disk this is straight forward. You can get the details from the virt-manager GUI or virsh dumpxml VM-Name.

Next up we use qemu-img, it’s installed by default with the libvirt stack, to add the extra space we need, in theory this can be done with the VM online, this is a random test VM so online time doesn’t matter, and of course if the VM matters to you there should be a proper backup done first! The fdisk isn’t necessary, it just allows you to see that the extra space is there.

# qemu-img resize /var/lib/libvirt/images/VM-Name.raw +4G
# fdisk -l /var/lib/libvirt/images/VM-Name.raw
Disk /var/lib/libvirt/images/VM-Name.raw: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe8b201aa

Device                                            Boot   Start     End Sectors Size Id Type
/var/lib/libvirt/images/VM-Name.raw1 *       2048 2099199 2097152   1G 83 Linux
/var/lib/libvirt/images/VM-Name.raw2      2099200 8388607 6289408   3G 83 Linux
#

Now power up the VM, login as root (or use sudo) for the next bits on the VM. The sfdisk tool has had a bunch of improvements over the last few years for partitioning. If you’ve not used it or looked at it recently I recommend checking the well written man page. Here I’m just expanding last partition (partition 2) on the disk to the maximum size the disk offers. For all the other possibilities “man sfdisk” is your friend!

# echo ", +" | sfdisk -N 2 /dev/vda --no-reread
# partprobe
# resize2fs /dev/vda2

And with that you should be good to go, df and friends will show you the new space, no reboot needed! The VM I have here is very basic partitions, no LVM etc so straight forward, if you have LVM there’s lots of docs on how to deal with that elsewhere.

using ssh keys with screen

It always annoyed me I couldn’t use my ssh key in a screen session. Every now and again I would try and work it out with google and some trial and error. Eventually with the help of a couple of good bits off the net I worked out what I thought to be the easiest way to achieve it consistently.

Firstly the ssh config bits:

Add the following to your ~/.ssh/config file, creating it if you don’t already have one:

host *
  ControlMaster auto
  ControlPath ~/.ssh/master-%r@%h:p

And create the ~/.ssh/rc file:

#!/bin/bash
if test "$SSH_AUTH_SOCK" ; then
    ln -sfv $SSH_AUTH_SOCK ~/.ssh/ssh_auth_sock
fi

And make sure they have the correct permissions for ssh:

chmod 600 ~/.ssh/config ~/.ssh/rc

Finally add the following to your ~/.screenrc file:

setenv SSH_AUTH_SOCK $HOME/.ssh/ssh_auth_sock

I’m not sure it’s the best and most effective way but it’s nice and simple and to date it’s been working well for me, I’ve not had issues with it. Any suggestions for improvement feel free to comment.

Disable SSLv3 in Dovecot

Disabling SSLv3 in Dovecot is nice and straight forward.

In the /etc/dovecot/conf.d/10-ssl.conf file edit the ssl_cipher_list line to look as below (or adjust to suit your specific requirements):

ssl_cipher_list = ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:+HIGH:+MEDIUM

To test the option to ensure it’ll work you can run the following command before you restart dovecot and the output should look something like below:

$ openssl ciphers -v 'ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:+HIGH:+MEDIUM'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA256
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256)  Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256)  Mac=SHA384
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA256
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-SHA256  TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(128)  Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA Au=ECDH Enc=AES(128)  Mac=SHA256
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256

Finally to test it from client side you can run the following command to ensure it’s not enabled. If it’s configured as expected the negotiation should fail and it’ll return you straight to the command prompt:

openssl s_client -connect mail.example.com:993 -ssl3