Episode Details

Back to Episodes
143: One small step for DRM, one giant leap for BSD

143: One small step for DRM, one giant leap for BSD

Published 9 years, 10 months ago
Description

This week on BSDNow, we have an interview with Matthew Macy, who has some exciting news to share with us regarding the state of graphics

This episode was brought to you by

iXsystems - Enterprise Servers and Storage for Open SourceDigitalOcean - Simple Cloud Hosting, Built for DevelopersTarsnap - Online Backups for the Truly Paranoid


Headlines

How the number of states affects pf’s performance of FreeBSD

  • Our friend Olivier of FreeNAS and BSDRP fame has an interesting blog post this week detailing his unique issue with finding a firewall that can handle upwards of 4 million state table entries.
  • He begins in the article with benchmarking the defaults, since without that we don’t have a framework to compare the later results. All done on his Netgate RCC-VE 4860 (4 cores ATOM C2558, 8GB RAM) under FreeBSD 10.3.
  • “We notice a little performance impact when we reach the default 10K state table limit: From 413Kpps with 128 states in-used, it lower to 372Kpps.”
  • With the initial benchmarks done and graphed, he then starts the tuning process by adjusting the “net.pf.states_hashsize”sysctl, and then playing with the number of states for the firewall to keep.
  • “For the next bench, the number of flow will be fixed for generating 9800 pf state entries, but I will try different value of pf.states_hashsize until the maximum allowed on my 8GB RAM server (still with the default max states of 10k):”
  • Then he cranks it up to 4 million states
  • “There is only 12% performance penalty between pf 128 pf states and 4 million pf states.”
  • “With 10M state, pf performance lower to 362Kpps: Still only 12% lower performance than with only 128 states”
  • He then looks at what this does of pfsync, the protocol to sync the state table between two redundant pf firewalls
  • Conclusions:

There need to be a linear relationship between the pf hard-limit of states and the pf.states_hashsize; RAM needed for pf.states_hashsize = pf.states_hashsize * 80 Byte and pf.states_hashsize should be a power of 2 (from the manual page); Even small hardware can manage large number of sessions (it's a matter of RAM), but under too lot's of pressure pfsync will suffer.


Introducing the BCHS Stack = BSD, C, httpd, SQLite

  • Pronounced Beaches
  • “It's a hipster-free, open source software stack for web applications”
  • “Don't just write C. Write portable and secure C.”
  • “Get to know your security tools. OpenBSD has systrace(4) and pledge(2). FreeBSD has capsicum(4).”
  • “Statically scan your binary with LLVM” and “Run your application under valgrind”
  • “Don't forget: BSD is a community of professionals. Go to conferences (EuroBSDCon, AsiaBSDCon, BSDCan, etc.)”
  • This seems like a really interesting project, we’ll have to get Kristaps Dzonsons back on the show to talk about it ***

Installing OpenBSD's httpd server, MariaDB, PHP 5.6 on OpenBSD 5.9

  • Looking to deploy your next web-stack on OpenBSD 5.9? If so this next article from rootbsd.net is for you.
  • Specifically it will walk you through the process of getting OpenBSD’s own httpd server up and running, followed by MariaDB and PHP 5.6.
  • Most of the setup is pretty straight-forward, the httpd syntax may be different to
Listen Now

Love PodBriefly?

If you like Podbriefly.com, please consider donating to support the ongoing development.

Support Us