another meaningless subtitle


last update:

After a six months hiatus here is a new blogpost. This saturday I finally found the time to upgrade the configuration of the server that hosts this very website. Software stack is pretty simple: FreeBSD (version 12.0-p6),nginx (version 1.15.10) and OpenSSL (version 1.1.1a-freebsd). Install the required software: $ pkg install nginx-devel py36-certbot Get a SSL certificate from letsencrypt: $ certbot-3.6 certonly --standalone -d domain.tld -d www.domain.tld Certfiles location is /usr/local/etc/letsencrypt/live/<domain.

PCI passthrough is the process of attaching a PCI-E device directly to a VM; CPU support (namely VT-D for Intel and AMD-V for AMD) and motherboard support (IOMMU) are required for PCI passthrough to work properly. Hardware configuration used: AMD Ryzen 1700x Gigabyte X370 K7 Nvidia Geforce GTX260 32 GiB of RAM and a few HDDs Fedora 29 as host OS The system only has a single graphic card because it is normally used as headless compute server for which a GPU is not really required; the graphic card is also very very old Nvidia Geforce GTX260 with a standard non UEFI BIOS.

The idea here is to be able to power on and unlock a remote Full Disk Encrypted (FDE from now on) server. I will leave the how “remotely power on” to the reader to figure out and focus on the other part. The easiest way to accomplish it is by using a program called: dracut-crypt-ssh. $ yum install dropbear dracut dracut-network openssh libblkid-devel gcc $ git clone https://github.com/dracut-crypt-ssh/dracut-crypt-ssh.git $ cd dracut-crypt-ssh $ .

QCOW2 disk images can be easily grown using libvirt command line utils. Unfortunately it isn’t possible to grow QCOW2 images in-place or online. First of all, power off the virtual machine, grow the file and make a copy of it: $ qemu-img resize image.qcow2 +200G $ cp image.qcow2 image-new.qcow2 Identify the specific partion you intend to grow: $ virt-filesystems -a image.qcow2 -l Name Type VFS Label Size Parent /dev/sda1 filesystem ext4 - 536870912 - /dev/sda3 filesystem xfs - 45885612000 - Expand the actual partition:

Yesterday I was reading phoronix 0 and phoronix 1 articles on STIBP mitigation impact on CPU performance, since I run a pretty old laptop equiped with a Sandy Bridge CPU I figured that I should do my own tests to see how bad things really are or aren’t. CPU: Intel Core i3-2310M - 2 cores / 4 threads Motherboard: Lenovo Thinkpad RAM: 2x4 GB DDR3 @1333 MHz HDD: Plextor M5pro OS: Fedora 29 x86_64 with stock kernels My benchmark of choice is compiling the Linux kernel (version 4.

In the last couple of months Xorg has been crashing more or less on a daily basis. What happens is that while you are there browsing the internet, or certain times even doing literally nothing, Xorg crashes and after a second of black screen the user is sent back to the login page. Hardware configuration of my machine is: CPU: AMD Ryzen 7 1700x Motherboard: Gigabyte X370 K7 - BIOS F23d RAM: 2x16 GB DDR4 HDD: Samsung 850 Pro GPU: Nvidia GTX260 Monitor 0: Dell U2412M connected via DVI-D Monitor 1: Dell U2412M connected via HDMI-DVI cable OS: Fedora 28 and Fedora 29 x86_64 GPU driver: nouveau, various versions others: varius versions of Linux, Xorg, mesa, etc I don’t think having two monitors is the culprit nor using a very old Nvidia graphic card is because a friend of mine runs a completely different system (AMD Radeon RX480, single monitor connected using Display Port) and still suffer from the very same problem.

Today I red an article that was comparing Fedora 29 and FreeBSD 11.2 network performance in a KVM/Qemu environment. Since I use KVM/Qemu and also Fedora and Freebsd I powered on a couple of vm and did my own tests. Results are quite interesting, I expected FreeBSD to be faster but it turns out Fedora 29 actually is. Host system configuration: CPU: Ryzen 7 1700x @4 GHz Motherboard: Gigabyte X370 K7 - BIOS F23d RAM: 2x16 GB DDR4 @3133 MHz CAS 16 HDD: Some Samsung SSD Operating systems Host: Fedora 29 x86_64 Fedora VM0: Fedora 29 X86_64 Fedora VM1: Fedora 29 X86_64 FreeBSD VM0: FreeBSD 11.

XMPP over TLS (formerly XEP-0368) is a clever mechanism that allows users to connect to a XMPP server from networks that restrict outgoing traffic only to specific ports; this block is circumvent by routing XMPP traffic via port TCP 433. If the server hosts only a XMPP server setting up XMPP over TLS is pretty easy, just instruct the server to listen on port 443. If the server also runs a webserver which is listening on port 443 things are a bit more complicated; luckily Nginx provides a way to manage XMPP traffic and redirect it to the XMPP server.

Guess it is time to write my first post using Hugo. Yesterday I downloaded a torrent consisting of 2 years worth of 4chan posts, the plan was to mess with it and use the data to train a chatbot. Dealing with big datasets is always fun because even the easiest tasks tend to get complicated, for example extracting the data from a ~3 GB tar.gz compressed archive was a challenge by itself.

For some reason one of my CentOS 7 boxes decided to nuke itself yesterday, when I powered it on it prompted me with the following error: “failed to open \efi\centos\grubx64.efi”. What I did to fix it is: Boot up a rescue USB, mount the required partitions and chroot. Add a DNS server: $ echo "nameserver *.*.*.*" &gt;&gt; /etc/resolv.conf Enable networking using ifconfig (in my case it was already enabled).