NOTES

This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon

Host Introductions - Jason Tubnor - https://www.tubsta.com / @tubsta / @Tubsta@soc.feditime.com

Headlines

Understanding ZFS vdev Types

Don't abuse su for dropping user privileges

News Roundup

Dynamic Tracing on OpenBSD 7.3

new Libressl

Manual Jails on FreeBSD 12

Tarsnap

• This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

Feedback/Questions

• Chris - questions
• Dan - zfs questions
• Pablo - Jail question

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

NOTES
This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon

Headlines

FreeBSD 13.2 Release Announcement

Using DTrace to find block sizes of ZFS, NFS, and iSCSI

News Roundup

Midnight BSD 3.0.1

Closing a stale SSH connection

How to automatically add identity to the SSH authentication agent

Tarsnap

• This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

Feedback/Questions

• Dan - ZFS question
• Matt - Thanks

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

NOTES
This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon

Headlines

Nextcloud + OpenBSD = <3

FreeBSD History Series - Understanding the Origins of DTrace

News Roundup

Bastille Templates for FreeBSD Jails

Initial support for guided disk encryption in the installer

Dynamic host configuration, please

BSDCan 2023 Tutorial: OpenBSD Storage Management

Jan/Feb 2023 Column Out in the FreeBSD Journal

loader: Add support for booting from a ZFS snapshot

Tarsnap

This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

NOTES
This episode of BSDNow is brought to you by Tarsnap

Headlines

DTrace Network Probes

Unix Shell Programming: The Next 50 Years

News Roundup

NetBSD on the Vortex86DX CPU

System CPU time – ‘sys’ time in top

rpg-cli —your filesystem as a dungeon!

Diving into toolchains

Tarsnap

• This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

Feedback/Questions

• [Alfred - Advice](https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/409/feedback/Alfred%20-%20Advice)
• [CY - Portable Patch Util](https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/409/feedback/CY%20-%20Portable%20Patch%20Util)
• [Denis - State of ZFS Ecosystem](https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/409/feedback/Denis%20-%20State%20of%20ZFS%20Ecosystem)

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

Headlines

36+ year old bug in FFS/UFS discovered and patched

This update eliminates a kernel stack disclosure bug in UFS/FFS directory entries that is caused by uninitialized directory entry padding written to the disk.

• When the directory entry is written to disk, it is written as a full 32bit entry, and the unused bytes were not initialized, so could possibly contain sensitive data from the kernel stack It can be viewed by any user with read access to that directory. Up to 3 bytes of kernel stack are disclosed per file entry, depending on the the amount of padding the kernel needs to pad out the entry to a 32 bit boundary. The offset in the kernel stack that is disclosed is a function of the filename size. Furthermore, if the user can create files in a directory, this 3 byte window can be expanded 3 bytes at a time to a 254 byte window with 75% of the data in that window exposed. The additional exposure is done by removing the entry, creating a new entry with a 4-byte longer name, extracting 3 more bytes by reading the directory, and repeating until a 252 byte name is created. This exploit works in part because the area of the kernel stack that is being disclosed is in an area that typically doesn't change that often (perhaps a few times a second on a lightly loaded system), and these file creates and unlinks themselves don't overwrite the area of kernel stack being disclosed. It appears that this bug originated with the creation of the Fast File System in 4.1b-BSD (Circa 1982, more than 36 years ago!), and is likely present in every Unix or Unix-like system that uses UFS/FFS. Amazingly, nobody noticed until now. This update also adds the -z flag to fsck_ffs to have it scrub the leaked information in the name padding of existing directories. It only needs to be run once on each UFS/FFS filesystem after a patched kernel is installed and running. Submitted by: David G. Lawrence dg@dglawrence.com
• So a patched kernel will no longer leak this data, and running the fsck_ffs -z command will erase any leaked data that may exist on your system
• OpenBSD commit with additional detail on mitigations The impact on OpenBSD is very limited: 1 - such stack bytes can be found in raw-device reads, from group operator. If you can read the raw disks you can undertake other more powerful actions. 2 - read(2) upon directory fd was disabled July 1997 because I didn't like how grep * would display garbage and mess up the tty, and applying vis(3) for just directory reads seemed silly. read(2) was changed to return 0 (EOF). Sep 2016 this was further changed to EISDIR, so you still cannot see the bad bytes. 3 - In 2013 when guenther adapted the getdents(2) directory-reading system call to 64-bit ino_t, the userland data format changed to 8-byte-alignment, making it incompatible with the 4-byte-alignment UFS on-disk format. As a result of code refactoring the bad bytes were not copied to userland. Bad bytes will remain in old directories on old filesystems, but nothing makes those bytes user visible. There will be no errata or syspatch issued. I urge other systems which do expose the information to userland to issue errata quickly, since this is a 254 byte infoleak of the stack which is great for ROP-chain building to attack some other bug. Especially if the kernel has no layout/link-order randomization ...

