EXT4 is usually pretty good at keeping files fragmentation at minimum, but, sometimes, especially if dealing with really huge files, some fragmentation may actually occur. Luckily EXT4 supports online defragmentation, command fsck displays, among other things, fragmentation percentage: [root@fedora ~]$ fsck.ext4 -fvn /dev/sda1 e2fsck 1.42.12 (29-Aug-2014) Warning! /dev/sda1 is mounted. Warning: skipping journal recovery because doing a read-only filesystem check. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information 429 inodes used (1.31%, out of 32768) **5 non-contiguous files (1.2%)** 1 non-contiguous directory (0.2%) # of inodes with ind/dind/tind blocks: 0/0/0 Extent depth histogram: 420 45161 blocks used (34.46%, out of 131072) 0 bad blocks 1 large file 402 regular files 17 directories 0 character device files 0 block device files 0 fifos 0 links 1 symbolic link (1 fast symbolic link) 0 sockets ------------ 420 files The command e4defrag, which is contained in e2fsprogs, can be used to perform online defragmentation of EXT4 volumes. …

Postfix configuration Install the required software: $ yum install postfix postgrey dovecot fail2ban spamassassin spamass-milter-postfix opendkim Create TLS certificate, key and CA authority (replace mail.domain.tld with a valid domain name): $ mkdir /etc/postfix/ssl $ cd /etc/postfix/ssl $ openssl genrsa -aes256 -out mail.domain.tld.key 4096 $ chmod 600 mail.domain.tld.key $ openssl req -sha256 -new -key mail.domain.tld.key -out mail.domain.tld.csr $ openssl x509 -sha256 -req -days 1825 -in mail.domain.tld.csr -signkey mail.domain.tld.key -out mail.domain.tld.crt $ openssl rsa -in mail.domain.tld.key -out mail.domain.tld.key.nopass $ mv mail.domain.tld.key.nopass mail.domain.tld.key $ openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650 -sha256 $ chmod 600 mail.domain.tld.key $ chmod 600 cakey.pem $ openssl dhparam -out dhparams.pem 4096 $ chmod 600 dhparams.pem Edit main.cf file accordingly (the other lines should be ok by default). No SQL database is used, for user authentication postfix relies on Linux users, email data are stored in ~/Maildir. …

I will be keeping this post up to date to keep track on how to configure and mantain an ejabberd server working efficiently and secure. I strongly advise any reader to read carefully what is written here and not just copy-and-paste the configuration file. My blog also contains a bunch of other posts regarding ejabberd that are worth giving a look at, use the search form. Server CentOS 7.5.1804 x86_64 Erlang/OTP 21.1.1-1 x86_64 ejabberd 18.09 Client LineageOS 15.1 (Android Nougat) Conversations 2.3.5+fcr .:. Installation and initial configuration Download and install erlang (release numbers here may not be up to date): …

To password protect a directory xyz and every file and subdirectory in it open the configuration file (nginx.conf or one of the virtual host configuration files) and add the following two lines: location /xyz/ { auth_basic "Restricted Area"; auth_basic_user_file conf.d/htpasswd; } htpasswd file must be encrypted, it can be created using a tool named htpasswd. [root@xenserver ~]# cd /etc/nginx/conf.d/ [root@xenserver ~]# htpasswd -b htpasswd user password

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