Getting Pi on my Wifi

This week on BSDNow, we’ve got Wifi galore, a new iocage and some RPi3 news and guides to share. Stay tuned for your place to B...SD!

This episode was brought to you by

href="http://www.digitalocean.com/" title="DigitalOcean"> href="http://www.tarsnap.com/bsdnow" title="Tarsnap">

Headlines

WiFi: 11n hostap mode added to athn(4) driver, testers wanted

• “OpenBSD as WiFi access points look set to be making a comeback in the near future”
• “Stefan Sperling added 802.11n hostap mode, with full support initially for the Atheros chips supported by the athn(4) driver.”
• “Hostap performance is not perfect yet but should be no worse than 11a/b/g modes in the same environment.”
• “For Linux clients a fix for WME params is needed which I also posted to tech@”
• “This diff does not modify the known-broken and disabled ar9003 code, apart from making sure it still builds.”

• “I'm looking for both tests and OKs.”

• There has also been a flurry of work in FreeBSD on the ath10k driver, which supports 802.11ac

• Like this one and this one

  ---

The long-awaited iocage update has landed

• We’ve hinted at the new things happening behind the scenes with iocage, and this last week the code has made its first public debut.
• So what’s changed you may ask. The biggest is that iocage has undergone a complete overhaul, moving from its original shell-base to python.
  
• The story behind that is that the author (Brandon) works at iXsystems, and the plan is to move away from the legacy warden-based jail management which was also shell-based.
  
• This new python re-write will allow it to integrate into FreeNAS (and other projects) better by exposing an API for all jail management tasks. Thats right, no more ugly CLI output parsing just to wrangle jail options either at creation or runtime.
• But what about users who just run iocage manually from the CLI? No worries, the new iocage is almost identical to the original CLI usage, making the switch over very simple.
• Just to re-cap, lets look at the new features list:

“FEATURES:

• Ease of use
• Rapid jail creation within seconds
• Automatic package installation
• Virtual networking stacks (vnet)
• Shared IP based jails (non vnet)
• Transparent ZFS snapshot management
• Export and import “
• The new iocage is available now via ports and packages under sysutils/py-iocage, give it a spin and be sure to report issues back to the developer(s). ***

Reading DHT11 temperature sensors on a Raspberry Pi under FreeBSD

• “DHT-11 is a very cheap temperature/humidity sensor which is commonly used in the IoT devices. It is not very accurate, so for the accurate measurement i would recommend to use DHT21 instead. Anyway, i had DHT-11 in my tool box, so decided to start with it. DHT-11 using very simple 1 wire protocol – host is turning on chip by sending 18ms low signal to the data output and then reading 40 bytes of data.”
• “To read data from the chip it should be connected to the power (5v) and gpio pin. I used pin 2 as VCC, 6 as GND and 11 as GPIO”
• “There is no support for this device out of the box on FreeBSD. I found some sample code on the github, see lex/freebsd-gpio-dht11 repository. This code was a good starting point, but soon i found 2 issues with it:
  • Results are very unreliable, probably due to gpio decoding algorithm.
• Checksum is not validated, so sometime values are bogus.
• “Initially i was thinking to fix this myself, but later found kernel module for this purpose, 1 wire over gpio. This module contains DHT11 kernel driver (gpio_sw) which implements DHT-11 protocol in the kernel space and exporting /dev/sw0 for the userland. Driver compiles on FreeBSD11/ARM without any changes. Use make install to install the driver.”
• The articles goes into how to install and configure the driver, including a set of devfs rules to allow non-root users to read from the sensor
• “Final goal was to add this sensor to the domoticz software. It is using LUA scripting to extend it functionality, e.g. to obtain data from non-supported or non standard devices. So, i decided to read /dev/sw0 from the LUA.”
• They ran into some trouble with LUA trying to read too much data at once, and had to work around it
• In the end, they got the results and were able to use them in the monitoring tool ***

Tor-ified Home Network using HardenedBSD and a RPi3