---

NomadBSD, a BSD for the Road

As regular It’s FOSS readers should know, I like diving into the world of BSDs. Recently, I came across an interesting BSD that is designed to live on a thumb drive. Let’s take a look at NomadBSD. NomadBSD is different than most available BSDs. NomadBSD is a live system based on FreeBSD. It comes with automatic hardware detection and an initial config tool. NomadBSD is designed to “be used as a desktop system that works out of the box, but can also be used for data recovery, for educational purposes, or to test FreeBSD’s hardware compatibility.” This German BSD comes with an OpenBox-based desktop with the Plank application dock. NomadBSD makes use of the DSB project. DSB stands for “Desktop Suite (for) (Free)BSD” and consists of a collection of programs designed to create a simple and working environment without needing a ton of dependencies to use one tool. DSB is created by Marcel Kaiser one of the lead devs of NomadBSD. Just like the original BSD projects, you can contact the NomadBSD developers via a mailing list.

• Version 1.2 Released

NomadBSD recently released version 1.2 on April 21, 2019. This means that NomadBSD is now based on FreeBSD 12.0-p3. TRIM is now enabled by default. One of the biggest changes is that the initial command-line setup was replaced with a Qt graphical interface. They also added a Qt5 tool to install NomadBSD to your hard drive. A number of fixes were included to improve graphics support. They also added support for creating 32-bit images.

• Thoughts on NomadBSD

I first discovered NomadBSD back in January when they released 1.2-RC1. At the time, I had been unable to install Project Trident on my laptop and was very frustrated with BSDs. I downloaded NomadBSD and tried it out. I initially ran into issues reaching the desktop, but RC2 fixed that issue. However, I was unable to get on the internet, even though I had an Ethernet cable plugged in. Luckily, I found the wifi manager in the menu and was able to connect to my wifi. Overall, my experience with NomadBSD was pleasant. Once I figured out a few things, I was good to go. I hope that NomadBSD is the first of a new generation of BSDs that focus on mobility and ease of use. BSD has conquered the server world, it’s about time they figured out how to be more user-friendly.

---

News Roundup

