SSL catch-22 on using custom FreeBSD package repository

Found myself in a Catch-22 situation. Since our package server is using SSL certicates by Let’s Encrypt which are not trusted by default in FreeBSD base system, causing error:

# pkg install vim-console
Updating custom repository catalogue…

Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

34404218008:error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/s3_clnt.c:1269:
...
Unable to update repository custom

Error updating repositories!

Normally the solution would be to install security/ca_root_nns. How-ever this fails since certificate cannot be trusted. To overwrite temporary disable the SSL validation ones to ensure the package get installed:

# env SSL_NO_VERIFY_PEER=1 pkg install ca_root_nss

One last remark; make sure the connection itself is not tampered while installing this package. Since you briefly expose a vector of attack, due to the disabling of the SSL verification. To circumvent this; 1) manually download the package 2) scp the package and 3) install it.

Resize VirtualBox (virtual) hard-disk at Ubuntu guest

My virtual filesystem used by my Ubuntu guest, required for building OpenEmbedded and OpenWRT was in need of some extra disk space. This sequence of commands will ensure the virtual hard-disk will be resized from 50GB to 90GB.

This will first require to resize the virtual hard-disk. After this action the partition table will need to be altered to match the new size. Next the filesystem should be updated to match the newly created partition size.

NOTE OF WARNING: Mangling with partitions and filesystems on-the-fly is dangerous. Make sure to backup your files on your guest system if required.

#
# First and foremost ensure Virtual host has been shutdown. Not suspended!
#
# Find VM UUID
host$ VBoxManage list vms
"FreeBSD 10.3" {3f37f0e4-b783-4022-bd34-faf5fc569cda}
"FreeBSD 9.3" {cfe9d640-5bd4-469d-82c1-096d7402d56c}
"FreeBSD 9.0" {fbc06586-c021-48bd-86b2-ea8cafc915c7}
"FreeBSD 11.2" {379e670a-cac8-420f-88cf-68e0fac98ecd}
"u1804 (Ubuntu 18.04)" {73056625-55b6-49a9-8ddc-f6f851f784af}
"FreeBSD 12.0" {7f5c67c2-3740-4b51-8a21-b9e2355b8ae6}
#
# Find HD UUID to resize
host$ VBoxManage showvminfo 73056625-55b6-49a9-8ddc-f6f851f784af | grep SATA
Storage Controller Name (1):            SATA
SATA (0, 0): /home/rick/VirtualBox VMs/u1804 (Ubuntu 18.04)/Ubuntu 18.04.vdi (UUID: 8fcc5023-6ebe-4fcb-9908-d8e7689d6b3a)
#
# Resize disk to 90GB (92160MB)
host$ VBoxManage modifymedium disk 8fcc5023-6ebe-4fcb-9908-d8e7689d6b3a --resize 92160
 0%…10%…20%…30%…40%…50%…60%…70%…80%…90%…100%
# 
# <start VM and login via ssh/console>
#
# Verify current disk size
guest$ df -h /
/dev/sda2        49G   45G  1.9G  96% /
#
# Repartition drive with larger partition size
guest$ sudo parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 83886080 blocks) or continue with the current setting? 
Fix/Ignore? Fix                                                           
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 96.6GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2097kB  1049kB                     bios_grub
 2      2097kB  53.7GB  53.7GB  ext4

(parted) resizepart 2                                                     
Warning: Partition /dev/sda2 is being used. Are you sure you want to continue?
Yes/No? Yes
End?  [53.7GB]? 96.6GB                                                    
(parted) print                                                            
Model: ATA VBOX HARDDISK (scsi)
Disk /dev/sda: 96.6GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2097kB  1049kB                     bios_grub
 2      2097kB  96.6GB  96.6GB  ext4

(parted) quit
Information: You may need to update /etc/fstab.
#
# Regrow filesystem
guest$ sudo resize2fs /dev/sda2 
resize2fs 1.44.1 (24-Mar-2018)
Filesystem at /dev/sda2 is mounted on /; on-line resizing required
old_desc_blocks = 7, new_desc_blocks = 12
The filesystem on /dev/sda2 is now 23583472 (4k) blocks long.
#
# Check newly grown filesystem
guest$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        89G   45G   40G  53% /

Shining a Beacon for Science

Featured

The World Community Grid (WCG) has surpassed it’s 14th anniversary and asking to write a nice article about the good work they employ.