• Shawn from HardendBSD has posted an article up on GitHub talking about his deployment of a new Tor relay on a RPi3
• This particular method was attractive, since it allows running a Relay, but without it being on a machine which may have personal data, such as SSH keys, files, etc
• While his setup is done on HardendBSD, the same applies to a traditional FreeBSD setup as well.
• First up, is the list of things needed for this project:

Raspberry Pi 3 Model B Rev 1.2 (aka, RPI3)
Serial console cable for the RPI3
Belkin F4U047 USB Ethernet Dongle
Insignia NS-CR2021 USB 2.0 SD/MMC Memory Card Reader
32GB SanDisk Ultra PLUS MicroSDHC
A separate system, running FreeBSD or HardenedBSD
HardenedBSD clang 4.0.0 image for the RPI3
An external drive to be formatted
A MicroUSB cable to power the RPI3
Two network cables
Optional: Edimax N150 EW-7811Un Wireless USB
Basic knowledge of vi

• After getting HBSD running on the RPi3 and serial connection established, he then takes us through the process of installing and enabling the various services needed. (Don’t forget to growfs your sdcard first!)
• Now the tricky part is that some of the packages needed to be compiled from ports, which is somewhat time-consuming on a RPi. He strongly recommends not compiling on the sdcard (it sounds like personal experience has taught him well) and to use iscsi or some external USB drive.
• With the compiling done, our package / software setup is nearly complete. Next up is firewalling the box, which he helpfully provides a full PF config setup that we can copy-n-paste here.
• The last bits will be enabling the torrc configuration knobs, which if you follow his example again, will result in a tor public relay, and a local transparent proxy for you.
• Bonus! Shawn helpfully provides DHCPD configurations, and even Wireless AP configurations, if you want to setup your RPi3 to proxy for devices that connect to it. ***

News Roundup

Unix Admin. Horror Story Summary, version 1.0