[OpenBSD automatic

upgrade](https://www.tumfatig.net/20190426/openbsd-automatic-upgrade/)

OpenBSD 6.5 advertises for an installer improvement: rdsetroot(8) (a build-time tool) is now available for general use. Used in combination with autoinstall.8, it is now really easy to do automatic upgrades of your OpenBSD instances. I first manually upgraded my OpenBSD sandbox to 6.5. Once that was done, I could use the stock rdsetroot(8) tool. The plan is quite simple: write an unattended installation response file, insert it to a bsd.rd 6.5 installation image and reboot my other OpenBSD instances using that image.

• Extra notes

There must be a way to run onetime commands (in the manner of fw_update) to automatically run sysmerge and packages upgrades. As for now, I’d rather do it manually. This worked like a charm on two Synology KVM instances using a single sd0 disk, on my Thinkpad X260 using Encrypted root with Keydisk and on a Vultr instance using Encrypted root with passphrase. And BTW, the upgrade on the X260 used the (iwn0) wireless connection. I just read that florian@ has released the sysupgrade(8) utility which should be released with OpenBSD 6.6. That will make upgrades even easier! Until then, happy upgrading.

FreeBSD Dtrace ext2fs Support

• Which logs were replaced by dtrace-probes:

  • Misc printf's under DEBUG macro in the blocks allocation path.
  • Different on-disk structures validation errors, now the filesystem will silently return EIO's.
  • Misc checksum errors, same as above.

• The only debug macro, which was leaved is EXT2FSPRINTEXTENTS.

• It is impossible to replace it by dtrace-probes, because the additional logic is required to walk thru file extents.

• The user still be able to see mount errors in the dmesg in case of:

  • Filesystem features incompatibility.
  • Superblock checksum error.

Create a dedicated user for ssh tunneling only

I use ssh tunneling A LOT, for everything. Yesterday, I removed the public access of my IMAP server, it’s now only available through ssh tunneling to access the daemon listening on localhost. I have plenty of daemons listening only on localhost that I can only reach through a ssh tunnel. If you don’t want to bother with ssh and redirect ports you need, you can also make a VPN (using ssh, openvpn, iked, tinc…) between your system and your server. I tend to avoid setting up VPN for the current use case as it requires more work and more maintenance than running ssh server and a ssh client. The last change, for my IMAP server, added an issue. I want my phone to access the IMAP server but I don’t want to connect to my main account from my phone for security reasons. So, I need a dedicated user that will only be allowed to forward ports. This is done very easily on OpenBSD. The steps are: 1. generate ssh keys for the new user 2. add an user with no password 3. allow public key for port forwarding Obviously, you must allow users (or only this one) to make port forwarding in your sshd_config.

---

That was easy. Some info on upgrading VMM VMs to 6.5

We're running dedicated vmm(4)/vmd(8) servers to host opinionated VMs. OpenBSD 6.5 is released! There are two ways you can upgrade your VM. Either do a manual upgrade or leverage autoinstall(8). You can take care of it via the console with vmctl(8).

• Upgrade yourself

To get connected to the console you need to have access to the host your VM is running on. The same username and public SSH key, as provided for the VM, are used to create a local user on the host. When this is done you can use vmctl(8) to manage your VM. The options you have are:

```$ vmctl start id [-c]```

$ vmctl stop id [-fw]```

```-w Wait until the VM has been terminated.```

-c Automatically connect to the VM console.```

• See the Article for the rest of the guide

Beastie Bits

• powerpc64 architecture support in FreeBSD ports
• GhostBSD 19.04 overview
• HardenedBSD will have two user selectable ASLR implementations
• NYCBUG 2016 Talk Shell-Fu Uploaded
• What is ZIL anyway?

Feedback/Questions

• Quentin - Organize an Ada/BSD interview
• DJ - Update
• Patrick - Bhyve frontends
• A small programming note: After BSDNow episode 300, the podcast will switch to audio-only, using a new higher quality recording and production system. The live stream will likely still include video.

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

##Headlines
###ZFS and DTrace update lands in NetBSD

merge a new version of the CDDL dtrace and ZFS code. This changes the upstream vendor from OpenSolaris to FreeBSD, and this version is based on FreeBSD svn r315983.

• r315983 is from March 2017 (14 months ago), so there is still more work to do

in addition to the 10 years of improvements from upstream, this version also has these NetBSD-specific enhancements:

• dtrace FBT probes can now be placed in kernel modules.
• ZFS now supports mmap().

• This brings NetBSD 10 years forward, and they should be able to catch the rest of the way up fairly quickly

###NetBSD network stack security audit

• Maxime Villard has been working on an audit of the NetBSD network stack, a project sponsored by The NetBSD Foundation, which has served all users of BSD-derived operating systems.

Over the last five months, hundreds of patches were committed to the source tree as a result of this work. Dozens of bugs were fixed, among which a good number of actual, remotely-triggerable vulnerabilities.

Changes were made to strengthen the networking subsystems and improve code quality: reinforce the mbuf API, add many KASSERTs to enforce assumptions, simplify packet handling, and verify compliance with RFCs. This was done in several layers of the NetBSD kernel, from device drivers to L4 handlers.
In the course of investigating several bugs discovered in NetBSD, I happened to look at the network stacks of other operating systems, to see whether they had already fixed the issues, and if so how. Needless to say, I found bugs there too.

• A lot of code is shared between the BSDs, so it is especially helpful when one finds a bug, to check the other BSDs and share the fix.

The IPv6 Buffer Overflow: The overflow allowed an attacker to write one byte of packet-controlled data into ‘packet_storage+off’, where ‘off’ could be approximately controlled too. This allowed at least a pretty bad remote DoS/Crash
The IPsec Infinite Loop: When receiving an IPv6-AH packet, the IPsec entry point was not correctly computing the length of the IPv6 suboptions, and this, before authentication. As a result, a specially-crafted IPv6 packet could trigger an infinite loop in the kernel (making it unresponsive). In addition this flaw allowed a limited buffer overflow - where the data being written was however not controllable by the attacker.
The IPPROTO Typo: While looking at the IPv6 Multicast code, I stumbled across a pretty simple yet pretty bad mistake: at one point the Pim6 entry point would return IPPROTO_NONE instead of IPPROTO_DONE. Returning IPPROTO_NONE was entirely wrong: it caused the kernel to keep iterating on the IPv6 packet chain, while the packet storage was already freed.
The PF Signedness Bug: A bug was found in NetBSD’s implementation of the PF firewall, that did not affect the other BSDs. In the initial PF code a particular macro was used as an alias to a number. This macro formed a signed integer. NetBSD replaced the macro with a sizeof(), which returns an unsigned result.
The NPF Integer Overflow: An integer overflow could be triggered in NPF, when parsing an IPv6 packet with large options. This could cause NPF to look for the L4 payload at the wrong offset within the packet, and it allowed an attacker to bypass any L4 filtering rule on IPv6.
The IPsec Fragment Attack: I noticed some time ago that when reassembling fragments (in either IPv4 or IPv6), the kernel was not removing the M_PKTHDR flag on the secondary mbufs in mbuf chains. This flag is supposed to indicate that a given mbuf is the head of the chain it forms; having the flag on secondary mbufs was suspicious.
What Now: Not all protocols and layers of the network stack were verified, because of time constraints, and also because of unexpected events: the recent x86 CPU bugs, which I was the only one able to fix promptly. A todo list will be left when the project end date is reached, for someone else to pick up. Me perhaps, later this year? We’ll see.
This security audit of NetBSD’s network stack is sponsored by The NetBSD Foundation, and serves all users of BSD-derived operating systems. The NetBSD Foundation is a non-profit organization, and welcomes any donations that help continue funding projects of this kind.

DigitalOcean

###MySQL on ZFS Performance

I used sysbench to create a table of 10M rows and then, using export/import tablespace, I copied it 329 times. I ended up with 330 tables for a total size of about 850GB. The dataset generated by sysbench is not very compressible, so I used lz4 compression in ZFS. For the other ZFS settings, I used what can be found in my earlier ZFS posts but with the ARC size limited to 1GB. I then used that plain configuration for the first benchmarks. Here are the results with the sysbench point-select benchmark, a uniform distribution and eight threads. The InnoDB buffer pool was set to 2.5GB.
In both cases, the load is IO bound. The disk is doing exactly the allowed 3000 IOPS. The above graph appears to be a clear demonstration that XFS is much faster than ZFS, right? But is that really the case? The way the dataset has been created is extremely favorable to XFS since there is absolutely no file fragmentation. Once you have all the files opened, a read IOP is just a single fseek call to an offset and ZFS doesn’t need to access any intermediate inode. The above result is about as fair as saying MyISAM is faster than InnoDB based only on table scan performance results of unfragmented tables and default configuration. ZFS is much less affected by the file level fragmentation, especially for point access type.

ZFS stores the files in B-trees in a very similar fashion as InnoDB stores data. To access a piece of data in a B-tree, you need to access the top level page (often called root node) and then one block per level down to a leaf-node containing the data. With no cache, to read something from a three levels B-tree thus requires 3 IOPS.

The extra IOPS performed by ZFS are needed to access those internal blocks in the B-trees of the files. These internal blocks are labeled as metadata. Essentially, in the above benchmark, the ARC is too small to contain all the internal blocks of the table files’ B-trees. If we continue the comparison with InnoDB, it would be like running with a buffer pool too small to contain the non-leaf pages. The test dataset I used has about 600MB of non-leaf pages, about 0.1% of the total size, which was well cached by the 3GB buffer pool. So only one InnoDB page, a leaf page, needed to be read per point-select statement.

To correctly set the ARC size to cache the metadata, you have two choices. First, you can guess values for the ARC size and experiment. Second, you can try to evaluate it by looking at the ZFS internal data. Let’s review these two approaches.

You’ll read/hear often the ratio 1GB of ARC for 1TB of data, which is about the same 0.1% ratio as for InnoDB. I wrote about that ratio a few times, having nothing better to propose. Actually, I found it depends a lot on the recordsize used. The 0.1% ratio implies a ZFS recordsize of 128KB. A ZFS filesystem with a recordsize of 128KB will use much less metadata than another one using a recordsize of 16KB because it has 8x fewer leaf pages. Fewer leaf pages require less B-tree internal nodes, hence less metadata. A filesystem with a recordsize of 128KB is excellent for sequential access as it maximizes compression and reduces the IOPS but it is poor for small random access operations like the ones MySQL/InnoDB does.

• In order to improve ZFS performance, I had 3 options:
• Increase the ARC size to 7GB
• Use a larger Innodb page size like 64KB
• Add a L2ARC

I was reluctant to grow the ARC to 7GB, which was nearly half the overall system memory. At best, the ZFS performance would only match XFS. A larger InnoDB page size would increase the CPU load for decompression on an instance with only two vCPUs; not great either. The last option, the L2ARC, was the most promising.

ZFS is much more complex than XFS and EXT4 but, that also means it has more tunables/options. I used a simplistic setup and an unfair benchmark which initially led to poor ZFS results. With the same benchmark, very favorable to XFS, I added a ZFS L2ARC and that completely reversed the situation, more than tripling the ZFS results, now 66% above XFS.

• Conclusion

We have seen in this post why the general perception is that ZFS under-performs compared to XFS or EXT4. The presence of B-trees for the files has a big impact on the amount of metadata ZFS needs to handle, especially when the recordsize is small. The metadata consists mostly of the non-leaf pages (or internal nodes) of the B-trees. When properly cached, the performance of ZFS is excellent. ZFS allows you to optimize the use of EBS volumes, both in term of IOPS and size when the instance has fast ephemeral storage devices. Using the ephemeral device of an i3.large instance for the ZFS L2ARC, ZFS outperformed XFS by 66%.

###OpenSMTPD new config

TL;DR:
OpenBSD #p2k18 hackathon took place at Epitech in Nantes.
I was organizing the hackathon but managed to make progress on OpenSMTPD.
As mentioned at EuroBSDCon the one-line per rule config format was a design error.
A new configuration grammar is almost ready and the underlying structures are simplified.
Refactor removes ~750 lines of code and solves _many_ issues that were side-effects of the design error.
New features are going to be unlocked thanks to this.

• Anatomy of a design error

OpenSMTPD started ten years ago out of dissatisfaction with other solutions, mainly because I considered them way too complex for me not to get things wrong from time to time.
The initial configuration format was very different, I was inspired by pyr@’s hoststated, which eventually became relayd, and designed my configuration format with blocks enclosed by brackets.
When I first showed OpenSMTPD to pyr@, he convinced me that PF-like one-line rules would be awesome, and it was awesome indeed.
It helped us maintain our goal of simple configuration files, it helped fight feature creeping, it helped us gain popularity and become a relevant MTA, it helped us get where we are now 10 years later.
That being said, I believe this was a design error. A design error that could not have been predicted until we hit the wall to understand WHY this was an error. One-line rules are semantically wrong, they are SMTP wrong, they are wrong.
One-line rules are making the entire daemon more complex, preventing some features from being implemented, making others more complex than they should be, they no longer serve our goals.
To get to the point: we should move to two-line rules :-)