The World Community Grid has been a beacon for science to people who understand the need of continuing research since it was created in 2004. What started out as a relatively small, short-term proof of concept initiative has grown into a major source of computing power for 29 (and counting) humanitarian scientific research projects. So far, this has led to breakthrough discoveries for childhood cancerwater filtration, and renewable energy, as well as many smaller discoveries that may one day lead to future breakthroughs.

Working together for a better and more connected world is a noble cause and a great moment to bootstrap the blog postings again.

December is traditionally a month of giving back to good causes and since our servers are running on green renewable energy they have been configured to donate their spare CPU cycles to WCG. With the intention to continue support throughout the year.

You can find our statistics here. If one also has hardware running which could donate a few spare cycles of CPU or GPU power, feel free to check out their website.

Eclipse Launcher Icon

Voor het europese onderzoeksproject HoliDES waar wij in meedraaien in het domain van de healthcare, zijn we op een punt aangekomen om test implementaties te maken. Deze zijn onder andere gebaseerd op tools als OSLC. De Java referentie implementatie voor Eclipse Lyo vereist een goedwerkende Eclipse omgeving.

Omdat de laatste versie van de software (van source) geen Eclipse Launcher icoon aanmaakt in Fedora (or andere Linux variant zoals Ubuntu, RedHat of CentOS) is het starten onhandig. Dit is te verhelpen door deze te toe te voegen aan je systeem, door het volgende te copieren/plakken in je terminal.

cat <<EOF ~/.local/share/applications/eclipse.desktop
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Eclipse
Comment=Eclipse IDE Editor
Exec=/opt/eclipse/eclipse
Icon=/opt/eclipse/icon.xpm
Categories=Application;
EOF

Rondspringen in UNIX terminal

Als je aan meerdere projecten werkt, welke allemaal in verschillende directory’s bevinden dan is het handig om snelkoppelingen te hebben. Voeg onderstaande regels toe aan ~/.bashrc en je kan dmv scd en jcd respectievelijk een directory markeren of ernaar toe gaan. Uiteraard met “tab-completion” support.

function jcd {
cd `grep $1 ~/.jcd | awk '{print $2}'`
}

function scd {
( grep -v "^$1" ~/.jcd; echo $1 `pwd` ) > ~/.jcd.new
mv ~/.jcd.new ~/.jcd
}

function _listcd {
COMPREPLY=()
cur="${COMP_WORDS[COMP_CWORD]}"
opts=$(awk '{print $1}' ~/.jcd | grep "^$2")
COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
return 0
}

complete -F _listcd jcd
complete -F _listcd scd

Potentieel hoge kosten bij gebruik M2M SIMs met vast IP

We kregen vandjohnny_automatic_bag_of_moneyaag een case over een grote rekening op een M2M SIM met fixed IP te horen (van MCS). De case ging als volgt: Vanwege het feit dat een vast IP over het hele internet te bereiken is, is dit IP dus ook te bereiken door geautomatiseerde ‘bots’ die door de ‘duistere’ mensen van het internet gebruikt worden om te kijken welke systemen kwetsbaar zijn door aan verschillende poorten te gaan ‘kloppen’. In sommige gevallen sturen ze een DDOS (een berg informatie) naar het fixed IP van de M2M SIM. Omdat het verkeer door de mobiele provider afgeleverd wordt bij de SIM kaart zal je voor die verstookte MB’s dus moeten betalen.

Zonder actieve monitoring, filteren en/of limieten kan dit dus aardig in de papieren lopen. Met 6 cent per MB is 10GB verstookte data dus 600 EUR. En 10GB data is op een 10Mbit/s 3G verbinding in ongeveer 2,5 uur verstookt. Dat is dus ongeveer 5000 EUR per dag.

Er is een aantal manieren om dit te voorkomen:

a) gebruik maken van een ‘gewoon’ IP, dan wordt deze namelijk geNAT, waardoor er niet direct informatie naar de SIM gestuurd kan worden. Nadeel is dan wel dat je een (VPN) tunnel op moet bouwen voor remote onderhoud (wat een remote end-point kost) en de verbinding moet blijven onderhouden (wat data kost).

b) afspraken maken met de provider dat het fixed IP enkel maar vanaf een bepaald vooraf gedefineerd IP adres bereikt kan worden (de provider moet dan van te voren gaan filteren wat echter vaak niet mogelijk is).

