TCP BBR looks promising and somehow managed to escape my radar so far.. need to take a look at how to improve my IT infrastructure with it:
Increase your Linux server Internet speed with TCP BBR congestion control
Make a diff!
TCP BBR looks promising and somehow managed to escape my radar so far.. need to take a look at how to improve my IT infrastructure with it:
Increase your Linux server Internet speed with TCP BBR congestion control
A nice summary by Werner Fischer (Thomas-Krenn) about how to enable and use Serial over LAN, particularly for Linux boxes:
(In German, but you can easily translate it using your favourite online translation tool, e.g. deepl.com or Google Translate)
It might be worth taking a closer look at Clip OS, a relatively new, security focused Linux distribution by the ANSSI, based on Hardened Gentoo and with some similarities to Qubes OS.
GitLab 10.5 introduced built-in support for Let’s Encrypt.
Unfortunately, if you follow the official GitLab instructions how to enable Let’s Encrypt support, you may encounter the following error when rebuilding GitLab:
Running handlers:
There was an error running gitlab-ctl reconfigure:letsencrypt_certificate[yourhost.yourdomain.com] (letsencrypt::http_authorization line 3) had an error: RuntimeError: acme_certificate[staging] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/letsencrypt/resources/certificate.rb line 20) had an error: RuntimeError: [yourhost.yourdomain.com] Validation failed for domain yourhost.yourdomain.com
Running handlers complete
Chef Client failed. 11 resources updated in 11 secondsWarnings:
Let’s Encrypt is enabled, but external_url is using http
The last line is rather misleading, as the domain validation can apparently also fail if one sets external_url = “https://yourhost.yourdomain.com”
As a workaround, add the following two additional lines to /etc/gitlab/gitlab.rb (hat tip to Kai Mindermann and Thomas Jost for the hints):
nginx['redirect_http_to_https_port'] = 80 nginx['redirect_http_to_https'] = true
So, all in all, you need to set in /etc/gitlab/gitlab.rb:
external_url 'https://yourhost.yourdomain.com'
and add the following lines (adjust the notification e-mail address):
letsencrypt['enable'] = true letsencrypt['contact_emails'] = ['gitlab-notifications@yourdomain.com'] # optional nginx['redirect_http_to_https_port'] = 80 nginx['redirect_http_to_https'] = true
Make sure that your firewall doesn’t block access to ports 22 (SSH), 80 (HTTP), 443 (HTTPS).
After that, reconfigure GitLab (in a shell):
# gitlab-ctl reconfigure
That’s it! You can now register/login at https://yourhost.yourdomain.com.
This blog has just been migrated to a newer and (much) faster host node running Proxmox 5 with ZFS.
Therefore, I was looking for the best method to migrate a WordPress blog to another server (and/or database and/or directory and/or URL).
Do you remember the times when migrating a WordPress blog was rather tedious, involving many manual steps, despite (other) handy tools like WP-CLI? Apparently, this is no longer needed, as all you need is the following plugin:
This plugin’s export and import functionality takes care of all the required configuration and path adjustments, allowing you to easily migrate a blog with up to 512 MB data. The steps are thus:
It’s hard to believe, but that’s really it!
When upgrading Ubuntu 14.04 LTS to 16.04 LTS the usual way, ‘do-release-upgrade’ will by default remove 3rd party packages. For a Zimbra/ZCS server this means that Zimbra/ZCS packages would be automatically removed when upgrading to Ubuntu 16.04 LTS.
Luckily, there’s a neat little trick to prevent ‘do-release-upgrade’ from removing Zimbra/ZCS packages during the upgrade. Here’s how to do it:
$ screen -R
$ sudo /etc/init.d/zimbra stop
$ sudo apt-get update && sudo apt-get upgrade
$ sudo do-release-upgrade
(if you don’t have do-release-upgrade, you have to execute ‘sudo apt-get install update-manager-core’ first)
# deb [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra # disabled on upgrade to xenial # deb-src [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra # disabled on upgrade to xenial
to
deb [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra deb-src [arch=amd64] https://repo.zimbra.com/apt/87 xenial zimbra
Then return to the first terminal/screen session and let ‘do-release-upgrade’ continue with the upgrade process (i.e. hit ‘enter’).
After this, Zimbra/ZCS should work nicely again, on Ubuntu 16.04 LTS.
Note: It can take Zimbra/ZCS quite some time to properly start all its services (it’s Java, after all). Sometimes, the output of ‘$ sudo /etc/init.d/zimbra status’ and what’s listed in the service monitoring section of the Zimbra/ZCS admin webUI can thus be inconsistent. Sometimes, it’s even necessary to stop and start Zimbra/ZCS a couple of times (with ‘/etc/init.d/zimbra’) after an upgrade until all services run nicely.
Also note that Zimbra’s new dedicated ‘imapd’ service won’t run properly, unless it’s configured manually, as shown in the Zimbra Collaboration Administrator Guide version 8.8.3. If it doesn’t run properly, this service will simply be ignored in a single server setup, your Zimbra/ZCS will thus likely work as usual.
If there are any problems or if you want to be extra cautious, you can also additionally download Zimbra/ZCS 8.8 for 16.04 LTS manually and run its installer again:
$ sudo ./install.sh
If everything is fine, unblock the SMTP and SMTPS (and IMAP and IMAPS) ports again.
If things aren’t fine, simply roll-back from the snapshot or restore the whole server from the backup.
You might then want to try a fresh install according to the official Zimbra/ZCS migration manual: How to move ZCS to another server.
(Source: Kudos to vchong68 for his valuable hint in his forum post)
If you see the following error when trying to backup a KVM VM image on Proxmox:
ERROR: Backup of VM 100 failed – disk ‘scsi0’ ‘zfsvols:vm-100-disk-1’ (iothread=on) can’t use backup feature currently. Please set backup=no for this drive at /usr/share/perl5/PVE/VZDump/QemuServer.pm line 77. INFO: Backup job finished with errors TASK ERROR: job errors
edit /etc/pve/qemu-server/100.conf, look for a line similar to
scsi0: zfsvols:vm-100-disk-1,iothread=1,size=70G
and change it to
scsi0: zfsvols:vm-100-disk-1,iothread=0,size=70G
Afterwards, it’s possible to backup the VM.
A useful post how to fsck (check and fix) a filesystem in a qcow2 image (as typically used for KVM VMs, e.g. in Proxmox):
How to recover a qcow2 file using fsck
On Proxmox or Debian, one does the following:
Attention:
# modprobe nbd max_part=8 # qemu-nbd --connect=/dev/nbd0 /var/lib/vz/images/100/vm-100-disk-1.qcow2 # fdisk -l /dev/ndb0 /dev/nbd0p1 2048 7813119 3905536 82 Linux swap / Solaris /dev/nbd0p2 * 7813120 119537663 55862272 83 Linux # fsck.ext4 /dev/nbd0p2 # fsck.ext4 -p /dev/nbd0p2 # qemu-nbd --disconnect /dev/nbd0
Like this, one doesn’t need to boot the VM using a boot ISO/CDROM and can fix the filesystem right from the host node.
Overview of recorded presentations:
https://media.ccc.de/b/congress/2015
My list of particularly interesting presentations (mostly for myself – disclaimer: I haven’t watched all of these presentations yet as I didn’t make it to Hamburg this year):
If you see the following error message when executing ‘zpool status’ after “upgrading” Proxmox to the (currently) latest version with ZoL 0.6.4 instead of 0.6.3:
zpool: Symbol `spa_feature_table' has different size in shared object, consider re-linking
Explanation:
“Re-linking” doesn’t have a special meaning in ZFS/ZoL terminology, it rather just describes the usual linking step after compiling some source code.
Solution:
The most likely cause is that some new, updated and required packages have not been installed (e.g. with ‘uname -a’, you’ll see that the old kernel is still running, even after rebooting). Usually, this happens if one executes “apt-get update && apt-get upgrade” (as usual) rather than “apt-get update && apt-get dist-upgrade“. So, in order to solve this problem, do:
# apt-get update && apt-get dist-upgrade # reboot
In this case, ZoL 0.6.4 also includes a couple of new features which can be enabled for all local ZFS pools by executing:
# zpool upgrade -a This system supports ZFS pool feature flags. Enabled the following features on 'rpool': spacemap_histogram enabled_txg hole_birth extensible_dataset embedded_data bookmarks