Anatomy of a design error
OpenSMTPD started ten years ago out of dissatisfaction with other solutions, mainly because I considered them way too complex for me not to get things wrong from time to time.

The initial configuration format was very different, I was inspired by pyr@’s hoststated, which eventually became relayd, and designed my configuration format with blocks enclosed by brackets.

When I first showed OpenSMTPD to pyr@, he convinced me that PF-like one-line rules would be awesome, and it was awesome indeed.

It helped us maintain our goal of simple configuration files, it helped fight feature creeping, it helped us gain popularity and become a relevant MTA, it helped us get where we are now 10 years later.

That being said, I believe this was a design error. A design error that could not have been predicted until we hit the wall to understand WHY this was an error. One-line rules are semantically wrong, they are SMTP wrong, they are wrong.

One-line rules are making the entire daemon more complex, preventing some features from being implemented, making others more complex than they should be, they no longer serve our goals.

To get to the point: we should move to two-line rules :-)

• The problem with one-line rules

OpenSMTPD decides to accept or reject messages based on one-line rules such as:

accept from any for domain poolp.org deliver to mbox

Which can essentially be split into three units:

• the decision: accept/reject
• the matching: from any for domain poolp.org
• the (default) action: deliver to mbox

To ensure that we meet the requirements of the transactions, the matching must be performed during the SMTP transaction before we take a decision for the recipient.
Given that the rule is atomic, that it doesn’t have an identifier and that the action is part of it, the two only ways to make sure we can remember the action to take later on at delivery time is to either:

