Long story short: in Fedora 20 (and as far as I remember also 19 and 18) XScreenSaver doesn’t power off the monitor backlight when locking the screen. Being the lazy ass I am it took like me 2 or 3 years to find the motivation to solve the issue. It was actually pretty simple, no need to edit some obscure config file or else, in XFCE just click on: Application menu -> Settings -> Screensaver. A window will appear, select Blank Screen Only in the Mode dropdown menu, then switch to the advanced tab, un-check power Management Enabled and check Quick Power-off in Blank Only Mode. This is it, now every time the screen locks the monitor backlight will also power off.

Being the tinfoil hat I am I obviously don’t like nor use whatsapp, some time ago I set up my own XMPP server and made a bunch of close friends switch to it. There are multiple clients for every platform, my personal preference goes to Xabber on Android and Pidgin on GNU/Linux; both support OTR encryption and all around are pretty decent clients. The only real issue we had so far is the very annoying problem of lost messages; if the internet connection is stable and decent the problem will very likely never come up, too bad that mobile phone internet connection is everything but stable. Every time there is a switch between EDGE, 3G, HSDPA and 4G the mobile phone is out of reach for some seconds (some time much more than just some). The switch between let’s say 3G and HSDPA is not predictable, so the client has physically no time to notificate the server that he is about to close the connection and on the other hand the server also has some trouble knowing if someone suddenly disconnect. Here comes XEP-199 a.k.a. XMPP ping, it is used to probe the clients connection state every X seconds, in my ejabbed (the XMPP server I use) configuration it is set to 60 seconds, so every 60 seconds the server ping every client, if after 32 additional seconds a client has not replied it will be considered as disconnected and any further message sent from everyone to it will be cached by the server and resent the next time the client will be back online. Enable XEP-199 in ejabberd is pretty easy… …

Ok, -everyone- knows it, this new version introduces a number of interesting updates, one above all: openssl version 1.0.1. Openssl is the library used by many programs to perform encryption tasks, for example it’s used by openssh, webservers, etc etc. The version included in CentOS 6.4 was really outdated, it doesn’t support TLS v1.2 for example, so I had to install it separately (which is a PITA to say the least). With the new version included in CentOS 6.5 TLS v1.2 works out of the box, keep up the good work CentOS team.

It’s been quite a while since the last time I fired up the single stage (actually, it should be 290 days), let alone having a LN2 session. Past saturday I went to my grandfather’s place and got him a new PC since his precedent one is, to say the least, outdated. Anyway, since the old one has some interesting parts I decided to give it a try, hooked it to the single stage and baaaaaaam. …

This post is meant to be the sequel of the one I wrote one month ago about CentOS as router, transparent proxy, and much more. A big chunk of the precedent article is on how configure squid and squidGuard to act as a transparent proxy with URLs filtering capabilities. But there’s a problem with that: nowadays many sites (f4c3b00k.c0m just to name the most annoying one) are HTTPS. With HTTP one can really easily intercept a packet and read the payload (which contains the URL) but with HTTPS this is not possible anymore since the payload is encrypted. The only way to be able to read the payload of an HTTPS packet is doing a man-in-the-middle attack with a fake certificate, but that’s not advisable and you really don’t wanna do it. If, like in my case, we are not interested in what the users are doing but we just want them to not be able to access some sites/services/whatever ipset (combined with iptables) are the right tools for the job. iptables is a pretty powerful tool, the only real issue is that it doesn’t scale pretty well if the number of the rules is very big, and this is not a good thing since we probably want to blacklist thousands of IPs. And here comes ipset: with it it’s possible to manage huge blacklists without iptables slowing down. …

I got a new TV for the living room (a Panasonic Viera TX-L39E6E) which is DLNA capable. To be honest I’m also planning to build some kind of media center, maybe a really low power one, based on some kind of raspeberry-pi lookalike device. Anyway, for now I’m using my workstation (Fedora 19 x86_64) to stream video contents using miniDLNA. First of all, let’s install it with the usual: $ sudo yum install minidlna Then, edit the following file: …

As usual, long story short: I’ve to setup a firewall to log traffic, block some stuff and do some other things. – epel repo is required – The system is made of a single CentOS machine with 2 physical network adapters: eth0, connected to WAN, static IP address 192.168.0.3 eth1, connected to LAN, static IP address 10.0.0.1/24 .:. Network adapters configuration WAN network adapter: [root@CentOS ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE="eth0" BOOTPROTO="none" HWADDR="**:**:**:**:**:**" IPADDR=192.168.0.3 NETMASK=255.255.255.0 GATEWAY=192.168.0.1 DNS=192.168.0.1 IPV6INIT="yes" IPV6_AUTOCONF="yes" NM_CONTROLLED="yes" ONBOOT="yes" TYPE="Ethernet" UUID="***" LAN network adapter: …

Ok, I know I fucked up, I know everyone who knows me just a little bit would never expect this, but I got my first mobile phone or, like they call them nowadays: a smartphone. I don’t like the smartphone buzzword since I think the only smart ones here are the guys who are able to sell this stuff for hundreds of bucks to billions of people, so I’ll stick with the old and almost forgotten mobile phone name. Anyway, I got this brand new Nexus 4, played with it a couple of days and then, following the official guide on CyanogenMod site, I installed the latest stable release of it (based on Android 4.2.2). – Why the Nexus 4? Because Nexus devices are the only Android phones worth to be bought. – CyanogenMod works great and with some programs (don’t fucking call them apps, seriously, don’t do it) installed (k-9 Mail, OpenVPN, BusyBox and JuiceSSH) I’m almost able to perform all the tasks I usually do with my workstation or Thinkpad. The only real issue is the process, or whatever it is, called Google Services using an enormous amount of network resources without any apparent good reason. Luckily I’ve a friend called DuckDuckGo which in a bunch of seconds was able to tell me how to solve the issue. The problem seems to be connected to the Google Play Store which is completely retarded and keeps downloading some kind of system updates which obviously is not able to install since I’m not using the stock Android operating system provided by Google. The solution is pretty simple: …

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. …