On most Linux distros it is possible to generate the htpasswd file entries simply using the htpasswd command line util. On FreeBSD the easiest way to accomplish the same task is using OpenSSL itself: openssl passwd -apr1 Enter the password twice to get a nice hash, copy that in the htpasswd file with the usual user:password_hash syntax.
Most Western Digital hard drives’ firmware let the heads park themselves after a certain amount of seconds in case the disk is not actively performing any operation. This might be useful to keep power consumption under control but is actually harmful for disks that run 24⁄7 (WD Red for example). Luckily there is a way to disable head parking, this can be done directly from Linux using a tool called idle3ctl.
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.