• save the action in the envelope, which is what we do today
• evaluate the envelope again at delivery
• And this this where it gets tricky… both solutions are NOT ok.

The first solution, which we’ve been using for a decade, was to save the action within the envelope and kind of carve it in stone. This works fine… however it comes with the downsides that errors fixed in configuration files can’t be caught up by envelopes, that delivery action must be validated way ahead of time during the SMTP transaction which is much trickier, that the parsing of delivery methods takes place as the _smtpd user rather than the recipient user, and that envelope structures that are passed all over OpenSMTPD carry delivery-time informations, and more, and more, and more. The code becomes more complex in general, less safe in some particular places, and some areas are nightmarish to deal with because they have to deal with completely unrelated code that can’t be dealt with later in the code path.

The second solution can’t be done. An envelope may be the result of nested rules, for example an external client, hitting an alias, hitting a user with a .forward file resolving to a user. An envelope on disk may no longer match any rule or it may match a completely different rule If we could ensure that it matched the same rule, evaluating the ruleset may spawn new envelopes which would violate the transaction. Trying to imagine how we could work around this leads to more and more and more RFC violations, incoherent states, duplicate mails, etc…

There is simply no way to deal with this with atomic rules, the matching and the action must be two separate units that are evaluated at two different times, failure to do so will necessarily imply that you’re either using our first solution and all its downsides, or that you are currently in a world of pain trying to figure out why everything is burning around you. The minute the action is written to an on-disk envelope, you have failed.

