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
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)]$
I recently managed to break the network on my VM that hosts this blog. Basically I removed the NetworkManager-initscripts-ifcfg-rh package because I don’t use the old style ifcfg configuration anywhere else and I had forgotten how long I’d had this VM. So I went into the web console, manually bought up the network with ip commands and reinstalled the package but it made no difference. Oh well! Time to just move it to the new config so I just worked out the nmcli options for all the bits in the old ifcfg. This VM network is nothing special, it’s basically dual IPv4/IPv6 interface with associated DNS.
Step 1: Show existing connections:
$ sudo nmcli c
NAME UUID TYPE DEVICE
eth0 a603bba7-fad8-3c71-9d4c-2cd5dc50e114 ethernet eth0
Step 2: Delete existing connection:
$ sudo nmcli c del a603bba7-fad8-3c71-9d4c-2cd5dc50e114
Step 3: Create a new connection (Note the IP addresses are random, the DNS servers are the Google public ones):
$ sudo nmcli c add type ethernet ifname eth0 con-name eth0 mac 80:00:00:ab:cd:ef ip4 192.168.10.6/24 gw4 192.168.10.1 ip6 fe80::b257:377c:e7b3:29ed/64 gw6 2A03:B0C0:0003:00D0:0000:0000:0000:0001 ipv4.dns "184.108.40.206 220.127.116.11" ipv6.dns "2001:4860:4860::8888 2001:4860:4860::8844"
Now the blog is back! The new connection is stored in /etc/NetworkManager/system-connections/eth0.nmconnection
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
# 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.
HTTP/2 is the new version of the well known HTTP protocol which has been at the venerable 1.1 since late last century. Version 2 was derived out of Google’s SPDY protocol and it’s a binary protocol over the text based 1.1. It introduces a bunch of improvements including reducing latency, multiplexing, and server push. There’s some useful improvements that will be great for things like apps that use WebSockets. The Apache httpd daemon has included complete support for HTTP/2 since the 2.4.17 release in the form of mod_http2.
First you should configure your site with SSL, I suggest using LetsEncrypt/certbot as documented in this Fedora Magazine article.
Then you need to make sure the module is loaded, at least in Fedora 25 this is enabled in /etc/httpd/conf.modules.d/00-base.conf by default:
LoadModule http2_module modules/mod_http2.so
Then you just need to enable the protocol in either the general configuration or in specific VirtualHost directives for specific sites:
# for a https server
Protocols h2 http/1.1
# for a http server
Protocols h2c http/1.1
Then it’s just a systemctl restart httpd to make the changes take effect.
To test whether you’re serving over HTTP/2 you can test using this HTTP/2 testing site or with the OpenSSL client (check for “ALPN protocol: h2” in the output) with the following command:
openssl s_client -alpn h2 -connect HOSTNAME:443
Note: HTTP/2 is not currently supported in the httpd shipped in RHEL.