• A great collection of stories, many of which will ring true with our viewers
• The very first one, is about a user changing root’s shell to /usr/local/bin/tcsh but forgetting to make it executable, resulting in not being able to login as root.
• I too have run into this issue, in a slightly different way. I had tcsh as my user shell (back before tcsh was in base), and after a major OS upgrade, but before I had a chance to recompile all of my ports. Now I couldn’t ssh in to the remote machine in order to recompile my shell. Now I always use a shell included in the base system, and test it before rebooting after an upgrade.
• “Our operations group, a VMS group but trying to learn UNIX, was assigned account administration. They were cleaning up a few non-used accounts like they do on VMS - backup and purge. When they came across the account "sccs", which had never been accessed, away it went. The "deleteuser" utility from DEC asks if you would like to delete all the files in the account. Seems reasonable, huh? Well, the home directory for "sccs" is "/". Enough said :-(“
• “I was working on a line printer spooler, which lived in /etc. I wanted to remove it, and so issued the command "rm /etc/lpspl." There was only one problem. Out of habit, I typed "passwd" after "/etc/" and removed the password file. Oops.”
• I’ve done things like this as well. Finger memory can be dangerous
• “I was happily churning along developing something on a Sun workstation, and was getting a number of annoying permission denieds from trying to write into a directory heirarchy that I didn't own. Getting tired of that, I decided to set the permissions on that subtree to 777 while I was working, so I wouldn't have to worry about it. Someone had recently told me that rather than using plain "su", it was good to use "su -", but the implications had not yet sunk in. (You can probably see where this is going already, but I'll go to the bitter end.) Anyway, I cd'd to where I wanted to be, the top of my subtree, and did su -. Then I did chmod -R 777. I then started to wonder why it was taking so damn long when there were only about 45 files in 20 directories under where I (thought) I was. Well, needless to say, su - simulates a real login, and had put me into root's home directory, /, so I was proceeding to set file permissions for the whole system to wide open. I aborted it before it finished, realizing that something was wrong, but this took quite a while to straighten out.”
• Where is a ZFS snapshot when you need it? ***

How individual contributors get stuck

• An interesting post looking at the common causes of people getting stuck when trying to create or contribute new code
  • Brainstorming/architecture: “I must have thought through all edge cases of all parts of everything before I can begin this project”
  • Researching possible solutions forever (often accompanied by desire to do a “bakeoff” where they build prototypes in different platforms/languages/etc)
  • Refactoring: “this code could be cleaner and everything would be just so much easier if we cleaned this up… and this up… and…”
  • Helping other people instead of doing their assigned tasks (this one isn’t a bad thing in an open source community)
  • Working on side projects instead of the main project (it is your time, it is up to you how to spend it)
  • Excessive testing (rare)
  • Excessive automation (rare)
  • Finish the last 10–20% of a project
  • Start a project completely from scratch
  • Do project planning (You need me to write what now? A roadmap?) (this is why FreeBSD has devsummits, some things you just need to whiteboard)
  • Work with unfamiliar code/libraries/systems
  • Work with other teams (please don’t make me go sit with data engineering!!)
  • Talk to other people
  • Ask for help (far beyond the point they realized they were stuck and needed help)
  • Deal with surprises or unexpected setbacks
  • Deal with vendors/external partners
  • Say no, because they can’t seem to just say no (instead of saying no they just go into avoidance mode, or worse, always say yes)
• “Noticing how people get stuck is a super power, and one that many great tech leads (and yes, managers) rely on to get big things done. When you know how people get stuck, you can plan your projects to rely on people for their strengths and provide them help or even completely side-step their weaknesses. You know who is good to ask for which kinds of help, and who hates that particular challenge just as much as you do.”
• “The secret is that all of us get stuck and sidetracked sometimes. There’s actually nothing particularly “bad” about this. Knowing the ways that you get hung up is good because you can choose to either a) get over the fears that are sticking you (lack of knowledge, skills, or confidence), b) avoid such tasks as much as possible, and/or c) be aware of your habits and use extra diligence when faced with tackling these areas.” ***

Make Docs!

• “MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file.”
• “MkDocs builds completely static HTML sites that you can host on GitHub pages, Amazon S3, or anywhere else you choose”
• It is an easy to install python package
• It includes a server mode that auto-refreshes the page as you write the docs, making it easy to preview your work before you post it online
• Everything needs docs, and writing docs should be as simple as possible, so that more of them will get written
• Go write some docs! ***

Experimental FreeNAS 11/12 builds

• We know there’s a lot of FreeNAS users who listen to BSDNow, so I felt it was important to share this little tidbit.
• I’ve posted something to the forums last night which includes links to brand-new spins of FreeNAS 9.10 based upon FreeBSD 11/stable and 12/current.
• These builds are updated nightly via our Jenkins infrastructure and hopefully will provide a new playground for technical folks and developers to experiment with FreeBSD features in their FreeNAS environment, long before they make it into a -STABLE release.
• As usual, the notes of caution do apply, these are nightlies, and as such bugs will abound. Do NOT use these with your production data, unless you are crazy, or just want an excuse to test your backup strategy
• If you do run these builds, of course feedback is welcome via the usual channels, such as the bug tracker.
• The hope is that by testing FreeBSD code earlier, we can vet and determine what is safe / ready to go into mainline FreeNAS sooner rather than later. ***

Beastie Bits

• An Explainer on Unix’s Most Notorious Code Comment
• turn your network inside out with one pf.conf trick
• A story of if_get(9)
• Apple re-affirms its commitment to LLVM/Clang
• python 3k17
• 2017 presentation proposals
• NetBSD 7.1_RC1 available
• #define FS_UFS2_MAGIC 0x19540119 (Happy Birthday to Kirk McKusick tomorrow) ***

Feedback/Questions

• J - LetsEncrypt
• Mike - OpenRC
• Timothy - ZFS Horror
• Troels
• Jason - Disk Label ***