A proper ruleset must define a set of matching patterns resolving to an action identifier that is carved in stone, AND a set of named action set that is resolved dynamically at delivery time.

• Follow the link above to see the rest of the article

Break

##News Roundup
###Backing up a legacy Windows machine to a FreeNAS with rsync

I have some old Windows servers (10 years and counting) and I have been using rsync to back them up to my FreeNAS box. It has been working great for me.

First of all, I do have my Windows servers backup in virtualized format. However, those are only one-time snapshops that I run once in a while. These are classic ASP IIS web servers that I can easily put up on a new VM. However, many of these legacy servers generate gigabytes of data a day in their repositories. Running VM conversion daily is not ideal.

My solution was to use some sort of rsync solution just for the data repos. I’ve tried some applications that didn’t work too well with Samba shares and these old servers have slow I/O. Copying files to external sata or usb drive was not ideal. We’ve moved on from Windows to Linux and do not have any Windows file servers of capacity to provide network backups. Hence, I decided to use Delta Copy with FreeNAS. So here is a little write up on how to set it up. I have 4 Windows 2000 servers backing up daily with this method.

First, download Delta Copy and install it. It is open-source and pretty much free. It is basically a wrapper for cygwin’s rsync. When you install it, it will ask you to install the Server services which allows you to run it as a Rsync server on Windows. You don’t need to do this. Instead, you will be just using the Delta Copy Client application. But before we do that, we will need to configure our Rsync service for our Windows Clients on FreeNAS.

• In FreeNAS, go under Services , Select Rsync > Rsync Modules > Add Rsync Module.
• Then fill out the form; giving the module a name and set the path. In my example, I simply called it WIN and linked it to a user called backupuser.
• This process is much easier than trying to configure the daemon rsyncd.conf file by hand.
• Now, on the Windows Client, start the DeltaCopy Client. You will create a new Profile.
• You will need to enter the IP of the Rsync server (FreeNAS) and specify the module name which will be called “Virtual Directory Name.” When you pull the select menu, the list of Rsync Modules you created earlier in FreeNAS will populate.
• You can set authentication. On the server, you can restrict by IP and do other things to lock down your rsync.
• Next, you will add folders (and/or files) you want to synchronize.
• Once the paths are set up, you can run a sync by right clicking the profile name.
• Here, I made a test sync to a home folder of a virtualized windows box. As you can see, I mounted the rsync volume on my mac to see the progress. The rsync worked beautifully. DeltaCopy did what it was told.
• Once you get everything working. The next thing to do is set schedules. If you done tasks schedules in Windows before, it is pretty straightforward. DeltaCopy has a link in the application to directly create a new task for you. I set my backups to run nightly and it has been working great.

There you have it. Windows rsync to FreeNAS using DeltaCopy.
The nice thing about FreeNAS is you don’t have to modify /etc/rsyncd.conf files. Everything can be done in the web admin.

iXsystems

###How to write ATF tests for NetBSD

I have recently started contributing to the amazing NetBSD foundation. I was thinking of trying out a new OS for a long time. Switching to the NetBSD OS has been a fun change.

My first contribution to the NetBSD foundation was adding regression tests for the Address Sanitizer (ASan) in the Automated Testing Framework(ATF) which NetBSD has. I managed to complete it with the help of my really amazing mentor Kamil. This post is gonna be about the ATF framework that NetBSD has and how to you can add multiple tests with ease.

• Intro

In ATF tests we will basically be talking about test programs which are a suite of test cases for a specific application or program.

• The ATF suite of Commands

There are a variety of commands that the atf suite offers. These include :

• atf-check: The versatile command that is a vital part of the checking process. man page

• atf-run: Command used to run a test program. man page

• atf-fail: Report failure of a test case.

• atf-report: used to pretty print the atf-run. man page

• atf-set: To set atf test conditions.

• We will be taking a better look at the syntax and usage later.

• Let’s start with the Basics

The ATF testing framework comes preinstalled with a default NetBSD installation. It is used to write tests for various applications and commands in NetBSD. One can write the Test programs in either the C language or in shell script. In this post I will be dealing with the Bash part.