c) gebruik maken van een private APN om zo je eigen ‘private network’ op te zetten, waarbij anderen geen toegang meer hebben tot jou systemen, en jijzelf alleen via een firewall/proxy het Internet op zou kunnen.

d) enkel de M2M aanzetten in het portal op het moment dat het nodig is en met een strakke limiet om zo (dikke) overshoot te voorkomen, met het risico van vergeten, of van opzettelijk niet, uit te zetten.

e) Contact opnemen met AnyWi zodat zij een passende oplossing voor uw uitdaging kunnen bedenken.

NB: De SigQ-router, welke geen fixed-IP SIM kaarten hebben, hebben hier uiteraard geen last van.

IPFW NAT and FWD combined

For the past year using (kernel) NAT together with FWD rules in ipfw has walked across my brain more often than I like to admit. But everytime I was not able to grab the concept sufficiently to get it right and make them work together. Finally today in the train, trying all sorts of combinations, pondering why it still did not work, I finally got it: If I cannot make the rules on the NAT and FWD match, I should match first, use skipto and then apply NAT and FWD to all traffic that passes in that block of firewall rules!

Example:

# NAT and forward both need to process the same packets
ipfw -q disable one_pass
ipfw -q -f flush
ipfw -q nat 123 config if em1
ipfw -q add skipto 1000 all from any to not 192.168.1.0/24
ipfw -q add skipto 65534 all from any to any
ipfw -q add 1000 nat 1 all from any to any
ipfw -q add 1100 fwd 192.168.178.1 all from any to any

where 192.168.178.1 is the gateway on em1. Now, this recipe is still missing the inbound NAT, performance considerations due to applying NAT multiple times on the packet, and probably much more, but the basic nut on how to format the ipfw ruleset has been cracked. The roost has left the nest. Policy Based Routing, here we come!

Note: after disabling ‘nat’ rules are no longer terminating the rule set, but ‘fwd’ rules are!

EuroBSDCon 2013

EuroBSDCon mascot

Smiling and helpful as usual, your BSD daemon

And there it was! All geeks unite! BSD lovers from all over Europe and the rest of the world gathered in Malta to discuss what was going on in the world of FreeBSD, NetBSD, and OpenBSD. The talks where better than ever (only 42 out of 75 submissions made it into the 3 tracks on 2 days).

Most impressive for me was the number of people using NanoBSD as a tool to provide their server, embedded systems, and node installations. But also in-depth discussions of fundamental issues like 64-bit time_t, security technologies, and performance enhancement). And of course the fun talks by the BSD veterans McKusick and phk. All in all a good BSDCOn. See you next year!

Raspberry Pi running FreeBSD

I received my Raspberry Pi, downloaded a torrent for FreeBSD Pi, and about 10 minutes later spent 1 hour zeroing, then backing up, then dumping the image onto a 8GB SD card. Spent another five minutes figuring out the power requirements (700mA over USB with a running ethernet connection, so an Apple iPhone USB power supply would do), powered it up, connected it to a network. Et voila!

root@fbsd-pi:~ # dmesg
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #0 r245446M: Tue Jan 15 12:53:26 SGT 2013
root@fbsd10:/usr/obj/arm.armv6/usr/src/sys/BSD-PI arm
CPU: ARM1176JZ-S rev 7 (ARM11J core)
Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext
WB enabled LABT branch prediction enabled
16KB/32B 4-way instruction cache
16KB/32B 4-way write-back-locking-C data cache
real memory  = 536870912 (512 MB)
avail memory = 451756032 (430 MB)
...

And this all based on open source hardware and software. Next step is to actually modify our NanoBSD environment to build images for this platform.

UPDATE: It looks like getting our stuff running on that platform is actually more work than expected, especially the cross compiling is going to be a challenge. So, back onto the Someday/Maybe pile…

Open Source advantage

Consider this bug report for iTerm2, a terminal program for Mac OS X, where it panic’s Mac OS. The bug has been around for a while. There is no way you can actually check with Apple whether this issue has been resolved, is being worked on, will be resolved when, etc. That bug report by now contains a possible fix based on the Open Source version of the OS. In an open source OS this would be a) fixed by now by someone having the problem, b) probably be included in a release that has already shipped, and c) if not included, patchable in your local system by yourself.

The advantage of closed source is obviously blame allocation: It is their fault because I, the paying customer, say so. However, that is not much help on a thursday evening when struggling to make automated updates of 450 NanoStation M2’s work, with a laptop that crashes every hour.