It’s summer, it’s hot as hell, I am back home from mountains and I’ve plenty of free time. Between a barbecue and the next one I spend my time playing with and learning new stuff: this week new stuff is called QEMU-KVM. Yesterday I also tried XenServer but to be honest I wasn’t impressed, it just look like to be an old version of CentOS minimal install with some custom repos and a fancy GUI. I played with it for just a bunch of hours, but the thing that just performing an installation on a software RAID-1 turned out to be a PITA to say the least is a clear sign that it’s not the best tool for my needs. I swapped a couple of HDDs and in 2 minutes I went back to the already installed CentOS 6.4 with QEMU+KVM. The client machine, for what it matters, is my Fedora 19 x86_64 workstation, virsh and virt-manager the tools I use for remote administration tasks. Installing QEMU-KVM is just a matter of typing yum install libvirtd qemu-kvm bla bla bla, chkconfig libvirtd on and doing a system reboot (better safe than sorry). The tricky part at least for me was setting up a damn bridged network interface, luckily I found this great writeup. I am going to report here what I did to setup a couple of bridged network interfaces on my setup. …

Given that SSL and TLS, especially v1.0, suffer from serious security issues (e.g. https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS) I thought it would be a good idea to use the latest and more secure version of it: v1.2. On CentOS 6.4 the openssl version included is quite old and doesn’t support TLS v1.1 and 1.2. So, first of all we have to install the latest version 1.0.1e, it can be done compiling from sources or by adding a third party repository; I chose the latter. …

Let’s say we have a WordPress blog and we would like to encrypt our login pages and the whole back-end of the site. There are many ways to do it, but since I already have a nginx instance configured as reverse proxy running in front of Apache I’ll use it to protect my admin pages and logins. In this page I’ll not cover Apache’s configuration, which, by the way, is trivial to say the least, so please refer to this other post: Apache + nginx as reverse proxy. Using the configuration posted in the above’s link as starting point, to add SSL encryption to admin pages we should add a couple more bunch of lines of code. First of all, we must create our own Certificate Authority and issue a SSL certificate. Another option is buying a certificate, but I don’t trust CA (certificate forgery anyone?) and I don’t mind having a properly signed certificate for a page I am the only one accessing to. Follows a brief explanation on how to create a CA and issue a certificate. …

OpenVPN is the de facto standard VPN free open source software; it is widely used, tested, well documented and also included in the CentOS repos (EPEL). .:. Server side configuration yum install openvpn easy-rsa dnsmasq When yum is done installing the required packages, copy the sample config file. cp /usr/share/doc/openvpn-*/sample/sample-config-files/server.conf /etc/openvpn Uncomment/edit the following lines in /etc/openvpn/server.conf: port 1194 proto udp dev tun ca ca.crt cert server.crt key server.key dh dh4096.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "redirect-gateway def1" push "dhcp-option DNS 10.8.0.1" keepalive 10 120 tls-auth ta.key 0 # This file is secret key-direction 0 tls-version-min 1.2 tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 auth SHA512 cipher AES-256-GCM #comp-lzo # Disable LZO compression persist-key persist-tun status openvpn-status.log ;log openvpn.log # disable log, optional ;log-append openvpn.log # disable log, optional user nobody group nobody Now, create two folders easy-rsa/keys in /etc/openvpn and copy some files into them: …

Yesterday’s night I installed a test machine to play with KVM and some other stuff, obviously the OS of choice is the trusty CentOS. I did a pretty minimal net-install but decided to install gnome desktop environment anyway because why not, not that it will be of much use, but still. Anyway, since the machine is an headless server it’s mandatory to be able to control it remotely, like the past 2 or 3 times, I installed XRDP expecting everything will be fine and working without any problem. And here is when I was wrong. It’s been quite a long time since the last time I installed XRDP somewhere, but I clearly remember it working flawless without any kind of manual configuration. I did the usual yum install xrdp, confirm the installation, bla bla bla, service xrdp start and both sesman and xrdp started with no problem. Then, when I went back to my workstation (Fedora 18 x64) and tried to connect to the server using Remmina Remote Desktop Client at first it seems to be working but once I typed user ID, password and press OK I got prompted the following error: …

With Samba being the clusterfuck it is, every time a new version is released you have to expect something to be messed up. This time they added a bunch of new features like MS Active Directory support, too bad that now the simple directory sharing is broken/not working like it did before. Something like 1 year ago I wrote a small guide about how to setup a Samba share on Centos 6 and I used the same smb.conf file on more than 10 machines without any problem since yesterday, when I tried it on my fresh installed Fedora 18 (which uses Samba 4.0.0). First of all, in the “Standalone Server Options” is reported that “security” options “share and server” are deprecated; too bad I just used “share” to save me the hassle of setting up a new user and stuff even if I would like the directory to be fully accessible by everyone without any restriction. I tried it anyway with “security = share” but there was no way to make the folder accessible, when trying to access the Samba share I always got a popup in which I had to login. So, at the end of the story, like it or not, I had to setup a new user, create a samba user and edit the “smb.conf” file. …