• Follow the link above to see the rest of the article

###The Importance of ZFS Block Size

• Warning! WARNING! Don’t just do things because some random blog says so

One of the important tunables in ZFS is the recordsize (for normal datasets) and volblocksize (for zvols). These default to 128KB and 8KB respectively.
As I understand it, this is the unit of work in ZFS. If you modify one byte in a large file with the default 128KB record size, it causes the whole 128KB to be read in, one byte to be changed, and a new 128KB block to be written out.
As a result, the official recommendation is to use a block size which aligns with the underlying workload: so for example if you are using a database which reads and writes 16KB chunks then you should use a 16KB block size, and if you are running VMs containing an ext4 filesystem, which uses a 4KB block size, you should set a 4KB block size
You can see it has a 16GB total file size, of which 8.5G has been touched and consumes space - that is, it’s a “sparse” file. The used space is also visible by looking at the zfs filesystem which this file resides in
Then I tried to copy the image file whilst maintaining its “sparseness”, that is, only touching the blocks of the zvol which needed to be touched. The original used only 8.42G, but the copy uses 14.6GB - almost the entire 16GB has been touched! What’s gone wrong?
I finally realised that the difference between the zfs filesystem and the zvol is the block size. I recreated the zvol with a 128K block size
That’s better. The disk usage of the zvol is now exactly the same as for the sparse file in the filesystem dataset

• It does impact the read speed too. 4K blocks took 5:52, and 128K blocks took 3:20
• Part of this is the amount of metadata that has to be read, see the MySQL benchmarks from earlier in the show
• And yes, using a larger block size will increase the compression efficiency, since the compressor has more redundant data to optimize.
• Some of the savings, and the speedup is because a lot less metadata had to be written
• Your zpool layout also plays a big role, if you use 4Kn disks, and RAID-Z2, using a volblocksize of 8k will actually result in a large amount of wasted space because of RAID-Z padding. Although, if you enable compression, your 8k records may compress to only 4k, and then all the numbers change again.

###Using a Raspberry Pi 2 as a Router on a Stick Starring NetBSD

• Sorry we didn’t answer you quickly enough

A few weeks ago I set about upgrading my feeble networking skills by playing around with a Cisco 2970 switch. I set up a couple of VLANs and found the urge to set up a router to route between them. The 2970 isn’t a modern layer 3 switch so what am I to do?

Why not make use of the Raspberry Pi 2 that I’ve never used and put it to some good use as a ‘router on a stick’.

I could install a Linux based OS as I am quite familiar with it but where’s the fun in that? In my home lab I use SmartOS which by the way is a shit hot hypervisor but as far as I know there aren’t any Illumos distributions for the Raspberry Pi. On the desktop I use Solus OS which is by far the slickest Linux based OS that I’ve had the pleasure to use but Solus’ focus is purely desktop. It’s looking like BSD then!

I believe FreeBSD is renowned for it’s top notch networking stack and so I wrote to the BSDNow show on Jupiter Broadcasting for some help but it seems that the FreeBSD chaps from the show are off on a jolly to some BSD conference or another(love the show by the way).

It looks like me and the luvverly NetBSD are on a date this Saturday. I’ve always had a secret love for NetBSD. She’s a beautiful, charming and promiscuous lover(looking at the supported architectures) and I just can’t stop going back to her despite her misgivings(ahem, zfs). Just my type of grrrl!

Let’s crack on…

• Follow the link above to see the rest of the article

##Beastie Bits

• BSD Jobs
• University of Aberdeen’s Internet Transport Research Group is hiring
• VR demo on OpenBSD via OpenHMD with OSVR HDK2
• patch runs ed, and ed can run anything (mentions FreeBSD and OpenBSD)
• Alacritty (OpenGL-powered terminal emulator) now supports OpenBSD
• MAP_STACK Stack Register Checking Committed to -current
• EuroBSDCon CfP till June 17, 2018

Tarsnap

##Feedback/Questions

• NeutronDaemon - Tutorial request
• Kurt - Question about transferability/bi-directionality of ZFS snapshots and send/receive
• Peter - A Question and much love for BSD Now
• Peter - netgraph state

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

This episode was brought to you by

Interview - Bryan Cantrill - bryan@joyent.com / @bcantrill

BSD and Solaris history, illumos, dtrace, Joyent, pkgsrc, various topics (and rants)

Feedback/Questions

• Randy writes in
• Jared writes in
• Steve writes in ***

This episode was brought to you by

Headlines

Even more BSD presentation videos

• More videos from this year's MeetBSD and OpenZFS devsummit were uploaded since last week
• Robert Ryan, At the Heart of the Digital Economy
• FreeNAS & ZFS, The Indestructible Duo - Except for the Hard Drives
• Richard Yao, libzfs_core and ioctl stabilization
• OpenZFS, Company lightning talks
• OpenZFS, Hackathon Presentation and Awards
• Pavel Zakharov, Fast File Cloning
• Rick Reed, Half a billion unsuspecting FreeBSD users
• Alex Reece & Matt Ahrens, Device Removal
• Chris Side, Channel Programs
• David Maxwell, The Unix command pipeline
• Be sure to check out the giant list of videos from last week's episode if you haven't seen them already ***

NetBSD on a Cobalt Qube 2

• The Cobalt Qube was a very expensive networking appliance around 2000
• In 2014, you can apparently get one of these MIPS-based machines for about forty bucks
• This blog post details getting NetBSD installed and set up on the rare relic of our networking past
• If you're an old-time fan of RISC or MIPS CPUs, this'll be a treat for you
• Lots of great pictures of the hardware too ***

OpenBSD vs. AFL

• In their never-ending security audit, some OpenBSD developers have been hitting various parts of the tree with a fuzzer
• If you're not familiar, fuzzing is a semi-automated way to test programs for crashes and potential security problems
• The program being subjected to torture gets all sorts of random and invalid input, in the hopes of uncovering overflows and other bugs
• American Fuzzy Lop, in particular, has provided some interesting results across various open source projects recently
• So far, it's fixed some NULL pointer dereferences in OpenSSH, various crashes in tcpdump and mandoc and a few other things
• AFL has an impressive list of CVEs (vulnerabilities) that it's helped developers discover and fix
• It also made its way into OpenBSD ports, FreeBSD ports and NetBSD's pkgsrc very recently, so you can try it out for yourself ***

GNOME 3 hits the FreeBSD ports tree

• While you've been able to run GNOME 3 on PC-BSD and OpenBSD for a while, it hasn't actually hit the FreeBSD ports tree.. until now
• Now you can play with GNOME 3 and all its goodies (as well as Cinnamon 2.2, which this also brings in) on vanilla FreeBSD
• Be sure to check the commit message and /usr/ports/UPDATING if you're upgrading from GNOME 2
• You might also want to go back and listen to our interview with Joe Marcus Clark about GNOME's portability ***

Interview - Brendan Gregg - bgregg@netflix.com / @brendangregg

Performance tuning, benchmarks, debugging

News Roundup

DragonFlyBSD 4.0 released

• A new major version of DragonFly, 4.0.1, was just recently announced
• This version includes support for Haswell GPUs, lots of SMP improvements (including some in PF) and support for up to 256 CPUs
• It's also the first release to drop support for i386, so it joins PCBSD in the 64 bit-only club
• Check the release notes for all the details, including networking and kernel improvements, as well as some crypto changes ***

Can we talk about FreeBSD vs Linux

• Hackernews had a recent thread about discussing Linux vs BSD, and the trolls stayed away for once
• Rather than rehashing why one is "better" than the other, it was focused on explaining some of the differences between ecosystems and communities
• If you're one of the many people who watch our show just out of curiosity about the BSD world, this might be a good thread to read
• Someone in the comments even gave bsdnow.tv a mention as a good resource to learn, thanks guy ***

OpenBSD IPSEC tunnel guide

• If you've ever wanted to connect two networks with OpenBSD gateways, this is the article for you
• It shows how to set up an IPSEC tunnel between destinations, how to lock it down and how to access all the machines on the other network just like they were on your LAN
• The article also explains some of the basics of IPSEC if you're not familiar with all the terminology, so this isn't just for experts
• Though the article itself is a few years old, it mostly still applies to the latest stuff today
• All the tools used are in the OpenBSD base system, so that's pretty handy too ***

DragonFly starts work on IPFW2

• DragonFlyBSD, much like FreeBSD, comes with more than one firewall you can use
• Now it looks like you're going to have yet another choice, as someone is working on a fork of IPFW (which is actually already in its second version, so it should be "IPFW3")
• Not a whole lot is known yet; it's still in heavy development, but there's a brief roadmap page with some planned additions
• The guy who's working on this has already agreed to come on the show for an interview, but we're going to give him a chance to get some more work done first
• Expect that sometime next year, once he's made some progress ***

Feedback/Questions

• Michael writes in
• Samael writes in
• Steven writes in
• Remy writes in
• Michael writes in ***