free and open-source display server for X Window System
POPULARITY
12 episodes with xorg
6 episodes with xorg
4 episodes with xorg
2 episodes with xorg
3 episodes with xorg
2 episodes with xorg
2 episodes with xorg
2 episodes with xorg
2 episodes with xorg
This show has been flagged as Clean by the host. Intro How I know BSD Very minimal NetBSD usage I'm am leaving out Dragonfly BSD Previous episodes Several by Claudio Miranda and others - check the tags page. hpr3799 :: My home router history hpr3187 :: Ansible for Dynamic Host Configuration Protocol hpr3168 :: FreeBSD Jails and iocage hpr2181 :: Install OpenBSD from Linux using Grub History and Overview https://en.wikipedia.org/wiki/History_of_the_Berkeley_Software_Distribution The history of the Berkeley Software Distribution began in the 1970s when University of California, Berkeley received a copy of Unix. Professors and students at the university began adding software to the operating system and released it as BSD to select universities. https://en.wikipedia.org/wiki/Comparison_of_BSD_operating_systems Comparisons to Linux Not better or worse, just different. BSD is a direct descendant of the original UNIX Not distributions - Separate projects with separate code bases. Permissive vs Copyleft One Project vs Kernel + User land Most Open Source software is available on BSD ports and packages Network Devices and DISKS will have different naming conventions. BE CAREFUL Distinctives FreeBSD Probably most widely used Base OS Commercial products Tightly integrated with ZFS Jails OS for Firewall appliances - PFSense and Opensense OpenBSD Focus on Code Correctness and Security Often First to develop new security methodologies - ASLR and Kernel relinking at boot Home of OpenSSH, ... Base includes Xorg and a minimal Window Manager The Best docs - man pages NetBSD Supports the most platforms pkgsrc can be used on any UNIX like. How I use BSD Home Router Recently migrated from FreeBSD to OpenBSD Better support for the cheap 2.5G network adapters in Ali express firewalls Workstations OpenBSD Dual boot laptop - missing some nice features - Vscode and BT audio OpenBSD for Banking NAS FreeBSD Was physical by migrated to Proxmox VM with direct attached drives Jails for some apps ZFS pools for storage My recommendations Router OpenBSD - Any BSD will work Opensense - similar experience to managing DD-WRT Thinkpads - OpenBSD Other laptops / PC - FreeBSD desktop focus derivative. ghost or midnight Servers/NAS FreeBSD ZFS Jails BSD is worth trying Dual booting is supported but can be tricky if unfamiliar. r Provide feedback on this episode.
I know. The Windows Blue Screen of Death is funny. I get it. But don't forget: Linux & macOS have seen some gnarly similar issues. Including some bugs that granted root access, completely broke graphical systems (like XOrg), and more. Funny Programming Pictures Part XLVIII - CrowdStrike BSOD Edition: https://lunduke.locals.com/post/5889816/funny-programming-pictures-part-xlviii Happy Blue Screen of Death Day! https://lunduke.locals.com/post/5889529/happy-blue-screen-of-death-day More from The Lunduke Journal: https://lunduke.com/ This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit lunduke.substack.com/subscribe
Linux Lugcast - https://linuxlugcast.com/ Hacker Public Radio - https://hackerpublicradio.org/ Reichsmark - https://en.wikipedia.org/wiki/Reichsmark 7-11 convenience store - https://www.7-eleven.com/ 7-11 pizza - https://www.7-eleven.com/products/pizza Peanut butter sandwich - https://www.foodnetwork.com/recipes/photos/pb-and-yay- Cereal - https://en.wikipedia.org/wiki/Cereal https://en.wikipedia.org/wiki/List_of_breakfast_cereals Medicaid - https://www.medicaid.gov/ Raspberry Pi - https://www.raspberrypi.com/ MX Linux - https://mxlinux.org/ MX Linux Pi OS Respin - https://mxlinux.org/blog/mx-23-1-raspberry-pi-os-respin/ Raspberry Pi OS - https://www.raspberrypi.com/software/ Chromium Browser - https://www.chromium.org/chromium-projects/ Firefox Browser - https://www.mozilla.org/en-US/firefox/new/ Raspberry Pi 400 - https://www.raspberrypi.com/products/raspberry-pi-400/ How Many Open Browser Tabs Is Too Many Open Browser Tabs? - https://lifehacker.com/does-having-too-many-tabs-open-really-slow-down-your-br-1848554140 HDMI - https://www.lifewire.com/hdmi-facts-high-definition-multimedia-interface-1847337 VGA - https://www.howtogeek.com/821620/what-is-vga/ RCA Connectors - https://www.cablethis.com/demystifying-rca-connectors-how-they-impact-your-audio-quality/ Composite Video - https://www.lifewire.com/composite-video-the-basics-1846869 CDC Pascal - https://standardpascal.org/CDC6000pascal.html https://exhibits.stanford.edu/stanford-pubs/catalog/sz874xb6118 Xerox - https://www.xerox.com/en-us IBM - https://www.ibm.com/us-en Thailand Death Train - https://www.bordersofadventure.com/death-railway-kanchanaburi-thailand/ https://www.thaitrainguide.com/death-railway/ West Virginia - https://www.wv.gov/Pages/default.aspx https://wvtourism.com/ Mining Effects On Fishing - https://fisheries.org/policy-media/policy-statements/afs-policy-statement-13/ Mining Land Remediation/Reclamation - https://www.epa.gov/remedytech/green-remediation-best-management-practices-mining-sites https://en.wikipedia.org/wiki/Mine_reclamation Kwai River - https://www.tripadvisor.com/Attraction_Review-g297924-d554151-Reviews-River_Kwai-Kanchanaburi_Kanchanaburi_Province.html Cassava - https://plants.usda.gov/DocumentLibrary/plantguide/pdf/pg_maes.pdf https://codycovefarm.com/plant-profile-cassava-manihot-esculenta/ Sugar Cane - https://en.wikipedia.org/wiki/Sugar_Kane Rice - https://en.wikipedia.org/wiki/Rice https://www.foodnetwork.com/how-to/articles/how-to-make-perfect-rice-a-step-by-step-guide The story of the great Polish train hack - https://www.railway-technology.com/news/the-story-of-the-great-polish-train-hack/?cf-view CompuServe Headquarters turns 50 - https://abc6onyourside.com/news/local/historical-status-given-to-central-ohio-building-that-once-housed-compuserve Compuserve - https://www.compuserve.com/ https://en.wikipedia.org/wiki/CompuServe PDP-10 Computer - http://www.columbia.edu/cu/computinghistory/pdp10.html Linear Power Supply - https://www.tek.com/en/documents/application-note/understanding-linear-power-supply-specifications Switching Power Supply - https://www.eleccircuit.com/what-switching-power-supply-how-does-it-work/ Asperger's Syndrome - https://www.autismspeaks.org/types-autism-what-asperger-syndrome DietPi - https://dietpi.com/ Debian Linux - https://www.debian.org/ XFCE - https://www.xfce.org/ Systemd - https://www.digitalocean.com/community/tutorials/what-is-systemd MX-23 XFCE (Bookworm) - https://forums.raspberrypi.com/viewtopic.php?t=362478 Thorium Web Browser - https://thorium.rocks/ Waterfox Web Browser - https://www.waterfox.net/ Group Speed Dial (FIrefox) - https://addons.mozilla.org/en-US/firefox/addon/groupspeeddial/ Raspberry Pi 5 - https://www.raspberrypi.com/products/raspberry-pi-5/ PDP-6 - http://pdp-6.net/ MIT - https://web.mit.edu/ MIT Early AI works - https://dspace.mit.edu/handle/1721.1/5460 ZULU Time - https://www.timeanddate.com/worldclock/timezone/zulu Daylight Savings Time - https://www.reuters.com/world/us/what-is-us-daylight-saving-time-why-was-it-created-2023-10-31/ Truck Driver Rules & Regulations - https://truckstop.com/blog/understanding-truck-driving-hours-and-regulations/ Amphetamine - https://en.wikipedia.org/wiki/Amphetamine Men In Black - https://www.imdb.com/title/tt0119654/ Cold War - https://www.britannica.com/event/Cold-War Pershing Ballastic Missle - https://www.lockheedmartin.com/en-us/news/features/history/pershing.html Pershing M26 Tank - https://tanks-encyclopedia.com/ww2/us/m26_pershing.php C4 Plastic Explosive - https://www.military.com/video/ammunition-and-explosives/explosives/c4-explained/1367499806001 Battleship New Jersey - https://www.battleshipnewjersey.org/ B-52 - https://stratofortress.org/history/ Wagner Military Group - https://en.wikipedia.org/wiki/Wagner_Group John Ringo - https://www.simonandschuster.com/authors/John-Ringo/1875432 Ghost (John Ringo book) - https://www.kirkusreviews.com/book-reviews/john-ringo/ghost-3/ Battleship Wisconsin - https://nauticus.org/explore/battleship-exhibits/about-the-battleship/ Jules Verne - https://www.biography.com/authors-writers/jules-verne M28/M29 Davy Crockett Tactical Nuclear Weapon - https://armyhistory.org/the-m28m29-davy-crockett-nuclear-weapon-system/ PTSD - https://www.psychiatry.org/patients-families/ptsd/what-is-ptsd Autistic Spectrum - https://www.cdc.gov/ncbddd/autism/signs.html Dyslexia - https://www.mayoclinic.org/diseases-conditions/dyslexia/symptoms-causes/syc-20353552 Boston - https://www.boston.gov/visiting-boston Clinical Depression - https://www.nimh.nih.gov/health/topics/depression Maine - https://visitmaine.com/ Spread Spectrum Communications - https://www.edn.com/what-is-spread-spectrum-technology/ Israeli Army Unit that recruits autistic teens - https://www.theatlantic.com/health/archive/2016/01/israeli-army-autism/422850/ Open Source - https://opensource.com/resources/what-open-source New Years Resolution - https://www.newsweek.com/new-years-resolution-2022-meaning-origin-ideas-1662947 Mini HDMI Cable - https://www.howtogeek.com/745530/hdmi-vs-mini-hdmi-vs-micro-hdmi-whats-the-difference/ LibreOffice Impress - https://www.libreoffice.org/discover/impress/ Powerpoint - https://www.microsoft.com/en-us/microsoft-365/powerpoint Google Drive - https://www.google.com/drive/ GPD Win 4 - https://www.gpd.hk/gpdwin4 Coreboot - https://www.coreboot.org/ Libreboot - https://libreboot.org/ FOSDEM - https://fosdem.org/2024/ BIOS - https://computer.howstuffworks.com/bios.htm X11 - https://www.baeldung.com/linux/x11 Wayland - https://wayland.freedesktop.org/ Gnome 3 - https://www.gnome.org/getting-gnome/ Mate - https://mate-desktop.org/ Xorg - https://wiki.archlinux.org/title/Xorg Open Suse - https://www.opensuse.org/ KDE - https://kde.org/ Unity - https://unityd.org/ Chromebook - https://www.google.com/chromebook/ ASUS EEE PC 901 - https://www.laptopmag.com/reviews/laptops/asus-eee-pc-901 ASUS EEE PC X101CH - https://www.cnet.com/reviews/asus-eee-pc-x101ch-review/ Star Labs - https://us.starlabs.systems/?shpxid=fc6f3491-925e-4b6c-aba5-4477924fc432 Pulse Audio - https://www.freedesktop.org/wiki/Software/PulseAudio/ Obsessive Compulsive Disorder (OCD) - https://www.nimh.nih.gov/health/topics/obsessive-compulsive-disorder-ocd STEM (Science, Technology, Engineering, & Math) - https://www.lifewire.com/what-is-stem-4150175
We've got a lot of big news for Linux users this week! We've got everything from marketshare growth to the latest updates for your favorite distros. Desktop Linux hits 4% market share! That's the highest ever by the way. Linux From Scratch just released a new version for those of you who dream of building […]
https://youtu.be/0cCBn-iMOUY Forum Discussion Thread (https://forum.tuxdigital.com/t/256-linux-desktop-growth-fedora-dropping-xorg-nintendo-vs-yuzu-lawsuit-amp-more-linux-news/6185) We've got a lot of big news for Linux users this week! We've got everything from marketshare growth to the latest updates for your favorite distros. Desktop Linux hits 4% market share! That's the highest ever by the way. Linux From Scratch just released a new version for those of you who dream of building your own OS. Fedora is considering dropping XOrg entirely on Fedora 41 Workstation. Arch Linux users are getting a pretty big update to their package manager, Pacman. Plus we are so close to 30,000 subscribers on my YouTube channel, if you enjoy this show and aren't subscribe to my channel then I'd appreciate it if you help me reach that milestone. That would be awesome. Now let's jump into This Week in Linux, Your Source for Linux GNews! Download as MP3 (https://aphid.fireside.fm/d/1437767933/2389be04-5c79-485e-b1ca-3a5b2cebb006/4edd037a-6771-4d27-b289-6abd39780b1d.mp3) Sponsored by: Kolide - thisweekinlinux.com/kolide (https://thisweekinlinux.com/kolide) Want to Support the Show? Become a Patron = https://tuxdigital.com/membership (https://tuxdigital.com/membership) Store = https://tuxdigital.com/store (https://tuxdigital.com/store) Chapters: 00:00 Intro 01:08 I'm going to SCALE - [link (https://www.socallinuxexpo.org/scale/21x)] 03:31 4% Marketshare for Linux on StatCounter! - [link (https://gs.statcounter.com/os-market-share/desktop/worldwide)] 06:28 Nintendo says Game Over to Yuzu Emulator with $2.4 Million lawsuit - [link (https://www.gamingonlinux.com/2024/03/yuzu-agrees-to-pay-nintendo-2-4-million-and-will-entirely-shut-down/)] 11:40 Open Collective Foundation is shutting down - [OCF (https://opencollective.foundation/), OSC comment (https://opencollective.com/opensource/updates/regarding-the-announcement-to-dissolve-open-collective-foundation)] 15:04 Sponsored by Kolide - [link (https://thisweekinlinux.com/kolide)] 16:26 Fedora Project Considering Dropping XOrg from Workstation - [link (https://www.phoronix.com/news/Fedora-41-No-GNOME-Xorg-Install)] 20:56 Flock to Fedora Conference - [link (https://fedoramagazine.org/flock-2024-rochester-new-york/)] 23:28 HDMI Forum 'blocks AMD open sourcing its 2.1 drivers' - [link (https://www.phoronix.com/news/HDMI-2.1-OSS-Rejected)] 24:37 Zorin OS 17.1 Released - [link (https://blog.zorin.com/2024/03/07/zorin-os-17.1-is-released/)] 26:37 OpenMediaVault 7.0 Released - [link (https://www.openmediavault.org/?p=3663)] 28:40 Arch Linux's Pacman 6.1 Released - [link (https://gitlab.archlinux.org/pacman/pacman/-/releases/v6.1.0)] 30:10 Linux From Scratch 12.1 Released - [link (https://lists.linuxfromscratch.org/sympa/arc/lfs-announce/2024-03/msg00001.html)] 33:34 Outro
This Week's Special Guests: Derek Taylor (DistroTube), & Brodie RobertsonThree, highly opinionated Linux nerds. Covering a small mountain of topics in one hour: Xorg, Wayland, Gentoo, Immutable Distros, The Linux Foundation, Red Hat, and more. Glorious.Watch the video version on Lunduke.Locals.com. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit lunduke.substack.com/subscribe
On this episode of TWIL (244), Red Hat has announced that Xorg is no more for RHEL. PipeWire 1.0 has been released to the world. Nextcloud has revealed they are joining forces with Roundcube to improve the Webmail option of Nextcloud. openSUSE is currently running a contest to change some logos for various projects. All […]
https://youtu.be/A7fXwNGVctk Forum Discussion Thread (https://forum.tuxdigital.com/t/244-pipewire-1-0-red-hat-dropping-xorg-opensuse-nextcloud-amp-more-linux-news/6089) On this episode of TWIL (244), Red Hat has announced that Xorg is no more for RHEL. PipeWire 1.0 has been released to the world. Nextcloud has revealed they are joining forces with Roundcube to improve the Webmail option of Nextcloud. openSUSE is currently running a contest to change some logos for various projects. All of this and more on this episode of This Week in Linux, Your Source for Linux GNews! Download as MP3 (https://aphid.fireside.fm/d/1437767933/2389be04-5c79-485e-b1ca-3a5b2cebb006/ae656d8d-3f04-4345-a3f2-3d56370b0d70.mp3) Supported by: LINBIT = https://thisweekinlinux.com/linbit Want to Support the Show? Become a Patron = https://tuxdigital.com/membership Store = https://tuxdigital.com/store Chapters: 00:00 TWIL 244 Intro 00:36 Red Hat Dropping Xorg for RHEL 10 - [ link (https://www.redhat.com/en/blog/rhel-10-plans-wayland-and-xorg-server) ] 03:13 PipeWire 1.0 Released - [ link (https://gitlab.freedesktop.org/pipewire/pipewire/-/releases/1.0.0) ] 04:55 PeerTube 6.0 Released - [ link (https://framablog.org/2023/11/28/peertube-v6-is-out-and-powered-by-your-ideas/) ] 07:13 LINBIT - [ link (https://thisweekinlinux.com/linbit) ] 08:38 OpenMandriva Lx 5.0 Released - [ link (https://www.openmandriva.org/en/news/article/openmandriva-lx-5-0-released) ] 09:40 Roundcube Webmail Merges With Nextcloud - [ link (https://nextcloud.com/blog/open-source-email-pioneer-roundcube-comes-aboard-nextcloud/) ] 12:35 Selecting the New Face of openSUSE - [ link (https://en.opensuse.org/Logocontest) ] 16:04 ChatGPT's OpenAI CEO Fiasco - [ link (https://openai.com/blog/openai-announces-leadership-transition) ] 19:27 GIMP 3.0 Is Hoping To Release In May - [ link (https://developer.gimp.org/core/roadmap/) ] 23:02 Windows XP Ugly Sweater - [ link (https://gear.xbox.com/pages/windows) ] 25:33 Outro
SHOW NOTES ►► https://tuxdigital.com/podcasts/this-week-in-linux/twil-237/
In this episode of This Week in Linux (237), Ubuntu is making waves with the release of Ubuntu 23.10, System76 announced a new version of their Thelio to their lineup, GNOME might be on the verge of removing Xorg and Microsoft made a tutorial for installing Linux? All of this and more on this episode […]
Our thoughts on the Raspberry Pi 5 announcement, yet another nail in Xorg's coffin, why we aren't convinced by Google's commitment to 7 years of software updates for the Pixel 8, praise for Mozilla(!), and more. With guest host Gary from Linux After Dark. News Introducing: Raspberry Pi 5 Testing PCIe on the Raspberry... Read More
Our thoughts on the Raspberry Pi 5 announcement, yet another nail in Xorg's coffin, why we aren't convinced by Google's commitment to 7 years of software updates for the Pixel 8, praise for Mozilla(!), and more. With guest host Gary from Linux After Dark. News Introducing: Raspberry Pi 5 Testing PCIe on the Raspberry... Read More
The guys come together to talk about Wayland and its Pros and Cons.
https://youtu.be/hRPizIVkMhY Download as MP3 (https://aphid.fireside.fm/d/1437767933/32f28071-0b08-4ea1-afcc-37af75bd83d6/e6c07773-94fb-48d8-bc9f-39fd058a09a0.mp3) On this episode of Destination Linux (333), AlmaLinux is making some waves in the Enterprise Linux world. Linux desktop marketshare has broken a usage barrier. And we help out a mate from Australia with finding a silent keyboard. Plus of course, we have our tips, tricks and software picks for you. So join us on the journey to Destination Linux. Sponsored by LINBIT = https://linbit.com Hosted by: Michael Tunnell = https://tuxdigital.com Ryan (DasGeek) = https://dasgeekcommunity.com Jill Bryant = https://jilllinuxgirl.com Want to Support the Show? Become a Patron = https://tuxdigital.com/membership Store = https://tuxdigital.com/store Chapters: 00:00 DL 333 Intro 01:00 Community Feedback - Logitech - https://amzn.to/44FAwgB - Superbcco - https://amzn.to/3KBNGDt - https://amzn.to/3O6ZYEA - Jelly Comb - https://www.jellycomb.com/.../kut019... (https://www.jellycomb.com/collections/keyboards-and-mouse-combos/products/kut019-wireless-keyboard-mouse-combo?variant=32955295465562) - https://www.jellycomb.com/.../ks15-2... (https://www.jellycomb.com/collections/keyboards-and-mouse-combos/products/ks15-2-wireless-keyboard-mouse-combo?variant=32942942486618) - https://www.jellycomb.com/.../ks45-3... (https://www.jellycomb.com/collections/keyboards-and-mouse-combos/products/ks45-3-wireless-keyboard-mouse-combo?variant=32942942617690) - Roccat - https://amzn.to/3Y6k4Dw 15:19 LINBIT - https://linbit.com 16:37 Linux Desktop Marketshare Increases to 3% - [ link (https://gs.statcounter.com/os-market-share/desktop/worldwide) ] 31:07 AlmaLinux Reacts to Red Hat's RHEL Source Code Changes - [ link (https://almalinux.org/blog/future-of-almalinux/) ] 41:47 Gaming: Pincrediball - [ link (https://store.steampowered.com/app/2378150/Pincrediball/) ] 46:54 Software Spotlight: JamesDSP for Linux - [ link (https://flathub.org/apps/me.timschneeberger.jdsp4linux) ] 49:57 Tip of the Week: how to see if you are using Wayland or Xorg [ echo $XDGSESSIONTYPE ] 52:55 Outro
How we found peace with the Linux community's perpetual debates; and our tricks for finding the signal from the noise.
NOTE: All future episodes will be published exclusively at Lunduke.Locals.com. Be sure to subscribe there so you don't miss out on the nerdy goodness.Lunduke's Big Tech Show - May 15th, 2023 - Episode 001Topics for today's show includes:* Taking a stand against Artificial Intelligence.* Is 47% of Internet traffic just… bots?* Fedora Linux Project Manager among the mass Red Hat layoffs.* Tech layoffs for 2023 closing in on 200,000.* Layoffs last week at Microsoft, Stack Overflow, Akamai, and LinkedIn.* Asahi Linux goes to war against Xorg. And it's very entertaining.* A brand new game (Zeta Wing 2) released for Commodore 64.New episodes, Monday through Thursday. Exclusively at Lunduke.Locals.com. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit lunduke.substack.com/subscribe
The boys are back with more Linux news, including another Ubuntu flavor, KDE Updates as per usual, and a rant about April fools. (Sorry for the lackluster audio quality. We'll do better). Video Version - https://youtube.com/live/bMZx9T-8SHc ==== Special Thanks to Our Patrons! ==== https://thelinuxcast.org/patrons/ ===== Follow us
First up in the news, Mint 21 will have a new graphical upgrade tool; Fedora plans to remove BIOS and XOrg; Gnome43 reworks adwaita tools; a Sony engineer makes exFAT 73% faster; and Alibaba previews a 128-core Armv9 server processor. Then in our Wanderings, Joe is Board of school runnings, Norbert is looking for a MATE, Moss blew up Kodi; and Bill is browsercasting. Download
Moving on from legacy BIOS and Xorg, Raspberry Pi OS finally catches up with security basics, the UK government give us more reasons to be angry, the usual KDE goodness, and more. News Work with Will writing Go Fedora 37 Looks To Deprecate Legacy BIOS Support Fedora 37 Considering Removal Of Legacy X.Org Drivers... Read More
Moving on from legacy BIOS and Xorg, Raspberry Pi OS finally catches up with security basics, the UK government give us more reasons to be angry, the usual KDE goodness, and more. News Work with Will writing Go Fedora 37 Looks To Deprecate Legacy BIOS Support Fedora 37 Considering Removal Of Legacy X.Org Drivers... Read More
Eduardo Medina es uno de esos usuarios de GNU/Linux que arrastran polémica por donde pasa, no tiene pelos en la lengua, ya sea para alabar o criticar al sistema del pingüino cuando hace falta.Una charla en la que tratamos los principales temas de actualidad de GNU/Linux y el software libre. Nvidia,. Wayland, Xorg,Fedora, Gnome, Plasma, etc...Su canal de Youtube: https://www.youtube.com/c/EduardoMedinaEdlinks
First up in the news, Raspberry PI Zero 2 W, Xorg has something new, SUSE goes Edge, A new MX linux, and Microsoft Blunders In security, an NPM library gets hijacked, Proton will not retain your data, Firefox implements GPC, and black Friday scams abound Then in our Wanderings, Joe tries his hand at tv repair, Norbert plays with legos, Tony shops for a new pc, and Josh gets a new throne Download
You should never host your own email, so we’ve gone and done just that. What we learned trying to build an email server in 2021. Plus our take on Ubuntu 21.04, become a master of your schedule with our pick, and a Garage Sale update.
Mobile Linux OSes are looking better than ever this week, a new effort to keep legacy applications running on Linux, and the signals indicating a Fuchsia release is nigh. Plus a PSA for GNOME users, and a recently improved tool for the Raspberry Pi. Special Guest: Dalton Durst.
Mobile Linux OSes are looking better than ever this week, a new effort to keep legacy applications running on Linux, and the signals indicating a Fuchsia release is nigh. Plus a PSA for GNOME users, and a recently improved tool for the Raspberry Pi. Special Guest: Dalton Durst.
Mobile Linux OSes are looking better than ever this week, a new effort to keep legacy applications running on Linux, and the signals indicating a Fuchsia release is nigh. Plus a PSA for GNOME users, and a recently improved tool for the Raspberry Pi. Special Guest: Dalton Durst.
We break down the next-level features coming to a Linux near you in just a few weeks.
Luc-Olivier gives Yanik an overview of what's coming to the electric car market in the next year or so.Related LinksFU: GitHub/probobpd: Think twice before abandoning Xorg. Wayland breaks everything!FU: Drew DeVault: I'm tired of this anti-Wayland horseshitFU: Polygon: Google shuts down internal Stadia game studioFU: Polygon: Terraria canceled on Stadia after developer gets locked out of his Google accountsFU: Ford says ‘millions’ of its vehicles will run on Google’s Android starting in 2023 - The VergeFU: Sean O’Kane on TwitterFU: Nissan Gives Up Root Shell Thanks To Hacked USB Drive | HackadayElectric cars mentioned:Audi e-tron GTThe rumoured Ford F-150 ElectricFord Mustang Mach-EGMC Hummer EVLucid AirMercedes-Benz EQCRivian R1SRivian R1TTesla CybertruckTesla Model STesla Model XVolkswagon ID.4Audi reveals its Porsche-powered E-Tron GT - The VergeApple Car Production Again Linked to Kia Motor's US Plant in Georgia - MacRumorsHyundai Executives Said to Be 'Divided' Over Prospect of Apple Car Partnership - MacRumors
Which distro is best for friends and family? We have a unique take on this common question. Plus new insights into the future of CentOS, and Chris falls in love with a 14-inch screamer. Special Guest: Carl George.
We explain the recent Qt upset, and then go hands-on with the new PeerTube release. Plus Wendell from Level1Techs joins us to discuss his thoughts on porting Linux to the Apple M1. Special Guest: Wendell Wilson.
We explain the recent Qt upset, and then go hands-on with the new PeerTube release. Plus Wendell from Level1Techs joins us to discuss his thoughts on porting Linux to the Apple M1. Special Guest: Wendell Wilson.
We explain the recent Qt upset, and then go hands-on with the new PeerTube release. Plus Wendell from Level1Techs joins us to discuss his thoughts on porting Linux to the Apple M1. Special Guest: Wendell Wilson.
Coming up in this episode we cover 1. We Network with Joe 2. Dive into Fedora 32 3. Listener feedback 4. App Focus on Bitwarden Welcome to the Linux User Space Fedora 32 Fedora (https://en.wikipedia.org/wiki/The_Fedora_Project) Warren Togami (https://fedoraproject.org/wiki/User:Wtogami?rd=WarrenTogami) Gnome Desktop (https://en.wikipedia.org/wiki/GNOME#GNOME_3) KDE Plasma 5 Desktop (https://en.wikipedia.org/wiki/KDE_Plasma_5) Heisenbug (https://en.wikipedia.org/wiki/Heisenbug) Matthew Miller arsTECHNICA Interview (https://arstechnica.com/gadgets/2020/05/linux-distro-review-fedora-workstation-32/) Basic Distro Details Base System - Fedora Desktop Environment(s) - (Official) GNOME, (Spins) KDE Plasma, LXQT, LXDE, Cinnamon, MATE, XFCE, SOAS Labs (https://labs.fedoraproject.org/) - Astronomy, Comp Neuro, Design Suite, Games, Jam, Python, Security Labs, Robotics File Manager - Based on DE you choose Package Manager - RPM package manager w/ DNF as the dependency resolver User Interface - GTK 3, Qt System & Service Manager - systemd Software Manager, DNFDragora, Discover Display Manager - GDM, SDDM, LightDM Window Manager - Wayland by default since Fedora 27, Xorg is there too Release Notes Fedora 32 (https://docs.fedoraproject.org/en-US/fedora/f32/release-notes/) Fedora Magazine (https://fedoramagazine.org/) RPM Fusion (https://rpmfusion.org/) Housekeeping Email us (mailto:contact@linuxuserspace.show) Command Line Heros (https://www.redhat.com/en/command-line-heroes) Support us at patreon.com/linuxuserspace Join us on Telegram (https://linuxuserspace.show/telegram) Follow us on twitter (https://twitter.com/LinuxUserSpace) Check out Linux User Space (https://linuxuserspace.show) on the web App Focus Bitwarden This episode's app: Bitwarden (https://bitwarden.com/) Join us in two weeks when we return to the Linux User Space
This conversation took almost an hour, so I split it into two shows: Part 1 talks mostly about the RFC itself, what it means and why. Part 2 goes into personal experiences with the RFC and with syndication in general, in particular in the context of web comics. This is part 1. The why When serving most RSS/Atom feed readers today, you have to choose: Do you make a complete feed with all the things you ever published, or do you make a shorter feed with just the latest entries? This is a trade-off with pros and cons, and it seems like a trade-off you have to make, but a solution to let your Atom feed have the cake and eat it too existed already 13 years ago, if only any of our feed readers would adhere to it: RFC 5005, Feed Paging and Archiving The what https://tools.ietf.org/html/rfc5005 was published in September 2007 The XML namespace for RFC 5005 elements is http://purl.org/syndication/history/1.0, aliased as fh below. Section 2 defines the complete feed: It is one document (Atom file) that contains the entire set the feed describes. The document is marked with an fh:complete element. Section 3 defines the paged feed: It is a series of documents connected with Atom link elements with rel set to the link relations first, last, previous or next. Section 4 defines the archived feed: It has a subscription document that may change at any time, and a series of archive documents that are expected to have stable contents and URIs. The link relations defined are current, prev-archive and next-archive. The semantics are clearer: prev-archive refers to previously published entries, and because the contents are stable you can stop when you see a URI to a document you already have. Archive documents are marked with the fh:archive element. The who In this show I’m talking to: fluffy Federated social web: https://queer.party/@fluffy Writes and makes things in several creative fields: https://beesbuzz.biz/ Publ is like a static site generator, but dynamic. It produces RFC 5005 archive feeds, of course: http://publ.beesbuzz.biz/ Thoughts on ephemeral content vs content worth archiving and how they relate to protocols: https://beesbuzz.biz/blog/5709-Keeping-it-personal Jamey Federated social web: https://toot.cat/@jamey Blog: http://minilop.net/ Made a prototype full-history reader that follows RFC 5005 links: http://reader.minilop.net/ Made a webcomic reader mostly mentioned in Part 2: https://www.comic-rocket.com/ Made a WordPress plugin implementing RFC 5005: https://github.com/jameysharp/wp-fullhistory Made an RFC 5005 archive feed synthesizer for sites with a predictable post frequency and URL structure: https://github.com/jameysharp/predictable/ Hosted at https://fh.minilop.net/ Was on HPR 9 years ago, talking about Xorg! http://hackerpublicradio.org/eps.php?id=0825 Conversation notes Google Reader was terminated 2013-07-01, all subscription data permanently gone on 2013-07-15: https://www.google.com/reader/about/ Mastodon had Atom feeds with paging, but the feeds went away when OStatus went away: https://github.com/tootsuite/mastodon/pull/11247 HTML4 does indeed define the HTML link relations: https://www.w3.org/TR/html4/types.html#h-6.12 It has prev rather than the previous of RFC 5005, but mentions that some browsers support previous as an alias. HTML5 also defines the HTML link relations: https://html.spec.whatwg.org/multipage/links.html Here previous is a lower-case must for historical reasons. IANA manages the Registry of Link Relations: https://www.iana.org/assignments/link-relations/link-relations.xhtml It references RFC 5005 for the Section 4 relations, but not the Section 3 ones. RFC 5005 singles out its own Section 3 (Paged Feeds) as the best-effort, loose, discouraged model. Section 3: Therefore, clients SHOULD NOT present paged feeds as coherent or complete, or make assumptions to that effect. Section 4: Unlike paged feeds, archived feeds enable clients to do this without losing entries. I’m confused about it in the show, but the RFC is clear that an archived feed has one dynamic subscription document, which points to a chain of immutable archive documents. Back in 2002, Aaron Swartz published his joke MIME-header-based RSS 3: http://www.aaronsw.com/weblog/000574 The cultural context at the time and the rivalry between RSS 0.91+, RSS 1.0, RSS 2.0 and Atom deserves a show of its own.
Hi are you a new comer to the FreeBSD world come and learn with me in my amazing experience with there operating system very wonderful. I'm here to preach for the FreeBSD @Community stay safe in these times. --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app Support this podcast: https://anchor.fm/jesu-tinto/support
FreeBSD on Power, DragonflyBSD 5.8 is here, Unifying FreeNAS/TrueNAS, OpenBSD vs. Prometheus and Go, gcc 4.2.1 removed from FreeBSD base, and more. Headlines FreeBSD on Power (https://www.freebsdfoundation.org/blog/power-to-the-people-making-freebsd-a-first-class-citizen-on-power/) The power and promise of all open source software is freedom. Another way to express freedom is choice — choice of platforms, deployment models, stacks, configurations, etc. The FreeBSD Foundation is dedicated to supporting and promoting the FreeBSD Project and community worldwide. But, what does this mean, exactly, you may wonder. The truth is it means many different things, but in all cases the Foundation acts to expand freedom and choice so that FreeBSD users have the power to serve their varied compute needs. This blog tells the story of one specific way the Foundation helps a member of the community provide greater hardware choice for all FreeBSD users. Dragonfly 5.8 (https://www.dragonflybsd.org/release58/) DragonFly version 5.8 brings a new dsynth utility for building your own binary dports packages, plus significant support work to speed up that build - up to and including the entire collection. Additional progress has been made on GPU and signal support. The details of all commits between the 5.6 and 5.8 branches are available in the associated commit messages for 5.8.0rc1 and 5.8.0. Also see /usr/src/UPDATING for specific file changes in PAM. See article for rest of information 2nd HamBUG meeting recap (https://www.hambug.ca/) The second meeting of the Hamilton BSD Users Group took place last night The next meeting is scheduled for the 2nd Tuesday of the month, April 14th 2020 News Roundup FreeNAS/TrueNAS Brand Unification (https://www.ixsystems.com/blog/freenas-truenas-unification/) FreeNAS and TrueNAS have been separate-but-related members of the #1 Open Source storage software family since 2012. FreeNAS is the free Open Source version with an expert community and has led the pursuit of innovations like Plugins and VMs. TrueNAS is the enterprise version for organizations of all sizes that need additional uptime and performance, as well as the enterprise-grade support necessary for critical data and applications. From the beginning at iXsystems, we’ve developed, tested, documented, and released both as separate products, even though the vast majority of code is shared. This was a deliberate technical decision in the beginning but over time became less of a necessity and more of “just how we’ve always done it”. Furthermore, to change it was going to require a serious overhaul to how we build and package both products, among other things, so we continued to kick the can down the road. As we made systematic improvements to development and QA efficiency over the past few years, the redundant release process became almost impossible to ignore as our next major efficiency roadblock to overcome. So, we’ve finally rolled up our sleeves. With the recent 11.3 release, TrueNAS gained parity with FreeNAS on features like VMs and Plugins, further homogenizing the code. Today, we announce the next phase of evolution for FreeNAS and TrueNAS. OpenBSD versus Prometheus (and Go). (https://utcc.utoronto.ca/~cks/space/blog/sysadmin/OpenBSDVsPrometheusAndGo) We have a decent number of OpenBSD machines that do important things (and that have sometimes experienced problems like running out of disk space), and we have a Prometheus based metrics and monitoring system. The Prometheus host agent has enough support for OpenBSD to be able to report on critical metrics, including things like local disk space. Despite all of this, after some investigation I've determined that it's not really sensible to even try to deploy the host agent on our OpenBSD machines. This is due to a combination of factors that have at their root OpenBSD's lack of ABI stability FreeBSD removed gcc from base (https://svnweb.freebsd.org/base?view=revision&revision=358454) As described in Warner's email message[1] to the FreeBSD-arch mailing list we have reached GCC 4.2.1's retirement date. At this time all supported architectures either use in-tree Clang, or rely on external toolchain (i.e., a contemporary GCC version from ports). GCC 4.2.1 was released July 18, 2007 and was imported into FreeBSD later that year, in r171825. GCC has served us well, but version 4.2.1 is obsolete and not used by default on any architecture in FreeBSD. It does not support modern C and does not support arm64 or RISC-V. Beastie Bits New Archive location for Dragonfly 4.x (https://www.dragonflydigest.com/2020/03/10/24276.html) A dead simple git cheat sheet (https://hub.iwebthings.com/a-dead-simple-git-cheatsheet/) Xorg 1.20.7 on HardenedBSD Comes with IE/RELRO+BIND_NOW/CFI/SafeStack Protections (https://twitter.com/lattera/status/1233412881569415168) Feedback/Questions Niclas writes in Regarding the Lenovo E595 user (episode 340) (http://dpaste.com/2YJ6PFW#wrap) Lyubomir writes about GELI and ZFS (http://dpaste.com/1S0DGT3#wrap) Peter writes in about scaling FreeBSD jails (http://dpaste.com/2FSZQ8V#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.
Authentication Vulnerabilities in OpenBSD, NetBSD 9.0 RC1 is available, Running FreeNAS on a DigitalOcean droplet, NomadBSD 1.3 is here, at e2k19 nobody can hear you scream, and more. Headlines Authentication vulnerabilities in OpenBSD (https://www.openwall.com/lists/oss-security/2019/12/04/5) We discovered an authentication-bypass vulnerability in OpenBSD's authentication system: this vulnerability is remotely exploitable in smtpd, ldapd, and radiusd, but its real-world impact should be studied on a case-by-case basis. For example, sshd is not exploitable thanks to its defense-in-depth mechanisms. From the manual page of login.conf: OpenBSD uses BSD Authentication, which is made up of a variety of authentication styles. The authentication styles currently provided are: passwd Request a password and check it against the password in the master.passwd file. See loginpasswd(8). skey Send a challenge and request a response, checking it with S/Key (tm) authentication. See loginskey(8). yubikey Authenticate using a Yubico YubiKey token. See loginyubikey(8). For any given style, the program /usr/libexec/auth/loginstyle is used to perform the authentication. The synopsis of this program is: /usr/libexec/auth/login_style [-v name=value] [-s service] username class This is the first piece of the puzzle: if an attacker specifies a username of the form "-option", they can influence the behavior of the authentication program in unexpected ways. login_passwd [-s service] [-v wheel=yes|no] [-v lastchance=yes|no] user [class] The service argument specifies which protocol to use with the invoking program. The allowed protocols are login, challenge, and response. (The challenge protocol is silently ignored but will report success as passwd-style authentication is not challenge-response based). This is the second piece of the puzzle: if an attacker specifies the username "-schallenge" (or "-schallenge:passwd" to force a passwd-style authentication), then the authentication is automatically successful and therefore bypassed. Case study: smtpd Case study: ldapd Case study: radiusd Case study: sshd Acknowledgments: We thank Theo de Raadt and the OpenBSD developers for their incredibly quick response: they published patches for these vulnerabilities less than 40 hours after our initial contact. We also thank MITRE's CVE Assignment Team. First release candidate for NetBSD 9.0 available! (https://blog.netbsd.org/tnf/entry/first_release_candidate_for_netbsd) Since the start of the release process four months ago a lot of improvements went into the branch - more than 500 pullups were processed! This includes usbnet (a common framework for usb ethernet drivers), aarch64 stability enhancements and lots of new hardware support, installer/sysinst fixes and changes to the NVMM (hardware virtualization) interface. We hope this will lead to the best NetBSD release ever (only to be topped by NetBSD 10 next year). Here are a few highlights of the new release: Support for Arm AArch64 (64-bit Armv8-A) machines, including "Arm ServerReady" compliant machines (SBBR+SBSA) Enhanced hardware support for Armv7-A Updated GPU drivers (e.g. support for Intel Kabylake) Enhanced virtualization support Support for hardware-accelerated virtualization (NVMM) Support for Performance Monitoring Counters Support for Kernel ASLR Support several kernel sanitizers (KLEAK, KASAN, KUBSAN) Support for userland sanitizers Audit of the network stack Many improvements in NPF Updated ZFS Reworked error handling and NCQ support in the SATA subsystem Support a common framework for USB Ethernet drivers (usbnet) More information on the RC can be found on the NetBSD 9 release page (https://www.netbsd.org/releases/formal-9/NetBSD-9.0.html) News Roundup Running FreeNAS on a Digitalocean droplet (https://www.shlomimarco.com/post/running-freenas-on-a-digitalocean-droplet) ZFS is awesome. FreeBSD even more so. FreeNAS is the battle-tested, enterprise-ready-yet-home-user-friendly software defined storage solution which is cooler then deep space, based on FreeBSD and makes heavy use of ZFS. This is what I (and soooooo many others) use for just about any storage-related task. I can go on and on and on about what makes it great, but if you're here, reading this, you probably know all that already and we can skip ahead. I've needed an offsite FreeNAS setup to replicate things to, to run some things, to do some stuff, basically, my privately-owned, tightly-controlled NAS appliance in the cloud, one I control from top to bottom and with support for whatever crazy thing I'm trying to do. Since I'm using DigitalOcean as my main VPS provider, it seemed logical to run FreeNAS there, however, you can't. While DO supports many many distos and pre-setup applications (e.g OpenVPN), FreeNAS isn't a supported feature, at least not in the traditional way :) Before we begin, here's the gist of what we're going to do: Base of a FreeBSD droplet, we'll re-image our boot block device with FreeNAS iso. We'll then install FreeNAS on the second block device. Once done we're going to do the ol' switcheroo: we're going to re-image our original boot block device using the now FreeNAS-installed second block device. Part 1: re-image our boot block device to boot FreeNAS install media. Part 2: Install FreeNAS on the second block-device Part 3: Re-image the boot block device using the FreeNAS-installed block device NomadBSD 1.3 is now available (https://nomadbsd.org/) From the release notes: The base system has been changed to FreeBSD 12.1-RELEASE-p1 Due to a deadlock problem, FreeBSD's unionfs has been replaced by unionfs-fuse The GPT layout has been changed to MBR. This prevents problems with Lenovo systems that refuse to boot from GPT if "lenovofix" is not set, and systems that hang on boot if "lenovofix" is set. Support for ZFS installations has been added to the NomadBSD installer. The rc-script for setting up the network interfaces has been fixed and improved. Support for setting the country code for the wlan device has been added. Auto configuration for running in VirtualBox has been added. A check for the default display has been added to the graphics configuration scripts. This fixes problems where users with Optimus have their NVIDIA card disabled, and use the integrated graphics chip instead. NVIDIA driver version 440 has been added. nomadbsd-dmconfig, a Qt tool for selecting the display manager theme, setting the default user and autologin has been added. nomadbsd-adduser, a Qt tool for added preconfigured user accounts to the system has been added. Martin Orszulik added Czech translations to the setup and installation wizard. The NomadBSD logo, designed by Ian Grindley, has been changed. Support for localized error messages has been added. Support for localizing the password prompts has been added. Some templates for starting other DEs have been added to ~/.xinitrc. The interfaces of nomadbsd-setup-gui and nomadbsd-install-gui have been improved. A script that helps users to configure a multihead systems has been added. The Xorg driver for newer Intel GPUs has been changed from "intel" to "modesetting". /proc has been added to /etc/fstab A D-Bus session issue has been fixed which prevented thunar from accessing samba shares. DSBBg which allows users to change and manage wallpapers has been added. The latest version of update_obmenu now supports auto-updating the Openbox menu. Manually updating the Openbox menu after packet (de)installation is therefore no longer needed. Support for multiple keyboard layouts has been added. www/palemoon has been removed. mail/thunderbird has been removed. audio/audacity has been added. deskutils/orage has been added. the password manager fpm2 has been replaced by KeePassXC mail/sylpheed has been replaced by mail/claws-mail multimedia/simplescreenrecorder has been added. DSBMC has been changed to DSBMC-Qt Many small improvements and bug fixes. At e2k19 nobody can hear you scream (https://undeadly.org/cgi?action=article;sid=20191204170908) After 2 years it was once again time to pack skis and snowshoes, put a satellite dish onto a sledge and hike through the snowy rockies to the Elk Lakes hut. I did not really have much of a plan what I wanted to work on but there were a few things I wanted to look into. One of them was rpki-client and the fact that it was so incredibly slow. Since Bob beck@ was around I started to ask him innocent X509 questions ... as if there are innocent X509 questions! Mainly about the abuse of the X509STORE in rpki-client. Pretty soon it was clear that rpki-client did it all wrong and most of the X509 verification had to be rewritten. Instead of only storing the root certificates in the store and passing the intermediate certs as a chain to the verification function rpki-client threw everything into it. The X509STORE is just not built for such an abuse and so it was no wonder that this was slow. Lucky me I pulled benno@ with me into this dark hole of libcrypto code. He managed to build up an initial diff to pass the chains as a STACKOF(X509) and together we managed to get it working. A big thanks goes to ingo@ who documented most of the functions we had to use. Have a look at STACKOF(3) and skpopfree(3) to understand why benno@ and I slowly turned crazy. Our next challenge was to only load the necessary certificate revocation list into the X509STORECTX. While doing those changes it became obvious that some of the data structures needed better lookup functions. Looking up certificates was done using a linear lookup and so we replaced the internal certificate and CRL tables with RB trees for fast lookups. deraadt@ also joined the rpki-client commit fest and changed the output code to use rename(2) so that files are replaced in an atomic operation. Thanks to this rpki-client can now be safely run from cron (there is an example in the default crontab). I did not plan to spend most of my week hacking on rpki-client but in the end I'm happy that I did and the result is fairly impressive. Working with libcrypto code and especially X509 was less than pleasant. Our screams of agony died away in the snowy rocky mountains and made Bob deep dive into UVM with a smile since he knew that benno@ and I had it worse. In case you wonder thanks to all changes at e2k19 rpki-client improved from over 20min run time to validate all VRPS to roughly 1min to do the same job. A factor 20 improvement! Thanks to Theo, Bob and Howie to make this possible. To all the cooks for the great food and to Xplornet for providing us with Internet at the hut. Beastie Bits FOSDEM 2020 BSD Devroom schedule (https://fosdem.org/2020/schedule/track/bsd/) Easy Minecraft Server on FreeBSD Howto (https://www.freebsdfoundation.org/freebsd/how-to-guides/easy-minecraft-server-on-freebsd/) stats(3) framework in the TCP stack (https://svnweb.freebsd.org/base?view=revision&revision=355304) 4017 days of uptime (https://twitter.com/EdwinKremer/status/1203071684535889921) sysget - A front-end for every package manager (https://github.com/emilengler/sysget) PlayOnBSD’s Cross-BSD Shopping Guide (https://www.playonbsd.com/shopping_guide/) Feedback/Questions Pat asks about the proper disk drive type for ZFS (http://dpaste.com/2FDN26X#wrap) Brad asks about a ZFS rosetta stone (http://dpaste.com/2X8PBMC#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag. Special Guest: Mariusz Zaborski.
Headlines FreeBSD and custom firmware on the Google Pixelbook (https://unrelenting.technology/articles/FreeBSD-and-custom-firmware-on-the-Google-Pixelbook) FreeBSD and custom firmware on the Google Pixelbook Back in 2015, I jumped on the ThinkPad bandwagon by getting an X240 to run FreeBSD on. Unlike most people in the ThinkPad crowd, I actually liked the clickpad and didnu2019t use the trackpoint much. But this summer Iu2019ve decided that it was time for something newer. I wanted something.. lighter and thinner (ha, turns out this is actually important, I got tired of carrying a T H I C C laptop - Apple was right all along); with a 3:2 display (why is Lenovo making these Serious Worku2122 laptops 16:9 in the first place?? 16:9 is awful in below-13-inch sizes especially); with a HiDPI display (and ideally with a good size for exact 2x scaling instead of fractional); with USB-C ports; without a dGPU, especially without an NVIDIA GPU; assembled with screws and not glue (I donu2019t necessarily need expansion and stuff in a laptop all that much, but being able to replace the battery without dealing with a glued chassis is good); supported by FreeBSD of course (u201csome development requiredu201d is okay but Iu2019m not going to write big drivers); how about something with open source firmware, that would be fun. I was considering a ThinkPad X1 Carbon from an old generation - the one from the same year as the X230 is corebootable, so thatu2019s fun. But going back in processor generations just doesnu2019t feel great. I want something more efficient, not less! And then I discovered the Pixelbook. Other than the big huge large bezels around the screen, I liked everything about it. Thin aluminum design, a 3:2 HiDPI screen, rubber palm rests (why isnu2019t every laptop ever doing that?!), the u201cconvertiblenessu201d (flip the screen around to turn it into.. something rather big for a tablet, but it is useful actually), a Wacom touchscreen that supports a pen, mostly reasonable hardware (Intel Wi-Fi), and that famous coreboot support (Chromebooksu2019 stock firmware is coreboot + depthcharge). So here it is, my new laptop, a Google Pixelbook. Conclusion Pixelbook, FreeBSD, coreboot, EDK2 good. Seriously, I have no big words to say, other than just recommending this laptop to FOSS enthusiasts :) Porting NetBSD to the AMD x86-64: a case study in OS portability (https://www.usenix.org/legacy/publications/library/proceedings/bsdcon02/full_papers/linden/linden_html/index.html) Abstract NetBSD is known as a very portable operating system, currently running on 44 different architectures (12 different types of CPU). This paper takes a look at what has been done to make it portable, and how this has decreased the amount of effort needed to port NetBSD to a new architecture. The new AMD x86-64 architecture, of which the specifications were published at the end of 2000, with hardware to follow in 2002, is used as an example. Portability Supporting multiple platforms was a primary goal of the NetBSD project from the start. As NetBSD was ported to more and more platforms, the NetBSD kernel code was adapted to become more portable along the way. General Generally, code is shared between ports as much as possible. In NetBSD, it should always be considered if the code can be assumed to be useful on other architectures, present or future. If so, it is machine-independent and put it in an appropriate place in the source tree. When writing code that is intended to be machine-independent, and it contains conditional preprocessor statements depending on the architecture, then the code is likely wrong, or an extra abstraction layer is needed to get rid of these statements. Types Assumptions about the size of any type are not made. Assumptions made about type sizes on 32-bit platforms were a large problem when 64-bit platforms came around. Most of the problems of this kind had to be dealt with when NetBSD was ported to the DEC Alpha in 1994. A variation on this problem had to be dealt with with the UltraSPARC (sparc64) port in 1998, which is 64-bit, but big endian (vs. the little-endianness of the Alpha). When interacting with datastructures of a fixed size, such as on-disk metadata for filesystems, or datastructures directly interpreted by device hardware, explicitly sized types are used, such as uint32t, int8t, etc. Conclusions and future work The port of NetBSD to AMD's x86-64 architecture was done in six weeks, which confirms NetBSD's reputation as being a very portable operating system. One week was spent setting up the cross-toolchain and reading the x86-64 specifications, three weeks were spent writing the kernel code, one week was spent writing the userspace code, and one week testing and debugging it all. No problems were observed in any of the machine-independent parts of the kernel during test runs; all (simulated) device drivers, file systems, etc, worked without modification. News Roundup ZFS performance really does degrade as you approach quota limits (https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSFullQuotaPerformanceIssue) Every so often (currently monthly), there is an "OpenZFS leadership meeting". What this really means is 'lead developers from the various ZFS implementations get together to talk about things'. Announcements and meeting notes from these meetings get sent out to various mailing lists, including the ZFS on Linux ones. In the September meeting notes, I read a very interesting (to me) agenda item: Relax quota semantics for improved performance (Allan Jude) Problem: As you approach quotas, ZFS performance degrades. Proposal: Can we have a property like quota-policy=strict or loose, where we can optionally allow ZFS to run over the quota as long as performance is not decreased. This is very interesting to me because of two reasons. First, in the past we have definitely seen significant problems on our OmniOS machines, both when an entire pool hits a quota limit and when a single filesystem hits a refquota limit. It's nice to know that this wasn't just our imagination and that there is a real issue here. Even better, it might someday be improved (and perhaps in a way that we can use at least some of the time). Second, any number of people here run very close to and sometimes at the quota limits of both filesystems and pools, fundamentally because people aren't willing to buy more space. We have in the past assumed that this was relatively harmless and would only make people run out of space. If this is a known issue that causes serious performance degradation, well, I don't know if there's anything we can do, but at least we're going to have to think about it and maybe push harder at people. The first step will have to be learning the details of what's going on at the ZFS level to cause the slowdown. (It's apparently similar to what happens when the pool is almost full, but I don't know the specifics of that either.) With that said, we don't seem to have seen clear adverse effects on our Linux fileservers, and they've definitely run into quota limits (repeatedly). One possible reason for this is that having lots of RAM and SSDs makes the effects mostly go away. Another possible reason is that we haven't been looking closely enough to see that we're experiencing global slowdowns that correlate to filesystems hitting quota limits. We've had issues before with somewhat subtle slowdowns that we didn't understand (cf), so I can't discount that we're having it happen again. Fixing up KA9Q-unix, or "neck deep in 30 year old codebases.." (http://adrianchadd.blogspot.com/2019/09/fixing-up-ka9q-unix-or-neck-deep-in-30.html) I'll preface this by saying - yes, I'm still neck deep in FreeBSD's wifi stack and 802.11ac support, but it turns out it's slow work to fix 15 year old locking related issues that worked fine on 11abg cards, kinda worked ok on 11n cards, and are terrible for these 11ac cards. I'll .. get there. Anyhoo, I've finally been mucking around with AX.25 packet radio. I've been wanting to do this since I was a teenager and found out about its existence, but back in high school and .. well, until a few years ago really .. I didn't have my amateur radio licence. But, now I do, and I've done a bunch of other stuff with a bunch of other radios. The main stumbling block? All my devices are either Apple products or run FreeBSD - and none of them have useful AX.25 stacks. The main stacks of choice these days run on Linux, Windows or are a full hardware TNC. So yes, I was avoiding hacking on AX.25 stuff because there wasn't a BSD compatible AX.25 stack. I'm 40 now, leave me be. But! A few weeks ago I found that someone was still running a packet BBS out of San Francisco. And amazingly, his local node ran on FreeBSD! It turns out Jeremy (KK6JJJ) ported both an old copy of KA9Q and N0ARY-BBS to run on FreeBSD! Cool! I grabbed my 2m radio (which is already cabled up for digital modes), compiled up his KA9Q port, figured out how to get it to speak to Direwolf, and .. ok. Well, it worked. Kinda. HAMMER2 and fsck for review (https://www.dragonflydigest.com/2019/09/24/23540.html) HAMMER2 is Copy on Write, meaning changes are made to copies of existing data. This means operations are generally atomic and can survive a power outage, etc. (You should read up on it!) However, thereu2019s now a fsck command, useful if you want a report of data validity rather than any manual repair process. [The return of startx(1) for non-root users with some caveats (https://undeadly.org/cgi?action=article;sid=20190917091236) Mark Kettenis (kettenis@) has recently committed changes which restore a certain amount of startx(1)/xinit(1) functionality for non-root users. The commit messages explain the situation: ``` CVSROOT: /cvs Module name: src Changes by: kettenis@cvs.openbsd.org 2019/09/15 06:25:41 Modified files: etc/etc.amd64 : fbtab etc/etc.arm64 : fbtab etc/etc.hppa : fbtab etc/etc.i386 : fbtab etc/etc.loongson: fbtab etc/etc.luna88k: fbtab etc/etc.macppc : fbtab etc/etc.octeon : fbtab etc/etc.sgi : fbtab etc/etc.sparc64: fbtab Log message: Add ttyC4 to lost of devices to change when logging in on ttyC0 (and in some cases also the serial console) such that X can use it as its VT when running without root privileges. ok jsg@, matthieu@ CVSROOT: /cvs Module name: xenocara Changes by: kettenis@cvs.openbsd.org 2019/09/15 06:31:08 Modified files: xserver/hw/xfree86/common: xf86AutoConfig.c Log message: Add modesetting driver as a fall-back when appropriate such that we can use it when running without root privileges which prevents us from scanning the PCI bus. This makes startx(1)/xinit(1) work again on modern systems with inteldrm(4), radeondrm(4) and amdgpu(4). In some cases this will result in using a different driver than with xenodm(4) which may expose issues (e.g. when we prefer the intel Xorg driver) or loss of acceleration (e.g. older cards supported by radeondrm(4)). ok jsg@, matthieu@ ``` Beastie Bits ASCII table and history. Or, why does Ctrl+i insert a Tab in my terminal? (https://bestasciitable.com/) Sourcehut makes BSD software better (https://sourcehut.org/blog/2019-09-12-sourcehut-makes-bsd-software-better/) Chaosnet for Unx (https://github.com/LM-3/chaos) The Vim-Inspired Editor with a Linguistic Twist (https://cosine.blue/2019-09-06-kakoune.html) bhyvearm64: CPU and Memory Virtualization on Armv8.0-A (https://papers.freebsd.org/2019/bsdcan/elisei-bhyvearm64_cpu_and_memory_virtualization_on_armv8.0_a/) DefCon25 - Are all BSD created Equally - A Survey of BSD Kernel vulnerabilities (https://www.youtube.com/watch?v=a2m56Yq-EIs) Feedback/Questions Tim - GSoC project ideas for pf rule syntax translation (http://dpaste.com/1RCSFK7#wrap) Brad - Steam on FreeBSD (http://dpaste.com/2SKA9YB#wrap) Ruslan - FreeBSD Quarterly Status Report - Q2 2019 (http://dpaste.com/0DQM3Q1) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.
Setting up buildbot in FreeBSD jails, Set up a mail server with OpenSMTPD, Dovecot and Rspamd, OpenBSD amateur packet radio with HamBSD, DragonFlyBSD's HAMMER2 gets fsck, return of startx for users. Headlines EuroBSDcon 2019 Recap (https://2019.eurobsdcon.org/) We’re back from EuroBSDcon in Lillehammer, Norway. It was a great conference with 212 people attending. 2 days of tutorials (https://2019.eurobsdcon.org/tutorial-speakers/), parallel to the FreeBSD Devsummit (https://wiki.freebsd.org/DevSummit/201909), followed by two days of talks (https://2019.eurobsdcon.org/program/). Some speakers uploaded their slides to papers.freebsd.org (https://papers.freebsd.org/2019/eurobsdcon/) already with more to come. The social event was also interesting. We visited an open air museum with building preserved from different time periods. In the older section they had a collection of farm buildings, a church originally built in the 1200s and relocated to the museum, and a school house. In the more modern area, they had houses from 1915, and each decade from 1930 to 1990, plus a “house of the future” as imagined in 2001. Many had open doors to allow you to tour the inside, and some were even “inhabited”. The latter fact gave a much more interactive experience and we could learn additional things about the history of that particular house. The town at the end included a general store, a post office, and more. Then, we all had a nice dinner together in the museum’s restaurant. The opening keynote by Patricia Aas was very good. Her talk on embedded ethics, from her perspective as someone trying to defend the sanctity of Norwegian elections, and a former developer for the Opera web browser, provided a great deal of insight into the issues. Her points about how the tech community has unleashed a very complex digital work upon people with barely any technical literacy were well taken. Her stories of trying to explain the problems with involving computers in the election process to journalists and politicians struck a chord with many of us, who have had to deal with legislation written by those who do not truly understand the issues with technology. Setting up buildbot in FreeBSD jails (https://andidog.de/blog/2018-04-22-buildbot-setup-freebsd-jails) In this article, I would like to present a tutorial to set up buildbot, a continuous integration (CI) software (like Jenkins, drone, etc.), making use of FreeBSD’s containerization mechanism "jails". We will cover terminology, rationale for using both buildbot and jails together, and installation steps. At the end, you will have a working buildbot instance using its sample build configuration, ready to play around with your own CI plans (or even CD, it’s very flexible!). Some hints for production-grade installations are given, but the tutorial steps are meant for a test environment (namely a virtual machine). Buildbot’s configuration and detailed concepts are not in scope here. Setting up a mail server with OpenSMTPD, Dovecot and Rspamd (https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/) Self-hosting and encouraging smaller providers is for the greater good First of all, I was not clear enough about the political consequences of centralizing mail services at Big Mailer Corps. It doesn’t make sense for Random Joe, sharing kitten pictures with his family and friends, to build a personal mail infrastructure when multiple Big Mailer Corps offer “for free” an amazing quality of service. They provide him with an e-mail address that is immediately available and which will generally work reliably. It really doesn’t make sense for Random Joe not to go there, and particularly if even techies go there without hesitation, proving it is a sound choice. There is nothing wrong with Random Joes using a service that works. What is terribly wrong though is the centralization of a communication protocol in the hands of a few commercial companies, EVERY SINGLE ONE OF THEM coming from the same country (currently led by a lunatic who abuses power and probably suffers from NPD), EVERY SINGLE ONE OF THEM having been in the news and/or in a court for random/assorted “unpleasant” behaviors (privacy abuses, eavesdropping, monopoly abuse, sexual or professional harassment, you just name it…), and EVERY SINGLE ONE OF THEM growing user bases that far exceeds the total population of multiple countries combined. News Roundup The HamBSD project aims to bring amateur packet radio to OpenBSD (https://hambsd.org/) The HamBSD project aims to bring amateur packet radio to OpenBSD, including support for TCP/IP over AX.25 and APRS tracking/digipeating in the base system. HamBSD will not provide a full AX.25 stack but instead only implement support for UI frames. There will be a focus on simplicity, security and readable code. The amateur radio community needs a reliable platform for packet radio for use in both leisure and emergency scenarios. It should be expected that the system is stable and resilient (but as yet it is neither). DragonFlyBSD's HAMMER2 Gets Basic FSCK Support (https://www.dragonflydigest.com/2019/09/24/23540.html) HAMMER2 is Copy on Write, meaning changes are made to copies of existing data. This means operations are generally atomic and can survive a power outage, etc. (You should read up on it!) However, there’s now a fsck command, useful if you want a report of data validity rather than any manual repair process. commit (https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/5554cc8b81fbfcfd347f50be3f3b1b9a54b871b) Add initial fsck support for HAMMER2, although CoW fs doesn't require fsck as a concept. Currently no repairing (no write), just verifying. Keep this as a separate command for now. https://i.redd.it/vkdss0mtdpo31.jpg The return of startx for users (http://undeadly.org/cgi?action=article;sid=20190917091236) Add modesetting driver as a fall-back when appropriate such that we can use it when running without root privileges which prevents us from scanning the PCI bus. This makes startx(1)/xinit(1) work again on modern systems with inteldrm(4), radeondrm(4) and amdgpu(4). In some cases this will result in using a different driver than with xenodm(4) which may expose issues (e.g. when we prefer the intel Xorg driver) or loss of acceleration (e.g. older cards supported by radeondrm(4)). Beastie Bits Ori Bernstein will be giving the October talk at NYCBUG (http://lists.nycbug.org:8080/pipermail/talk/2019-September/018046.html) BSD Pizza Night: 2019/09/26, 7–9PM, Portland, Oregon, USA (http://calagator.org/events/1250476200) Nick Wolff : Home Lab Show & Tell (http://knoxbug.org/2019-09-30) Installing the Lumina Desktop in DragonflyBSD (https://www.youtube.com/watch?v=eWkCjj4_xsk) dhcpcd 8.0.6 added (https://www.dragonflydigest.com/2019/09/20/23519.html) Feedback/Questions Bruce - FOSDEM videos (http://dpaste.com/15ABRRB#wrap) Lars - Super Cluster of BSD on Rock64Pr (http://dpaste.com/1X9FEJJ) Madhukar - Question (http://dpaste.com/0TWF1NB#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.
The UNIX Philosophy in 2019, why use package managers, touchpad interrupted, Porting wine to amd64 on NetBSD second evaluation report, Enhancing Syzkaller Support for NetBSD, all about the Pinebook Pro, killing a process and all of its descendants, fast software the best software, and more. Headlines The UNIX Philosophy in 2019 (https://triosdevelopers.com/jason.eckert/blog/Entries/2019/6/1_Entry_1.html) Today, Linux and open source rules the world, and the UNIX philosophy is widely considered compulsory. Organizations are striving to build small, focused applications that work collaboratively in a cloud and microservices environment. We rely on the network, as well as HTTP (text) APIs for storing and referencing data. Moreover, nearly all configuration is stored and communicated using text (e.g. YAML, JSON or XML). And while the UNIX philosophy has changed dramatically over the past 5 decades, it hasn’t strayed too far from Ken Thompson’s original definition in 1973: We write programs that do one thing and do it well We write programs to work together And we write programs that handle text streams, because that is a universal interface Why Use Package Managers? (https://uwm.edu/hpc/software-management/) Valuable research is often hindered or outright prevented by the inability to install software. This need not be the case. Since I began supporting research computing in 1999, I’ve frequently seen researchers struggle for days or weeks trying to install a single open source application. In most cases, they ultimately failed. In many cases, they could have easily installed the software in seconds with one simple command, using a package manager such as Debian packages, FreeBSD ports, MacPorts, or Pkgsrc, just to name a few. Developer websites often contain poorly written instructions for doing “caveman installs”; manually downloading, unpacking, patching, and building the software. The same laborious process must often be followed for other software packages on which it depends, which can sometimes number in the dozens. Many researchers are simply unaware that there are easier ways to install the software they need. Caveman installs are a colossal waste of man-hours. If 1000 people around the globe spend an average of 20 hours each trying to install the same program that could have been installed with a package manager (this is not uncommon), then 20,000 man-hours have been lost that could have gone toward science. How many important discoveries are delayed by this? The elite research institutions have ample funding and dozens of IT staff dedicated to research computing. They can churn out publications even if their operation is inefficient. Most institutions, however, have few or no IT staff dedicated to research, and cannot afford to squander precious man-hours on temporary, one-off software installs. The wise approach for those of us in that situation is to collaborate on making software deployment easier for everyone. If we do so, then even the smallest research groups can leverage that work to be more productive and make more frequent contributions to science. Fortunately, the vast majority of open source software installs can be made trivial for anyone to do for themselves. Modern package managers perform all the same steps as a caveman install, but automatically. Package managers also install dependencies for us automatically. News Roundup Touchpad, Interrupted (https://jcs.org/2019/07/28/ihidev) For two years I've been driving myself crazy trying to figure out the source of a driver problem on OpenBSD: interrupts never arrived for certain touchpad devices. A couple weeks ago, I put out a public plea asking for help in case any non-OpenBSD developers recognized the problem, but while debugging an unrelated issue over the weekend, I finally solved it. It's been a long journey and it's a technical tale, but here it is. Porting wine to amd64 on NetBSD, second evaluation report (https://blog.netbsd.org/tnf/entry/porting_wine_to_amd64_on2) Summary Presently, Wine on amd64 is in test phase. It seems to work fine with caveats like LDLIBRARYPATH which has to be set as 32-bit Xorg libs don't have ${PREFIX}/emul/netbsd32/lib in its rpath section. The latter is due to us extracting 32-bit libs from tarballs in lieu of building 32-bit Xorg on amd64. As previously stated, pkgsrc doesn't search for pkgconfig files in ${PREFIX}/emul/netbsd32/lib which might have inadvertent effects that I am unaware of as of now. I shall be working on these issues during the final coding period. I would like to thank @leot, @maya and @christos for saving me from shooting myself in the foot many a time. I, admittedly, have had times when multiple approaches, which all seemed right at that time, perplexed me. I believe those are times when having a mentor counts, and I have been lucky enough to have really good ones. Once again, thanks to Google for this wonderful opportunity. Enhancing Syzkaller Support for NetBSD, Part 2 (https://blog.netbsd.org/tnf/entry/enchancing_syzkaller_support_for_netbsd) As a part of Google Summer of Code’19, I am working on improving the support for Syzkaller kernel fuzzer. Syzkaller is an unsupervised coverage-guided kernel fuzzer, that supports a variety of operating systems including NetBSD. This report details the work done during the second coding period. You can also take a look at the first report to learn more about the initial support that we added. : https://blog.netbsd.org/tnf/entry/enhancingsyzkallersupportfornetbsd July Update: All about the Pinebook Pro (https://www.pine64.org/2019/07/05/july-update-all-about-the-pinebook-pro/) "So I said I won’t be talking about the BSDs, but I feel like I should at the very least give you a general overview of the RK3399 *BSD functionality. I’ll make it quick. I’ve spoken to *BSD devs whom worked on the RockPro64 and from what I’ve gathered (despite the different *BSDs having varying degree of support for the RK3399 SOC) many of the core features are already supported, which bodes well for *BSD on the Pro. That said, some of the things you’d require on a functional laptop – such as the LCD (using eDP) for instance – will not work on the Pinebook Pro using *BSD as of today. So clearly a degree of work is yet needed for a BSD to run on the device. However, keep in mind that *BSD developers will be receiving their units soon and by the time you receive yours some basic functionality may be available." Killing a process and all of its descendants (http://morningcoffee.io/killing-a-process-and-all-of-its-descendants.html) Killing processes in a Unix-like system can be trickier than expected. Last week I was debugging an odd issue related to job stopping on Semaphore. More specifically, an issue related to the killing of a running process in a job. Here are the highlights of what I learned: Unix-like operating systems have sophisticated process relationships. Parent-child, process groups, sessions, and session leaders. However, the details are not uniform across operating systems like Linux and macOS. POSIX compliant operating systems support sending signals to process groups with a negative PID number. Sending signals to all processes in a session is not trivial with syscalls. Child processes started with exec inherit their parent signal configuration. If the parent process is ignoring the SIGHUP signal, for example, this configuration is propagated to the children. The answer to the “What happens with orphaned process groups” question is not trivial. Fast Software, the Best Software (https://craigmod.com/essays/fast_software/) I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness. Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why. But why is slow bad? Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow. When the nerds upon Nerd Hill fight to the death over Vi and Emacs, it’s partly because they have such a strong affinity for the flow of the application and its meldiness. They have invested. The Tool Is Good, so they feel. Not breaking flow is an axiom of great tools. A typewriter is an excellent tool because, even though it’s slow in a relative sense, every aspect of the machine itself operates as quickly as the user can move. It is focused. There are no delays when making a new line or slamming a key into the paper. Yes, you have to put a new sheet of paper into the machine at the end of a page, but that action becomes part of the flow of using the machine, and the accumulation of paper a visual indication of work completed. It is not wasted work. There are no fundamental mechanical delays in using the machine. The best software inches ever closer to the physical directness of something like a typewriter. (The machine may break down, of course, ribbons need to be changed — but this is maintenance and separate from the use of the tool. I’d be delighted to “maintain” Photoshop if it would lighten it up.) Beastie Bits Register for vBSDCon 2019, Sept 5-7 in Reston VA (https://vbsdcon.com/registration) Register for EuroBSDCon 2019, Sept 19-22 in Lillehammer, Norway (https://2019.eurobsdcon.org/registration/) Feedback/Questions Paulo - FreeNAS Question (http://dpaste.com/2GDG7WR#wrap) Marc - Changing VT without function keys? (http://dpaste.com/1AKC7A1#wrap) Caleb - Patch, update, and upgrade management (http://dpaste.com/2D6J482#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.
Website protection with OPNsense, FreeBSD Support Pull Request for ZFS-on-Linux, How much has Unix changed, Porting Wine to amd64 on NetBSD, FreeBSD Enterprise 1 PB Storage, the death watch for X11 has started, and more. Headlines Website protection with OPNsense (https://medium.com/@jccwbb/website-protection-with-opnsense-3586a529d487) with nginx plugin OPNsense become a strong full featured Web Application Firewall (WAF) The OPNsense security platform can help you to protect your network and your webservers with the nginx plugin addition. In old days, install an open source firewall was a very trick task, but today it can be done with few clicks (or key strokes). In this article I'll not describe the detailed OPNsense installation process, but you can watch this video that was extracted from my OPNsense course available in Udemy. The video is in portuguese language, but with the translation CC Youtube feature you may be able to follow it without problems (if you don't are a portuguese speaker ofcourse) :-) + See the article for the rest of the writeup FreeBSD Support Pull Request against the ZFS-on-Linux repo (https://github.com/zfsonlinux/zfs/pull/8987) This pull request integrates the sysutils/openzfs port’s sources into the upstream ZoL repo > Adding FreeBSD support to ZoL will make it easier to move changes back and forth between FreeBSD and Linux > Refactor tree to separate out Linux and FreeBSD specific code > import FreeBSD's SPL > add ifdefs in common code where it made more sense to do so than duplicate the code in separate files > Adapted ZFS Test Suite to run on FreeBSD and all tests that pass on ZoL passing on ZoF The plan to officially rename the common repo from ZFSonLinux to OpenZFS was announced at the ZFS Leadership Meeting on June 25th Video of Leadership Meeting (https://www.youtube.com/watch?v=TJwykiJmH0M) Meeting Agenda and Notes (https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit) This will allow improvements made on one OS to be made available more easily (and more quickly) to the other platforms For example, mav@’s recent work: Add wakeupany(), cheaper version of wakeupone() for taskqueue(9) (https://svnweb.freebsd.org/base?view=revision&revision=349220) > As result, on 72-core Xeon v4 machine sequential ZFS write to 12 ZVOLs with 16KB block size spend 34% less time in wakeupany() and descendants then it was spending in wakeupone(), and total write throughput increased by ~10% with the same as before CPU usage. News Roundup Episode 5 Notes - How much has UNIX changed? (http://adventofcomputing.libsyn.com/episode-5-notes-how-much-has-unix-changed) UNIX-like systems have dominated computing for decades, and with the rise of the internet and mobile devices their reach has become even larger. True, most systems now use more modern OSs like Linux, but how much has the UNIX-like landscape changed since the early days? So, my question was this: how close is a modern *NIX userland to some of the earliest UNIX releases? To do this I'm going to compare a few key points of a modern Linux system with the earliest UNIX documentation I can get my hands on. The doc I am going to be covering(https://www.tuhs.org/Archive/Distributions/Research/Dennisv1/UNIXProgrammersManual_Nov71.pdf) is from November 1971, predating v1 of the system. I think the best place to start this comparison is to look at one of the highest-profile parts of the OS, that being the file system. Under the hood modern EXT file systems are completely different from the early UNIX file systems. However, they are still presented in basically the same way, as a heirerarchicat structure of directories with device files. So paths still look identical, and navigating the file system still functions the same. Often used commands like ls, cp, mv, du, and df function the same. So are mount and umount. But, there are some key differences. For instance, cd didn't exist, yet instead chdir filled its place. Also, chmod is somewhat different. Instead of the usual 3-digit octal codes for permissions, this older version only uses 2 digits. Really, that difference is due to the underlying file system using a different permission set than modern systems. For the most part, all the file handling is actually pretty close to a Linux system from 2019. See the article for the rest of the writeup Porting Wine to amd64 on NetBSD (https://blog.netbsd.org/tnf/entry/porting_wine_to_amd64_on) I have been working on porting Wine to amd64 on NetBSD as a GSoC 2019 project. Wine is a compatibility layer which allows running Microsoft Windows applications on POSIX-complaint operating systems. This report provides an overview of the progress of the project during the first coding period. Initially, when I started working on getting Wine-4.4 to build and run on NetBSD i386 the primary issue that I faced was Wine displaying black windows instead of UI, and this applied to any graphical program I tried running with Wine. I suspected it , as it is related to graphics, to be an issue with the graphics driver or Xorg. Subsequently, I tried building modular Xorg, and I tried running Wine on it only to realize that Xorg being modular didn't affect it in the least. After having tried a couple of configurations, I realized that trying to hazard out every other probability is going to take an awful lot of time that I didn't have. This motivated me to bisect the repo using git, and find the first version of Wine which failed on NetBSD. + See the article for the rest of the writeup FreeBSD Enterprise 1 PB Storage (https://vermaden.wordpress.com/2019/06/19/freebsd-enterprise-1-pb-storage/?utm_source=discoverbsd) Today FreeBSD operating system turns 26 years old. 19 June is an International FreeBSD Day. This is why I got something special today :). How about using FreeBSD as an Enterprise Storage solution on real hardware? This where FreeBSD shines with all its storage features ZFS included. Today I will show you how I have built so called Enterprise Storage based on FreeBSD system along with more then 1 PB (Petabyte) of raw capacity. This project is different. How much storage space can you squeeze from a single 4U system? It turns out a lot! Definitely more then 1 PB (1024 TB) of raw storage space. See the article for the rest of the writeup The death watch for the X Window System (aka X11) has probably started (https://utcc.utoronto.ca/~cks/space/blog/unix/XDeathwatchStarts) Once we are done with this we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is. I have no idea how true this is about X.org X server maintenance, either now or in the future, but I definitely think it's a sign that developers have started saying this. If Gnome developers feel that X.org is going to be in hard maintenance mode almost immediately, they're probably pretty likely to also put the Gnome code that deals with X into hard maintenance mode. And public Gnome statements about this (and public action or lack of it) provide implicit support for KDE and any other desktop to move in this direction if they want to (and probably create some pressure to do so). I've known that Wayland was the future for some time, but I would still like it to not arrive any time soon. Beastie Bits Porting NetBSD to Risc-V -- Video (https://www.youtube.com/watch?v=2vQXGomKoxA) FreeBSD 11.3RC3 Available (https://www.freebsd.org/news/newsflash.html#event20190628:01) Open Source Could Be a Casualty of the Trade War (https://www.bunniestudios.com/blog/?p=5590) Celebrate UNIX50 and SDF32 (https://sdf.org/sdf32/) doas environmental security (https://undeadly.org/cgi?action=article;sid=20190621104048) Feedback/Questions Matt - BSD or Older Hardware (http://dpaste.com/1RP09F0#wrap) MJRodriguez - Some Playstation news (http://dpaste.com/046SPPB#wrap) Moritz - bhyve VT-x passthrough (http://dpaste.com/1H4PJXW) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.
OpenZFS-kmod port available, using blacklistd with NPF as fail2ban replacement, ZFS raidz expansion alpha preview 1, audio VU-meter increases CO2 footprint rant, XSAVE and compat32 kernel work for LLDB, where icons for modern X applications come from, and more. Headlines ZFSonFreeBSD ports renamed OpenZFS (https://www.freshports.org/sysutils/openzfs-kmod) The ZFS on FreeBSD project has renamed the userland and kernel ports from zol and zol-kmod to openzfs and openzfs-kmod The new versions from this week are IOCTL compatible with the command line tools in FreeBSD 12.0, so you can use the old userland with the new kernel module (although obviously not the new features) With the renaming it is easier to specify which kernel module you want to load in /boot/loader.conf: > zfs_load=”YES” or > openzfs_load=”YES” To load traditional or the newer version of ZFS The kmod still requires FreeBSD 12-stable or 13-current because it depends on the newer crypto support in the kernel for the ZFS native encryption feature. Allan is looking at ways to work around this, but it may not be practical. We would like to do an unofficial poll on how people would the userland to co-exist. Add a suffix to the new commands in /usr/local (zfs.new zpool.new or whatever). One idea i’ve had is to move the zfs and zpool commands to /libexec and make /sbin/zfs and /sbin/zpool a switcher script, that will call the base or ports version based on a config file (or just based on if the port is installed) For testing purposes, generally you should be fine as long as you don’t run ‘zpool upgrade’, which will make your pool only importable using the newer ZFS. For extra safety, you can create a ‘zpool checkpoint’, which will allow you to undo any changes that are made to the pool during your testing with the new openzfs tools. Note: the checkpoint will undo EVERYTHING. So don’t save new data you want to keep. Note: Checkpoints disable all freeing operations, to prevent any data from being overwritten so that you can re-import at the checkpoint and undo any operation (including zfs destroy-ing a dataset), so also be careful you don’t run out of space during testing. Please test and provide feedback. How to use blacklistd(8) with NPF as a fail2ban replacement (https://www.unitedbsd.com/d/63-how-to-use-blacklistd8-with-npf-as-a-fail2ban-replacement) About blacklistd(8) blacklistd(8) provides an API that can be used by network daemons to communicate with a packet filter via a daemon to enforce opening and closing ports dynamically based on policy. The interface to the packet filter is in /libexec/blacklistd-helper (this is currently designed for npf) and the configuration file (inspired from inetd.conf) is in etc/blacklistd.conf Now, blacklistd(8) will require bpfjit(4) (Just-In-Time compiler for Berkeley Packet Filter) in order to properly work, in addition to, naturally, npf(7) as frontend and syslogd(8), as a backend to print diagnostic messages. Also remember npf shall rely on the npflog* virtual network interface to provide logging for tcpdump() to use. Unfortunately (dont' ask me why :P) in 8.1 all the required kernel components are still not compiled by default in the GENERIC kernel (though they are in HEAD), and are rather provided as modules. Enabling NPF and blacklistd services would normally result in them being automatically loaded as root, but predictably on securelevel=1 this is not going to happen News Roundup [WIP] raidz expansion, alpha preview 1 (https://github.com/zfsonlinux/zfs/pull/8853) Motivation and Context > This is a alpha-quality preview of RAID-Z expansion. This feature allows disks to be added one at a time to a RAID-Z group, expanding its capacity incrementally. This feature is especially useful for small pools (typically with only one RAID-Z group), where there isn't sufficient hardware to add capacity by adding a whole new RAID-Z group (typically doubling the number of disks). > For additional context as well as a design overview, see my short talk from the 2017 OpenZFS Developer Summit: slides video Rant: running audio VU-meter increases my CO2 footprint (https://medium.com/@MartinCracauer/bug-rant-running-audio-vu-meter-increases-my-co2-footprint-871d5c1bee5a) A couple months ago I noticed that the monitor on my workstation never power off anymore. Screensaver would go on, but DPMs (to do the poweroff) never kicked in. I grovels the output of various tools that display DPMS settings, which as usual in Xorg were useless. Everybody said DPMS is on with a timeout. I even wrote my own C program to use every available Xlib API call and even the xscreensaver library calls. (should make it available) No go, everybody says that DPMs is on, enabled and set on a timeout. Didn’t matter whether I let xscreeensaver do the job or just the X11 server. After a while I noticed that DPMS actually worked between starting my X11 server and starting all my clients. I have a minimal .xinitrc and start the actual session from a script, that is how I could notice. If I used a regular desktop login I wouldn’t have noticed. A server state bug was much more likely than a client bug. + See the article for the rest... XSAVE and compat32 kernel work for LLDB (http://blog.netbsd.org/tnf/entry/xsave_and_compat32_kernel_work) Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages. In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support and lately extending NetBSD's ptrace interface to cover more register types. You can read more about that in my Apr 2019 report. In May, I was primarily continuing the work on new ptrace interface. Besides that, I've found and fixed a bug in ptrace() compat32 code, pushed LLVM buildbot to ‘green’ status and found some upstream LLVM regressions. More below. Some things about where icons for modern X applications come from (https://utcc.utoronto.ca/~cks/space/blog/unix/ModernXAppIcons) If you have a traditional window manager like fvwm, one of the things it can do is iconify X windows so that they turn into icons on the root window (which would often be called the 'desktop'). Even modern desktop environments that don't iconify programs to the root window (or their desktop) may have per-program icons for running programs in their dock or taskbar. If your window manager or desktop environment can do this, you might reasonably wonder where those icons come from by default. Although I don't know how it was done in the early days of X, the modern standard for this is part of the Extended Window Manager Hints. In EWMH, applications give the window manager a number of possible icons, generally in different sizes, as ARGB bitmaps (instead of, say, SVG format). The window manager or desktop environment can then pick whichever icon size it likes best, taking into account things like the display resolution and so on, and display it however it wants to (in its original size or scaled up or down). How this is communicated in specific is through the only good interprocess communication method that X supplies, namely X properties. In the specific case of icons, the NETWMICON property is what is used, and xprop can display the size information and an ASCII art summary of what each icon looks like. It's also possible to use some additional magic to read out the raw data from _NETWM_ICON in a useful format; see, for example, this Stackoverflow question and its answers. Beastie Bits Recent Security Innovations (http://undeadly.org/cgi?action=article;sid=20190605110020) Old Unix books + Solaris (https://imgur.com/a/HbSYtQI) Pro-Desktop - A Tiling Desktop Environment (https://bitcannon.net/post/pro-desktop/) The Tar Pipe (https://blog.extracheese.org/2010/05/the-tar-pipe.html) At least one vim trick you might not know (https://www.hillelwayne.com/post/intermediate-vim/) Feedback/Questions Johnny - listener feedback (http://dpaste.com/0ZQCQ8Y#wrap) Brian - Questions (http://dpaste.com/1843RNX#wrap) Mark - ZFS Question (http://dpaste.com/3M83X9G#wrap) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Your browser does not support the HTML5 video tag.
The following instructions are for Arch Linux without Xorg (so essentially terminal only arch or what you get after a fresh Arch Linux install). If you are using Ubuntu server or another distro, the steps should be close to the same. But not exact so please do your research. You may get lucky and just have to edit the config file. --- Support this podcast: https://anchor.fm/hackerculture/support
¿Conoces el hardware de tu ordenador?¿Conoces que herramientas tienes en Linux para descubrir el hardware de tu equipo? En este nuevo episodio del podcast, te hablo de diferentes herramientas tanto gráficas, como para el terminal, que te permitirán obtener información sobre el hardware que tienes instalado en tu equipo. Conocer el hardware de tu ordenador es una obligación, pero no tienes porque saberlo de memoria. Simplemente se trata de que tengas las herramientas adecuadas para obtener esta información cuando la necesites. De esta manera, si quieres cambiar algún componente, si quieres reemplazar la memoria RAM o el disco duro mecánico por uno de estado sólido, necesitarás información sobre el hardware de tu ordenador. Aplicaciones gráficas para conoce el hardware de tu ordenador CPU-G CPU-G es una aplicación pensada para darte información sobre el hardware de tu ordenador, desarrollada inicialmente por Fotis Tsamis y posteriormente por Michael Schmöller, Michał Głowienka y Michał Olber. En el momento de escribir este artículo, prácticamente habían transcurrido casi 3 años desde que decidí retomar este proyecto y migrarlo a Python 3 y GTK+3. Desde entonces he incluido distintas mejoras y actualizaciones, algunas bastante interesantes y que han mejorado sensiblemente la aplicación. Cambios introducidos en esta versión... I-Nex I-Nex es una herramienta que recopila información sobre el hardware de tu ordenador y te lo muestra utilizando un interfaz similar a la popular aplicación de Windows CPU-Z. Lo cierto es que yo no he visto esta popular aplicación Windows, con lo que no te puedo confirmar esta afirmación de los desarrolladores de I-Nex. Lo que si te puedo garantizar es que hoy en día, esta aplicación se ve antigua. I-Nex muestra información de los siguientes componentes, CPU GPU Placa madre Sonido Discos duros RAM Red USB También muestra otra información relevante sobre otros aspectos, no menos importantes, como la distribución Linux que estás utilizando. O sobre la versión de Xorg, GCC y GLX. Así como información relativa al núclo de Linux. Además de todo esto, I-Nex genera informes donde recopila la información que selecciones relativa al hardware instalado en tu equipo. Y opcionalmente, si así lo deseas, la puede enviar a servicios como Pastebin. Respecto al tema de los informes, decirte que he intentado generar uno y ha sido imposible. En los diferentes intentos siempre me arrojaba un error. Mucha mas información en las notas del podcast sobre aplicaciones para conocer el hardware de tu ordenador
¿Conoces el hardware de tu ordenador?¿Conoces que herramientas tienes en Linux para descubrir el hardware de tu equipo? En este nuevo episodio del podcast, te hablo de diferentes herramientas tanto gráficas, como para el terminal, que te permitirán obtener información sobre el hardware que tienes instalado en tu equipo. Conocer el hardware de tu ordenador es una obligación, pero no tienes porque saberlo de memoria. Simplemente se trata de que tengas las herramientas adecuadas para obtener esta información cuando la necesites. De esta manera, si quieres cambiar algún componente, si quieres reemplazar la memoria RAM o el disco duro mecánico por uno de estado sólido, necesitarás información sobre el hardware de tu ordenador. Aplicaciones gráficas para conoce el hardware de tu ordenador CPU-G CPU-G es una aplicación pensada para darte información sobre el hardware de tu ordenador, desarrollada inicialmente por Fotis Tsamis y posteriormente por Michael Schmöller, Michał Głowienka y Michał Olber. En el momento de escribir este artículo, prácticamente habían transcurrido casi 3 años desde que decidí retomar este proyecto y migrarlo a Python 3 y GTK+3. Desde entonces he incluido distintas mejoras y actualizaciones, algunas bastante interesantes y que han mejorado sensiblemente la aplicación. Cambios introducidos en esta versión... I-Nex I-Nex es una herramienta que recopila información sobre el hardware de tu ordenador y te lo muestra utilizando un interfaz similar a la popular aplicación de Windows CPU-Z. Lo cierto es que yo no he visto esta popular aplicación Windows, con lo que no te puedo confirmar esta afirmación de los desarrolladores de I-Nex. Lo que si te puedo garantizar es que hoy en día, esta aplicación se ve antigua. I-Nex muestra información de los siguientes componentes, CPU GPU Placa madre Sonido Discos duros RAM Red USB También muestra otra información relevante sobre otros aspectos, no menos importantes, como la distribución Linux que estás utilizando. O sobre la versión de Xorg, GCC y GLX. Así como información relativa al núclo de Linux. Además de todo esto, I-Nex genera informes donde recopila la información que selecciones relativa al hardware instalado en tu equipo. Y opcionalmente, si así lo deseas, la puede enviar a servicios como Pastebin. Respecto al tema de los informes, decirte que he intentado generar uno y ha sido imposible. En los diferentes intentos siempre me arrojaba un error. Mucha mas información en las notas del podcast sobre aplicaciones para conocer el hardware de tu ordenador
Thoughts on NetBSD 8.0, Monitoring love for a GigaBit OpenBSD firewall, cat’s source history, X.org root permission bug, thoughts on OpenBSD as a desktop, and NomadBSD review. ##Headlines Some thoughts on NetBSD 8.0 NetBSD is a highly portable operating system which can be run on dozens of different hardware architectures. The operating system’s clean and minimal design allow it to be run in all sorts of environments, ranging from embedded devices, to servers, to workstations. While the base operating system is minimal, NetBSD users have access to a large repository of binary packages and a ports tree which I will touch upon later. I last tried NetBSD 7.0 about three years ago and decided it was time to test drive the operating system again. In the past three years NetBSD has introduced a few new features, many of them security enhancements. For example, NetBSD now supports write exclusive-or execute (W^X) protection and address space layout randomization (ASLR) to protect programs against common attacks. NetBSD 8.0 also includes USB3 support and the ability to work with ZFS storage volumes. Early impressions Since I had set up NetBSD with a Full install and enabled xdm during the setup process, the operating system booted to a graphical login screen. From here we can sign into our account. The login screen does not provide options to shut down or restart the computer. Logging into our account brings up the twm window manager and provides a virtual terminal, courtesy of xterm. There is a panel that provides a method for logging out of the window manager. The twm environment is sparse, fast and devoid of distractions. Software management NetBSD ships with a fairly standard collection of command line tools and manual pages, but otherwise it is a fairly minimal platform. If we want to run network services, have access to a web browser, or use a word processor we are going to need to install more software. There are two main approaches to installing new packages. The first, and easier approach, is to use the pkgin package manager. The pkgin utility works much the same way APT or DNF work in the Linux world, or as pkg works on FreeBSD. We can search for software by name, install or remove items. I found pkgin worked well, though its output can be terse. My only complaint with pkgin is that it does not handle “close enough” package names. For example, if I tried to run “pkgin install vlc” or “pkgin install firefox” I would quickly be told these items did not exist. But a more forgiving package manager will realize items like vlc2 or firefox45 are available and offer to install those. The pkgin tool installs new programs in the /usr/pkg/bin directory. Depending on your configuration and shell, this location may not be in your user’s path, and it will be helpful to adjust your PATH variable accordingly. The other common approach to acquiring new software is to use the pkgsrc framework. I have talked about using pkgsrc before and I will skip the details. Basically, we can download a collection of recipes for building popular open source software and run a command to download and install these items from their source code. Using pkgsrc basically gives us the same software as using pkgin would, but with some added flexibility on the options we use. Once new software has been installed, it may need to be enabled and activated, particularly if it uses (or is) a background service. New items can be enabled in the /etc/rc.conf file and started or stopped using the service command. This works about the same as the service command on FreeBSD and most non-systemd Linux distributions. Hardware I found that, when logged into the twm environment, NetBSD used about 130MB of RAM. This included kernel memory and all active memory. A fresh, Full install used up 1.5GB of disk space. I generally found NetBSD ran well in both VirtualBox and on my desktop computer. The system was quick and stable. I did have trouble getting a higher screen resolution in both environments. NetBSD does not offer VirtualBox add-on modules. There are NetBSD patches for VirtualBox out there, but there is some manual work involved in getting them working. When running on my desktop computer I think the resolution issue was one of finding and dealing with the correct video driver. Screen resolution aside, NetBSD performed well and detected all my hardware. Personal projects Since NetBSD provides users with a small, core operating system without many utilities if we want to use NetBSD for something we need to have a project in mind. I had four mini projects in mind I wanted to try this week: install a desktop environment, enable file sharing for computers on the local network, test multimedia (video, audio and YouTube capabilities), and set up a ZFS volume for storage. I began with the desktop. Specifically, I followed the same tutorial I used three years ago to try to set up the Xfce desktop. While Xfce and its supporting services installed, I was unable to get a working desktop out of the experience. I could get the Xfce window manager working, but not the entire session. This tutorial worked beautifully with NetBSD 7.0, but not with version 8.0. Undeterred, I switched gears and installed Fluxbox instead. This gave me a slightly more powerful graphical environment than what I had before with twm while maintaining performance. Fluxbox ran without any problems, though its application menu was automatically populated with many programs which were not actually installed. Next, I tried installing a few multimedia applications to play audio and video files. Here I ran into a couple of interesting problems. I found the music players I installed would play audio files, but the audio was quite slow. It always sounded like a cassette tape dragging. When I tried to play a video, the entire graphical session would crash, taking me back to the login screen. When I installed Firefox, I found I could play YouTube videos, and the video played smoothly, but again the audio was unusually slow. I set up two methods of sharing files on the local network: OpenSSH and FTP. NetBSD basically gives us OpenSSH for free at install time and I added an FTP server through the pkgin package manager which worked beautifully with its default configuration. I experimented with ZFS support a little, just enough to confirm I could create and access ZFS volumes. ZFS seems to work on NetBSD just as well, and with the same basic features, as it does on FreeBSD and mainstream Linux distributions. I think this is a good feature for the portable operating system to have since it means we can stick NetBSD on nearly any networked computer and use it as a NAS. Conclusions NetBSD, like its close cousins (FreeBSD and OpenBSD) does not do a lot of hand holding or automation. It offers a foundation that will run on most CPUs and we can choose to build on that foundation. I mention this because, on its own, NetBSD does not do much. If we want to get something out of it, we need to be willing to build on its foundation - we need a project. This is important to keep in mind as I think going into NetBSD and thinking, “Oh I’ll just explore around and expand on this as I go,” will likely lead to disappointment. I recommend figuring out what you want to do before installing NetBSD and making sure the required tools are available in the operating system’s repositories. Some of the projects I embarked on this week (using ZFS and setting up file sharing) worked well. Others, like getting multimedia support and a full-featured desktop, did not. Given more time, I’m sure I could find a suitable desktop to install (along with the required documentation to get it and its services running), or customize one based on one of the available window managers. However, any full featured desktop is going to require some manual work. Media support was not great. The right players and codecs were there, but I was not able to get audio to play smoothly. My main complaint with NetBSD relates to my struggle to get some features working to my satisfaction: the documentation is scattered. There are four different sections of the project’s website for documentation (FAQs, The Guide, manual pages and the wiki). Whatever we are looking for is likely to be in one of those, but which one? Or, just as likely, the tutorial we want is not there, but is on a forum or blog somewhere. I found that the documentation provided was often thin, more of a quick reference to remind people how something works rather than a full explanation. As an example, I found a couple of documents relating to setting up a firewall. One dealt with networking NetBSD on a LAN, another explored IPv6 support, but neither gave an overview on syntax or a basic guide to blocking all but one or two ports. It seemed like that information should already be known, or picked up elsewhere. Newcomers are likely to be a bit confused by software management guides for the same reason. Some pages refer to using a tool called pkg_add, others use pkgsrc and its make utility, others mention pkgin. Ultimately, these tools each give approximately the same result, but work differently and yet are mentioned almost interchangeably. I have used NetBSD before a few times and could stumble through these guides, but new users are likely to come away confused. One quirk of NetBSD, which may be a security feature or an inconvenience, depending on one’s point of view, is super user programs are not included in regular users’ paths. This means we need to change our path if we want to be able to run programs typically used by root. For example, shutdown and mount are not in regular users’ paths by default. This made checking some things tricky for me. Ultimately though, NetBSD is not famous for its convenience or features so much as its flexibility. The operating system will run on virtually any processor and should work almost identically across multiple platforms. That gives NetBSD users a good deal of consistency across a range of hardware and the chance to experiment with a member of the Unix family on hardware that might not be compatible with Linux or the other BSDs. ###Showing a Gigabit OpenBSD Firewall Some Monitoring Love I have a pretty long history of running my home servers or firewalls on “exotic” hardware. At first, it was Sun Microsystem hardware, then it moved to the excellent Soekris line, with some cool single board computers thrown in the mix. Recently I’ve been running OpenBSD Octeon on the Ubiquiti Edge Router Lite, an amazing little piece of kit at an amazing price point. Upgrade Time! This setup has served me for some time and I’ve been extremely happy with it. But, in the #firstworldproblems category, I recently upgraded the household to the amazing Gigabit fibre offering from Sonic. A great problem to have, but also too much of a problem for the little Edge Router Lite (ERL). The way the OpenBSD PF firewall works, it’s only able to process packets on a single core. Not a problem for the dual-core 500 MHz ERL when you’re pushing under ~200 Mbps, but more of a problem when you’re trying to push 1000 Mbps. I needed something that was faster on a per core basis but still satisfied my usual firewall requirements. Loosely: small form factor fan-less multiple Intel Ethernet ports (good driver support) low power consumption not your regular off-the-shelf kit relatively inexpensive After evaluating a LOT of different options I settled on the Protectli Vault FW2B. With the specs required for the firewall (2 GB RAM and 8 GB drive) it comes in at a mere $239 USD! Installation of OpenBSD 6.4 was pretty straight forward, with the only problem I had was Etcher did not want to recognize the ‘.fs’ extension on the install image as bootable image. I quickly fixed this with good old Unix dd(1) on the Mac. Everything else was incredibly smooth. After loading the same rulesets on my new install, the results were fantastic! Monitoring Now that the machine was up and running (and fast!), I wanted to know what it was doing. Over the years, I’ve always relied on the venerable pfstat software to give me an overview of my traffic, blocked packets, etc. It looks like this: As you can see it’s based on RRDtool, which was simply incredible in its time. Having worked on monitoring almost continuously for almost the past decade, I wanted to see if we could re-implement the same functionality using more modern tools as RRDtool and pfstat definitely have their limitations. This might be an opportunity to learn some new things as well. I came across pf-graphite which seemed to be a great start! He had everything I needed and I added a few more stats from the detailed interface statistics and the ability for the code to exit for running from cron(8), which is a bit more OpenBSD style. I added code for sending to some SaaS metrics platforms but ultimately stuck with straight Graphite. One important thing to note was to use the Graphite pickle port (2004) instead of the default plaintext port for submission. Also you will need to set a loginterface in your ‘pf.conf’. A bit of tweaking with Graphite and Grafana, and I had a pretty darn good recreation of my original PF stats dashboard! As you can see it’s based on RRDtool, which was simply incredible in its time. Having worked on monitoring almost continuously for almost the past decade, I wanted to see if we could re-implement the same functionality using more modern tools as RRDtool and pfstat definitely have their limitations. This might be an opportunity to learn some new things as well. I came across pf-graphite which seemed to be a great start! He had everything I needed and I added a few more stats from the detailed interface statistics and the ability for the code to exit for running from cron(8), which is a bit more OpenBSD style. I added code for sending to some SaaS metrics platforms but ultimately stuck with straight Graphite. One important thing to note was to use the Graphite pickle port (2004) instead of the default plaintext port for submission. Also you will need to set a loginterface in your ‘pf.conf’. A bit of tweaking with Graphite and Grafana, and I had a pretty darn good recreation of my original PF stats dashboard! ###The Source History of Cat I once had a debate with members of my extended family about whether a computer science degree is a degree worth pursuing. I was in college at the time and trying to decide whether I should major in computer science. My aunt and a cousin of mine believed that I shouldn’t. They conceded that knowing how to program is of course a useful and lucrative thing, but they argued that the field of computer science advances so quickly that everything I learned would almost immediately be outdated. Better to pick up programming on the side and instead major in a field like economics or physics where the basic principles would be applicable throughout my lifetime. I knew that my aunt and cousin were wrong and decided to major in computer science. (Sorry, aunt and cousin!) It is easy to see why the average person might believe that a field like computer science, or a profession like software engineering, completely reinvents itself every few years. We had personal computers, then the web, then phones, then machine learning… technology is always changing, so surely all the underlying principles and techniques change too. Of course, the amazing thing is how little actually changes. Most people, I’m sure, would be stunned to know just how old some of the important software on their computer really is. I’m not talking about flashy application software, admittedly—my copy of Firefox, the program I probably use the most on my computer, is not even two weeks old. But, if you pull up the manual page for something like grep, you will see that it has not been updated since 2010 (at least on MacOS). And the original version of grep was written in 1974, which in the computing world was back when dinosaurs roamed Silicon Valley. People (and programs) still depend on grep every day. My aunt and cousin thought of computer technology as a series of increasingly elaborate sand castles supplanting one another after each high tide clears the beach. The reality, at least in many areas, is that we steadily accumulate programs that have solved problems. We might have to occasionally modify these programs to avoid software rot, but otherwise they can be left alone. grep is a simple program that solves a still-relevant problem, so it survives. Most application programming is done at a very high level, atop a pyramid of much older code solving much older problems. The ideas and concepts of 30 or 40 years ago, far from being obsolete today, have in many cases been embodied in software that you can still find installed on your laptop. I thought it would be interesting to take a look at one such old program and see how much it had changed since it was first written. cat is maybe the simplest of all the Unix utilities, so I’m going to use it as my example. Ken Thompson wrote the original implementation of cat in 1969. If I were to tell somebody that I have a program on my computer from 1969, would that be accurate? How much has cat really evolved over the decades? How old is the software on our computers? Thanks to repositories like this one, we can see exactly how cat has evolved since 1969. I’m going to focus on implementations of cat that are ancestors of the implementation I have on my Macbook. You will see, as we trace cat from the first versions of Unix down to the cat in MacOS today, that the program has been rewritten more times than you might expect—but it ultimately works more or less the same way it did fifty years ago. Research Unix Ken Thompson and Dennis Ritchie began writing Unix on a PDP 7. This was in 1969, before C, so all of the early Unix software was written in PDP 7 assembly. The exact flavor of assembly they used was unique to Unix, since Ken Thompson wrote his own assembler that added some features on top of the assembler provided by DEC, the PDP 7’s manufacturer. Thompson’s changes are all documented in the original Unix Programmer’s Manual under the entry for as, the assembler. The first implementation of cat is thus in PDP 7 assembly. I’ve added comments that try to explain what each instruction is doing, but the program is still difficult to follow unless you understand some of the extensions Thompson made while writing his assembler. There are two important ones. First, the ; character can be used to separate multiple statements on the same line. It appears that this was used most often to put system call arguments on the same line as the sys instruction. Second, Thompson added support for “temporary labels” using the digits 0 through 9. These are labels that can be reused throughout a program, thus being, according to the Unix Programmer’s Manual, “less taxing both on the imagination of the programmer and on the symbol space of the assembler.” From any given instruction, you can refer to the next or most recent temporary label n using nf and nb respectively. For example, if you have some code in a block labeled 1:, you can jump back to that block from further down by using the instruction jmp 1b. (But you cannot jump forward to that block from above without using jmp 1f instead.) The most interesting thing about this first version of cat is that it contains two names we should recognize. There is a block of instructions labeled getc and a block of instructions labeled putc, demonstrating that these names are older than the C standard library. The first version of cat actually contained implementations of both functions. The implementations buffered input so that reads and writes were not done a character at a time. The first version of cat did not last long. Ken Thompson and Dennis Ritchie were able to persuade Bell Labs to buy them a PDP 11 so that they could continue to expand and improve Unix. The PDP 11 had a different instruction set, so cat had to be rewritten. I’ve marked up this second version of cat with comments as well. It uses new assembler mnemonics for the new instruction set and takes advantage of the PDP 11’s various addressing modes. (If you are confused by the parentheses and dollar signs in the source code, those are used to indicate different addressing modes.) But it also leverages the ; character and temporary labels just like the first version of cat, meaning that these features must have been retained when as was adapted for the PDP 11. The second version of cat is significantly simpler than the first. It is also more “Unix-y” in that it doesn’t just expect a list of filename arguments—it will, when given no arguments, read from stdin, which is what cat still does today. You can also give this version of cat an argument of - to indicate that it should read from stdin. In 1973, in preparation for the release of the Fourth Edition of Unix, much of Unix was rewritten in C. But cat does not seem to have been rewritten in C until a while after that. The first C implementation of cat only shows up in the Seventh Edition of Unix. This implementation is really fun to look through because it is so simple. Of all the implementations to follow, this one most resembles the idealized cat used as a pedagogic demonstration in K&R C. The heart of the program is the classic two-liner: while ((c = getc(fi)) != EOF) putchar(c); There is of course quite a bit more code than that, but the extra code is mostly there to ensure that you aren’t reading and writing to the same file. The other interesting thing to note is that this implementation of cat only recognized one flag, -u. The -u flag could be used to avoid buffering input and output, which cat would otherwise do in blocks of 512 bytes. BSD After the Seventh Edition, Unix spawned all sorts of derivatives and offshoots. MacOS is built on top of Darwin, which in turn is derived from the Berkeley Software Distribution (BSD), so BSD is the Unix offshoot we are most interested in. BSD was originally just a collection of useful programs and add-ons for Unix, but it eventually became a complete operating system. BSD seems to have relied on the original cat implementation up until the fourth BSD release, known as 4BSD, when support was added for a whole slew of new flags. The 4BSD implementation of cat is clearly derived from the original implementation, though it adds a new function to implement the behavior triggered by the new flags. The naming conventions already used in the file were adhered to—the fflg variable, used to mark whether input was being read from stdin or a file, was joined by nflg, bflg, vflg, sflg, eflg, and tflg, all there to record whether or not each new flag was supplied in the invocation of the program. These were the last command-line flags added to cat; the man page for cat today lists these flags and no others, at least on Mac OS. 4BSD was released in 1980, so this set of flags is 38 years old. cat would be entirely rewritten a final time for BSD Net/2, which was, among other things, an attempt to avoid licensing issues by replacing all AT&T Unix-derived code with new code. BSD Net/2 was released in 1991. This final rewrite of cat was done by Kevin Fall, who graduated from Berkeley in 1988 and spent the next year working as a staff member at the Computer Systems Research Group (CSRG). Fall told me that a list of Unix utilities still implemented using AT&T code was put up on a wall at CSRG and staff were told to pick the utilities they wanted to reimplement. Fall picked cat and mknod. The cat implementation bundled with MacOS today is built from a source file that still bears his name at the very top. His version of cat, even though it is a relatively trivial program, is today used by millions. Fall’s original implementation of cat is much longer than anything we have seen so far. Other than support for a -? help flag, it adds nothing in the way of new functionality. Conceptually, it is very similar to the 4BSD implementation. It is only longer because Fall separates the implementation into a “raw” mode and a “cooked” mode. The “raw” mode is cat classic; it prints a file character for character. The “cooked” mode is cat with all the 4BSD command-line options. The distinction makes sense but it also pads out the implementation so that it seems more complex at first glance than it actually is. There is also a fancy error handling function at the end of the file that further adds to its length. MacOS The very first release of Mac OS X thus includes an implementation of cat pulled from the NetBSD project. So the first Mac OS X implementation of cat is Kevin Fall’s cat. The only thing that had changed over the intervening decade was that Fall’s error-handling function err() was removed and the err() function made available by err.h was used in its place. err.h is a BSD extension to the C standard library. The NetBSD implementation of cat was later swapped out for FreeBSD’s implementation of cat. According to Wikipedia, Apple began using FreeBSD instead of NetBSD in Mac OS X 10.3 (Panther). But the Mac OS X implementation of cat, according to Apple’s own open source releases, was not replaced until Mac OS X 10.5 (Leopard) was released in 2007. The FreeBSD implementation that Apple swapped in for the Leopard release is the same implementation on Apple computers today. As of 2018, the implementation has not been updated or changed at all since 2007. So the Mac OS cat is old. As it happens, it is actually two years older than its 2007 appearance in MacOS X would suggest. This 2005 change, which is visible in FreeBSD’s Github mirror, was the last change made to FreeBSD’s cat before Apple pulled it into Mac OS X. So the Mac OS X cat implementation, which has not been kept in sync with FreeBSD’s cat implementation, is officially 13 years old. There’s a larger debate to be had about how much software can change before it really counts as the same software; in this case, the source file has not changed at all since 2005. The cat implementation used by Mac OS today is not that different from the implementation that Fall wrote for the 1991 BSD Net/2 release. The biggest difference is that a whole new function was added to provide Unix domain socket support. At some point, a FreeBSD developer also seems to have decided that Fall’s rawargs() function and cookargs() should be combined into a single function called scanfiles(). Otherwise, the heart of the program is still Fall’s code. I asked Fall how he felt about having written the cat implementation now used by millions of Apple users, either directly or indirectly through some program that relies on cat being present. Fall, who is now a consultant and a co-author of the most recent editions of TCP/IP Illustrated, says that he is surprised when people get such a thrill out of learning about his work on cat. Fall has had a long career in computing and has worked on many high-profile projects, but it seems that many people still get most excited about the six months of work he put into rewriting cat in 1989. The Hundred-Year-Old Program In the grand scheme of things, computers are not an old invention. We’re used to hundred-year-old photographs or even hundred-year-old camera footage. But computer programs are in a different category—they’re high-tech and new. At least, they are now. As the computing industry matures, will we someday find ourselves using programs that approach the hundred-year-old mark? Computer hardware will presumably change enough that we won’t be able to take an executable compiled today and run it on hardware a century from now. Perhaps advances in programming language design will also mean that nobody will understand C in the future and cat will have long since been rewritten in another language. (Though C has already been around for fifty years, and it doesn’t look like it is about to be replaced any time soon.) But barring all that, why not just keep using the cat we have forever? I think the history of cat shows that some ideas in computer science are in fact very durable. Indeed, with cat, both the idea and the program itself are old. It may not be accurate to say that the cat on my computer is from 1969. But I could make a case for saying that the cat on my computer is from 1989, when Fall wrote his implementation of cat. Lots of other software is just as ancient. So maybe we shouldn’t think of computer science and software development primarily as fields that disrupt the status quo and invent new things. Our computer systems are built out of historical artifacts. At some point, we may all spend more time trying to understand and maintain those historical artifacts than we spend writing new code. ##News Roundup Trivial Bug in X.Org Gives Root Permission on Linux and BSD Systems A vulnerability that is trivial to exploit allows privilege escalation to root level on Linux and BSD distributions using X.Org server, the open source implementation of the X Window System that offers the graphical environment. The flaw is now identified as CVE-2018-14665 (credited to security researcher Narendra Shinde). It has been present in xorg-server for two years, since version 1.19.0 and is exploitable by a limited user as long as the X server runs with elevated permissions. Privilege escalation and arbitrary file overwrite An advisory on Thursday describes the problem as an “incorrect command-line parameter validation” that also allows an attacker to overwrite arbitrary files. Privilege escalation can be accomplished via the -modulepath argument by setting an insecure path to modules loaded by the X.org server. Arbitrary file overwrite is possible through the -logfile argument, because of improper verification when parsing the option. Bug could have been avoided in OpenBSD 6.4 OpenBSD, the free and open-source operating system with a strong focus on security, uses xorg. On October 18, the project released version 6.4 of the OS, affected by CVE-2018-14665. This could have been avoided, though. Theo de Raadt, founder and leader of the OpenBSD project, says that X maintainer knew about the problem since at least October 11. For some reason, the OpenBSD developers received the message one hour before the public announcement this Thursday, a week after their new OS release. “As yet we don’t have answers about why our X maintainer (on the X security team) and his team provided information to other projects (some who don’t even ship with this new X server) but chose to not give us a heads-up which could have saved all the new 6.4 users a lot of grief,” Raadt says. Had OpenBSD developers known about the bug before the release, they could have taken steps to mitigate the problem or delay the launch for a week or two. To remedy the problem, the OpenBSD project provides a source code patch, which requires compiling and rebuilding the X server. As a temporary solution, users can disable the Xorg binary by running the following command: chmod u-s /usr/X11R6/bin/Xorg Trivial exploitation CVE-2018-14665 does not help compromise systems, but it is useful in the following stages of an attack. Leveraging it after gaining access to a vulnerable machine is fairly easy. Matthew Hickey, co-founder, and head of Hacker House security outfit created and published an exploit, saying that it can be triggered from a remote SSH session. Three hours after the public announcement of the security gap, Daemon Security CEO Michael Shirk replied with one line that overwrote shadow files on the system. Hickey did one better and fit the entire local privilege escalation exploit in one line. Apart from OpenBSD, other operating systems affected by the bug include Debian and Ubuntu, Fedora and its downstream distro Red Hat Enterprise Linux along with its community-supported counterpart CentOS. ###OpenBSD on the Desktop: some thoughts I’ve been using OpenBSD on my ThinkPad X230 for some weeks now, and the experience has been peculiar in some ways. The OS itself in my opinion is not ready for widespread desktop usage, and the development team is not trying to push it in the throat of anybody who wants a Windows or macOS alternative. You need to understand a little bit of how *NIX systems work, because you’ll use CLI more than UI. That’s not necessarily bad, and I’m sure I learned a trick or two that could translate easily to Linux or macOS. Their development process is purely based on developers that love to contribute and hack around, just because it’s fun. Even the mailing list is a cool place to hang on! Code correctness and security are a must, nothing gets committed if it doesn’t get reviewed thoroughly first - nowadays the first two properties should be enforced in every major operating system. I like the idea of a platform that continually evolves. pledge(2) and unveil(2) are the proof that with a little effort, you can secure existing software better than ever. I like the “sensible defaults” approach, having an OS ready to be used - UI included if you selected it during the setup process - is great. Just install a browser and you’re ready to go. Manual pages on OpenBSD are real manuals, not an extension of the “–help” command found in most CLI softwares. They help you understand inner workings of the operating system, no internet connection needed. There are some trade-offs, too. Performance is not first-class, mostly because of all the security mitigations and checks done at runtime3. I write Go code in neovim, and sometimes you can feel a slight slowdown when you’re compiling and editing multiple files at the same time, but usually I can’t notice any meaningful difference. Browsers are a different matter though, you can definitely feel something differs from the experience you can have on mainstream operating systems. But again, trade-offs. To use OpenBSD on the desktop you must be ready to sacrifice some of the goodies of mainstream OSes, but if you’re searching for a zen place to do your computing stuff, it’s the best you can get right now. ###Review: NomadBSD 1.1 One of the most recent additions to the DistroWatch database is NomadBSD. According to the NomadBSD website: “NomadBSD is a 64-bit live system for USB flash drives, based on FreeBSD. Together with automatic hardware detection and setup, it is configured to be used as a desktop system that works out of the box, but can also be used for data recovery.” The latest release of NomadBSD (or simply “Nomad”, as I will refer to the project in this review) is version 1.1. It is based on FreeBSD 11.2 and is offered in two builds, one for generic personal computers and one for Macbooks. The release announcement mentions version 1.1 offers improved video driver support for Intel and AMD cards. The operating system ships with Octopkg for graphical package management and the system should automatically detect, and work with, VirtualBox environments. Nomad 1.1 is available as a 2GB download, which we then decompress to produce a 4GB file which can be written to a USB thumb drive. There is no optical media build of Nomad as it is designed to be run entirely from the USB drive, and write data persistently to the drive, rather than simply being installed from the USB media. Initial setup Booting from the USB drive brings up a series of text-based menus which ask us to configure key parts of the operating system. We are asked to select our time zone, keyboard layout, keyboard model, keyboard mapping and our preferred language. While we can select options from a list, the options tend to be short and cryptic. Rather than “English (US)”, for example, we might be given “enUS”. We are also asked to create a password for the root user account and another one for a regular user which is called “nomad”. We can then select which shell nomad will use. The default is zsh, but there are plenty of other options, including csh and bash. We have the option of encrypting our user’s home directory. I feel it is important to point out that these settings, and nomad’s home directory, are stored on the USB drive. The options and settings we select will not be saved to our local hard drive and our configuration choices will not affect other operating systems already installed on our computer. At the end, the configuration wizard asks if we want to run the BSDstats service. This option is not explained at all, but it contacts BSDstats to provide some basic statistics on BSD users. The system then takes a few minutes to apply its changes to the USB drive and automatically reboots the computer. While running the initial setup wizard, I had nearly identical experiences when running Nomad on a physical computer and running the operating system in a VirtualBox virtual machine. However, after the initial setup process was over, I had quite different experiences depending on the environment so I want to divide my experiences into two different sections. Physical desktop computer At first, Nomad failed to boot on my desktop computer. From the operating system’s boot loader, I enabled Safe Mode which allowed Nomad to boot. At that point, Nomad was able to start up, but would only display a text console. The desktop environment failed to start when running in Safe Mode. Networking was also disabled by default and I had to enable a network interface and DHCP address assignment to connect to the Internet. Instructions for enabling networking can be found in FreeBSD’s Handbook. Once we are on-line we can use the pkg command line package manager to install and update software. Had the desktop environment worked then the Octopkg graphical package manager would also be available to make browsing and installing software a point-n-click experience. Had I been able to run the desktop for prolonged amounts of time I could have made use of such pre-installed items as the Firefox web browser, the VLC media player, LibreOffice and Thunderbird. Nomad offers a fairly small collection of desktop applications, but what is there is mostly popular, capable software. When running the operating system I noted that, with one user logged in, Nomad only runs 15 processes with the default configuration. These processes require less than 100MB of RAM, and the whole system fits comfortably on a 4GB USB drive. Conclusions Ultimately using Nomad was not a practical option for me. The operating system did not work well with my hardware, or the virtual environment. In the virtual machine, Nomad crashed consistently after just a few minutes of uptime. On the desktop computer, I could not get a desktop environment to run. The command line tools worked well, and the system performed tasks very quickly, but a command line only environment is not well suited to my workflow. I like the idea of what NomadBSD is offering. There are not many live desktop flavours of FreeBSD, apart from GhostBSD. It was nice to see developers trying to make a FreeBSD-based, plug-and-go operating system that would offer a desktop and persistent storage. I suspect the system would work and perform its stated functions on different hardware, but in my case my experiment was necessarily short lived. ##Beastie Bits FreeBSD lockless algorithm - seq Happy Bob’s Libtls tutorial Locking OpenBSD when it’s sleeping iio - The OpenBSD Way Installing Hugo and Hosting Website on OpenBSD Server Fosdem 2019 reminder: BSD devroom CfP OpenBGPD, gotta go fast! - Claudio Jeker Project Trident RC3 available FreeBSD 10.4 EOL Play “Crazy Train” through your APU2 speaker ##Feedback/Questions Tobias - Satisfying my storage hunger and wallet pains Lasse - Question regarding FreeBSD backups https://twitter.com/dlangille https://dan.langille.org/ Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
#10 - Escalation issues affecting xorg, multiple vulnerabilities in Mac OS and iOS kernel, and more. by FortiGuard Labs
This week we look at some details of the 61 unique CVEs addressed across the supported Ubuntu releases, with a particular focus on the recent Xorg vulnerability ([CVE-2018-14665](https://people.canonical.com/~ubuntu-security/cve/CVE-2018-14665)), plus Cosmic is now officially supported by the Security Team.
OpenBSD on Microsoft Surface Go, FreeBSD Foundation August Update, What’s taking so long with Project Trident, pkgsrc config file versioning, and MacOS remnants in ZFS code. ##Headlines OpenBSD on the Microsoft Surface Go For some reason I like small laptops and the constraints they place on me (as long as they’re still usable). I used a Dell Mini 9 for a long time back in the netbook days and was recently using an 11" MacBook Air as my primary development machine for many years. Recently Microsoft announced a smaller, cheaper version of its Surface tablets called Surface Go which piqued my interest. Hardware The Surface Go is available in two hardware configurations: one with 4Gb of RAM and a 64Gb eMMC, and another with 8Gb of RAM with a 128Gb NVMe SSD. (I went with the latter.) Both ship with an Intel Pentium Gold 4415Y processor which is not very fast, but it’s certainly usable. The tablet measures 9.65" across, 6.9" tall, and 0.3" thick. Its 10" diagonal 3:2 touchscreen is covered with Gorilla Glass and has a resolution of 1800x1200. The bezel is quite large, especially for such a small screen, but it makes sense on a device that is meant to be held, to avoid accidental screen touches. The keyboard and touchpad are located on a separate, removable slab called the Surface Go Signature Type Cover which is sold separately. I opted for the “cobalt blue” cover which has a soft, cloth-like alcantara material. The cover attaches magnetically along the bottom edge of the device and presents USB-attached keyboard and touchpad devices. When the cover is folded up against the screen, it sends an ACPI sleep signal and is held to the screen magnetically. During normal use, the cover can be positioned flat on a surface or slightly raised up about 3/4" near the screen for better ergonomics. When using the device as a tablet, the cover can be rotated behind the screen which causes it to automatically stop sending keyboard and touchpad events until it is rotated back around. The keyboard has a decent amount of key travel and a good layout, with Home/End/Page Up/Page Down being accessible via Fn+Left/Right/Up/Down but also dedicated Home/End/Page Up/Page Down keys on the F9-F12 keys which I find quite useful since the keyboard layout is somewhat small. By default, the F1-F12 keys do not send F1-F12 key codes and Fn must be used, either held down temporarily or Fn pressed by itself to enable Fn-lock which annoyingly keeps the bright Fn LED illuminated. The keys are backlit with three levels of adjustment, handled by the keyboard itself with the F7 key. The touchpad on the Type Cover is a Windows Precision Touchpad connected via USB HID. It has a decent click feel but when the cover is angled up instead of flat on a surface, it sounds a bit hollow and cheap. Surface Go Pen The touchscreen is powered by an Elantech chip connected via HID-over-i2c, which also supports pen input. A Surface Pen digitizer is available separately from Microsoft and comes in the same colors as the Type Covers. The pen works without any pairing necessary, though the top button on it works over Bluetooth so it requires pairing to use. Either way, the pen requires an AAAA battery inside it to operate. The Surface Pen can attach magnetically to the left side of the screen when not in use. A kickstand can swing out behind the display to use the tablet in a laptop form factor, which can adjust to any angle up to about 170 degrees. The kickstand stays firmly in place wherever it is positioned, which also means it requires a bit of force to pull it out when initially placing the Surface Go on a desk. Along the top of the display are a power button and physical volume rocker buttons. Along the right side are the 3.5mm headphone jack, USB-C port, power port, and microSD card slot located behind the kickstand. Charging can be done via USB-C or the dedicated charge port, which accommodates a magnetically-attached, thin barrel similar to Apple’s first generation MagSafe adapter. The charging cable has a white LED that glows when connected, which is kind of annoying since it’s near the mid-line of the screen rather than down by the keyboard. Unlike Apple’s MagSafe, the indicator light does not indicate whether the battery is charged or not. The barrel charger plug can be placed up or down, but in either direction I find it puts an awkward strain on the power cable coming out of it due to the vertical position of the port. Wireless connectivity is provided by a Qualcomm Atheros QCA6174 802.11ac chip which also provides Bluetooth connectivity. Most of the sensors on the device such as the gyroscope and ambient light sensor are connected behind an Intel Sensor Hub PCI device, which provides some power savings as the host CPU doesn’t have to poll the sensors all the time. Firmware The Surface Go’s BIOS/firmware menu can be entered by holding down the Volume Up button, then pressing and releasing the Power button, and releasing Volume Up when the menu appears. Secure Boot as well as various hardware components can be disabled in this menu. Boot order can also be adjusted. A temporary boot menu can be brought up the same way but using Volume Down instead. ###FreeBSD Foundation Update, August 2018 MESSAGE FROM THE EXECUTIVE DIRECTOR Dear FreeBSD Community Member, It’s been a busy summer for the Foundation. From traveling around the globe spreading the word about FreeBSD to bringing on new team members to improve the Project’s Continuous Integration work, we’re very excited about what we’ve accomplished. Take a minute to check out the latest updates within our Foundation sponsored projects; read more about our advocacy efforts in Bangladesh and community building in Cambridge; don’t miss upcoming Travel Grant deadlines, and new Developer Summits; and be sure to find out how your support will ensure our progress continues into 2019. We can’t do this without you! Happy reading!! Deb August 2018 Development Projects Update Fundraising Update: Supporting the Project August 2018 Release Engineering Update BSDCam 2018 Recap October 2018 FreeBSD Developer Summit Call for Participation SANOG32 and COSCUP 2018 Recap MeetBSD 2018 Travel Grant Application Deadline: September 7 ##News Roundup Project Trident: What’s taking so long? What is taking so long? The short answer is that it’s complicated. Project Trident is quite literally a test of the new TrueOS build system. As expected, there have been quite a few bugs, undocumented features, and other optional bits that we discovered we needed that were not initially present. All of these things have to be addressed and retested in a constant back and forth process. While Ken and JT are both experienced developers, neither has done this kind of release engineering before. JT has done some release engineering back in his Linux days, but the TrueOS and FreeBSD build system is very different. Both Ken and JT are learning a completely new way of building a FreeBSD/TrueOS distribution. Please keep in mind that no one has used this new TrueOS build system before, so Ken and JT want to not only provide a good Trident release, but also provide a model or template for other potential TrueOS distributions too! Where are we now? Through perseverance, trial and error, and a lot of head-scratching we have reached the point of having successful builds. It took a while to get there, but now we are simply working out a few bugs with the new installer that Ken wrote as well as finding and fixing all the new Xorg configuration options which recently landed in FreeBSD. We also found that a number of services have been removed or replaced between TrueOS 18.03 and 18.06 so we are needing to adjust what we consider the “base” services for the desktop. All of these issues are being resolved and we are continually rebuilding and pulling in new patches from TrueOS as soon as they are committed. In the meantime we have made an early BETA release of Trident available to the users in our Telegram Channel for those who want to help out in testing these early versions. Do you foresee any other delays? At the moment we are doing many iterations of testing and tweaking the install ISO and package configurations in order to ensure that all the critical functionality works out-of-box (networking, sound, video, basic apps, etc). While we do not foresee any other major delays, sometimes things happen that our outside of our control. For an example, one of the recent delays that hit recently was completely unexpected: we had a hard drive failure on our build server. Up until recently, The aptly named “Poseidon” build server was running a Micron m500dc drive, but that drive is now constantly reporting errors. Despite ordering a replacement Western Digital Blue SSD several weeks ago, we just received it this past week. The drive is now installed with the builder back to full functionality, but we did lose many precious days with the delay. The build server for Project Trident is very similar to the one that JT donated to the TrueOS project. JT had another DL580 G7, so he donated one to the Trident Project for their build server. Poseidon also has 256GB RAM (64 x 4GB sticks) which is a smidge higher than what the TrueOS builder has. Since we are talking about hardware, we probably should address another question we get often, “What Hardware are the devs testing on?” So let’s go ahead and answer that one now. Developer Hardware JT: His main test box is a custom-built Intel i7 7700K system running 32GB RAM, dual Intel Optane 900P drives, and an Nvidia 1070 GTX with four 4K Acer Monitors. He also uses a Lenovo x250 ThinkPad alongside a desk full of x230t and x220 ThinkPads. One of which he gave away at SouthEast LinuxFest this year, which you can read about here. However it’s not done there, being a complete hardware hoarder, JT also tests on several Intel NUCs and his second laptop a Fujitsu t904, not to mention a Plethora of HP DL580 servers, a DL980 server, and a stack of BL485c, BL460c, and BL490c Blades in his HP c7000 and c3000 Bladecenter chassis. (Maybe it’s time for an intervention for his hardware collecting habits) Ken: For a laptop, he primarily uses a 3rd generation X1 Carbon, but also has an old Eee PC T101MT Netbook (dual core 1GHz, 2GB of memory) which he uses for verifying how well Trident works on low-end hardware. As far as workstations go, his office computer is an Intel i7 with an NVIDIA Geforce GTX 960 running three 4K monitors and he has a couple other custom-built workstations (1 AMD, 1 Intel+NVIDIA) at his home. Generally he assembled random workstations based on hardware that was given to him or that he could acquire cheap. Tim: is using a third gen X1 Carbon and a custom built desktop with an Intel Core i5-4440 CPU, 16 GiB RAM, Nvidia GeForce GTX 750 Ti, and a RealTek 8168 / 8111 network card. Rod: Rod uses… No one knows what Rod uses, It’s kinda like how many licks does it take to get to the center of a Tootsie-Roll Tootsie-Pop… the world may just never know. ###NetBSD GSoC: pkgsrc config file versioning A series of reports from the course of the summer on this Google Summer of Code project The goal of the project is to integrate with a VCS (Version Control System) to make managing local changes to config files for packages easier GSoC 2018 Reports: Configuration files versioning in pkgsrc, Part 1 Packages may install code (both machine executable code and interpreted programs), documentation and manual pages, source headers, shared libraries and other resources such as graphic elements, sounds, fonts, document templates, translations and configuration files, or a combination of them. Configuration files are usually the means through which the behaviour of software without a user interface is specified. This covers parts of the operating systems, network daemons and programs in general that don’t come with an interactive graphical or textual interface as the principal mean for setting options. System wide configuration for operating system software tends to be kept under /etc, while configuration for software installed via pkgsrc ends up under LOCALBASE/etc (e.g., /usr/pkg/etc). Software packaged as part of pkgsrc provides example configuration files, if any, which usually get extracted to LOCALBASE/share/examples/PKGBASE/. Don’t worry: automatic merging is disabled by default, set $VCSAUTOMERGE to enable it. In order to avoid breakage, installed configuration is backed up first in the VCS, separating user-modified files from files that have been already automatically merged in the past, in order to allow the administrator to easily restore the last manually edited file in case of breakage. VCS functionality only applies to configuration files, not to rc.d scripts, and only if the environment variable $NOVCS is unset. The version control system to be used as a backend can be set through $VCS. It default to RCS, the Revision Control System, which works only locally and doesn’t support atomic transactions. Other backends such as CVS are supported and more will come; these, being used at the explicit request of the administrator, need to be already installed and placed in a directory part of $PATH. GSoC 2018 Reports: Configuration files versioning in pkgsrc, part 2: remote repositories (git and CVS) pkgsrc is now able to deploy configuration from packages being installed from a remote, site-specific vcs repository. User modified files are always tracked even if automerge functionality is not enabled, and a new tool, pkgconftrack(1), exists to manually store user changes made outside of package upgrade time. Version Control software is executed as the same user running pkgadd or make install, unless the user is “root”. In this case, a separate, unprivileged user, pkgvcsconf, gets created with its own home directory and a working login shell (but no password). The home directory is not strictly necessary, it exists to facilitate migrations betweens repositories and vcs changes; it also serves to store keys used to access remote repositories. Using git instead of rcs is simply done by setting VCS=git in pkginstall.conf GSoC 2018 Reports: Configuration files versioning in pkgsrc, part 3: remote repositories (SVN and Mercurial) GSoC 2018 Reports: Configuration files versioning in pkgsrc, part 4: configuration deployment, pkgtools and future improvements Support for configuration tracking is in scripts, pkginstall scripts, that get built into binary packages and are run by pkgadd upon installation. The idea behind the proposal suggested that users of the new feature should be able to store revisions of their installed configuration files, and of package-provided default, both in local or remote repositories. With this capability in place, it doesn’t take much to make the scripts “pull” configuration from a VCS repository at installation time. That’s what setting VCSCONFPULL=yes in pkginstall.conf after having enabled VCSTRACKCONF does: You are free to use official, third party prebuilt packages that have no customization in them, enable these options, and point pkgsrc to a private conf repository. If it contains custom configuration for the software you are installing, an attempt will be made to use it and install it on your system. If it fails, pkginstall will fall back to using the defaults that come inside the package. RC scripts are always deployed from the binary package, if existing and PKGRCDSCRIPTS=yes in pkginstall.conf or the environment. This will be part of packages, not a separate solution like configuration management tools. It doesn’t support running scripts on the target system to customize the installation, it doesn’t come with its domain-specific language, it won’t run as a daemon or require remote logins to work. It’s quite limited in scope, but you can define a ROLE for your system in pkginstall.conf or in the environment, and pkgsrc will look for configuration you or your organization crafted for such a role (e.g., public, standalone webserver vs reverse proxy or node in a database cluster) ###A little bit of the one-time MacOS version still lingers in ZFS Once upon a time, Apple came very close to releasing ZFS as part of MacOS. Apple did this work in its own copy of the ZFS source base (as far as I know), but the people in Sun knew about it and it turns out that even today there is one little lingering sign of this hoped-for and perhaps prepared-for ZFS port in the ZFS source code. Well, sort of, because it’s not quite in code. Lurking in the function that reads ZFS directories to turn (ZFS) directory entries into the filesystem independent format that the kernel wants is the following comment: objnum = ZFSDIRENTOBJ(zap.zafirstinteger); / MacOS X can extract the object type here such as: * uint8t type = ZFSDIRENTTYPE(zap.zafirstinteger); */ Specifically, this is in zfsreaddir in zfsvnops.c . ZFS maintains file type information in directories. This information can’t be used on Solaris (and thus Illumos), where the overall kernel doesn’t have this in its filesystem independent directory entry format, but it could have been on MacOS (‘Darwin’), because MacOS is among the Unixes that support d_type. The comment itself dates all the way back to this 2007 commit, which includes the change ‘reserve bits in directory entry for file type’, which created the whole setup for this. I don’t know if this file type support was added specifically to help out Apple’s MacOS X port of ZFS, but it’s certainly possible, and in 2007 it seems likely that this port was at least on the minds of ZFS developers. It’s interesting but understandable that FreeBSD didn’t seem to have influenced them in the same way, at least as far as comments in the source code go; this file type support is equally useful for FreeBSD, and the FreeBSD ZFS port dates to 2007 too (per this announcement). Regardless of the exact reason that ZFS picked up maintaining file type information in directory entries, it’s quite useful for people on both FreeBSD and Linux that it does so. File type information is useful for any number of things and ZFS filesystems can (and do) provide this information on those Unixes, which helps make ZFS feel like a truly first class filesystem, one that supports all of the expected general system features. ##Beastie Bits Mac-like FreeBSD Laptop Syncthing on FreeBSD New ZFS Boot Environments Tool My system’s time was so wrong, that even ntpd didn’t work OpenSSH 7.8/7.8p1 (2018-08-24) EuroBSD (Sept 20-23rd) registration Early Bird Period is coming to an end MeetBSD (Oct 18-20th) is coming up fast, hurry up and register! AsiaBSDcon 2019 Dates ##Feedback/Questions Will - Kudos and a Question Peter - Fanless Computers Ron - ZFS disk clone or replace or something Bostjan - ZFS Record Size Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
DragonflyBSD release 5.2.1 is here, BPF kernel exploit writeup, Remote Debugging the running OpenBSD kernel, interview with Patrick Mooney, FreeBSD buildbot setup in a jail, dumping your USB, and 5 years of gaming on FreeBSD. Headlines DragonFlyBSD: release52 (w/stable HAMMER2, as default root) DragonflyBSD 5.2.1 was released on May 21, 2018 > Big Ticket items: Meltdown and Spectre mitigation support Meltdown isolation and spectre mitigation support added. Meltdown mitigation is automatically enabled for all Intel cpus. Spectre mitigation must be enabled manually via sysctl if desired, using sysctls machdep.spectremitigation and machdep.meltdownmitigation. HAMMER2 H2 has received a very large number of bug fixes and performance improvements. We can now recommend H2 as the default root filesystem in non-clustered mode. Clustered support is not yet available. ipfw Updates Implement state based "redirect", i.e. without using libalias. ipfw now supports all possible ICMP types. Fix ICMPMAXTYPE assumptions (now 40 as of this release). Improved graphics support The drm/i915 kernel driver has been updated to support Intel Coffeelake GPUs Add 24-bit pixel format support to the EFI frame buffer code. Significantly improve fbio support for the "scfb" XOrg driver. This allows EFI frame buffers to be used by X in situations where we do not otherwise support the GPU. Partly implement the FBIOBLANK ioctl for display powersaving. Syscons waits for drm modesetting at appropriate places, avoiding races. PS4 4.55 BPF Race Condition Kernel Exploit Writeup Note: While this bug is primarily interesting for exploitation on the PS4, this bug can also potentially be exploited on other unpatched platforms using FreeBSD if the attacker has read/write permissions on /dev/bpf, or if they want to escalate from root user to kernel code execution. As such, I've published it under the "FreeBSD" folder and not the "PS4" folder. Introduction Welcome to the kernel portion of the PS4 4.55FW full exploit chain write-up. This bug was found by qwerty, and is fairly unique in the way it's exploited, so I wanted to do a detailed write-up on how it worked. The full source of the exploit can be found here. I've previously covered the webkit exploit implementation for userland access here. FreeBSD or Sony's fault? Why not both... Interestingly, this bug is actually a FreeBSD bug and was not (at least directly) introduced by Sony code. While this is a FreeBSD bug however, it's not very useful for most systems because the /dev/bpf device driver is root-owned, and the permissions for it are set to 0600 (meaning owner has read/write privileges, and nobody else does) - though it can be used for escalating from root to kernel mode code execution. However, let’s take a look at the make_dev() call inside the PS4 kernel for /dev/bpf (taken from a 4.05 kernel dump). seg000:FFFFFFFFA181F15B lea rdi, unk_FFFFFFFFA2D77640 seg000:FFFFFFFFA181F162 lea r9, aBpf ; "bpf" seg000:FFFFFFFFA181F169 mov esi, 0 seg000:FFFFFFFFA181F16E mov edx, 0 seg000:FFFFFFFFA181F173 xor ecx, ecx seg000:FFFFFFFFA181F175 mov r8d, 1B6h seg000:FFFFFFFFA181F17B xor eax, eax seg000:FFFFFFFFA181F17D mov cs:qword_FFFFFFFFA34EC770, 0 seg000:FFFFFFFFA181F188 call make_dev We see UID 0 (the UID for the root user) getting moved into the register for the 3rd argument, which is the owner argument. However, the permissions bits are being set to 0x1B6, which in octal is 0666. This means anyone can open /dev/bpf with read/write privileges. I’m not sure why this is the case, qwerty speculates that perhaps bpf is used for LAN gaming. In any case, this was a poor design decision because bpf is usually considered privileged, and should not be accessible to a process that is completely untrusted, such as WebKit. On most platforms, permissions for /dev/bpf will be set to 0x180, or 0600. Race Conditions - What are they? The class of the bug abused in this exploit is known as a "race condition". Before we get into bug specifics, it's important for the reader to understand what race conditions are and how they can be an issue (especially in something like a kernel). Often in complex software (such as a kernel), resources will be shared (or "global"). This means other threads could potentially execute code that will access some resource that could be accessed by another thread at the same point in time. What happens if one thread accesses this resource while another thread does without exclusive access? Race conditions are introduced. Race conditions are defined as possible scenarios where events happen in a sequence different than the developer intended which leads to undefined behavior. In simple, single-threaded programs, this is not an issue because execution is linear. In more complex programs where code can be running in parallel however, this becomes a real issue. To prevent these problems, atomic instructions and locking mechanisms were introduced. When one thread wants to access a critical resource, it will attempt to acquire a "lock". If another thread is already using this resource, generally the thread attempting to acquire the lock will wait until the other thread is finished with it. Each thread must release the lock to the resource after they're done with it, failure to do so could result in a deadlock. While locking mechanisms such as mutexes have been introduced, developers sometimes struggle to use them properly. For example, what if a piece of shared data gets validated and processed, but while the processing of the data is locked, the validation is not? There is a window between validation and locking where that data can change, and while the developer thinks the data has been validated, it could be substituted with something malicious after it is validated, but before it is used. Parallel programming can be difficult, especially when, as a developer, you also want to factor in the fact that you don't want to put too much code in between locking and unlocking as it can impact performance. See article for the rest iXsystems Remote Debugging the running OpenBSD kernel Subtitled: A way to understand the OpenBSD internals +> The Problem +> A few month ago, I tried porting the FreeBSD kdb along with it's gdb stub implementations to OpenBSD as a practice of learning the internals of an BSD operating system. The ddb code in both FreeBSD and OpenBSD looks pretty much the same and the GDB Remote Serial Protocol looks very minimal. +> But sadly I got very busy and the work is stalled but I'm planning on resuming the attempt as soon as I get the chance, But there is an alternative way to Debugging the OpenBSD kernel via QEMU. What I did below is basically the same with a few minor changes which I hope to describe it as best. +> Installing OpenBSD on Qemu +> For debugging the kernel, we need a working OpenBSD system running on Qemu. I chose to create a raw disk file to be able to easily mount it later via the host and copy the custom kernel onto it. $ qemu-img create -f raw disk.raw 5G $ qemu-system-x8664 -m 256M -drive format=raw,file=install63.fs -drive format=raw,file=disk.raw +> Custom Kernel +> To debug the kernel, we need a version of the kernel with debugging symbols and for that we have to recompile it first. The process is documented at Building the System from Source: ... +> Then we can copy the bsd kernel to the guest machine and keep the bsd.gdb on the host to start the remote debugging via gdb. +> Remote debugging kernel +> Now it's to time to boot the guest with the new custom kernel. Remember that the -s argument enables the gdb server on qemu on localhost port 1234 by default: $ qemu-system-x8664 -m 256M -s -net nic -net user -drive format=raw,file=install63.fs +> Now to finally attach to the running kernel: Interview - Patrick Mooney - Software Engineer pmooney@pfmooney.com / @pfmooney BR: How did you first get introduced to UNIX? AJ: What got you started contributing to an open source project? BR: What sorts of things have you worked on in the past? AJ: Can you tell us more about what attracted you to illumos? BR: How did you get interested in, and started with, systems development? AJ: When did you first get interested in bhyve? BR: How much work was it to take the years-old port of bhyve and get it working on modern IllumOS? AJ: What was the process for getting the bhyve port caught up to current FreeBSD? BR: How usable is bhyve on illumOS? AJ: What area are you most interested in improving in bhyve? BR: Do you think the FreeBSD and illumos versions of bhyve will stay in sync with each other? AJ: What do you do for fun? BR: Anything else you want to mention? News Roundup Setting up buildbot in FreeBSD Jails In this article, I would like to present a tutorial to set up buildbot, a continuous integration (CI) software (like Jenkins, drone, etc.), making use of FreeBSD’s containerization mechanism "jails". We will cover terminology, rationale for using both buildbot and jails together, and installation steps. At the end, you will have a working buildbot instance using its sample build configuration, ready to play around with your own CI plans (or even CD, it’s very flexible!). Some hints for production-grade installations are given, but the tutorial steps are meant for a test environment (namely a virtual machine). Buildbot’s configuration and detailed concepts are not in scope here. Table of contents Choosing host operating system and version for buildbot Create a FreeBSD playground Introduction to jails Overview of buildbot Set up jails Install buildbot master Run buildbot master Install buildbot worker Run buildbot worker Set up web server nginx to access buildbot UI Run your first build Production hints Finished! Choosing host operating system and version for buildbot We choose the released version of FreeBSD (11.1-RELEASE at the moment). There is no particular reason for it, and as a matter of fact buildbot as a Python-based server is very cross-platform; therefore the underlying OS platform and version should not make a large difference. It will make a difference for what you do with buildbot, however. For instance, poudriere is the de-facto standard for building packages from source on FreeBSD. Builds run in jails which may be any FreeBSD base system version older or equal to the host’s version (reason will be explained below). In other words, if the host is FreeBSD 11.1, build jails created by poudriere could e.g. use 9.1, 10.3, 11.0, 11.1, but potentially not version 12 or newer because of incompatibilities with the host’s kernel (jails do not run their own kernel as full virtual machines do). To not prolong this article over the intended scope, the details of which nice things could be done or automated with buildbot are not covered. Package names on the FreeBSD platform are independent of the OS version, since external software (as in: not part of base system) is maintained in FreeBSD ports. So, if your chosen FreeBSD version (here: 11) is still officially supported, the packages mentioned in this post should work. In the unlikely event of package name changes before you read this article, you should be able to find the actual package names like pkg search buildbot. Other operating systems like the various Linux distributions will use different package names but might also offer buildbot pre-packaged. If not, the buildbot installation manual offers steps to install it manually. In such case, the downside is that you will have to maintain and update the buildbot modules outside the stability and (semi-)automatic updates of your OS packages. See article for the rest DigitalOcean Dumping your USB One of the many new features of OpenBSD 6.3 is the possibility to dump USB traffic to userland via bpf(4). This can be done with tcpdump(8) by specifying a USB bus as interface: ``` tcpdump -Xx -i usb0 tcpdump: listening on usb0, link-type USBPCAP 12:28:03.317945 bus 0 < addr 1: ep1 intr 2 0000: 0400 .. 12:28:03.318018 bus 0 > addr 1: ep0 ctrl 8 0000: 00a3 0000 0002 0004 00 ......... [...] ``` As you might have noted I decided to implement the existing USBPcap capture format. A capture format is required because USB packets do not include all the necessary information to properly interpret them. I first thought I would implement libpcap's DLTUSB but then I quickly realize that this was not a standard. It is instead a FreeBSD specific format which has been since then renamed DLTUSBFREEBSD. But I didn't want to embrace xkcd #927, so I look at the existing formats: DLTUSBFREEBSD, DLTUSBLINUX, DLTUSBLINUXMMAPPED, DLTUSBDARWIN and DLT_USBPCAP. I was first a bit sad to see that nobody could agree on a common format then I moved on and picked the simplest one: USBPcap. Implementing an already existing format gives us out-of-box support for all the tools supporting it. That's why having common formats let us share our energy. In the case of USBPcap it is already supported by Wireshark, so you can already inspect your packet graphically. For that you need to first capture raw packets: ``` tcpdump -s 3303 -w usb.pcap -i usb0 tcpdump: listening on usb0, link-type USBPCAP ^C 208 packets received by filter 0 packets dropped by kernel ``` USB packets can be quite big, that's why I'm not using tcpdump(8)'s default packet size. In this case, I want to make sure I can dump the complete uaudio(4) frames. It is important to say that what is dumped to userland is what the USB stack sees. Packets sent on the wire might differ, especially when it comes to retries and timing. So this feature is not here to replace any USB analyser, however I hope that it will help people understand how things work and what the USB stack is doing. Even I found some interesting timing issues while implementing isochronous support. Run OpenBSD on your web server Deploy and login to your OpenBSD server first. As soon as you're there you can enable an httpd(8) daemon, it's already installed on OpenBSD, you just need to configure it: www# vi /etc/httpd.conf Add two server sections---one for www and another for naked domain (all requests are redirected to www). ``` server "www.example.com" { listen on * port 80 root "/htdocs/www.example.com" } server "example.com" { listen on * port 80 block return 301 "http://www.example.com$REQUEST_URI" } ``` httpd is chrooted to /var/www by default, so let's make a document root directory: www# mkdir -p /var/www/htdocs/www.example.com Save and check this configuration: www# httpd -n configuration ok Enable httpd(8) daemon and start it. www# rcctl enable httpd www# rcctl start httpd Publish your website Copy your website content into /var/www/htdocs/www.example.com and then test it your web browser. http://XXX.XXX.XXX.XXX/ Your web server should be up and running. Update DNS records If there is another HTTPS server using this domain, configure that server to redirect all HTTPS requests to HTTP. Now as your new server is ready you can update DNS records accordingly. example.com. 300 IN A XXX.XXX.XXX.XXX www.example.com. 300 IN A XXX.XXX.XXX.XXX Examine your DNS is propagated. $ dig example.com www.example.com Check IP addresses it answer sections. If they are correct, you should be able to access your new web server by its domain name. What's next? Enable HTTPS on your server. Modern Akonadi and KMail on FreeBSD For, quite literally a year or more, KMail and Akonadi on FreeBSD have been only marginally useful, at best. KDE4 era KMail was pretty darn good, but everything after that has had a number of FreeBSD users tearing out their hair. Sure, you can go to Trojitá, which has its own special problems and is generally “meh”, or bail out entirely to webmail, but .. KMail is a really great mail client when it works. Which, on Linux desktops, is nearly always, and on FreeBSD, is was nearly never. I looked at it with Dan and Volker last summer, briefly, and we got not much further than “hmm”. There’s a message about “The world is going to end!” which hardly makes sense, it means that a message has been truncated or corrupted while traversing a UNIX domain socket. Now Alexandre Martins — praise be! — has wandered in with a likely solution. KDE Bug 381850 contains a suggestion, which deserves to be publicised (and tested): sysctl net.local.stream.recvspace=65536 sysctl net.local.stream.sendspace=65536 The default FreeBSD UNIX local socket buffer space is 8kiB. Bumping the size up to 64kiB — which matches the size that Linux has by default — suddenly makes KMail and Akonadi shine again. No other changes, no recompiling, just .. bump the sysctls (perhaps also in /etc/sysctl.conf) and KMail from Area51 hums along all day without ending the world. Since changing this value may have other effects, and Akonadi shouldn’t be dependent on a specific buffer size anyway, I’m looking into the Akonadi code (encouraged by Dan) to either automatically size the socket buffers, or to figure out where in the underlying code the assumption about buffer size lives. So for now, sysctl can make KMail users on FreeBSD happy, and later we hope to have things fully automatic (and if that doesn’t pan out, well, pkg-message exists). PS. Modern KDE PIM applications — Akonadi, KMail — which live in the deskutils/ category of the official FreeBSD ports were added to the official tree April 10th, so you can get your fix now from the official tree. Beastie Bits pkg-provides support for DragonFly (from Rodrigo Osorio) Memories of writing a parser for man pages Bryan Cantrill interview over at DeveloperOnFire podcast 1978-03-25 - 2018-03-25: 40 years BSD Mail My 5 years of FreeBSD gaming: a compendium of free games and engines running natively on FreeBSD Sequential Resilver being upstreamed to FreeBSD, from FreeNAS, where it was ported from ZFS-on-Linux University of Aberdeen’s Internet Transport Research Group is hiring Tarsnap ad Feedback/Questions Dave - mounting non-filesystem things inside jails Morgan - ZFS on Linux Data loss bug Rene - How to keep your ISP’s nose out of your browser history with encrypted DNS Rodriguez - Feedback question! Relating to Windows Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
Arcan and OpenBSD, running OpenBSD 6.3 on RPI 3, why C is not a low-level language, HardenedBSD switching back to OpenSSL, how the Internet was almost broken, EuroBSDcon CfP is out, and the BSDCan 2018 schedule is available. Headlines Towards Secure System Graphics: Arcan and OpenBSD Let me preface this by saying that this is a (very) long and medium-rare technical article about the security considerations and minutiae of porting (most of) the Arcan ecosystem to work under OpenBSD. The main point of this article is not so much flirting with the OpenBSD crowd or adding further noise to software engineering topics, but to go through the special considerations that had to be taken, as notes to anyone else that decides to go down this overgrown and lonesome trail, or are curious about some less than obvious differences between how these things “work” on Linux vs. other parts of the world. A disclaimer is also that most of this have been discovered by experimentation and combining bits and pieces scattered in everything from Xorg code to man pages, there may be smarter ways to solve some of the problems mentioned – this is just the best I could find within the time allotted. I’d be happy to be corrected, in patch/pull request form that is 😉 Each section will start with a short rant-like explanation of how it works in Linux, and what the translation to OpenBSD involved or, in the cases that are still partly or fully missing, will require. The topics that will be covered this time are: Graphics Device Access Hotplug Input Backlight Xorg Pledging Missing Installing OpenBSD 6.3 (snapshots) on Raspberry pi 3 The Easy way Installing the OpenBSD on raspberry pi 3 is very easy and well documented which almost convinced me of not writing about it, but still I felt like it may help somebody new to the project (But again I really recommend reading the document if you are interested and have the time). Note: I'm always running snapshots and recommend anybody to do it as well. But the snapshots links will change to the next version every 6 month, so I changed the links to the 6.3 version to keep the blog post valid over times. If you're familiar to the OpenBSD flavors, feel free to use the snapshots links instead. Requirements Due to the lack of driver, the OpenBSD can not boot directly from the SD Card yet, So we'll need an USB Stick for the installtion target aside the SD Card for the U-Boot and installer. Also, a Serial Console connection is required. I Used a PL2303 USB to Serial (TTL) adapter connected to my Laptop via USB port and connected to the Raspberry via TX, RX and GND pins. iXsystems https://www.ixsystems.com/blog/truenas-m-series-veeam-pr-2018/ Why Didn’t Larrabee Fail? Every month or so, someone will ask me what happened to Larrabee and why it failed so badly. And I then try to explain to them that not only didn't it fail, it was a pretty huge success. And they are understandably very puzzled by this, because in the public consciousness Larrabee was like the Itanic and the SPU rolled into one, wasn't it? Well, not quite. So rather than explain it in person a whole bunch more times, I thought I should write it down. This is not a history, and I'm going to skip a TON of details for brevity. One day I'll write the whole story down, because it's a pretty decent escapade with lots of fun characters. But not today. Today you just get the very start and the very end. When I say "Larrabee" I mean all of Knights, all of MIC, all of Xeon Phi, all of the "Isle" cards - they're all exactly the same chip and the same people and the same software effort. Marketing seemed to dream up a new codeword every week, but there was only ever three chips: Knights Ferry / Aubrey Isle / LRB1 - mostly a prototype, had some performance gotchas, but did work, and shipped to partners. Knights Corner / Xeon Phi / LRB2 - the thing we actually shipped in bulk. Knights Landing - the new version that is shipping any day now (mid 2016). That's it. There were some other codenames I've forgotten over the years, but they're all of one of the above chips. Behind all the marketing smoke and mirrors there were only three chips ever made (so far), and only four planned in total (we had a thing called LRB3 planned between KNC and KNL for a while). All of them are "Larrabee", whether they do graphics or not. When Larrabee was originally conceived back in about 2005, it was called "SMAC", and its original goals were, from most to least important: Make the most powerful flops-per-watt machine for real-world workloads using a huge array of simple cores, on systems and boards that could be built into bazillo-core supercomputers. Make it from x86 cores. That means memory coherency, store ordering, memory protection, real OSes, no ugly scratchpads, it runs legacy code, and so on. No funky DSPs or windowed register files or wacky programming models allowed. Do not build another Itanium or SPU! Make it soon. That means keeping it simple. Support the emerging GPGPU market with that same chip. Intel were absolutely not going to build a 150W PCIe card version of their embedded graphics chip (known as "Gen"), so we had to cover those programming models. As a bonus, run normal graphics well. Add as little graphics-specific hardware as you can get away with. That ordering is important - in terms of engineering and focus, Larrabee was never primarily a graphics card. If Intel had wanted a kick-ass graphics card, they already had a very good graphics team begging to be allowed to build a nice big fat hot discrete GPU - and the Gen architecture is such that they'd build a great one, too. But Intel management didn't want one, and still doesn't. But if we were going to build Larrabee anyway, they wanted us to cover that market as well. ... the design of Larrabee was of a CPU with a very wide SIMD unit, designed above all to be a real grown-up CPU - coherent caches, well-ordered memory rules, good memory protection, true multitasking, real threads, runs Linux/FreeBSD, etc. Larrabee, in the form of KNC, went on to become the fastest supercomputer in the world for a couple of years, and it's still making a ton of money for Intel in the HPC market that it was designed for, fighting very nicely against the GPUs and other custom architectures. Its successor, KNL, is just being released right now (mid 2016) and should do very nicely in that space too. Remember - KNC is literally the same chip as LRB2. It has texture samplers and a video out port sitting on the die. They don't test them or turn them on or expose them to software, but they're still there - it's still a graphics-capable part. But it's still actually running FreeBSD on that card, and under FreeBSD it's just running an x86 program called DirectXGfx (248 threads of it). News Roundup C Is Not a Low-level Language : Your computer is not a fast PDP-11. In the wake of the recent Meltdown and Spectre vulnerabilities, it's worth spending some time looking at root causes. Both of these vulnerabilities involved processors speculatively executing instructions past some kind of access check and allowing the attacker to observe the results via a side channel. The features that led to these vulnerabilities, along with several others, were added to let C programmers continue to believe they were programming in a low-level language, when this hasn't been the case for decades. Processor vendors are not alone in this. Those of us working on C/C++ compilers have also participated. What Is a Low-Level Language? Computer science pioneer Alan Perlis defined low-level languages this way: "A programming language is low level when its programs require attention to the irrelevant." While, yes, this definition applies to C, it does not capture what people desire in a low-level language. Various attributes cause people to regard a language as low-level. Think of programming languages as belonging on a continuum, with assembly at one end and the interface to the Starship Enterprise's computer at the other. Low-level languages are "close to the metal," whereas high-level languages are closer to how humans think. For a language to be "close to the metal," it must provide an abstract machine that maps easily to the abstractions exposed by the target platform. It's easy to argue that C was a low-level language for the PDP-11. They both described a model in which programs executed sequentially, in which memory was a flat space, and even the pre- and post-increment operators cleanly lined up with the PDP-11 addressing modes. Fast PDP-11 Emulators The root cause of the Spectre and Meltdown vulnerabilities was that processor architects were trying to build not just fast processors, but fast processors that expose the same abstract machine as a PDP-11. This is essential because it allows C programmers to continue in the belief that their language is close to the underlying hardware. C code provides a mostly serial abstract machine (until C11, an entirely serial machine if nonstandard vendor extensions were excluded). Creating a new thread is a library operation known to be expensive, so processors wishing to keep their execution units busy running C code rely on ILP (instruction-level parallelism). They inspect adjacent operations and issue independent ones in parallel. This adds a significant amount of complexity (and power consumption) to allow programmers to write mostly sequential code. In contrast, GPUs achieve very high performance without any of this logic, at the expense of requiring explicitly parallel programs. The quest for high ILP was the direct cause of Spectre and Meltdown. A modern Intel processor has up to 180 instructions in flight at a time (in stark contrast to a sequential C abstract machine, which expects each operation to complete before the next one begins). A typical heuristic for C code is that there is a branch, on average, every seven instructions. If you wish to keep such a pipeline full from a single thread, then you must guess the targets of the next 25 branches. This, again, adds complexity; it also means that an incorrect guess results in work being done and then discarded, which is not ideal for power consumption. This discarded work has visible side effects, which the Spectre and Meltdown attacks could exploit. On a modern high-end core, the register rename engine is one of the largest consumers of die area and power. To make matters worse, it cannot be turned off or power gated while any instructions are running, which makes it inconvenient in a dark silicon era when transistors are cheap but powered transistors are an expensive resource. This unit is conspicuously absent on GPUs, where parallelism again comes from multiple threads rather than trying to extract instruction-level parallelism from intrinsically scalar code. If instructions do not have dependencies that need to be reordered, then register renaming is not necessary. Consider another core part of the C abstract machine's memory model: flat memory. This hasn't been true for more than two decades. A modern processor often has three levels of cache in between registers and main memory, which attempt to hide latency. The cache is, as its name implies, hidden from the programmer and so is not visible to C. Efficient use of the cache is one of the most important ways of making code run quickly on a modern processor, yet this is completely hidden by the abstract machine, and programmers must rely on knowing implementation details of the cache (for example, two values that are 64-byte-aligned may end up in the same cache line) to write efficient code. Backup URL Hacker News Commentary HardenedBSD Switching Back to OpenSSL Over a year ago, HardenedBSD switched to LibreSSL as the default cryptographic library in base for 12-CURRENT. 11-STABLE followed suit later on. Bernard Spil has done an excellent job at keeping our users up-to-date with the latest security patches from LibreSSL. After recently updating 12-CURRENT to LibreSSL 2.7.2 from 2.6.4, it has become increasingly clear to us that performing major upgrades requires a team larger than a single person. Upgrading to 2.7.2 caused a lot of fallout in our ports tree. As of 28 Apr 2018, several ports we consider high priority are still broken. As it stands right now, it would take Bernard a significant amount of his spare personal time to fix these issues. Until we have a multi-person team dedicated to maintaining LibreSSL in base along with the patches required in ports, HardenedBSD will use OpenSSL going forward as the default cryptographic library in base. LibreSSL will co-exist with OpenSSL in the source tree, as it does now. However, MK_LIBRESSL will default to "no" instead of the current "yes". Bernard will continue maintaining LibreSSL in base along with addressing the various problematic ports entries. To provide our users with ample time to plan and perform updates, we will wait a period of two months prior to making the switch. The switch will occur on 01 Jul 2018 and will be performed simultaneously in 12-CURRENT and 11-STABLE. HardenedBSD will archive a copy of the LibreSSL-centric package repositories and binary updates for base for a period of six months after the switch (expiring the package repos on 01 Jan 2019). This essentially gives our users eight full months for an upgrade path. As part of the switch back to OpenSSL, the default NTP daemon in base will switch back from OpenNTPd to ISC NTP. Users who have localopenntpdenable="YES" set in rc.conf will need to switch back to ntpd_enable="YES". Users who build base from source will want to fully clean their object directories. Any and all packages that link with libcrypto or libssl will need to be rebuilt or reinstalled. With the community's help, we look forward to the day when we can make the switch back to LibreSSL. We at HardenedBSD believe that providing our users options to rid themselves of software monocultures can better increase security and manage risk. DigitalOcean http://do.co/bsdnow -- $100 credit for 60 days How Dan Kaminsky Almost Broke the Internet In the summer of 2008, security researcher Dan Kaminsky disclosed how he had found a huge flaw in the Internet that could let attackers redirect web traffic to alternate servers and disrupt normal operations. In this Hacker History video, Kaminsky describes the flaw and notes the issue remains unfixed. “We were really concerned about web pages and emails 'cause that’s what you get to compromise when you compromise DNS,” Kaminsky says. “You think you’re sending an email to IBM but it really goes to the bad guy.” As the phone book of the Internet, DNS translates easy-to-remember domain names into IP addresses so that users don’t have to remember strings of numbers to reach web applications and services. Authoritative nameservers publish the IP addresses of domain names. Recursive nameservers talk to authoritative servers to find addresses for those domain names and saves the information into its cache to speed up the response time the next time it is asked about that site. While anyone can set up a nameserver and configure an authoritative zone for any site, if recursive nameservers don’t point to it to ask questions, no one will get those wrong answers. We made the Internet less flammable. Kaminsky found a fundamental design flaw in DNS that made it possible to inject incorrect information into the nameserver's cache, or DNS cache poisoning. In this case, if an attacker crafted DNS queries looking for sibling names to existing domains, such as 1.example.com, 2.example.com, and 3.example.com, while claiming to be the official "www" server for example.com, the nameserver will save that server IP address for “www” in its cache. “The server will go, ‘You are the official. Go right ahead. Tell me what it’s supposed to be,’” Kaminsky says in the video. Since the issue affected nearly every DNS server on the planet, it required a coordinated response to address it. Kaminsky informed Paul Vixie, creator of several DNS protocol extensions and application, and Vixie called an emergency summit of major IT vendors at Microsoft’s headquarters to figure out what to do. The “fix” involved combining the 16-bit transaction identifier that DNS lookups used with UDP source ports to create 32-bit transaction identifiers. Instead of fixing the flaw so that it can’t be exploited, the resolution focused on making it take more than ten seconds, eliminating the instantaneous attack. “[It’s] not like we repaired DNS,” Kaminsky says. “We made the Internet less flammable.” DNSSEC (Domain Name System Security Extensions), is intended to secure DNS by adding a cryptographic layer to DNS information. The root zone of the internet was signed for DNSSEC in July 2010 and the .com Top Level Domain (TLD) was finally signed for DNSSEC in April 2011. Unfortunately, adoption has been slow, even ten years after Kaminsky first raised the alarm about DNS, as less than 15 percent of users pass their queries to DNSSEC validating resolvers. The Internet was never designed to be secure. The Internet was designed to move pictures of cats. No one expected the Internet to be used for commerce and critical communications. If people lose faith in DNS, then all the things that depend on it are at risk. “What are we going to do? Here is the answer. Some of us gotta go out fix it,” Kaminsky says. OpenIndiana Hipster 2018.04 is here We have released a new OpenIndiana Hipster snapshot 2018.04. The noticeable changes: Userland software is rebuilt with GCC 6. KPTI was enabled to mitigate recent security issues in Intel CPUs. Support of Gnome 2 desktop was removed. Linked images now support zoneproxy service. Mate desktop applications are delivered as 64-bit-only. Upower support was integrated. IIIM was removed. More information can be found in 2018.04 Release notes and new medias can be downloaded from http://dlc.openindiana.org. Beastie Bits EuroBSDCon - Call for Papers OpenSSH 7.7 pkgsrc-2018Q1 released BSDCan Schedule Michael Dexter's LFNW talk Tarsnap ad Feedback/Questions Bob - Help locating FreeBSD Help Alex - Convert directory to dataset Adam - FreeNAS Question Florian - Three Questions Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv iX Ad spot: iXsystems TrueNAS M-Series Blows Away Veeam Backup Certification Tests
OpenBSD 6.3 and DragonflyBSD 5.2 are released, bug fix for disappearing files in OpenZFS on Linux (and only Linux), understanding the FreeBSD CPU scheduler, NetBSD on RPI3, thoughts on being a committer for 20 years, and 5 reasons to use FreeBSD in 2018. Headlines OpenBSD 6.3 released Punctual as ever, OpenBSD 6.3 has been releases with the following features/changes: Improved HW support, including: SMP support on OpenBSD/arm64 platforms vmm/vmd improvements: IEEE 802.11 wireless stack improvements Generic network stack improvements Installer improvements Routing daemons and other userland network improvements Security improvements dhclient(8) improvements Assorted improvements OpenSMTPD 6.0.4 OpenSSH 7.7 LibreSSL 2.7.2 DragonFlyBSD 5.2 released Big-ticket items Meltdown and Spectre mitigation support Meltdown isolation and spectre mitigation support added. Meltdown mitigation is automatically enabled for all Intel cpus. Spectre mitigation must be enabled manually via sysctl if desired, using sysctls machdep.spectremitigation and machdep.meltdownmitigation. HAMMER2 H2 has received a very large number of bug fixes and performance improvements. We can now recommend H2 as the default root filesystem in non-clustered mode. Clustered support is not yet available. ipfw Updates Implement state based "redirect", i.e. without using libalias. ipfw now supports all possible ICMP types. Fix ICMPMAXTYPE assumptions (now 40 as of this release). Improved graphics support The drm/i915 kernel driver has been updated to support Intel Coffeelake GPUs Add 24-bit pixel format support to the EFI frame buffer code. Significantly improve fbio support for the "scfb" XOrg driver. This allows EFI frame buffers to be used by X in situations where we do not otherwise support the GPU. Partly implement the FBIOBLANK ioctl for display powersaving. Syscons waits for drm modesetting at appropriate places, avoiding races. + For more details, check out the “All changes since DragonFly 5.0” section. ZFS on Linux bug causes files to disappear A bug in ZoL 0.7.7 caused 0.7.8 to be released just 3 days after the release The bug only impacts Linux, the change that caused the problem was not upstreamed yet, so does not impact ZFS on illumos, FreeBSD, OS X, or Windows The bug can cause files being copied into a directory to not be properly linked to the directory, so they will no longer be listed in the contents of the directory ZoL developers are working on a tool to allow you to recover the data, since no data was actually lost, the files were just not properly registered as part of the directory The bug was introduced in a commit made in February, that attempted to improve performance of datasets created with the case insensitivity option. In an effort to improve performance, they introduced a limit to cap to give up (return ENOSPC) if growing the directory ZAP failed twice. The ZAP is the key-value pair data structure that contains metadata for a directory, including a hash table of the files that are in a directory. When a directory has a large number of files, the ZAP is converted to a FatZAP, and additional space may need to be allocated as additional files are added. Commit cc63068 caused ENOSPC error when copy a large amount of files between two directories. The reason is that the patch limits zap leaf expansion to 2 retries, and return ENOSPC when failed. Finding the root cause of this issue was somewhat hampered by the fact that many people were not able to reproduce the issue. It turns out this was caused by an entirely unrelated change to GNU coreutils. On later versions of GNU Coreutils, the files were returned in a sorted order, resulting in them hitting different buckets in the hash table, and not tripping the retry limit Tools like rsync were unaffected, because they always sort the files before copying If you did not see any ENOSPC errors, you were likely not impacted The intent for limiting retries is to prevent pointlessly growing table to max size when adding a block full of entries with same name in different case in mixed mode. However, it turns out we cannot use any limit on the retry. When we copy files from one directory in readdir order, we are copying in hash order, one leaf block at a time. Which means that if the leaf block in source directory has expanded 6 times, and you copy those entries in that block, by the time you need to expand the leaf in destination directory, you need to expand it 6 times in one go. So any limit on the retry will result in error where it shouldn't. Recommendations for Users from Ryan Yao: The regression makes it so that creating a new file could fail with ENOSPC after which files created in that directory could become orphaned. Existing files seem okay, but I have yet to confirm that myself and I cannot speak for what others know. It is incredibly difficult to reproduce on systems running coreutils 8.23 or later. So far, reports have only come from people using coreutils 8.22 or older. The directory size actually gets incremented for each orphaned file, which makes it wrong after orphan files happen. We will likely have some way to recover the orphaned files (like ext4’s lost+found) and fix the directory sizes in the very near future. Snapshots of the damaged datasets are problematic though. Until we have a subcommand to fix it (not including the snapshots, which we would have to list), the damage can be removed from a system that has it either by rolling back to a snapshot before it happened or creating a new dataset with 0.7.6 (or another release other than 0.7.7), moving everything to the new dataset and destroying the old. That will restore things to pristine condition. It should also be possible to check for pools that are affected, but I have yet to finish my analysis to be certain that no false negatives occur when checking, so I will avoid saying how for now. Writes to existing files cannot trigger this bug, only adding new files to a directory in bulk News Roundup des@’s thoughts on being a FreeBSD committer for 20 years Yesterday was the twentieth anniversary of my FreeBSD commit bit, and tomorrow will be the twentieth anniversary of my first commit. I figured I’d split the difference and write a few words about it today. My level of engagement with the FreeBSD project has varied greatly over the twenty years I’ve been a committer. There have been times when I worked on it full-time, and times when I did not touch it for months. The last few years, health issues and life events have consumed my time and sapped my energy, and my contributions have come in bursts. Commit statistics do not tell the whole story, though: even when not working on FreeBSD directly, I have worked on side projects which, like OpenPAM, may one day find their way into FreeBSD. My contributions have not been limited to code. I was the project’s first Bugmeister; I’ve served on the Security Team for a long time, and have been both Security Officer and Deputy Security Officer; I managed the last four Core Team elections and am doing so again this year. In return, the project has taught me much about programming and software engineering. It taught me code hygiene and the importance of clarity over cleverness; it taught me the ins and outs of revision control; it taught me the importance of good documentation, and how to write it; and it taught me good release engineering practices. Last but not least, it has provided me with the opportunity to work with some of the best people in the field. I have the privilege today to count several of them among my friends. For better or worse, the FreeBSD project has shaped my career and my life. It set me on the path to information security in general and IAA in particular, and opened many a door for me. I would not be where I am now without it. I won’t pretend to be able to tell the future. I don’t know how long I will remain active in the FreeBSD project and community. It could be another twenty years; or it could be ten, or five, or less. All I know is that FreeBSD and I still have things to teach each other, and I don’t intend to call it quits any time soon. iXsystems unveils new TrueNAS M-Series Unified Storage Line San Jose, Calif., April 10, 2018 — iXsystems, the leader in Enterprise Open Source servers and software-defined storage, announced the TrueNAS M40 and M50 as the newest high-performance models in its hybrid, unified storage product line. The TrueNAS M-Series harnesses NVMe and NVDIMM to bring all-flash array performance to the award-winning TrueNAS hybrid arrays. It also includes the Intel® Xeon® Scalable Family of Processors and supports up to 100GbE and 32Gb Fibre Channel networking. Sitting between the all-flash TrueNAS Z50 and the hybrid TrueNAS X-Series in the product line, the TrueNAS M-Series delivers up to 10 Petabytes of highly-available and flash-powered network attached storage and rounds out a comprehensive product set that has a capacity and performance option for every storage budget. Designed for On-Premises & Enterprise Cloud Environments As a unified file, block, and object sharing solution, TrueNAS can meet the needs of file serving, backup, virtualization, media production, and private cloud users thanks to its support for the SMB, NFS, AFP, iSCSI, Fibre Channel, and S3 protocols. At the heart of the TrueNAS M-Series is a custom 4U, dual-controller head unit that supports up to 24 3.5” drives and comes in two models, the M40 and M50, for maximum flexibility and scalability. The TrueNAS M40 uses NVDIMMs for write cache, SSDs for read cache, and up to two external 60-bay expansion shelves that unlock up to 2PB in capacity. The TrueNAS M50 uses NVDIMMs for write caching, NVMe drives for read caching, and up to twelve external 60-bay expansion shelves to scale upwards of 10PB. The dual-controller design provides high-availability failover and non-disruptive upgrades for mission-critical enterprise environments. By design, the TrueNAS M-Series unleashes cutting-edge persistent memory technology for demanding performance and capacity workloads, enabling businesses to accelerate enterprise applications and deploy enterprise private clouds that are twice the capacity of previous TrueNAS models. It also supports replication to the Amazon S3, BackBlaze B2, Google Cloud, and Microsoft Azure cloud platforms and can deliver an object store using the ubiquitous S3 object storage protocol at a fraction of the cost of the public cloud. Fast As a true enterprise storage platform, the TrueNAS M50 supports very demanding performance workloads with up to four active 100GbE ports, 3TB of RAM, 32GB of NVDIMM write cache and up to 15TB of NVMe flash read cache. The TrueNAS M40 and M50 include up to 24/7 and global next-business-day support, putting IT at ease. The modular and tool-less design of the M-Series allows for easy, non-disruptive servicing and upgrading by end-users and support technicians for guaranteed uptime. TrueNAS has US-Based support provided by the engineering team that developed it, offering the rapid response that every enterprise needs. Award-Winning TrueNAS Features Enterprise: Perfectly suited for private clouds and enterprise workloads such as file sharing, backups, M&E, surveillance, and hosting virtual machines. Unified: Utilizes SMB, AFP, NFS for file storage, iSCSI, Fibre Channel and OpenStack Cinder for block storage, and S3-compatible APIs for object storage. Supports every common operating system, hypervisor, and application. Economical: Deploy an enterprise private cloud and reduce storage TCO by 70% over AWS with built-in enterprise-class features such as in-line compression, deduplication, clones, and thin-provisioning. Safe: The OpenZFS file system ensures data integrity with best-in-class replication and snapshotting. Customers can replicate data to the rest of the iXsystems storage lineup and to the public cloud. Reliable: High Availability option with dual hot-swappable controllers for continuous data availability and 99.999% uptime. Familiar: Provision and manage storage with the same simple and powerful WebUI and REST APIs used in all iXsystems storage products, as well as iXsystems’ FreeNAS Software. Certified: TrueNAS has passed the Citrix Ready, VMware Ready, and Veeam Ready certifications, reducing the risk of deploying a virtualized infrastructure. Open: By using industry-standard sharing protocols, the OpenZFS Open Source enterprise file system and FreeNAS, the world’s #1 Open Source storage operating system (and also engineered by iXsystems), TrueNAS is the most open enterprise storage solution on the market. Availability The TrueNAS M40 and M50 will be generally available in April 2018 through the iXsystems global channel partner network. The TrueNAS M-Series starts at under $20,000 USD and can be easily expanded using a linear “per terabyte” pricing model. With typical compression, a Petabtye can be stored for under $100,000 USD. TrueNAS comes with an all-inclusive software suite that provides NFS, Windows SMB, iSCSI, snapshots, clones and replication. For more information, visit www.ixsystems.com/TrueNAS TrueNAS M-Series What's New Video Understanding and tuning the FreeBSD Scheduler ``` Occasionally I noticed that the system would not quickly process the tasks i need done, but instead prefer other, longrunning tasks. I figured it must be related to the scheduler, and decided it hates me. A closer look shows the behaviour as follows (single CPU): Lets run an I/O-active task, e.g, postgres VACUUM that would continuously read from big files (while doing compute as well [1]): pool alloc free read write read write cache - - - - - - ada1s4 7.08G 10.9G 1.58K 0 12.9M 0 Now start an endless loop: while true; do :; done And the effect is: pool alloc free read write read write cache - - - - - - ada1s4 7.08G 10.9G 9 0 76.8K 0 The VACUUM gets almost stuck! This figures with WCPU in "top": PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 85583 root 99 0 7044K 1944K RUN 1:06 92.21% bash 53005 pgsql 52 0 620M 91856K RUN 5:47 0.50% postgres Hacking on kern.sched.quantum makes it quite a bit better: sysctl kern.sched.quantum=1 kern.sched.quantum: 94488 -> 7874 pool alloc free read write read write cache - - - - - - ada1s4 7.08G 10.9G 395 0 3.12M 0 PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 85583 root 94 0 7044K 1944K RUN 4:13 70.80% bash 53005 pgsql 52 0 276M 91856K RUN 5:52 11.83% postgres Now, as usual, the "root-cause" questions arise: What exactly does this "quantum"? Is this solution a workaround, i.e. actually something else is wrong, and has it tradeoff in other situations? Or otherwise, why is such a default value chosen, which appears to be ill-deceived? The docs for the quantum parameter are a bit unsatisfying - they say its the max num of ticks a process gets - and what happens when they're exhausted? If by default the endless loop is actually allowed to continue running for 94k ticks (or 94ms, more likely) uninterrupted, then that explains the perceived behaviour - buts thats certainly not what a scheduler should do when other procs are ready to run. 11.1-RELEASE-p7, kern.hz=200. Switching tickless mode on or off does not influence the matter. Starting the endless loop with "nice" does not influence the matter. [1] A pure-I/O job without compute load, like "dd", does not show this behaviour. Also, when other tasks are running, the unjust behaviour is not so stongly pronounced. ``` aarch64 support added I have committed about adding initial support for aarch64. booting log on RaspberryPI3: ``` boot NetBSD/evbarm (aarch64) Drop to EL1...OK Creating VA=PA tables Creating KSEG tables Creating KVA=PA tables Creating devmap tables MMU Enable...OK VSTART = ffffffc000001ff4 FDT devmap cpufunc bootstrap consinit ok uboot: args 0x3ab46000, 0, 0, 0 NetBSD/evbarm (fdt) booting ... FDT /memory [0] @ 0x0 size 0x3b000000 MEM: add 0-3b000000 MEM: res 0-1000 MEM: res 3ab46000-3ab4a000 Usable memory: 1000 - 3ab45fff 3ab4a000 - 3affffff initarm: kernel phys start 1000000 end 17bd000 MEM: res 1000000-17bd000 bootargs: root=axe0 1000 - ffffff 17bd000 - 3ab45fff 3ab4a000 - 3affffff ------------------------------------------ kern_vtopdiff = 0xffffffbfff000000 physical_start = 0x0000000000001000 kernel_start_phys = 0x0000000001000000 kernel_end_phys = 0x00000000017bd000 physical_end = 0x000000003ab45000 VM_MIN_KERNEL_ADDRESS = 0xffffffc000000000 kernel_start_l2 = 0xffffffc000000000 kernel_start = 0xffffffc000000000 kernel_end = 0xffffffc0007bd000 kernel_end_l2 = 0xffffffc000800000 (kernel va area) (devmap va area) VM_MAX_KERNEL_ADDRESS = 0xffffffffffe00000 ------------------------------------------ Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 8.99.14 (RPI64) #11: Fri Mar 30 12:34:19 JST 2018 ryo@moveq:/usr/home/ryo/tmp/netbsd-src-ryo-wip/sys/arch/evbarm/compile/RPI64 total memory = 936 MB avail memory = 877 MB … Starting local daemons:. Updating motd. Starting sshd. Starting inetd. Starting cron. The following components reported failures: /etc/rc.d/swap2 See /var/run/rc.log for more information. Fri Mar 30 12:35:31 JST 2018 NetBSD/evbarm (rpi3) (console) login: root Last login: Fri Mar 30 12:30:24 2018 on console rpi3# uname -ap NetBSD rpi3 8.99.14 NetBSD 8.99.14 (RPI64) #11: Fri Mar 30 12:34:19 JST 2018 ryo@moveq:/usr/home/ryo/tmp/netbsd-src-ryo-wip/sys/arch/evbarm/compile/RPI64 evbarm aarch64 rpi3# ``` Now, multiuser mode works stably on fdt based boards (RPI3,SUNXI,TEGRA). But there are still some problems, more time is required for release. also SMP is not yet. See sys/arch/aarch64/aarch64/TODO for more detail. Especially the problems around TLS of rtld, and C++ stack unwindings are too difficult for me to solve, I give up and need someone's help (^o^)/ Since C++ doesn't work, ATF also doesn't work. If the ATF works, it will clarify more issues. sys/arch/evbarm64 is gone and integrated into sys/arch/evbarm. One evbarm/conf/GENERIC64 kernel binary supports all fdt (bcm2837,sunxi,tegra) based boards. While on 32bit, sys/arch/evbarm/conf/GENERIC will support all fdt based boards...but doesn't work yet. (WIP) My deepest appreciation goes to Tohru Nishimura (nisimura@) whose writes vector handlers, context switchings, and so on. and his comments and suggestions were innumerably valuable. I would also like to thank Nick Hudson (skrll@) and Jared McNeill (jmcneill@) whose added support FDT and integrated into evbarm. Finally, I would like to thank Matt Thomas (matt@) whose commited aarch64 toolchains and preliminary support for aarch64. Beastie Bits 5 Reasons to Use FreeBSD in 2018 Rewriting Intel gigabit network driver in Rust Recruiting to make Elastic Search on FreeBSD better Windows Server 2019 Preview, in bhyve on FreeBSD “SSH Mastery, 2nd ed” in hardcover Feedback/Questions Jason - ZFS Transfer option Luis - ZFS Pools ClonOS Michael - Tech Conferences anonymous - BSD trash on removable drives Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv
Ubuntu is switching back to Xorg, Linus calls out Intel, and are the BSDs dying? Plus how you can start testing Plasma Mobile, Pursim aims for convergence, and Mycroft is back!
Ubuntu is switching back to Xorg, Linus calls out Intel & are the BSDs dying? Plus how you can start testing Plasma Mobile, Purism aims for convergence & Mycroft is back!
Ubuntu is switching back to Xorg, Linus calls out Intel, and are the BSDs dying? Plus how you can start testing Plasma Mobile, Pursim aims for convergence, and Mycroft is back!
Ubuntu is switching back to Xorg, Linus calls out Intel, and are the BSDs dying? Plus how you can start testing Plasma Mobile, Pursim aims for convergence, and Mycroft is back!
Ubuntu is switching back to Xorg, Linus calls out Intel & are the BSDs dying? Plus how you can start testing Plasma Mobile, Purism aims for convergence & Mycroft is back!
Wir haben dieses mal den Mario Hommel mit dabei und er erzählt von seinem Einblick in Contactless Payments! Außerdem reden wir über das Dschungelcamp, Ubuntu 18.04 LTS, Wayland, Xorg, Mobile Payments, iOS11, ZDnet, Canonical, VLC Media Player und Events :)
We provide you with updates to Spectre and Meltdown from various BSD projects, a review of TrueOS from Linux, how to set up FreeBSD on ThinkPad x240, and a whole bunch of beastie bits. This episode was brought to you by Headlines KPTI patch lands in FreeBSD -current (https://svnweb.freebsd.org/base?view=revision&revision=328083) After a heroic effort by Konstantin Belousov kib@FreeBSD.org, the first meltdown patch has landed in FreeBSD This creates separate page tables for the Kernel and userland, and switches between them when executions enters the kernel, and when it returns to userland It is currently off by default, but you are encouraged to test it, so it can be merged back to the release branches. Set vm.pmap.pti=1 in /boot/loader.conf The existing implementation of PCID (process-context identifiers), is not compatible with the new PTI code, and is disabled when PTI is enabled, decreasing performance. A future patch will use PCID in a way that is compatible with PTI. PCID allows the OS to annotate memory mappings to specific processes, so that they can be flushed selectively, and so that they are only used when in the context of that application. Once the developers are relatively confident in the correctness of the code that has landed in -current, it will be ported back to FreeBSD 10 and 11, and released as a security advisory. Apparently porting back to FreeBSD 11 only has some relatively simple merge conflicts, but 10 will be more work. Former FreeBSD Security Officer Dag-Erling Smørgrav has created a meltdown testing and PoC tool (https://github.com/dag-erling/meltdown) that you can use to check your system. It is not finished yet, and doesn't seem to work with newer processors (haswell and newer). The first partial mitigation for Spectre variant 2 (https://svnweb.freebsd.org/changeset/base/328011) for bhyve on AMD64 has also been committed The latest information is always available on the FreeBSD Wiki (https://wiki.freebsd.org/action/edit/SpeculativeExecutionVulnerabilities) *** Some thoughts on Spectre and Meltdown (http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-spectre-and-meltdown.html) Colin Percival breaks down how these vulnerabilities work, with same nice analogies What is a side channel: I want to know when my girlfriend's passport expires, but she won't show me her passport (she complains that it has a horrible photo) and refuses to tell me the expiry date. I tell her that I'm going to take her to Europe on vacation in August and watch what happens: If she runs out to renew her passport, I know that it will expire before August; while if she doesn't get her passport renewed, I know that it will remain valid beyond that date. Her desire to ensure that her passport would be valid inadvertently revealed to me some information: Whether its expiry date was before or after August. Spectre Variant 1: I tell my girlfriend that I'm going to take her on vacation in June, but I don't tell her where yet; however, she knows that it will either be somewhere within Canada (for which she doesn't need a passport, since we live in Vancouver) or somewhere in Europe. She knows that it takes time to get a passport renewed, so she checks her passport and (if it was about to expire) gets it renewed just in case I later reveal that I'm going to take her to Europe. If I tell her later that I'm only taking her to Ottawa — well, she didn't need to renew her passport after all, but in the meantime her behaviour has already revealed to me whether her passport was about to expire. This is what Google refers to "variant 1" of the Spectre vulnerability: Even though she didn't need her passport, she made sure it was still valid just in case she was going to need it. Spectre Variant 2: I spend a week talking about how Oxford is a wonderful place to visit and I really enjoyed the years I spent there, and then I tell her that I want to take her on vacation. She very reasonably assumes that — since I've been talking about Oxford so much — I must be planning on taking her to England, and runs off to check her passport and potentially renew it... but in fact I tricked her and I'm only planning on taking her to Ottawa. Meltdown: I tell my girlfriend that I want to take her to the Korean peninsula. She knows that her passport is valid for long enough; but she immediately runs off to check that her North Korean visa hasn't expired. Why does she have a North Korean visa, you ask? Good question. She doesn't — but she runs off to check its expiry date anyway! Because she doesn't have a North Korean visa, she (somehow) checks the expiry date on someone else's North Korean visa, and then (if it is about to expire) runs out to renew it — and so by telling her that I want to take her to Korea for a vacation I find out something she couldn't have told me even if she wanted to. Final thoughts on vulnerability disclosure The way these issues were handled was a mess; frankly, I expected better of Google, I expected better of Intel, and I expected better of the Linux community. When I found that Hyper-Threading was easily exploitable, I spent five months notifying the security community and preparing everyone for my announcement of the vulnerability; but when the embargo ended at midnight UTC and FreeBSD published its advisory a few minutes later, the broader world was taken entirely by surprise. Nobody knew what was coming aside from the people who needed to know; and the people who needed to know had months of warning. Contrast that with what happened this time around. Google discovered a problem and reported it to Intel, AMD, and ARM on June 1st. Did they then go around contacting all of the operating systems which would need to work on fixes for this? Not even close. FreeBSD was notified the week before Christmas, over six months after the vulnerabilities were discovered. Now, FreeBSD can occasionally respond very quickly to security vulnerabilities, even when they arise at inconvenient times — on November 30th 2009 a vulnerability was reported at 22:12 UTC, and on December 1st I provided a patch at 01:20 UTC, barely over 3 hours later — but that was an extremely simple bug which needed only a few lines of code to fix; the Spectre and Meltdown issues are orders of magnitude more complex. To make things worse, the Linux community was notified and couldn't keep their mouths shut. Standard practice for multi-vendor advisories like this is that an embargo date is set, and nobody does anything publicly prior to that date. People don't publish advisories; they don't commit patches into their public source code repositories; and they definitely don't engage in arguments on public mailing lists about whether the patches are needed for different CPUs. As a result, despite an embargo date being set for January 9th, by January 4th anyone who cared knew about the issues and there was code being passed around on Twitter for exploiting them. This is not the first time I've seen people get sloppy with embargoes recently, but it's by far the worst case. As an industry we pride ourselves on the concept of responsible disclosure — ensuring that people are notified in time to prepare fixes before an issue is disclosed publicly — but in this case there was far too much disclosure and nowhere near enough responsibility. We can do better, and I sincerely hope that next time we do. CPU microcode update code for amd64 (https://undeadly.org/cgi?action=article;sid=20180115073406) (https://marc.info/?l=openbsd-tech&m=151588857304763&w=2) Patrick Wildt (patrick@) recently committed some code that will update the Intel microcode on many Intel CPUs, a diff initially written by Stefan Fritsch (sf@). The microcode of your CPU is basically the firmware that runs on your (Intel) processor, defining its instruction set in terms of so called "microinstructions". The new code depends, of course, on the corresponding firmware package, ported by Patrick which can be installed using a very recent fw_update(1). Of course, this all plays into the recently revealed problems in Intel (and other) CPUs, Meltdown and Spectre. Now Theo has explained the workings of the code on openbsd-tech, detailing some of the challenges in updating microcode on CPUs where your OS is already starting to run. Theo hints at future updates to the intel-firmware package in his mail: (https://marc.info/?l=openbsd-tech&m=151588857304763&w=2) Patrick and others committed amd64 Intel cpu microcode update code over the last few days. The approach isn't perfect, but it is good enough for a start. I want to explain the situation. When you fw_update, you'll get the firmware files. Upon a reboot, it will attempt to update the microcode on your cpus. Maybe there isn't a new microcode. Maybe your BIOS has a copy of the microcode and installs it before booting OpenBSD. This firmware installation is done a little late. Doing it better will require some work in the bootblocks to find the firmware files, but time is a bit short to do that right now. The branch-target-cache flushing features added in new microcode are not being used yet. There is more code which has to be written, but again other work is happening first. Also, Intel is saying their new microcodes sucks and people should wait a little. "Hi, my name is Intel and I'm an cheating speculator". Several developers are working on mitigations for these issues, attacking the problem from several angles. Expect to see more updates to a CVS tree near you soon. Intel: as a *BSD user, I am fucking pissed! (https://malcont.net/2018/01/dont-like-meltdown-spectre-releated-bugs-handled/) I wasn't going to write anything on the recently found x64 architecture – related bugs. I'm not a kernel developer nor even a programmer and I can't say that I have a solid understanding of what Meltdown and Spectre attacks are. Also there already is a ton of articles and posts written by people who have no grasp of the subject. I'm however a malcontent and I find this a good way to express my feelings: Intel: as a *BSD user, I am fucking pissed! Meltdown, Spectre and BSD – the “pissed” part Part of my work is UNIX-like systems administration – including BSDs and Linuces. As much as I am happy with Linux changes already made, I am beyond pissed about how the BSDs were handled by Intel – because they were not. FreeBSD Security Team received some heads-up just before Xmas, while OpenBSD, NetBSD and DragonflyBSD teams received no prior warnings. Meltdown and Spectre attacks are hard to perform. It is a hard work to mitigate them in the software, as the bugs lay in the CPUs and are not fixable by microcode updates. Developers are trying to mitigate these bugs in a way that will deliver smallest performance losses. A lot of time consuming work is needed to fix CPU vendors' mistakes. Linux developers had this time. BSD developers did not. BSD user base too small? BSD user base is small in comparison to Linux. Seems that it's too small for Intel. PlayStation4 consoles are FreeBSD-based (and use AMD CPUs) but I think it's safe to say that gaming devices are not the most important systems to be fixed. Netflix serves their content off FreeBSD but the bugs are not remotely exploitable (possibly not including JavaScript, but it's running someone's code locally) so there's probably not much harm to be done here either. However gamers and Netflix aren't the only ones who use *BSD systems. I'd say that there is more than a few FreeBSD, NetBSD, OpenBSD and DragonFlyBSD servers on the internet. In March 2017, Intel promised “more timely support to FreeBSD”. They knew about flaws in their CPUs in June and decided that a timely manner is the end of December – short before the embargo was to be lifted. Intel and Google (probably Intel more): it was your job to pick the correct people to whom the bugs can be disclosed. In my humble opinion you chose poorly by disclosing these issues with ONLY Apple, Microsoft, and the Linux Foundation, of OS vendors. You did much harm to the BSD community. Intel: It's your bugs. And you offered “more support” to the FreeBSD Foundation less than 3 months prior to being informed (my guess is that you knew much earlier) on the flaws in YOUR products. I don't want to write more here as the wording would be too strong. Interview - Viewer Questions These days, do you consider yourself more of an programmer or a sysadmin? Which one do you enjoy more? Does FreeBSD/BSD enable your business or would another OS suit your needs just as well? You've hinted that you use FreeBSD as part of your business. Can you elaborate on that and give some technical detail on how it's used in that environment? If you were allowed three wishes for anything at all to be implemented or changed in ZFS, what would they be, and why? Per Dataset throughput and IOPS limiting Per-File Cloning and/or zfsmv (move a file from one dataset to another, without copying) Cluster support Allan, you have previously mentioned that you have worked on FreeBSD on MIPS, what made you choose the Onion Omega over something like the Raspberry Pi? What is BSD Now's association with Jupiter broadcasting, and how did the relationship come to be? Jupiter seems to be associated with several Linux-themed podcasts, and I'm wondering how and why BSD Now joined Jupiter. The two communities (the Linuxes and BSDs) don't always seem to mix freely -- or do they? What kind of keyboard is that? Have you ever tried an ErgoDox? The ErgoDox EZ is made by a Canadian. You mentioned when doing one of your talks on UCL for FreeBSD that you had only recently learned C. I am also aware of your history also on contributing to the FreeBSD handbook and to documentation in general. Given you started with C relatively recently, what made you want to learn it, how quickly did you pick it up, and is it your favourite language? It is most inspiring to me, as you are clearly so talented, and of all the languages I have learned (including C++), I still prefer C in my heart of hearts. I'd be really interested to hear your answer, many thanks. *** News Roundup LinuxAndUbuntu Review Of TrueOS A Unix Based OS (http://www.linuxandubuntu.com/home/linuxandubuntu-review-of-trueos-a-unix-based-os) Trust me, the name TrueOS takes me back to 1990s when Tru64 UNIX operating system made its presence. TrueOS is PC-BSD's new unified brand built upon FreeBSD-CURRENT code base. Note that TrueOS is not a Linux distro but is BSD Unix. FreeBSD is known for its cutting-edge features, security, scalability, and ability to work both as a server and desktop operating system. TrueOS aims at having user-friendliness with the power of FreeBSD OS. Let us start with going into details of different aspects of the TrueOS. TrueOS History ? TrueOS was founded by Kris Moore in 2005 with name PC-BSD. Initial version focused to make FreeBSD easy to use starting with providing GUI based installer (to relatively complicated FreeBSD installer). In the year 2006, PC-BSD was acquired by iXsystems. Before rebranding as TrueOS in Sept 2016, PC-BSD reached a stage starting considering better than vanilla FreeBSD. Older PC-BSD version used to support both x86 and x86-64 architecture. Kris Moore, the developer founder, says about rebranding: “We've already been using TrueOS for the server side of PC-BSD, and it made sense to unify the names. PC-BSD doesn't reflect server or embedded well. TrueOS Desktop/Server/Embedded can be real products, avoids some of the alphabet soup, and gives us a more catchy name.” TrueOS First Impression ? The startup is little longer; may be due to starting up of many services. The heavy KDE well suited to PC-BSD. The C++/Qt5 based Lumina desktop environment is light and fast. The Lumina offers an easy way to configure menu and panels. I did not face any problems for continuous use of two weeks on a virtual machine having the minimal configuration: 1 GB RAM, 20 GB hard disk and Intel 3.06 GHz i3 processor. The Lumina desktop is light and fast. The developers of Lumina know what they are doing and have a good idea of what makes a good IDE. As it happens with any new desktop environment, it needs some time to settle. Let us hope that they keep to the path they are on with it. Conclusion ? The TrueOS is impressive when consider it as relatively young. It is a daring step that TrueOS developers took FreeBSD Current rather than FreeBSD Stable code base. Overall it has created its own place from the legacy shadow of PC-BSD. Starting with easy installation TrueOS is a good combination of software and utilities that make the system ready to use. Go and get a TrueOS ISO to unleash the “bleeding edge” tag of FreeBSD Thinkpad x240 - FreeBSD Setup (http://stygix.org/nix/x240-freebsd.php) What follows is a record of how I set up FreeBSD to be my daily driver OS on the Lenovo Thinkpad X240. Everything seems to work great. Although, the touchpad needs some tweaking. I've tried several configurations, even recompiling Xorg with EVDEV support and all that, to no avail. Eventually I will figure it out. Do not sleep the laptop from the command line. Do it from within Xorg, or it will not wake up. I don't know why. You can do it from a terminal within Xorg, just not from the naked command line without Xorg started. It also will not sleep by closing the lid. I included a sudo config that allows you to run /usr/sbin/zzz without a password, so what I do is I have a key combo assigned within i3wm to run "sudo /usr/sbin/zzz". It works fine this way. I go into detail when it comes to setting up Xorg with i3wm. You can skip this if you want, but if you've never used a tiling window manager, it will handle screen real estate very efficiently on a laptop with a 12.5-inch screen and a touchpad. First, download the amd64 image for 11.1-RELEASE and flash it to a USB pen drive. For the Unices, use this: # dd if=FreeBSD-11.1-RELEASE-amd64-memstick.img of=/dev/da0 bs=1M conv=sync Obviously, you'll change /dev/da0 to whatever the USB pen drive is assigned. Plug it in, check dmesg. Leave it plugged in, restart the laptop. When prompted, tap Enter to halt the boot process, then F12 to select a bootable device. Choose the USB drive. I won't go through the actual install process, but it is pretty damn easy so just look at a guide or two and you'll be fine. If you can install Debian, you can install FreeBSD. I will, however, recommend ZFS if you have over 4GB of RAM (my particular variant of the X240 has 8GB of RAM, so yours should have at least 4GB), along with an encrypted disk, and an encrypted SWAP partition. When prompted to add an additional user, and you get to the question where it asks for additional groups, please make sure you add the user to "wheel". The rest should be self-explanatory during the install. Now for the good shit. You just booted into a fresh FreeBSD install. Now what? Well, time to fire up vi and open some config files... CNN Article about CDROM.com and FreeBSD, from 1999 (https://www.cnn.com/TECH/computing/9904/08/cdrom.idg/index.html) Walnut Creek CDROM sells a lot of CD-ROMs, but it gives away even more data. Specifically, anyone who has Internet access is free to log into wcarchive (ftp.cdrom.com) and start downloading bits. Even with a good Internet connection, however, you should expect to be at it for a while. At the present time, wcarchive resides on half a terabyte (500 GB) of RAID 5-disk storage. Even if your 56-Kbps modem can deliver seven kilobytes per second, downloading the complete archive would take you 70 million seconds. Even then, some of the files would be more than two years out of date, so a bit of "back and fill" would be needed. Of course, nobody uses wcarchive that way. Instead, they just drop in when they need the odd file or two. The FTP server is very accommodating; 3,600 simultaneous download sessions is the current limit and an upgrade to 10,000 sessions is in the works. This translates to about 800 GB per day of downloads. Bob Bruce (Walnut Creek's founder) says he's thinking about issuing a press release when they reach a terabyte a day. But 800 GB isn't all that shabby.... The hardware Because FTP archives don't do a lot of thinking, wcarchive doesn't need a massive cluster of CPUs. In fact, it gets by with a single 200-MHz P6 Pentium Pro and a measly(!) 1 GB of RAM. The I/O support, however, is fairly impressive. A six-channel Mylex RAID controller (DAC960SXI; Ultra-Wide SCSI-SCSI) is the centerpiece of the I/O subsystem. Two channels link it to the PC ("Personal Computer"!?!), via a dual-channel Adaptec card (AHA-3940AUW; PCI to Ultra-Wide SCSI). An 256-MB internal cache helps it to eliminate recurring disk accesses. Four nine-drive disk arrays provide the actual storage. The two larger arrays use 18-GB IBM drives; the two smaller arrays use 9-GB Micropolis and Quantum drives. A separate 4-GB Quantum drive is used as the "system disk." The output side is handled by a single Intel 100Base-T controller (Pro/100B PCI), which feeds into the Internet through a number of shared DS3 (45 Mbps) and OC3 (155 Mbps) circuits. A detailed description of the system is available as ftp.cdrom.com/archive-info/configuration; The software The system software is rather prosaic: a copy of FreeBSD, supplemented by home-grown FTP mirroring and server code. Because of the massive hardware support, the software "only" needs to keep the I/O going in an efficient and reliable manner. FreeBSD, the "prosaic" operating system mentioned above, merits a bit more discussion. Like Linux, FreeBSD is open source. Anyone can examine, modify, and/or redistribute the source code. And, like Linux, an active user community helps the authors to find bugs, improve documentation, and generally support the OS. Unlike Linux, FreeBSD is derived from the Berkeley Unix code that forms the foundation for most commercial Unix variants. When you use the "fast file system" (cylinder groups, long file names, symbolic links, etc.), TCP/IP networking, termcap, or even vi, you are using Berkeley Unix additions. The version of BSD underlying FreeBSD, however, is "pure" BSD; don't look for the System V modifications you see in Solaris. Instead, think of it as SunOS, brought up to date with Kerberos, modern sendmail, an updated filesystem, and more. Solid, fast, and free! One of FreeBSD's finest innovations, the Ports Collection, makes FreeBSD a delight for open source application users. The Ports Collection automates the downloading, building, and installation (including de-installation) of 2,300+ open source packages. The company Walnut Creek CDROM has been around for several years now, so you are likely to be familiar with its offerings. You may not realize, however, that it provides the major financial support for FreeBSD. The FreeBSD support has two purposes. First, it provides the company with a solid base to run wcarchive and other massive projects. Second, it ties in with the company's mission of making software (and data) economically accessible. Bob Bruce, the firm's founder, is an interesting guy: laid back and somewhat conservative in manner, but productive and innovative in practice. Here is a possibly illustrative story. When Bob started selling CD-ROMs, disc caddies were selling for $15 each. Bob thought that was rather high, so he started investigating the marketplace. A long-distance call to Japan got him Sony's fax number; a series of faxes got him in touch with the salespeople. It turned out that caddies were available, in bulk, for only a few dollars each. Bulk, in this case, meant pallet-loads of 10,000 caddies. In an act of great faith, Bob purchased a pallet of caddies, then proceeded to sell them for five dollars each. The results were everything he might have wished. Folks who bought his CD-ROMs added caddies to their orders; folks who bought piles of caddies added in a disc or two. Either way, Walnut Creek CDROM was making a name for itself. Many pallet-loads later, the company is still selling caddies, making and distributing CD-ROMs, and giving away bits. Walnut Creek CDROM is a real open-source success story; its breadth and depth of offerings is well worth a look. Beastie Bits OpenBSD adds kqueue event support to DRM, to detect device changes like HDMI cables being plugged in, and trigger randr events (https://github.com/openbsd/src/commit/b8584f4233dc11a328cd245a5843ec3d67462200) Thesis describing QUAD3, a unix-like, multi-tasking operating system for the 6502 processor (https://archive.org/details/AMultiTaskingOperatingSystemForMicrocomputers) Windows is getting chmod and chown... (https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/) Timeline: How they kept Meltdown and Spectre secret for so long (https://www.theverge.com/platform/amp/2018/1/11/16878670/meltdown-spectre-disclosure-embargo-google-microsoft-linux) bsd.network is a *BSD-themed Mastodon Instance (https://bsd.network/): Peter Hessler is administering a new Mastodon instance, running in an OpenBSD VM on top of an OpenBSD vmm hypervisor Computer-Aided Instruction on UNIX (https://virtuallyfun.com/wordpress/wp-content/uploads/2017/12/whfUb.pdf) AsiaBSDCon 2018 Travel Grant Application Now Open (https://www.freebsdfoundation.org/blog/asiabsdcon-2018-travel-grant-application-now-open/) AsiaBSDCon 2018 FreeBSD Developers Summit Call for Proposals (https://www.freebsdfoundation.org/news-and-events/call-for-papers/asiabsdcon-2018-freebsd-developers-summit-call-for-proposals/) LinuxFest Northwest 2018 Call for Proposals (https://www.freebsdfoundation.org/news-and-events/call-for-papers/linuxfest-northwest-2018-call-for-proposals/) Feedback/Questions Jason - Dont break my ports (http://dpaste.com/05PRNG2) Wilyarti - show content (http://dpaste.com/1BG8GZW) https://clinetworking.wordpress.com/2017/12/08/data-de-duplication-file-diff-ing-and-s3-style-object-storage-using-digital-ocean-spaces Scott - Your show is Perfect! (http://dpaste.com/0KER8YE#wrap) Ken - Community Culture (http://dpaste.com/0WT8285#wrap)
This week on BSD Now, we clear up some ZFS FUD, show you how to write a NetBSD kernel module, and cover DragonflyBSD on the desktop. This episode was brought to you by Headlines ZFS is the best file system (for now) (http://blog.fosketts.net/2017/07/10/zfs-best-filesystem-now/) In my ongoing effort to fight misinformation and FUD about ZFS, I would like to go through this post in detail and share my thoughts on the current state and future of OpenZFS. The post starts with: ZFS should have been great, but I kind of hate it: ZFS seems to be trapped in the past, before it was sidelined it as the cool storage project of choice; it's inflexible; it lacks modern flash integration; and it's not directly supported by most operating systems. But I put all my valuable data on ZFS because it simply offers the best level of data protection in a small office/home office (SOHO) environment. Here's why. When ZFS first appeared in 2005, it was absolutely with the times, but it's remained stuck there ever since. The ZFS engineers did a lot right when they combined the best features of a volume manager with a “zettabyte-scale” filesystem in Solaris 10 The skies first darkened in 2007, as NetApp sued Sun, claiming that their WAFL patents were infringed by ZFS. Sun counter-sued later that year, and the legal issues dragged on. The lawsuit was resolved, and it didn't really impede ZFS. Some say it is the reason that Apple didn't go with ZFS, but there are other theories too. By then, Sun was hitting hard times and Oracle swooped in to purchase the company. This sowed further doubt about the future of ZFS, since Oracle did not enjoy wide support from open source advocates. Yes, Oracle taking over Sun and closing the source for ZFS definitely seemed like a setback at the time, but the OpenZFS project was started and active development has continued as an ever increasing pace. As of today, more than half of the code in OpenZFS has been written since the fork from the last open version of Oracle ZFS. the CDDL license Sun applied to the ZFS code was https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ (judged incompatible) with the GPLv2 that covers Linux, making it a non-starter for inclusion in the world's server operating system. That hasn't stopped the ZFS-on-Linux project, or Ubuntu… Although OpenSolaris continued after the Oracle acquisition, and FreeBSD embraced ZFS, this was pretty much the extent of its impact outside the enterprise. Sure, NexentaStor and http://blog.fosketts.net/2008/09/15/greenbytes-embraces-extends-zfs/ (GreenBytes) helped push ZFS forward in the enterprise, but Oracle's lackluster commitment to Sun in the datacenter started having an impact. Lots of companies have adopted OpenZFS for their products. Before OpenZFS, there were very few non-Sun appliances that used ZFS, now there are plenty. OpenZFS Wiki: Companies with products based on OpenZFS (http://open-zfs.org/wiki/Companies) OpenZFS remains little-changed from what we had a decade ago. Other than the fact that half of the current code did not exist a decade ago… Many remain skeptical of deduplication, which hogs expensive RAM in the best-case scenario. This is one of the weaker points in ZFS. As it turns out, the demand for deduplication is actually not that strong. Most of the win can be had with transparent compression. However, there are a number of suggested designs to work around the dedup problems: Dedup Ceiling: Set a limit on the side of the DDT and just stop deduping new unique blocks when this limit is reached. Allocation Classes: A feature being developed by Intel for a supercomputer, will allow different types of data to be classified, and dedicated vdevs (or even metaslabs within a vdev), to be dedicated to that class of data. This could be extended to having the DDT live on a fast device like an PCIe NVMe, combined with the Dedup Ceiling when the device is full. DDT Pruning: Matt Ahrens described a design where items in the DDT with only a single reference, would be expired in an LRU type fashion, to allow newer blocks to live in the DDT in hopes that they would end up with more than a single reference. This doesn't cause bookkeeping problems since when a block is about to be freed, if it is NOT listed in the DDT, ZFS knows it was never deduplicated, so the current block must be the only reference, and it can safely be freed. This provides a best case scenario compared to Dedup Ceiling, since blocks that will deduplicate well, are likely to be written relatively close together, whereas the chance to a dedup match on a very old block is much lower. And I do mean expensive: Pretty much every ZFS FAQ flatly declares that ECC RAM is a must-have and 8 GB is the bare minimum. In my own experience with FreeNAS, 32 GB is a nice amount for an active small ZFS server, and this costs $200-$300 even at today's prices. As we talked about a few weeks ago, ECC is best, but it is not required. If you want your server to stay up for a long time, to be highly available, you'll put ECC in it. Don't let a lack of ECC stop you from using ZFS, you are just putting your data at more risk. The scrub of death is a myth. ZFS does not ‘require' lots of ram. Your NAS will work happily with 8 GB instead of 32 GB of RAM. Its cache hit ratio will be much lower, so performance will be worse. It won't be able to buffer as many writes, so performance will be worse. Copy-on-Write has some drawbacks, data tends to get scattered and fragmented across the drives when it is written gradually. The ARC (RAM Cache) lessens the pain of this, and allows ZFS to batch incoming writes up into nice contiguous writes. ZFS purposely alternates between reading and writing, since both are faster when the other is not happening. So writes are batched up until there is too much dirty data, or the timeout expires. Then reads are held off while the bulk linear write finishes as quickly as possible, and reads are resumed. Obviously all of this works better and more efficiently in larger batches, which you can do if you have more RAM. ZFS can be tuned to use less RAM, and if you do not have a lot of RAM, or you have a lot of other demand on your RAM, you should do that tuning. And ZFS never really adapted to today's world of widely-available flash storage: Although flash can be used to support the ZIL and L2ARC caches, these are of dubious value in a system with sufficient RAM, and ZFS has no true hybrid storage capability. It's laughable that the ZFS documentation obsesses over a few GB of SLC flash when multi-TB 3D NAND drives are on the market. And no one is talking about NVMe even though it's everywhere in performance PC's. Make up your mind, is 32GB of ram too expensive or not… the L2ARC exists specifically for the case where it is not possible to just install more RAM. Be it because there are no more slots, of limits of the processor, or limits of your budget. The SLOG is optional, but it never needs to be very big. A number of GBs of SLC flash is all you need, it is only holding writes that have not been flushed to the regular storage devices yet. The reason the documentation talks about SLC specifically is because your SLOG needs a very high write endurance, something never the newest NVMe devices cannot yet provide. Of course you can use NVMe devices with ZFS, lots of people do. All flash ZFS arrays are for sale right now. Other than maybe a little tuning of the device queue depths, ZFS just works and there is nothing to think about. However, to say there is nothing happening in this space is woefully inaccurate. The previously mentioned allocation classes code can be used to allocate metadata (4 KB blocks) on SSD or NVMe, while allocating bulk storage data (up to 16 MB blocks) on spinning disks. Extended a bit beyond what Intel is building for their super computer, this will basically create hybrid storage for ZFS. With the metaslab classes feature, it will even be possible to mix classes on the same device, grouping small allocations and large allocations in different areas, decreasing fragmentation. Then there's the question of flexibility, or lack thereof. Once you build a ZFS volume, it's pretty much fixed for life. There are only three ways to expand a storage pool: Replace each and every drive in the pool with a larger one (which is great but limiting and expensive) It depends on your pool layout. If you design with this in mind using ZFS Mirrors, it can be quite useful Add a stripe on another set of drives (which can lead to imbalanced performance and redundancy and a whole world of potential stupid stuff) The unbalanced LUNs performance issues were sorted out in 2013-2016. 2014: OpenZFS Allocation Performance (http://open-zfs.org/w/images/3/31/Performance-George_Wilson.pdf) 2016: OpenZFS space allocation: doubling performance on large and fragmented pools (http://www.bsdcan.org/2016/schedule/events/710.en.html) These also mostly solved the performance issues when a pool gets full, you can run a lot closer to the edge now Build a new pool and “zfs send” your datasets to it (which is what I do, even though it's kind of tricky) This is one way to do it, yes. There is another way coming, but I can't talk about it just yet. Look for big news later this year. Apart from option 3 above, you can't shrink a ZFS pool. Device removal is arriving now. It will not work for RAIDZ*, but for Mirrors and Stripes you will be able to remove a device. I've probably made ZFS sound pretty unappealing right about now. It was revolutionary but now it's startlingly limiting and out of touch with the present solid-state-dominated storage world. I don't feel like ZFS is out of touch with solid state. Lots of people are running SSD only pools. I will admit the tiered storage options in ZFS are a bit limited still, but there is a lot of work being done to overcome this. After all, reliably storing data is the only thing a storage system really has to do. All my important data goes on ZFS, from photos to music and movies to office files. It's going to be a long time before I trust anything other than ZFS! + I agree. + ZFS has a great track record of doing its most important job, keeping your data safe. + Work is ongoing to make ZFS more performance, and more flexible. The import thing is that this work is never allowed to compromise job #1, keeping your data safe. + Hybrid/tiered storage features, re-RAID-ing, are coming + There is a lot going on with OpenZFS, check out the notes from the last two OpenZFS Developer Summits just to get an idea of what some of those things are: 2015 (http://open-zfs.org/wiki/OpenZFS_Developer_Summit_2015) & 2016 (http://open-zfs.org/wiki/OpenZFS_Developer_Summit_2016) Some highlights: Compressed ARC Compressed send/recv ABD (arc buf scatter/gather) ZFS Native Encryption (scrub/resilver, send/recv, etc without encryption keys loaded) Channel Programs (do many administrative operations as one atomic transaction) Device Removal Redacted send/recv ZStandard Compression TRIM Support (FreeBSD has its own, but this will be more performant and universal) Faster Scrub/Resilver (https://youtu.be/SZFwv8BdBj4) Declustered RAID (https://youtu.be/MxKohtFSB4M) Allocation Classes (https://youtu.be/28fKiTWb2oM) Multi-mount protection (for Active/Passive failover) Zpool Checkpoint (undo almost anything) Even more Improved Allocator Performance vdev spacemap log ZIL performance improvements (w/ or w/o SLOG) Persistent L2ARC What I don't think the author of this article understands is how far behind every other filesystem is. 100s of Engineer years have gone into OpenZFS, and the pace is accelerating. I don't see how BtrFS can ever catch up, without a huge cash infusion. Writing a NetBSD kernel module (https://saurvs.github.io/post/writing-netbsd-kern-mod/) Kernel modules are object files used to extend an operating system's kernel functionality at run time. In this post, we'll look at implementing a simple character device driver as a kernel module in NetBSD. Once it is loaded, userspace processes will be able to write an arbitrary byte string to the device, and on every successive read expect a cryptographically-secure pseudorandom permutation of the original byte string. You will need the NetBSD Source Code. This doc (https://www.netbsd.org/docs/guide/en/chap-fetch.html) will explain how you can get it. The article gives an easy line by line walkthrough which is easy to follow and understand. The driver implements the bare minimum: open, close, read, and write, plus the module initialization function It explains the differences in how memory is allocated and freed in the kernel It also describes the process of using UIO to copy data back and forth between userspace and the kernel Create a Makefile, and compile the kernel module Then, create a simple userspace program to use the character device that the kernel module creates All the code is available here (https://github.com/saurvs/rperm-netbsd) *** DragonFlyBSD Desktop! (https://functionallyparanoid.com/2017/07/11/dragonflybsd-desktop/) If you read my last post (https://functionallyparanoid.com/2017/06/30/boot-all-the-things/), you know that I set up a machine (Thinkpad x230) with UEFI and four operating systems on it. One, I had no experience with – DragonFlyBSD (other than using Matthew Dillon's C compiler for the Amiga back in the day!) and so it was uncharted territory for me. After getting the install working, I started playing around inside of DragonFlyBSD and discovered to my delight that it was a great operating system with some really unique features – all with that BSD commitment to good documentation and a solid coupling of kernel and userland that doesn't exist (by design) in Linux. So my goal for my DragonFlyBSD desktop experience was to be as BSD as I possibly could. Given that (and since I'm the maintainer of the port on OpenBSD ), I went with Lumina as the desktop environment and XDM as the graphical login manager. I have to confess that I really like the xfce terminal application so I wanted to make sure I had that as well. Toss in Firefox, libreOffice and ownCloud sync client and I'm good to go! OK. So where to start. First, we need to get WiFi and wired networking happening for the console at login. To do that, I added the following to /etc/rc.conf: wlans_iwn0=”wlan0″ ifconfig_wlan0=”WPA DHCP” ifconfig_em0=”DHCP” I then edited /etc/wpa_supplicant.conf to put in the details of my WiFi network: network={ ssid=”MY-NETWORK-NAME” psk=”my-super-secret-password” } A quick reboot showed that both wired and wireless networking were functional and automatically were assigned IP addresses via DHCP. Next up is to try getting into X with whatever DragonFlyBSD uses for its default window manager. A straight up “startx” met with, shall we say, less than stellar results. Therefore, I used the following command to generate a simple /etc/X11/xorg.conf file: # Xorg -configure # cp /root/xorg.conf.new /etc/X11/xorg.conf With that file in place, I could get into the default window manager, but I had no mouse. After some searching and pinging folks on the mailing list, I was able to figure out what I needed to do. I added the following to my /etc/rc.conf file: moused_enable=”YES” moused_type=”auto” moused_port=”/dev/psm0″ I rebooted (I'm sure there is an easier way to get the changes but I don't know it… yet) and was able to get into a basic X session and have a functional mouse. Next up, installing and configuring Lumina! To do that, I went through the incredibly torturous process of installing Lumina: # pkg install lumina Wow! That was really, really hard. I might need to pause here to catch my breath.
The NetBSD 8.0 release process is underway, we try to measure the weight of an electron, and look at stack clashing. This episode was brought to you by Headlines NetBSD 8.0 release process underway (https://mail-index.netbsd.org/netbsd-announce/2017/06/06/msg000267.html) Soren Jacobsen writes on NetBSD-announce: If you've been reading source-changes@, you likely noticed the recent creation of the netbsd-8 branch. If you haven't been reading source-changes@, here's some news: the netbsd-8 branch has been created, signaling the beginning of the release process for NetBSD 8.0. We don't have a strict timeline for the 8.0 release, but things are looking pretty good at the moment, and we expect this release to happen in a shorter amount of time than the last couple major releases did. At this point, we would love for folks to test out netbsd-8 and let us know how it goes. A couple of major improvements since 7.0 are the addition of USB 3 support and an overhaul of the audio subsystem, including an in-kernel mixer. Feedback about these areas is particularly desired. To download the latest binaries built from the netbsd-8 branch, head to [http://daily-builds.NetBSD.org/pub/NetBSD-daily/netbsd-8/(]http://daily-builds.NetBSD.org/pub/NetBSD-daily/netbsd-8/) Thanks in advance for helping make NetBSD 8.0 a stellar release! OpenIndiana Hipster 2017.04 is here (https://www.openindiana.org/2017/05/03/openindiana-hipster-2017-04-is-here/) Desktop software and libraries Xorg was updated to 1.18.4, xorg libraries and drivers were updated. Mate was updated to 1.16 Intel video driver was updated, the list of supported hardware has significantly extended (https://wiki.openindiana.org/oi/Intel+KMS+driver) libsmb was updated to 4.4.6 gvfs was updated to 1.26.0 gtk3 was updated to 3.18.9 Major text editors were updated (we ship vim 8.0.104, joe 4.4, emacs 25.2, nano 2.7.5 pulseaudio was updated to 10.0 firefox was updated to 45.9.0 thunderbird was updated to 45.8.0 critical issue in enlightenment was fixed, now it's operational again privoxy was updated to 3.0.26 Mesa was updated to 13.0.6 Nvidia driver was updated to 340.102 Development tools and libraries GCC 6 was added. Patches necessary to compile illumos-gate with GCC 6 were added (note, compiling illumos-gate with version other than illumos-gcc-4.4.4 is not supported) GCC 7.1 added to Hipster (https://www.openindiana.org/2017/05/05/gcc-7-1-added-the-hipster-and-rolling-forward/) Bison was updated to 3.0.4 Groovy 2.4 was added Ruby 1.9 was removed, Ruby 2.3 is the default Ruby now Perl 5.16 was removed. 64-bit Perl 5.24 is shipped. 64-bit OpenJDK 8 is the default OpenJDK version now. Mercurial was updated to 4.1.3 Git was updated to 2.12.2 ccache was updated to 3.3.3 QT 5.8.0 was added Valgrind was updated to 3.12.0 Server software PostgreSQL 9.6 was added, PostgreSQL 9.3-9.5 were updated to latest minor versions MongoDB 3.4 was added MariaDB 10.1 was added NodeJS 7 was added Percona Server 5.5/5.6/5.7 and MariaDB 5.5 were updated to latest minor versions OpenVPN was updated to 2.4.1 ISC Bind was updated to 9.10.4-P8 Squid was updated to 3.5.25 Nginx was updated to 1.12.0 Apache 2.4 was updated to 2.4.25. Apache 2.4 is the default Apache server now. Apache 2.2 will be removed before the next snapshot. ISC ntpd was updated to 4.2.8p10 OpenSSH was updated to 7.4p1 Samba was updated to 4.4.12 Tcpdump was updated to 4.9.0 Snort was updated to 2.9.9.0 Puppet was updated to 3.8.6 A lot of other bug fixes and minor software updates included. *** PKGSRC at The University of Wisconsin–Milwaukee (https://uwm.edu/hpc/software-management/) This piece is from the University of Wisconsin, Milwaukee Why Use Package Managers? Why Pkgsrc? Portability Flexibility Modernity Quality and Security Collaboration Convenience Growth Binary Packages for Research Computing The University of Wisconsin — Milwaukee provides binary pkgsrc packages for selected operating systems as a service to the research computing community. Unlike most package repositories, which have a fixed prefix and frequently upgraded packages, these packages are available for multiple prefixes and remain unchanged for a given prefix. Additional packages may be added and existing packages may be patched to fix bugs or security issues, but the software versions will not be changed. This allows researchers to keep older software in-place indefinitely for long-term studies while deploying newer software in later snapshots. Contributing to Pkgsrc Building Your Own Binary Packages Check out the full article and consider using pkgsrc for your own research purposes. PKGSrc Con is this weekend! (http://www.pkgsrc.org/pkgsrcCon/2017/) *** Measuring the weight of an electron (https://deftly.net/posts/2017-06-01-measuring-the-weight-of-an-electron.html) An interesting story of the struggles of one person, aided only by their pet Canary, porting Electron to OpenBSD. This is a long rant. A rant intended to document lunacy, hopefully aid others in the future and make myself feel better about something I think is crazy. It may seem like I am making an enemy of electron, but keep in mind that isn't my intention! The enemy here, is complexity! My friend Henry, a canary, is coming along for the ride! Getting the tools At first glance Electron seems like a pretty solid app, it has decent docs, it's consolidated in a single repository, has a lot of visibility, porting it shouldn't be a big deal, right? After cloning the repo, trouble starts: Reading through the doc, right off the bat there are a few interesting things: At least 25GB disk space. Huh, OK, some how this ~47M repository is going to blow up to 25G? Continuing along with the build, I know I have two versions of clang installed on OpenBSD, one from ports and one in base. Hopefully I will be able to tell the build to use one of these versions. Next, it's time to tell the bootstrap that OpenBSD exists as a platform. After that is fixed, the build-script runs. Even though cloning another git repo fails, the build happily continues. Wait. Another repository failed to clone? At least this time the build failed after trying to clone boto.. again. I am guessing it tried twice because something might have changed between now and the last clone? Off in the distance we catch a familiar tune, it almost sounds like Gnarls Barkley's song Crazy, can't tell for sure. As it turns out, if you are using git-fsck, you are unable to clone boto and requests. Obviously the proper fix for his is to not care about the validity of the git objects! So we die a little inside and comment out fsckobjects in our ~/.gitconfig. Next up, chromium-58 is downloaded… Out of curiosity we look at vendor/libchromiumcontent/script/update, it seems its purpose is to download / extract chromium clang and node, good thing we already specified --clang_dir or it might try to build clang again! 544 dots and 45 minutes later, we have an error! The chromium-58.0.3029.110.tar.xz file is mysteriously not there anymore.. Interesting. Wut. “Updating Clang…”. Didn't I explicitly say not to build clang? At this point we have to shift projects, no longer are we working on Electron.. It's libchromiumcontent that needs our attention. Fixing sub-tools Ahh, our old friends the dots! This is the second time waiting 45+ minutes for a 500+ MB file to download. We are fairly confident it will fail, delete the file out from under itself and hinder the process even further, so we add an explicit exit to the update script. This way we can copy the file somewhere safe! Another 45 minute chrome build and saving the downloaded executable to a save space seems in order. Fixing another 50 occurrences of error conditions let's the build continue - to another clang build. We remove the call to update_clang, because.. well.. we have two copies of it already and the Electron doc said everything would be fine if we had >= clang 3.4! More re-builds and updates of clang and chromium are being commented out, just to get somewhere close to the actual electron build. Fixing sub-sub-tools Ninja needs to be build and the script for that needs to be told to ignore this “unsupported OS” to continue. No luck. At this point we are faced with a complex web of python scripts that execute gn on GN files to produce ninja files… which then build the various components and somewhere in that cluster, something doesn't know about OpenBSD… I look at Henry, he is looking a photo of his wife and kids. They are sitting on a telephone wire, the morning sun illuminating their beautiful faces. Henry looks back at me and says “It's not worth it.” We slam the laptop shut and go outside. Interview - Dan McDonald - allcoms@gmail.com (mailto:allcoms@gmail.com) (danboid) News Roundup g4u 2.6 (ghosting for unix) released 18th birthday (https://mail-index.netbsd.org/netbsd-users/2017/06/08/msg019625.html) Hubert Feyrer writes in his mail to netbsd-users: After a five-year period for beta-testing and updating, I have finally released g4u 2.6. With its origins in 1999, I'd like to say: Happy 18th Birthday, g4u! About g4u: g4u ("ghosting for unix") is a NetBSD-based bootfloppy/CD-ROM that allows easy cloning of PC harddisks to deploy a common setup on a number of PCs using FTP. The floppy/CD offers two functions. The first is to upload the compressed image of a local harddisk to a FTP server, the other is to restore that image via FTP, uncompress it and write it back to disk. Network configuration is fetched via DHCP. As the harddisk is processed as an image, any filesystem and operating system can be deployed using g4u. Easy cloning of local disks as well as partitions is also supported. The past: When I started g4u, I had the task to install a number of lab machines with a dual-boot of Windows NT and NetBSD. The hype was about Microsoft's "Zero Administration Kit" (ZAK) then, but that did barely work for the Windows part - file transfers were slow, depended on the clients' hardware a lot (requiring fiddling with MS DOS network driver disks), and on the ZAK server the files for installing happened do disappear for no good reason every now and then. Not working well, and leaving out NetBSD (and everything else), I created g4u. This gave me the (relative) pain of getting things working once, but with the option to easily add network drivers as they appeared in NetBSD (and oh they did!), plus allowed me to install any operating system. The present: We've used g4u successfully in our labs then, booting from CDROM. I also got many donations from public and private institutions plus companies from many sectors, indicating that g4u does make a difference. In the meantime, the world has changed, and CDROMs aren't used that much any more. Network boot and USB sticks are today's devices of choice, cloning of a full disk without knowing its structure has both advantages but also disadvantages, and g4u's user interface is still command-line based with not much space for automation. For storage, FTP servers are nice and fast, but alternatives like SSH/SFTP, NFS, iSCSI and SMB for remote storage plus local storage (back to fun with filesystems, anyone? avoiding this was why g4u was created in the first place!) should be considered these days. Further aspects include integrity (checksums), confidentiality (encryption). This leaves a number of open points to address either by future releases, or by other products. The future: At this point, my time budget for g4u is very limited. I welcome people to contribute to g4u - g4u is Open Source for a reason. Feel free to get back to me for any changes that you want to contribute! The changes: Major changes in g4u 2.6 include: Make this build with NetBSD-current sources as of 2017-04-17 (shortly before netbsd-8 release branch), binaries were cross-compiled from Mac OS X 10.10 Many new drivers, bugfixes and improvements from NetBSD-current (see beta1 and beta2 announcements) Go back to keeping the disk image inside the kernel as ramdisk, do not load it as separate module. Less error prone, and allows to boot the g4u (NetBSD) kernel from a single file e.g. via PXE (Testing and documentation updates welcome!) Actually DO provide the g4u (NetBSD) kernel with the embedded g4u disk image from now on, as separate file, g4u-kernel.gz In addition to MD5, add SHA512 checksums Congratulation, g4u. Check out the g4u website (http://fehu.org/~feyrer/g4u/) and support the project if you are using it. *** Fixing FreeBSD Networking on Digital Ocean (https://wycd.net/posts/2017-05-19-fixing-freebsd-networking-on-digital-ocean.html) Most cloud/VPS providers use some form of semi-automated address assignment, rather than just regular static address configuration, so that newly created virtual machines can configure themselves. Sometimes, especially during the upgrade process, this can break. This is the story of one such user: I decided it was time to update my FreeBSD Digital Ocean droplet from the end-of-life version 10.1 (shame on me) to the modern version 10.3 (good until April 2018), and maybe even version 11 (good until 2021). There were no sensitive files on the VM, so I had put it off. Additionally, cloud providers tend to have shoddy support for BSDs, so breakages after messing with the kernel or init system are rampant, and I had been skirting that risk. The last straw for me was a broken pkg: /usr/local/lib/libpkg.so.3: Undefined symbol "openat" So the user fires up freebsd-update and upgrades to FreeBSD 10.3 I rebooted, and of course, it happened: no ssh access after 30 seconds, 1 minute, 2 minutes…I logged into my Digital Ocean account and saw green status lights for the instance, but something was definitely wrong. Fortunately, Digital Ocean provides console access (albeit slow, buggy, and crashes my browser every time I run ping). ifconfig revealed that the interfaces vtnet0 (public) and vtnet1 (private) haven't been configured with IP addresses. Combing through files in /etc/rc.*, I found a file called /etc/rc.digitalocean.d/${DROPLETID}.conf containing static network settings for this droplet (${DROPLETID} was something like 1234567). It seemed that FreeBSD wasn't picking up the Digital Ocean network settings config file. The quick and dirty way would have been to messily append the contents of this file to /etc/rc.conf, but I wanted a nicer way. Reading the script in /etc/rc.d/digitalocean told me that /etc/rc.digitalocean.d/${DROPLET_ID}.conf was supposed to have a symlink at /etc/rc.digitalocean.d/droplet.conf. It was broken and pointed to /etc/rc.digitalocean.d/.conf, which could happen when the curl command in /etc/rc.d/digitalocean fails Maybe the curl binary was also in need for an upgrade so failed to fetch the droplet ID Using grep to fish for files containing droplet.conf, I discovered that it was hacked into the init system via loadrcconfig() in /etc/rc.subr I would prefer if Digital Ocean had not customized the version of FreeBSD they ship quite so much I could fix that symlink and restart the services: set DROPLET_ID=$(curl -s http://169.254.169.254/metadata/v1/id) ln -s -f /etc/rc.digitalocean.d/${DROPLET_ID}.conf /etc/rc.digitalocean.d/droplet.conf /etc/rc.d/netif restart /etc/rc.d/routing restart Networking was working again, and I could then ssh into my server and run the following to finish the upgrade: freebsd-update install At this point, I decided that I didn't want to deal with this mess again until at least 2021, so I decided to go for 11.0-RELEASE freebsd-update -r 11.0-RELEASE update freebsd-update install reboot freebsd-update install pkg-static install -f pkg pkg update pkg upgrade uname -a FreeBSD hostname 11.0-RELEASE-p9 FreeBSD 11.0-RELEASE-p9 pkg -v 1.10.1 The problem was solved correctly, and my /etc/rc.conf remains free of generated cruft. The Digital Ocean team can make our lives easier by having their init scripts do more thorough system checking, e.g., catching broken symlinks and bad network addresses. I'm hopeful that collaboration of the FreeBSD team and cloud providers will one day result in automatic fixing of these situations, or at least a correct status indicator. The Digital Ocean team didn't really know many FreeBSD people when they made the first 10.1 images, they have improved a lot, but they of course could always use more feedback from BSD users ** Stack Clash (https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt) A 12-year-old question: "If the heap grows up, and the stack grows down, what happens when they clash? Is it exploitable? How? In 2005, Gael Delalleau presented "Large memory management vulnerabilities" and the first stack-clash exploit in user-space (against mod_php 4.3.0 on Apache 2.0.53) (http://cansecwest.com/core05/memory_vulns_delalleau.pdf) In 2010, Rafal Wojtczuk published "Exploiting large memory management vulnerabilities in Xorg server running on Linux", the second stack-clash exploit in user-space (CVE-2010-2240) (http://www.invisiblethingslab.com/resources/misc-2010/xorg-large-memory-attacks.pdf) Since 2010, security researchers have exploited several stack-clashes in the kernel-space, In user-space, however, this problem has been greatly underestimated; the only public exploits are Gael Delalleau's and Rafal Wojtczuk's, and they were written before Linux introduced a protection against stack-clashes (a "guard-page" mapped below the stack) (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2240) In this advisory, we show that stack-clashes are widespread in user-space, and exploitable despite the stack guard-page; we discovered multiple vulnerabilities in guard-page implementations, and devised general methods for: "Clashing" the stack with another memory region: we allocate memory until the stack reaches another memory region, or until another memory region reaches the stack; "Jumping" over the stack guard-page: we move the stack-pointer from the stack and into the other memory region, without accessing the stack guard-page; "Smashing" the stack, or the other memory region: we overwrite the stack with the other memory region, or the other memory region with the stack. So this advisory itself, is not a security vulnerability. It is novel research showing ways to work around the mitigations against generic vulnerability types that are implemented on various operating systems. While this issue with the mitigation feature has been fixed, even without the fix, successful exploitation requires another application with its own vulnerability in order to be exploited. Those vulnerabilities outside of the OS need to be fixed on their own. FreeBSD-Security post (https://lists.freebsd.org/pipermail/freebsd-security/2017-June/009335.html) The issue under discussion is a limitation in a vulnerability mitigation technique. Changes to improve the way FreeBSD manages stack growth, and mitigate the issue demonstrated by Qualys' proof-of-concept code, are in progress by FreeBSD developers knowledgeable in the VM subsystem. FreeBSD address space guards (https://svnweb.freebsd.org/base?view=revision&revision=320317) HardenedBSD Proof of Concept for FreeBSD (https://github.com/lattera/exploits/blob/master/FreeBSD/StackClash/001-stackclash.c) HardenedBSD implementation: https://github.com/HardenedBSD/hardenedBSD/compare/de8124d3bf83d774b66f62d11aee0162d0cd1031...91104ed152d57cde0292b2dc09489fd1f69ea77c & https://github.com/HardenedBSD/hardenedBSD/commit/00ad1fb6b53f63d6e9ba539b8f251b5cf4d40261 Qualys PoC: freebsd_cve-2017-fgpu.c (https://www.qualys.com/2017/06/19/stack-clash/freebsd_cve-2017-fgpu.c) Qualys PoC: freebsd_cve-2017-fgpe.c (https://www.qualys.com/2017/06/19/stack-clash/freebsd_cve-2017-fgpe.c) Qualys PoC: freebsd_cve-2017-1085.c (https://www.qualys.com/2017/06/19/stack-clash/freebsd_cve-2017-1085.c) Qualys PoC: OpenBSD (https://www.qualys.com/2017/06/19/stack-clash/openbsd_at.c) Qualys PoC: NetBSD (https://www.qualys.com/2017/06/19/stack-clash/netbsd_cve-2017-1000375.c) *** Will ZFS and non-ECC RAM kill your data? (http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/) TL;DR: ECC is good, but even without, having ZFS is better than not having ZFS. What's ECC RAM? Is it a good idea? What's ZFS? Is it a good idea? Is ZFS and non-ECC worse than not-ZFS and non-ECC? What about the Scrub of Death? The article walks through ZFS folk lore, and talks about what can really go wrong, and what is just the over-active imagination of people on the FreeNAS forums But would using any other filesystem that isn't ZFS have protected that data? ‘Cause remember, nobody's arguing that you can lose data to evil RAM – the argument is about whether evil RAM is more dangerous with ZFS than it would be without it. I really, really want to use the Scrub Of Death in a movie or TV show. How can I make it happen? I don't care about your logic! I wish to appeal to authority! OK. “Authority” in this case doesn't get much better than Matthew Ahrens, one of the cofounders of ZFS at Sun Microsystems and current ZFS developer at Delphix. In the comments to one of my filesystem articles on Ars Technica, Matthew said “There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem.” Beastie Bits EuroBSDcon 2017 Travel Grant Application Now Open (https://www.freebsdfoundation.org/blog/eurobsdcon-2017-travel-grant-application-now-open/) FreeBSD 11.1-BETA3 is out, please give it a test (https://lists.freebsd.org/pipermail/freebsd-stable/2017-June/087303.html) Allan and Lacey let us know the video to the Postgresql/ZFS talk is online (http://dpaste.com/1FE80FJ) Trapsleds (https://marc.info/?l=openbsd-tech&m=149792179514439&w=2) BSD User group in North Rhine-Westphalia, Germany (https://bsd.nrw/) *** Feedback/Questions Joe - Home Server Suggestions (http://dpaste.com/2Z5BJCR#wrap) Stephen - general BSD (http://dpaste.com/1VRQYAM#wrap) Eduardo - ZFS Encryption (http://dpaste.com/2TWADQ8#wrap) Joseph - BGP Kernel Error (http://dpaste.com/0SC0GAC#wrap) ***
This week on BSD Now, we review the EuroBSDcon schedule, we explore the mysteries of Docker on OpenBSD, and show you how to run PostgreSQL on ZFS. This episode was brought to you by Headlines EuroBSDcon 2017 - Talks & Schedule published (https://2017.eurobsdcon.org/2017/05/26/talks-schedule-published/) The EuroBSDcon website was updated with the tutorial and talk schedule for the upcoming September conference in Paris, France. Tutorials on the 1st day: Kirk McKusick - An Introduction to the FreeBSD Open-Source Operating System, George Neville-Neil - DTrace for Developers, Taylor R Campbell - How to untangle your threads from a giant lock in a multiprocessor system Tutorials on the 2nd day: Kirk continues his Introduction lecture, Michael Lucas - Core concepts of ZFS (half day), Benedict Reuschling - Managing BSD systems with Ansible (half day), Peter Hessler - BGP for developers and sysadmins Talks include 3 keynotes (2 on the first day, beginning and end), another one at the end of the second day by Brendan Gregg Good mixture of talks of the various BSD projects Also, a good amount of new names and faces Check out the full talk schedule (https://2017.eurobsdcon.org/talks-schedule/). Registration is not open yet, but will be soon. *** OpenBSD on the Xiaomi Mi Air 12.5" (https://jcs.org/2017/05/22/xiaomiair) The Xiaomi Mi Air 12.5" (https://xiaomi-mi.com/notebooks/xiaomi-mi-notebook-air-125-silver/) is a basic fanless 12.5" Ultrabook with good build quality and decent hardware specs, especially for the money: while it can usually be had for about $600, I got mine for $489 shipped to the US during a sale about a month ago. Xiaomi offers this laptop in silver and gold. They also make a 13" version but it comes with an NVidia graphics chip. Since these laptops are only sold in China, they come with a Chinese language version of Windows 10 and only one or two distributors that carry them ship to the US. Unfortunately that also means they come with practically no warranty or support. Hardware > The Mi Air 12.5" has a fanless, 6th generation (Skylake) Intel Core m3 processor, 4Gb of soldered-on RAM, and a 128Gb SATA SSD (more on that later). It has a small footprint of 11.5" wide, 8" deep, and 0.5" thick, and weighs 2.3 pounds. > A single USB-C port on the right-hand side is used to charge the laptop and provide USB connectivity. A USB-C ethernet adapter I tried worked fine in OpenBSD. Whether intentional or not, a particular design touch I appreciated was that the USB-C port is placed directly to the right of the power button on the keyboard, so you don't have to look or feel around for the port when plugging in the power cable. > A single USB 3 type-A port is also available on the right side next to the USB-C port. A full-size HDMI port and a headphone jack are on the left-hand side. It has a soldered-on Intel 8260 wireless adapter and Bluetooth. The webcam in the screen bezel attaches internally over USB. > The chassis is all aluminum and has sufficient rigidity in the keyboard area. The 12.5" 1920x1080 glossy IPS screen has a fairly small bezel and while its hinge is properly weighted to allow opening the lid with one hand (if you care about that kind of thing), the screen does have a bit of top-end wobble when open, especially when typing on another laptop on the same desk. > The keyboard has a roomy layout and a nice clicky tactile with good travel. It is backlit, but with only one backlight level. When enabled via Fn+F10 (which is handled by the EC, so no OpenBSD support required), it will automatically shut off after not typing for a short while, automatically turning back once a key is pressed. Upgrades > An interesting feature of the Mi Air is that it comes with a 128Gb SATA SSD but also includes an open PCI-e slot ready to accept an NVMe SSD. > I upgraded mine with a Samsung PM961 256Gb NVMe SSD (left), and while it is possible to run with both drives in at the same time, I removed the Samsung CM871a 128Gb SATA (right) drive to save power. > The bottom case can be removed by removing the seven visible screws, in addition to the one under the foot in the middle back of the case, which just pries off. A spudger tool is needed to release all of the plastic attachment clips along the entire edge of the bottom cover. > Unfortunately this upgrade proved to be quite time consuming due to the combination of the limited UEFI firmware on the Mi Air and a bug in OpenBSD. A Detour into UEFI Firmware Variables > Unlike a traditional BIOS where one can boot into a menu and configure the boot order as well as enabling and disabling options such as "USB Hard Drive", the InsydeH2O UEFI firmware on the Xiaomi Air only provides the ability to adjust the boot order of existing devices. Any change or addition of boot devices must be done from the operating system, which is not possible under OpenBSD. > I booted to a USB key with OpenBSD on it and manually partitioned the new NVME SSD, then rsynced all of the data over from the old drive, but the laptop would not boot to the new NVME drive, instead showing an error message that there was no bootable OS. > Eventually I figured out that the GPT table that OpenBSD created on the NVMe disk was wrong due to a [one-off bug in the nvme driver](https://github.com/openbsd/src/commit/dc8298f669ea2d7e18c8a8efea509eed200cb989) which was causing the GPT table to be one sector too large, causing the backup GPT table to be written in the wrong location (and other utilities under Linux to write it over the OpenBSD area). I'm guessing the UEFI firmware would fail to read the bad GPT table on the disk that the boot variable pointed to, then declare that disk as missing, and then remove any variables that pointed to that disk. OpenBSD Support > The Mi Air's soldered-on Intel 8260 wireless adapter is supported by OpenBSD's iwm driver, including 802.11n support. The Intel sound chip is recognized by the azalia driver. > The Synaptics touchpad is connected via I2C, but is not yet supported. I am actively hacking on my dwiic driver to make this work and the touchpad will hopefully operate as a Windows Precision Touchpad via imt so I don't have to write an entirely new Synaptics driver. > Unfortunately since OpenBSD's inteldrm support that is ported from Linux is lagging quite a bit behind, there is no kernel support for Skylake and Kaby Lake video chips. Xorg works at 1920x1080 through efifb so the machine is at least usable, but X is not very fast and there is a noticeable delay when doing certain redrawing operations in xterm. Screen backlight can be adjusted through my OpenBSD port of intel_backlight. Since there is no hardware graphics support, this also means that suspend and resume do not work because nothing is available to re-POST the video after resume. Having to use efifb also makes it impossible to adjust the screen gamma, so for me, I can't use redshift for comfortable night-time hacking. Flaws > Especially taking into account the cheap price of the laptop, it's hard to find faults with the design. One minor gripe is that the edges of the case along the bottom are quite sharp, so when carrying the closed laptop, it can feel uncomfortable in one's hands. > While all of those things could be overlooked, unfortunately there is also a critical flaw in the rollover support in the keyboard/EC on the laptop. When typing certain combinations of keys quickly, such as holding Shift and typing "NULL", one's fingers may actually hold down the Shift, N, and U keys at the same time for a very brief moment before releasing N. Normally the keyboard/EC would recognize U being pressed after N is already down and send an interrupt for the U key. Unfortunately on this laptop, particular combinations of three keys do not interrupt for the third key at all until the second key is lifted, usually causing the third key not to register at all if typed quickly. I've been able to reproduce this problem in OpenBSD, Linux, and Windows, with the combinations of at least Shift+N+U and Shift+D+F. Holding Shift and typing the two characters in sequence quickly enough will usually fail to register the final character. Trying the combinations without Shift, using Control or Alt instead of Shift, or other character pairs does not trigger the problem. This might be a problem in the firmware on the Embedded Controller, or a defect in the keyboard circuitry itself. As I mentioned at the beginning, getting technical support for this machine is difficult because it's only sold in China. Docker on OpenBSD 6.1-current (https://medium.com/@dave_voutila/docker-on-openbsd-6-1-current-c620513b8110) Dave Voutila writes: So here's the thing. I'm normally a macOS user…all my hardware was designed in Cupertino, built in China. But I'm restless and have been toying with trying to switch my daily machine over to a non-macOS system sort of just for fun. I find Linux messy, FreeBSD not as Apple-laptop-friendly as it should be, and Windows a non-starter. Luckily, I found a friend in Puffy. Switching some of my Apple machines over to dual-boot OpenBSD left a gaping hole in my workflow. Luckily, all the hard work the OpenBSD team has done over the last year seems to have plugged it nicely! OpenBSD's hypervisor support officially made it into the 6.1 release, but after some experimentation it was rather time consuming and too fragile to get a Linux guest up and running (i.e. basically the per-requisite for Docker). Others had reported some success starting with QEMU and doing lots of tinkering, but after a wasted evening I figured I'd grab the latest OpenBSD snapshot and try what the openbsd-misc list suggested was improved Linux support in active development. 10 (11) Steps to docker are provided Step 0 — Install the latest OpenBSD 6.1 snapshot (-current) Step 1 — Configure VMM/VMD Step 2 — Grab an Alpine Linux ISO Step 3 — Make a new virtual disk image Step 4 — Boot Alpine's ISO Step 5 — Inhale that fresh Alpine air Step 6 — Boot Alpine for Reals Step 7 — Install Docker Step 8 — Make a User Step 9 — Ditch the Serial Console Step 10 — Test out your Docker instance I haven't done it yet, but I plan on installing docker-compose via Python's pip package manager. I prefer defining containers in the compose files. PostgreSQL + ZFS Best Practices and Standard Procedures (https://people.freebsd.org/~seanc/postgresql/scale15x-2017-postgresql_zfs_best_practices.pdf) Slides from Sean Chittenden's talk about PostgreSQL and ZFS at Scale 15x this spring Slides start with a good overview of Postgres and ZFS, and how to use them together To start, it walks through the basics of how PostgreSQL interacts with the filesystem (any filesystem) Then it shows the steps to take a good backup of PostgreSQL, then how to do it even better with ZFS Then an intro to ZFS, and how Copy-on-Write changes host PostgreSQL interacts with the filesystem Overview of how ZFS works ZFS Tuning tips: Compression, Recordsize, atime, when to use mostly ARC vs sharedbuffer, plus pgrepack Followed by a discussion of the reliability of SSDs, and their Bit Error Rate (BER) A good SSD has a 4%/year chance of returning the wrong data. A cheap SSD 34% If you put 20 SSDs in a database server, that means 58% (Good SSDs) to 99.975% (Lowest quality commercially viable SSD) chance of an error per year Luckily, ZFS can detect and correct these errors This applies to all storage, not just SSDs, every device fails More Advice: Use quotas and reservations to avoid running out of space Schedule Periodic Scrubs One dataset per database Backups: Live demo of rm -rf'ing the database and getting it back Using clones to test upgrades on real data Naming Conventions: Use a short prefix not on the root filesystem (e.g. /db) Encode the PostgreSQL major version into the dataset name Give each PostgreSQL cluster its own dataset (e.g. pgdb01) Optional but recommended: one database per cluster Optional but recommended: one app per database Optional but recommended: encode environment into DB name Optional but recommended: encode environment into DB username using ZFS Replication Check out the full detailed PDF and implement a similar setup for your database needs *** News Roundup TrueOS Evolving Its "Stable" Release Cycle (https://www.trueos.org/blog/housekeeping-update-infrastructure-trueos-changes/) TrueOS is reformulating its Stable branch based on feedback from users. The goal is to have a “release” of the stable branch every 6 months, for those who do not want to live on the edge with the rapid updates of the full rolling release Most of the TrueOS developers work for iX Systems in their Tennessee office. Last month, the Tennessee office was moved to a different location across town. As part of the move, we need to move all our servers. We're still getting some of the infrastructure sorted before moving the servers, so please bear with us as we continue this process. As we've continued working on TrueOS, we've heard a significant portion of the community asking for a more stable “STABLE” release of TrueOS, maybe something akin to an old PC-BSD version release. In order to meet that need, we're redefining the TrueOS STABLE branch a bit. STABLE releases are now expected to follow a six month schedule, with more testing and lots of polish between releases. This gives users the option to step back a little from the “cutting edge” of development, but still enjoy many of the benefits of the “rolling release” style and the useful elements of FreeBSD Current. Critical updates like emergency patches and utility bug fixes are still expected to be pushed to STABLE on a case-by-case basis, but again with more testing and polish. This also applies to version updates of the Lumina and SysAdm projects. New, released work from those projects will be tested and added to STABLE outside the 6 month window as well. The UNSTABLE branch continues to be our experimental “cutting edge” track, and users who want to follow along with our development and help us or FreeBSD test new features are still encouraged to follow the UNSTABLE track by checking that setting in their TrueOS Update Manager. With boot environments, it will be easy to switch back and forth, so you can have the best of both worlds. Use the latest bleeding edge features, but knowing you can fall back to the stable branch with just a reboot As TrueOS evolves, it is becoming clearer that one role of the system is to function as a “test platform” for FreeBSD. In order to better serve this role, TrueOS will support both OpenRC and the FreeBSD RC init systems, giving users the choice to use either system. While the full functionality isn't quite ready for the next STABLE update, it is planned for addition after the last bit of work and testing is complete. Stay tuned for an upcoming blog post with all the details of this change, along with instructions how to switch between RC and OpenRC. This is the most important change for me. I used TrueOS as an easy way to run the latest version of -CURRENT on my laptop, to use it as a user, but also to do development. When TrueOS deviates from FreeBSD too much, it lessens the power of my expertise, and complicates development and debugging. Being able to switch back to RC, even if it takes another minute to boot, will bring TrueOS back to being FreeBSD + GUI and more by default, instead of a science project. We need both of those things, so having the option, while more work for the TrueOS team, I think will be better for the entire community *** Logical Domains on SunFire T2000 with OpenBSD/sparc64 (http://www.h-i-r.net/2017/05/logical-domains-on-sunfire-t2000-with.html) A couple of years ago, I picked up a Sun Fire T2000. This is a 2U rack mount server. Mine came with four 146GB SAS drives, a 32-core UltraSPARC T1 CPU and 32GB of RAM. Sun Microsystems incorporated Logical Domains (LDOMs) on this class of hardware. You don't often need 32 threads and 32GB of RAM in a single server. LDOMs are a kind of virtualization technology that's a bit closer to bare metal than vmm, Hyper-V, VirtualBox or even Xen. It works a bit like Xen, though. You can allocate processor, memory, storage and other resources to virtual servers on-board, with a blend of firmware that supports the hardware allocation, and some software in userland (on the so-called primary or control domain, similar to Xen DomU) to control it. LDOMs are similar to what IBM calls Logical Partitions (LPARs) on its Mainframe and POWER series computers. My day job from 2006-2010 involved working with both of these virtualization technologies, and I've kind of missed it. While upgrading OpenBSD to 6.1 on my T2000, I decided to delve into LDOM support under OpenBSD. This was pretty easy to do, but let's walk through it Resources: The ldomctl(8) man page (http://man.openbsd.org/OpenBSD-current/man8/sparc64/ldomctl.8) tedu@'s write-up on Flak (for a different class of server) (http://www.tedunangst.com/flak/post/OpenBSD-on-a-Sun-T5120) A Google+ post by bmercer@ (https://plus.google.com/101694200911870273983/posts/jWh4rMKVq97) Once you get comfortable with the fact that there's a little-tiny computer (the ALOM) powered by VXWorks inside that's acting as the management system and console (there's no screen or keyboard/mouse input), Installing OpenBSD on the base server is pretty straightforward. The serial console is an RJ-45 jack, and, yes, the ubiquitous blue-colored serial console cables you find for certain kinds of popular routers will work fine. OpenBSD installs quite easily, with the same installer you find on amd64 and i386. I chose to install to /dev/sd0, the first SAS drive only, leaving the others unused. It's possible to set them up in a hardware RAID configuration using tools available only under Solaris, or use softraid(4) on OpenBSD, but I didn't do this. I set up the primary LDOM to use the first ethernet port, em0. I decided I wanted to bridge the logical domains to the second ethernet port. You could also use a bridge and vether interface, with pf and dhcpd to create a NAT environment, similar to how I networked the vmm(4) systems. Create an LDOM configuration file. You can put this anywhere that's convenient. All of this stuff was in a "vm" subdirectory of my home. I called it ldom.conf: domain primary { vcpu 8 memory 8G } domain puffy { vcpu 8 memory 4G vdisk "/home/axon/vm/ldom1" vnet } Make as many disk images as you want, and make as many additional domain clauses as you wish. Be mindful of system resources. I couldn't actually allocate a full 32GB of RAM across all the LDOMs I eventually provisioned seven LDOMs (in addition to the primary) on the T2000, each with 3GB of RAM and 4 vcpu cores. If you get creative with use of network interfaces, virtual ethernet, bridges and pf rules, you can run a pretty complex environment on a single chassis, with services that are only exposed to other VMs, a DMZ segment, and the internal LAN. A nice tutorial, and an interesting look at an alternative platform that was ahead of its time *** documentation is thoroughly hard (http://www.tedunangst.com/flak/post/documentation-is-thoroughly-hard) Ted Unangst has a new post this week about documentation: Documentation is good, so therefore more documentation must be better, right? A few examples where things may have gotten out of control A fine example is the old OpenBSD install instructions. Once you've installed OpenBSD once or twice, the process is quite simple, but you'd never know this based on reading the instructions. Compare the files for 4.8 INSTALL and 5.8 INSTALL. Both begin with a brief intro to the project. Then 4.8 has an enormous list of mirrors, which seems fairly redundant if you've already found the install file. Followed by an enormous list of every supported variant of every supported device. Including a table of IO port configurations for ISA devices. Finally, after 1600 lines of introduction we get to the actual installation instructions. (Compared to line 231 for 5.8.) This includes a full page of text about how to install from tape, which nobody ever does. It took some time to recognize that all this documentation was actually an impediment to new users. Attempting to answer every possible question floods the reader with information for questions they were never planning to ask. Part of the problem is how the information is organized. Theoretically it makes sense to list supported hardware before instructions. After all, you can't install anything if it's not supported, right? I'm sure that was considered when the device list was originally inserted above the install instructions. But as a practical matter, consulting a device list is neither the easiest nor fastest way to determine what actually works. In the FreeBSD docs tree, we have been doing a facelift project, trying to add ‘quick start' sections to each chapter to let you get to the more important information first. It is also helpful to move data in the forms of lists and tables to appendices or similar, where they can easily be references, but are not blocking your way to the information you are actually hunting for An example of nerdview signage (http://languagelog.ldc.upenn.edu/nll/?p=29866). “They have in effect provided a sign that will tell you exactly what the question is provided you can already supply the answer.” That is, the logical minds of technical people often decide to order information in an order that makes sense to them, rather than in the order that will be most useful to the reader In the end, I think “copy diskimage to USB and follow prompts” is all the instructions one should need, but it's hard to overcome the unease of actually making the jump. What if somebody is confused or uncertain? Why is this paragraph more redundant than that paragraph? (And if we delete both, are we cutting too much?) Sometimes we don't need to delete the information. Just hide it. The instructions to upgrade to 4.8 and upgrade to 5.8 are very similar, with a few differences because every release is a little bit different. The pages look very different, however, because the not at all recommended kernel free procedure, which takes up half the page, has been hidden from view behind some javascript and only expanded on demand. A casual browser will find the page and figure the upgrade process will be easy, as opposed to some long ordeal. This is important as well, it was my original motivation for working on the FreeBSD Handbook's ZFS chapter. The very first section of the chapter was the custom kernel configuration required to run ZFS on i386. That scared many users away. I moved that to the very end, and started with why you might want to use ZFS. Much more approachable. Sometimes it's just a tiny detail that's overspecified. The apmd manual used to explain exactly which CPU idle time thresholds were used to adjust frequency. Those parameters, and the algorithm itself, were adjusted occasionally in response to user feedback, but sometimes the man page lagged behind. The numbers are of no use to a user. They're not adjustable without recompiling. Knowing that the frequency would be reduced at 85% idle vs 90% idle doesn't really offer much guidance as to whether to enable auto scaling or not. Deleting this detail ensured the man page was always correct and spares the user the cognitive load of trying to solve an unnecessary math problem. For fun: For another humorous example, it was recently observed that the deja-dup package provides man page translations for Australia, Canada, and Great Britain. I checked, the pages are in fact not quite identical. Some contain typo fixes that didn't propagate to other translations. Project idea: attempt to identify which country has the most users, or most fastidious users, by bug fixes to localized man pages. lldb on BeagleBone Black (https://lists.freebsd.org/pipermail/freebsd-arm/2017-May/016260.html) I reliably managed to build (lldb + clang/lld) from the svn trunk of LLVM 5.0.0 on my Beaglebone Black running the latest snapshot (May 20th) of FreeBSD 12.0-CURRENT, and the lldb is working very well, and this includes single stepping and ncurses-GUI mode, while single stepping with the latest lldb 4.0.1 from the ports does not work. In order to reliably build LLVM 5.0.0 (svn), I set up a 1 GB swap partition for the BBB on a NFSv4 share on a FreeBSD fileserver in my network - I put a howto of the procedure on my BLog: https://obsigna.net/?p=659 The prerequesites on the Beaglebone are: ``` pkg install tmux pkg install cmake pkg install python pkg install libxml2 pkg install swig30 pkg install ninja pkg install subversion ``` On the FreeBSD fileserver: ``` /pathtothe/bbb_share svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm cd llvm/tools svn co http://llvm.org/svn/llvm-project/cfe/trunk clang svn co http://llvm.org/svn/llvm-project/lld/trunk lld svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb ``` + On the Beaglebone Black: # mount_nfs -o noatime,readahead=4,intr,soft,nfsv4 server:/path_to_the/bbb_share /mnt # cd /mnt # mkdir build # cmake -DLLVM_TARGETS_TO_BUILD="ARM" -DCMAKE_BUILD_TYPE="MinSizeRel" -DLLVM_PARALLEL_COMPILE_JOBS="1" -DLLVM_PARALLEL_LINK_JOBS="1" -G Ninja .. I execute the actual build command from within a tmux session, so I may disconnect during the quite long (40 h) build: ``` tmux new "ninja lldb install" ``` When debugging in GUI mode using the newly build lldb 5.0.0-svn, I see only a minor issue, namely UTF8 strings are not displayed correctly. This happens in the ncurses-GUI only, and this is an ARM issue, since it does not occur on x86 machines. Perhaps this might be related to the signed/unsigned char mismatch between ARM and x86. Beastie Bits Triangle BSD Meetup on June 27th (https://www.meetup.com/Triangle-BSD-Users-Group/events/240247251/) Support for Controller Area Networks (CAN) in NetBSD (http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20170521_0113.html) Notes from Monday's meeting (http://mailman.uk.freebsd.org/pipermail/ukfreebsd/2017-May/014104.html) RunBSD - A site about the BSD family of operating systems (http://runbsd.info/) BSDCam(bridge) 2017 Travel Grant Application Now Open (https://www.freebsdfoundation.org/blog/bsdcam-2017-travel-grant-application-now-open/) New BSDMag has been released (https://bsdmag.org/download/nearly-online-zpool-switching-two-freebsd-machines/) *** Feedback/Questions Philipp - A show about byhve (http://dpaste.com/390F9JN#wrap) Jake - byhve Support on AMD (http://dpaste.com/0DYG5BD#wrap) CY - Pledge and Capsicum (http://dpaste.com/1YVBT12#wrap) CY - OpenSSL relicense Issue (http://dpaste.com/3RSYV23#wrap) Andy - Laptops (http://dpaste.com/0MM09EX#wrap) ***
This week on BSDNow, we're going to be leading off with the latest news about Wayland and Xorg support on FreeBSD, then a look at OpenBSD ARM64 This episode was brought to you by Headlines Wayland is now in the FreeBSD Ports tree (https://svnweb.freebsd.org/ports?view=revision&revision=432406) This commit brings Wayland, the new windowing system, into the FreeBSD ports tree “This port was first created by Koop Mast (kwm@) then updated and improved by Johannes Lundberg” “Wayland is intended as a simpler replacement for X, easier to develop and maintain. GNOME and KDE are expected to be ported to it.” Wayland is designed for desktop and laptop use, rather than X, which was designed for use over the network, where clients were not powerful enough to run the applications locally. “Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.” “Please report bugs to the FreeBSD bugtracker!” It is good to see this project progressing, as it seems in a few generations, high performance graphics drivers may only be actively developed for Wayland. *** Call For Testing: xorg 1.18.4 and newer intel/ati DDX (https://lists.freebsd.org/pipermail/freebsd-x11/2017-January/018738.html) Baptiste Daroussin, and the FreeBSD X11 team, have issued a call for testing for the upgrade to Xorg 1.18.4 Along with it comes newer ATI/AMD and Intel drivers “Note that you will need to rebuild all the xf86-* packages to work with thatnewer xorg (hence the bump of the revision)” “Do not expect newer gpu supported as this is not the kernel part”, it only provides the newer Xorg driver, not the kernel mode setting driver (this is a separate project) “If you experience any issue with intel or radeon driver please try to use the new modesetting driver provided by xorg directly (note that fedora and debian recommend the use of the new driver instead of the ati/intel one)” *** Error handling in C (http://www.tedunangst.com/flak/post/to-errno-or-to-error) “Unlike other languages which have one preferred means of signalling an error, C is a multi error paradigm language. Error handling styles in C can be organized into one of several distinct styles, such as popular or correct. Some examples of each.” “One very popular option is the classic unix style. -1 is returned to indicate an error.” “Another option seen in the standard C library is NULL for errors.” “The latter has the advantage that NULL is a false value, which makes it easier to write logical conditions. File descriptor 0 is valid (stdin) but false, while -1 is invalid but true.” “And of course, there's the worst of both worlds approach requiring a special sentinel that you'll probably forget to use” “Other unix functions, those that don't need to return a file descriptor, stick to just 0 and -1” “Of course, none of these functions reveal anything about the nature of the error. For that, you need to consult the errno on the side” The article goes on to describe different ways of dealing with the issue, and return values. There is also coverage of more complex examples and involve a context that might contain the error message It is really interesting to see the differences, and the pitfalls of each approach *** Fixing POSIX Filenames (http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html) “Traditionally, Unix/Linux/POSIX pathnames and filenames can be almost any sequence of bytes. A pathname lets you select a particular file, and may include zero or more “/” characters. Each pathname component (separated by “/”) is a filename; filenames cannot contain “/”. Neither filenames nor pathnames can contain the ASCII NUL character (), because that is the terminator.” “This lack of limitations is flexible, but it also creates a legion of unnecessary problems. In particular, this lack of limitations makes it unnecessarily difficult to write correct programs (enabling many security flaws). It also makes it impossible to consistently and accurately display filenames, causes portability problems, and confuses users.” “This article will try to convince you that adding some tiny limitations on legal Unix/Linux/POSIX filenames would be an improvement. Many programs already presume these limitations, the POSIX standard already permits such limitations, and many Unix/Linux filesystems already embed such limitations — so it'd be better to make these (reasonable) assumptions true in the first place. This article will discuss, in particular, the three biggest problems: control characters in filenames (including newline, tab, and escape), leading dashes in filenames, and the lack of a standard character encoding scheme (instead of using UTF-8). These three problems impact programs written in any language on Unix/Linux/POSIX system. There are other problems, of course. Spaces in filenames can cause problems; it's probably hopeless to ban them outright, but resolving some of the other issues will simplify handling spaces in filenames. For example, when using a Bourne shell, you can use an IFS trick (using IFS=printf 'nt') to eliminate some problems with spaces. Similarly, special metacharacters in filenames cause some problems; I suspect few if any metacharacters could be forbidden on all POSIX systems, but it'd be great if administrators could locally configure systems so that they could prevent or escape such filenames when they want to. I then discuss some other tricks that can help.” “After limiting filenames slightly, creating completely-correct programs is much easier, and some vulnerabilities in existing programs disappear. This article then notes some others' opinions; I knew that some people wouldn't agree with me, but I'm heartened that many do agree that something should be done. Finally, I briefly discuss some methods for solving this long-term; these include forbidding creation of such names (hiding them if they already exist on the underlying filesystem), implementing escaping mechanisms, or changing how tools work so that these are no longer problems (e.g., when globbing/scanning, have the libraries prefix “./” to any filename beginning with “-”). Solving this is not easy, and I suspect that several solutions will be needed. In fact, this paper became long over time because I kept finding new problems that needed explaining (new “worms under the rocks”). If I've convinced you that this needs improving, I'd like your help in figuring out how to best do it!” “Filename problems affect programs written in any programming language. However, they can be especially tricky to deal with when using Bourne shells (including bash and dash). If you just want to write shell programs that can handle filenames correctly, you should see the short companion article Filenames and Pathnames in Shell: How to do it correctly (http://www.dwheeler.com/essays/filenames-in-shell.html).” Imagine that you don't know Unix/Linux/POSIX (I presume you really do), and that you're trying to do some simple tasks. For our purposes we will create simple scripts on the command line (using a Bourne shell) for these tasks, though many of the underlying problems affect any program. For example, let's try to print out the contents of all files in the current directory, putting the contents into a file in the parent directory: cat * > ../collection # WRONG cat ./* > ../collection # CORRECT cat find . -type f > ../collection # WRONG ( set -f ; for file in find . -type f ; do # WRONG cat "$file" done ) > ../collection ( find . -type f | xargs cat ) > ../collection # WRONG, WAY WRONG Just think about trying to remove a file named: -rf / *** News Roundup OpenBSD ARM64 (https://www.openbsd.org/arm64.html) A new page has appeared on the OpenBSD website, offering images for ARM64 “The current target platforms are the Pine64 and the Raspberry Pi 3.” “OpenBSD/arm64 bundles various platforms sharing the 64-bit ARM architecture. Due to the fact that there are many System on a Chips (SoC) around, OpenBSD/arm64 differentiates between various SoCs and may have a different level of support between them” The page contains a list of the devices that are supported, and which components have working drivers At the time of recording, the link to download the snapshots did not work yet, but by time this airs a week from now, it should be working. *** The design of Chacha20 (http://loup-vaillant.fr/tutorials/chacha20-design) Seems like every few episodes we end up discussing Ciphers (With their o-so amusing naming) and today is no exception. We have a great writeup on the D & I of the ‘chacha20' cipher written by “Loup Vaillant” First of all, is this story for you? Maybe the summary will help make that call: “Quick summary: Chacha20 is ARX-based hash function, keyed, running in counter mode. It embodies the idea that one can use a hash function to encrypt data.” If your eyes didn't glaze over, then you are cleared to proceed. Chacha20 is built around stream ciphers: While Chacha20 is mainly used for encryption, its core is a pseudo-random number generator. The cipher text is obtained by XOR'ing the plain text with a pseudo-random stream: ciphertext = plaintext XOR chacha_stream(key, nonce) Provided you never use the same nonce with the same key twice, you can treat that stream as a one time pad. This makes it very simple: unlike block ciphers, you don't have to worry about padding, and decryption is the same operation as encryption: plaintext = ciphertext XOR chacha_stream(key, nonce) Now we just have to get that stream. The idea that the streams can mimic the concept of a one-time pad does make chacha20 very attractive, even to a non-crypto guy such as myself. From here the article goes into depth on how the cipher scrambles 512bit blocks using the quarter-round method (A forth of a block or 4 32bit numbers) Some ascii art is used here to help visualize how this done, in the quarter round-phase, then to the complete block as the 4 quarters are run in parallel over the entire 512 bit block. From here the article goes more into depth, looking at the complete chacha block, and the importance of a seemingly unnecessary 32byte constant (Hint: it's really important) If crypto is something you find fascinating, you'll want to make sure you give this one a full read-through. *** CyberChef - Coming to a FreeBSD Ports tree near you (https://twitter.com/DLangille/status/823915729430913025) Dan Langille tweets that he will be creating a port of GCHQ's CyberChef tool “CyberChef is a simple, intuitive web app for carrying out all manner of "cyber" operations within a web browser. These operations include creating hexdumps, simple encoding like XOR or Base64, more complex encryption like AES, DES and Blowfish, data compression and decompression, calculating hashes and checksums, IPv6 and X.509 parsing, and much more.” “The tool is designed to enable both technical and non-technical analysts to manipulate data in complex ways without having to deal with complex tools or algorithms. It was conceived, designed, built and incrementally improved by an analyst in their 10% innovation time over several years. Every effort has been made to structure the code in a readable and extendable format, however it should be noted that the analyst is not a professional developer and the code has not been peer-reviewed for compliance with a formal specification.” Some handy functions, beyond stuff like base64 encoding: Network Enumeration (CIDR to list of IPS) (https://gchq.github.io/CyberChef/?recipe=%5B%7B%22op%22%3A%22Parse%20IP%20range%22%2C%22args%22%3A%5Btrue%2Ctrue%2Cfalse%5D%7D%5D&input=MTcyLjIxLjAuMzIvMjcK) Browser User Agent Parser (what browser is that, based on your HTTP logs) XOR Brute Force: enter some XOR'd text, and try every possible key to find plaintext. Optionally give it a regex of known plaintext to find the right key. Calculate the “Shannon Entropy” of the input (how random is this data) It also has a number of built in regular expressions for common things, very useful The project is up on github if you want to play with the code *** Building Electron and VSCode in FreeBSD11 (https://gist.github.com/prash-wghats/89be1ee069d2acf23c289e9c606616e1) A patch and set of instructions for building Electron and VSCode on FreeBSD “Visual Studio Code is a source code editor developed by Microsoft for Windows, Linux and macOS. It includes support for debugging, embedded Git control, syntax highlighting, intelligent code completion, snippets, and code refactoring. It is also customizable, so users can change the editor's theme, keyboard shortcuts, and preferences. It is free and open-source, although the official download is under a proprietary license.” “Visual Studio Code is based on Electron, a framework which is used to deploy Node.js applications for the desktop running on the Blink layout engine. Although it uses the Electron framework, the software is not a fork of Atom, it is actually based on Visual Studio Online's editor (codename "Monaco")” It would be interesting to see official support for VSCode on FreeBSD Has anyone tried VSCode on the FreeBSD Code base? *** Beastie Bits Soft Label Keys (http://roy.marples.name/blog/blog/soft-label-keys) WPA1 (TKIP) disabled by default (OpenBSD) (https://www.mail-archive.com/source-changes@openbsd.org/msg84599.html) Cool but obscure unix tools (https://kkovacs.eu/cool-but-obscure-unix-tools) KDE Frameworks and Plasma on FreeBSD (http://euroquis.nl/bobulate/?p=1521) Initiative to migrate OpenBSD mirrors to HTTPS (https://www.mail-archive.com/source-changes@openbsd.org/msg84904.html) That moment you realize FreeBSD has got some Star Wars fans (http://i.imgur.com/dC7c1y4.png) Pagelink (https://wiki.freebsd.org/PortsSubversionPrimer)
This week on BSDNow, we're going to be hearing about Allan's trip to EuroBSDCon, plus an Interview about “Bro on BSD”! Stay tuned, for your place to This episode was brought to you by Headlines EuroBSDCon 2016 Wrapup Ollivier Robert's Photos from EuroBSDCon (https://assets.keltia.net/photos/EuroBSDCon-2016/) Get your BSDNow die-cut stickers (http://www.jupiterbroadcasting.com/stickers/) NetBSD for newbies - Develop your own Power PC (http://discusscomputerx.blogspot.com/2016/09/netbsd-for-noobies-your-power-laptop.html) We don't get to feature too many stories on NetBSD being deployed as a Power PC (Not PowerPC, you know, a Powerful “PC”), so we jumped at this one. Specifically it starts off with some of the pre-req's that you'll need to get started, such as NetBSD 7.0.1 / amd64, along with some information about which wireless nics you may be using. (NetBSD like other BSD's will give a driver based device name for network interfaces) From there, instructions on how to write your WPA_supplicant config are provided, in order for us to fetch the NetBSD sources and convert to their -STABLE branch. After doing a CVS checkout of the sources, he then provides a walkthrough of doing a kernel compile / install, however it mentions changing the config, but doesn't provide an example of what options were changed. Perhaps to remove drivers we don't need? At this point the rest of the “desktop” setup is pretty straight forward. Some packages are added such as openbox, lxappearance, firefox, etc. To get working sound, firefox requires pulseaudio, which in turn needs dbus, so instructions on getting that service up and running are provided as well. When it's all said and done, you'll end up with your shiny new NetBSD -STABLE desktop (or laptop), bragging rights achieved! *** More about OpenSMTPD 6.0.0 (https://www.poolp.org/tech/posts/2016/09/12/opensmtpd-6-0-0-released/) OpenSMTPd 6.0.0 has just been released “and it's quite different from former releases.” “Unlike most of our releases, it comes out with almost no new feature.”, “Turns out most of the changes are not visible.” Changelog: new fork+reexec model so each process has its own randomized memory space logging format has been reworked a "multi-line response" bug in the LMTP delivery backend has been fixed connections concurrency limits have been bumped artificial delaying in remote sessions have been reduced dhparams option has been removed dhe option has been added, supporting auto and legacy modes smtp engine has been simplified various cosmetic changes, code cleanup and documentation improvement “The OpenSMTPD bootstrap process was quite simple: Upon executation, the parent process would read configuration, build a memory representation of it and would then create a bunch of socketpair() before fork()-ing all of its child processes.” The problem is that this does not take advantage of the new address randomization feature. Each child will have the same memory layout, copied from the parent process “So deraadt@ suggested that if OpenSMTPD would not just fork() children but instead fork() them and reexecute the smtpd binary, then each of the children would have its own randomized memory space.” “The idea itself is neat, however not so trivial to implement because when we reexec the whole "inherit configuration and descriptors" part goes away. It's not just fork and exec, it's fork and exec and figure a way for the parent to pass back all the information and descriptors back to the new post-fork instance so it is the new instance that allocates memory and decides where the information goes.” *** Upgrade a FreeBSD 10.3 Installation with ZFS on Root and Full Disk Encryption to 11.0 (http://ftfl.ca/blog/2016-09-17-zfs-fde-one-pool-conversion.html) While FreeBSD 11.0 is not out yet, Joseph Mingrone has helped me work out and test the instructions for upgrading a FreeBSD 10.3 ZFS on full disk encryption setup (bootpool + zpool) to the new GELIBoot feature, which does not require any unencrypted partitions, just the 128kb bootcode Note: Do not upgrade to FreeBSD 11.0 yet. While some images have landed on the FTP server, they do not contain the final openssl fix and are going to be recreated. Currently, GELIBoot does not support key files, so the first step is to reencrypt the master key with only a passphrase. Next, to avoid GELIBoot picking up encrypted partitions that it does not support, or partitions you do not want decrypted at boot, only partitions with the GELIBoot flag are decrypted, so set the flag on your root partition Then, move the loader, kernel, and other files into /boot on the root filesystem, instead of them living on the bootpool. This allows the kernel to be versioned with boot environments, and is the main purpose of this work Then, install the newer gptzfsboot, as this is required to support GELIBoot The old 2gb bootpool partition is then purposely mislabeled as freebsd-vinum, so it is not picked up by the boot blocks. Later, if the upgrade is successful, this partition can be deleted, and used as addition swap or something In order to boot correctly, you want all boot environments to have the ‘canmount' ZFS property set to ‘noauto' Thank you to Joseph for taking the time to prod me for the information required to write this up, and for testing it and finding all of the issues *** Interview - Michael Shirk - mshirk@daemon-security.com (mailto:mshirk@daemon-security.com) / @shirkdog (https://twitter.com/shirkdog) Running Bro on BSD *** News Roundup FreeBSD based distro for virtual hosting platform and appliance (https://clonos.tekroutine.com/) An interesting new FreeBSD-based project as shown up online, called “ClonOS”, which bills itself as a “free open-source FreeBSD-based platform for virtual environments creation and management” It looks to be leveraging an impressive list of technologies, including Bhyve, Xen, Jails and CBSD / Puppet for management tasks. Among its list of features: ZFS features support; VM cloning, export, import Ethernet SoftSwitch for separated networking jails for lightweight container VNC terminal for VM/containers Templates for VM/containers Configuration management/helpers Multi-node operation Multi-Node? Color me intrigued! Right now it appears to be under heavy development, but we'll reach out to the developer to see if we can get an interview lined up at some point! The Raspberry PI Platform and The Challenges of Developing FreeBSD (https://bsdmag.org/oleksandr_rybalko/) BSDMag recently did an interview with FreeBSD developer Olesandr Rybalko! Oleksandr lives in the Ukraine, and while you may not have heard of him, he has worked on some cool projects for FreeBSD including the new “vt” console driver (Which a lot of people are using now), and ARM/MIPS support. The interview covers some of the work he's done to get the PI support working with FreeBSD: I think, my main help here was a USB OTG driver, which I wrote before for another device (Ralink RT3052), then port it to R-Pi. But it was rewritten by Hans Peter Selasky. I do not know so much about USB as Hans knows. Another useful part of my help is Xorg support. I did a simple Xorg video driver which uses framebuffer exported by virtual terminal subsystem. That is help to many guys to start use RPi as a simple desktop system. He was also asked the question “Why would FreeBSD be good fit for ARM?” FreeBSD is very powerful as a network server. All modern network features in one box, with very fast processing. Another good side of FreeBSD is modularity. It is not required to write code to use some driver that was already written for another system, you can just define it in configuration files (kernel config, kernel hints, FDT). So if you want build a nice, R-Pi based, home server – use FreeBSD. If you want to play with devices attached to R-Pi's GPIO – use FreeBSD. He also discusses his work on the ZRouter project, which is a very light-weight platform for tiny routers / embedded devices. But lastly the RPI comes up again, specifically asking him how interested individuals can get involved. Specifically the wiki.freebsd.org is a great reference point for those intested in getting started with FreeBSD on embedded. The warm community is also a plus! Trying out the FreeBSD powered TrueOS (http://www.phoronix.com/scan.php?page=news_item&px=TrueOS-First-Spin) The folks over at Phoronix have done an early look at the new TrueOS desktop images and given some of their thoughts. First up he gives props to the installer, noting that: The TrueOS desktop installer is basically the same as from the PC-BSD days, just re-branded. Still one of the easiest BSD graphical installers I've dealt with and makes it a breeze for setting up a FreeBSD-on-ZFS system by default. After that they took it for a minimal spin, and thing mostly seem to be working. He mentions some of the default apps (Such as qupzilla and trojita) aren't their favorite, but Lumina has come quite a ways for 1.0, despite a few rough edges still. (We are in the process of changing those default e-mail / browser apps) Lastly the article mentions that it's time to do a more full BSD round-up to see the state of installation of them, which we happen to have next! Trying out 8 BSDs on a modern PC (http://www.phoronix.com/scan.php?page=article&item=trying-8-bsds&num=1) First up was TrueOS again, which no major changes there, easy install and done. From there he tries out DragonFlyBSD, which he mentions that while the installer isn't as easy, it is still one of his favorite BSD's, working with all the hardware they've thrown at it. Next up was GhostBSD, which also has an Easy-To-Use graphical installer similar to TrueOS that made it quick to get loaded and up to the Mate desktop. Also tested was FreeBSD 11.0-RC2, which he mentions was easy to installed, and once done then ‘pkg' could be used to easily get the setup he wanted setup. Turning over to page two we get to the naughty list of BSD's he had troubles with. First up was OpenBSD which he tried 6.0. After installation and first boot, the display kept ‘disappearing' which meant he couldn't get IP information to try SSH'ing into the box. Perhaps a display driver error? NetBSD 7 was up next, where the installer couldn't get past a root device prompt. Most likely trouble finding the install media, which was the same story with MightnightBSD as well. Also tested was “PacBSD” (Formerly ArchBSD) which he did manage to get installed, but not after major fighting with the process. After the process he ran into some issues getting packages up and running, but mentions it may have been bad timing due to them moving to a new server at the time. *** IllumOS imports a modified FreeBSD boot loader to replace grub 0.97 (https://www.listbox.com/member/archive/182181/2016/09/sort/time_rev/page/1/entry/0:1/20160923124232:B7978ED4-81AC-11E6-A6DA-02E3F010038B/) Toomas Soome's work to port the FreeBSD boot loader to IllumOS has been merged into illumos-gate, the upstream repository for all IllumOS distributions Toomas' work has also resulted in a number of commits to FreeBSD, and code sharing in both directions Toomas helped me a lot with the building of the ZFS boot environment listing menu, even though on IllumOS they use a configuration file to list the BEs, rather than interrogating the live zpool like we do in FreeBSD Toomas' work to improve msdosfs and the block cache to speed up booting IllumOS also greatly helped FreeBSD This work means IllumOS can now boot from a RAID-Z (the old grub they used could not), and if the work Toomas has done on FreeBSD is any indication, support for almost all other zpool features is also on the way This work also sets IllumOS on a path to eventually having UEFI boot as well It is good to see this work happening, FreeBSD technology being reused elsewhere, but also the improvements being made for IllumOS are coming back to FreeBSD, often landing upstream first, to make merging them into IllumOS easier. The mailing list post describes how to convert existing systems away from grub, as well as how to opt to remain on grub for a while longer. Grub 0.97 is expected to be removed from IllumOS within a year. *** Beastie Bits A demo of booting CentOS and Windows 10 in FreeBSD Bhyve through VNC headless (https://www.youtube.com/watch?v=8YQQfXqtyaA) This year's anemic output (http://blather.michaelwlucas.com/archives/2762) “PAM Mastery” ebook now out (http://blather.michaelwlucas.com/archives/2771) How-to Install OpenBSD 6.0 plus XFCE desktop and basic applications (https://www.youtube.com/watch?v=oC5D9fenQBs) *** Feedback/Questions Piotr - LibreBoot (http://pastebin.com/yniniNpV) Alan - FreeBSD and PC-BSD (http://pastebin.com/dCNX0yF7) Eduardo - Newcomers (http://pastebin.com/LndNeAYb) Greg - ZFS ACL's (http://pastebin.com/F0y6L6NK) Brian - Laptop Recs (http://pastebin.com/sqMPJGMM) ***
This week on BSDNow! We've got Netflix + FreeBSD news to discuss, always a crowd pleaser, that plus EuroBSDCon is just around the corner. Stick around for your place This episode was brought to you by Headlines Protecting Netflix Viewing Privacy at Scale, with FreeBSD (http://techblog.netflix.com/search/label/FreeBSD) This blog post from Netflix tells the story of how Netflix developed in-kernel TLS to speed up delivery of video via HTTPS Since the beginning of the Open Connect program we have significantly increased the efficiency of our OCAs - from delivering 8 Gbps of throughput from a single server in 2012 to over 90 Gbps from a single server in 2016. We contribute to this effort on the software side by optimizing every aspect of the software for our unique use case - in particular, focusing on the open source FreeBSD operating system and the NGINX web server that run on the OCAs. In the modern internet world, we have to focus not only on efficiency, but also security. There are many state-of-the-art security mechanisms in place at Netflix, including Transport Level Security (TLS) encryption of customer information, search queries, and other confidential data. We have always relied on pre-encoded Digital Rights Management (DRM) to secure our video streams. Over the past year, we've begun to use Secure HTTP (HTTP over TLS or HTTPS) to encrypt the transport of the video content as well. This helps protect member privacy, particularly when the network is insecure - ensuring that our members are safe from eavesdropping by anyone who might want to record their viewing habits. The goal is to ensure that your government, ISP, and wifi sniffing neighbour cannot tell which Netflix videos you are watching Netflix Open Connect serves over 125 million hours of content per day, all around the world. Given our scale, adding the overhead of TLS encryption calculations to our video stream transport had the potential to greatly reduce the efficiency of our global infrastructure. We evaluated available and applicable ciphers and decided to primarily use the Advanced Encryption Standard (AES) cipher in Galois/Counter Mode (GCM), available starting in TLS 1.2. We chose AES-GCM over the Cipher Block Chaining (CBC) method, which comes at a higher computational cost. The AES-GCM cipher algorithm encrypts and authenticates the message simultaneously - as opposed to AES-CBC, which requires an additional pass over the data to generate keyed-hash message authentication code (HMAC). CBC can still be used as a fallback for clients that cannot support the preferred method. All revisions of Open Connect Appliances also have Intel CPUs that support AES-NI, the extension to the x86 instruction set designed to improve encryption and decryption performance. We needed to determine the best implementation of AES-GCM with the AES-NI instruction set, so we investigated alternatives to OpenSSL, including BoringSSL and the Intel Intelligent Storage Acceleration Library (ISA-L). Netflix and NGINX had previously worked together to improve our HTTP client request and response time via the use of sendfile calls to perform a zero-copy data flow from storage (HDD or SSD) to network socket, keeping the data in the kernel memory address space and relieving some of the CPU burden. The Netflix team specifically added the ability to make the sendfile calls asynchronous - further reducing the data path and enabling more simultaneous connections. However, TLS functionality, which requires the data to be passed to the application layer, was incompatible with the sendfile approach. To retain the benefits of the sendfile model while adding TLS functionality, we designed a hybrid TLS scheme whereby session management stays in the application space, but the bulk encryption is inserted into the sendfile data pipeline in the kernel. This extends sendfile to support encrypting data for TLS/SSL connections. We tested the BoringSSL and ISA-L AES-GCM implementations with our sendfile improvements against a baseline of OpenSSL (with no sendfile changes), under typical Netflix traffic conditions on three different OCA hardware types. Our changes in both the BoringSSL and ISA-L test situations significantly increased both CPU utilization and bandwidth over baseline - increasing performance by up to 30%, depending on the OCA hardware version. We chose the ISA-L cipher implementation, which had slightly better results. With these improvements in place, we can continue the process of adding TLS to our video streams for clients that support it, without suffering prohibitive performance hits. If you would like more detail, check out the papers from AsiaBSDCon 2015 (https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf) and the updated one from 2016 (https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf) *** OpenBSD on HP Stream 7 (http://www.tedunangst.com/flak/post/OpenBSD-on-HP-Stream-7) Recent events have rocked the mobile computing world to its core. OpenBSD retired the zaurus port, leaving users in desperate need of a new device. And not long before that, Microsoft released the Anniversary Update to Windows 10, but with free space requirements such that it's nigh impossible to install on cheap 32GB eMMC equipped devices such as the HP Stream series, leaving users searching for a new lightweight operating system. With necessity as both mother and father, the scene is set for a truly epic pairing. OpenBSD on the HP Stream 7. The HP Stream line is a series of budget computers in a couple form factors. The Stream 11 is a fairly typical netbook. However, the Stream 7 and 8 are tablets. They look like cheap Android devices, but inside the case, they're real boys, er PCs, with Intel Atom CPUs. To install OpenBSD on such a device, we need a few parts. Obviously, the tablet itself. There's a dearth of ports on these things, but there is a micro USB port. Attaching anything useful requires an OTG “on the go” cable that creates a type A port. Attaching more than one useful thing requires a mini hub. And completing the install requires one each USB stick, keyboard, and network adapter. First, we need to prep the machine to boot from USB. Actually, before doing anything, make sure you have a full charge. It's going to be battery only from here on out. Plug everything in. Flash drive, keyboard, and network into the hub, hub into the OTG cable, cable into the port on top of the Stream. Turn on the machine while holding the volume down button. This launches a mini menu from which we can enter the BIOS. There's a little on screen keyboard in the corner, so this can be done even without a keyboard attached, but the USB keyboard should work. We need to change two settings in the boot section. First, turn off secure boot. Second, switch boot order to prefer USB. Save and exit. The first reboot reveals a confirmation screen checking that we really want to disable secure boot. We must enter a PIN and press enter. Enter the PIN shown on the screen and press enter. And we are go. Then boot up OpenBSD from the USB drive Ted then works there a number of kernel panics and device driver issues, but after disabling ACPI and IntelDRM, the device boots OpenBSD. Of course, there's no X at this point. And definitely no touch screen. And no internal networking. However, by keeping our USB hub attached, we can drive the console and access the network. At least until the battery is depleted, even if we have no way of knowing how long that will be since we disabled all the ACPI devices, which also means no suspend or resume. With some xorg.conf hacking, he did get Xorg working *** DragonflyBSD steps towards base LibreSSL (http://lists.dragonflybsd.org/pipermail/commits/2016-September/624493.html) Project: DragonFlyBSD / Switch base to use private LibreSSL libraries (http://freshbsd.org/commit/dfbsd/304ca408000cd34559ef5319b4b5a6766d6eb35b) DragonFly BSD adopts uses of LibreSSL (http://undeadly.org/cgi?action=article&sid=20160911231651) The number of projects beginning to switch over to LibreSSL is growing and it appears we can now throw DragonFly into that camp. Following something that sounds vaguely familiar (Allan!) DFLY is now creating “private” LibreSSL libraries which are only linked against by base system binaries. For the moment OpenSSL is still built, primarily so that various ports and 3rd party apps can continue to function as before. A NO_OPENSSL option has also been added, but doesn't really do much (yet), since it'll still build and install headers / libraries even if set. *** OpenBSD g2k16 Hackathon g2k16 Hackathon Report: Antoine Jacoutot on Binary Patches (http://undeadly.org/cgi?action=article&sid=20160911012316) g2k16 Hackathon Report: Matthieu Herrb on xenodm (http://undeadly.org/cgi?action=article&sid=20160911231712) g2k16 Hackathon Report: Vincent Gross on iked(8), armv7 and sys/netinet[6] (http://undeadly.org/cgi?action=article&sid=20160911000337) g2k16 Hackathon Report: Florian Obser on httpd, networking, acme-client, and more (http://undeadly.org/cgi?action=article&sid=20160911000052) g2k16 Hackathon Report: Jasper Lievisse Adriaanse on ddb(4) and more (http://undeadly.org/cgi?action=article&sid=20160909012520) g2k16 Hackathon Report: Christian Weisgerber on gettext progress, RTC work, removing kernel cruft (http://undeadly.org/cgi?action=article&sid=20160908002430) g2k16 Hackathon Report: Brent Cook on Chromebooks, crypto, and more (http://undeadly.org/cgi?action=article&sid=20160907131655) g2k16 Hackathon Report: Ted Unangst on doas, signify, code removal (http://undeadly.org/cgi?action=article&sid=20160906230610) g2k16 Hackathon Report: Marc Espie on package signing evolution (http://undeadly.org/cgi?action=article&sid=20160905235911) g2k16 Hackathon Report: Adam Wolk on ports, wireless drivers and more (http://undeadly.org/cgi?action=article&sid=20160906004915) g2k16 Hackathon Report: Mike Larkin on vmm + vmd progress (http://undeadly.org/cgi?action=article&sid=20160905134009&mode=expanded) *** News Roundup OpenBSD (with encrypted softraid) on the Chromebook Pixel (https://jcs.org/notaweblog/2016/08/26/openbsd_chromebook/) Looking for a Laptop to make your OpenBSD road-warrior? If so, we have a great blog tutorial on getting OpenBSD setup on the Chromebook Pixel with encrypted softraid! Author Joshua Stein gives us a very verbose look at how to install and dial-in the laptop perfectly. But first for those wondering about the hardware in the pixel: The Chromebook Pixel LS (2015) has an Intel Core i7 processor (Broadwell) at 2.4Ghz, 16Gb of RAM, a 2560x1700 400-nit IPS screen (239ppi), and Intel 802.11ac wireless. It has a Kingston 64Gib flash chip, of which about 54Gib can be used by OpenBSD when dual-booting with a 1Gb Chrome OS partition. Due to this being a chromebook with seaBIOS, some manual key-press trickery will be required to initially get the OpenBSD Installer up and running. From here you'll want to pay special close attention to the disk partitioning. In particular Joshua will show us how to shrink the existing encrypted /home that ChromeOS uses, keeping the dual-boot intact. This will become important if you ever plan on updating the device. From here, we move back to a more traditional setup, but with the added bonus of doing a soft-raid setup. But the fun isn't over yet! If you want to make OpenBSD the default boot, that'll require cracking the lid on the device and removing a special pink write-protect screw. And of course if you want to remove the default splash-screen image, Joshua has you covered as well, although some flashrom magic will be required. At this point you are nearly done. Final details on enabling specific bits of hardware are discussed. Most things work, apart from Audio and Bluetooth as of right now. *** doas mastery (http://www.tedunangst.com/flak/post/doas-mastery) “doas” mastery - Paging MWL! Our buddy Ted Unangst has written up a great ‘mastery' guide of the doas command, which can come in handy if you are among the un-initiated in doas land. UNIX systems have two classes of user, the super user and regular users. The super user is super, and everybody else is not. This concentration of power keeps things simple, but also means that often too much power is granted. Usually we only need super user powers to perform one task. We would rather not have such power all the time. Think of the responsibility that would entail! Like the sudo command, doas allows for subdivision of super user privileges, granting them only for specific tasks. He starts with the basic doas.conf setup, which starts with an empty config file The doas config is much like a pf ruleset, the default is to block everything > We add the root rule second because doas evaluates rules in a last match manner. root is in the wheel group, so the first rule will match, and then we need to override that with a second rule. Remember to always start with general rules, then make them more specific. *** iXsystems iXsystems to host MeetBSD (https://www.ixsystems.com/blog/ixsystems-host-meetbsd-california-2016-uc-berkeley/) FreeBSD Foundation Welcomes New Board Members New Board Members (https://www.freebsdfoundation.org/blog/freebsd-foundation-welcomes-new-board-members/) The FreeBSD Foundation has added two new board members Interview with Kylie Liang (https://www.freebsdfoundation.org/blog/new-board-member-interview-kylie-liang/) Kylie will focus on representing FreeBSD at conferences and businesses in China I live in China. There, I can act as a bridge between Chinese companies and the FreeBSD community to help drive FreeBSD adoption. Through my leadership role in the FreeBSD Foundation, I will help promote FreeBSD in China and also represent the Foundation at conferences and events in my region. Kylie leads the team the ensures FreeBSD runs well on Hyper-V and Azure, including providing commercial support for customers who run FreeBSD or FreeBSD based appliances on the Azure Cloud I joined Microsoft and started to lead the project called FreeBSD Integration Service to get FreeBSD running well on Hyper-V and Azure. To promote our work and to understand the FreeBSD ecosystem, I started to participate in FreeBSD events where I was inspired by this technical community. Interview with Philip Paeps (https://www.freebsdfoundation.org/blog/new-board-member-interview-philip-paeps/) Philip started with FreeBSD in the early 2000s and got his commit bit in 2004 The patches I submitted to make ACPI and input devices work on that laptop led to a src commit bit in 2004. While I haven't worked on ACPI or input devices since, I have been contributing to different areas of the kernel. Taking up maintainership of some ports I cared about also got me a ports commit bit after some time. Philip will continue to help run EuroBSDCon, but is also spreading the word about FreeBSD in India and Africa Primarily, I think I can be useful! I attend (and organize) a number of conferences around the world every year, particularly in regions that have a mostly “stealthy” FreeBSD community. While I clearly don't need to be on the FreeBSD Foundation board to advocate for FreeBSD, joining as a director will provide an additional asset when working in areas of the world where organizational affiliations are meaningful. Philip has also developed network drivers and various other bits and pieces, and has extensive experience working with and for hardware vendors and appliance vendors Despite intending to eventually contribute their code to the FreeBSD Project as open source, many hardware vendors still find it very difficult to engage directly with the FreeBSD development community. The Foundation helps bridge that gap and helps facilitate collaboration between commercial vendors and the FreeBSD community. I hope to make FreeBSD more visible in regions of the world where it is historically under-represented. I expect I will be attending even more conferences and getting myself invited to even more organizations. more, less, and a story of typical Unix fossilization (https://utcc.utoronto.ca/~cks/space/blog/unix/MoreAndUnixFossilization) Chris Siebenmann from the University of Toronto digs into the history of the difference between ‘less' and ‘more' In the beginning, by which we mean V7, Unix didn't have a pager at all. That was okay; Unix wasn't very visual in those days, partly because it was still sort of the era of the hard copy terminal. Then along came Berkeley and BSD. People at Berkeley were into CRT terminals, and so BSD Unix gave us things like vi and the first pager program, more (which showed up quite early, in 3BSD, although this isn't as early as vi, which appears in 2BSD). Calling a pager more is a little bit odd but it's a Unix type of name and from the beginning more prompted you with '--More--' at the bottom of the screen. All of the Unix vendors that based their work on BSD Unix (like Sun and DEC) naturally shipped versions of more along with the rest of the BSD programs, and so more spread around the BSD side of things. However, more was by no means the best pager ever; as you might expect, it was actually a bit primitive and lacking in features. So fairly early on Mark Nudelman wrote a pager with somewhat more features and it wound up being called less as somewhat of a joke. In a sane world, Unix vendors would have either replaced their version of more with the clearly superior less or at least updated their version of more to the 4.3 BSD version. Maybe less wouldn't have replaced more immediately, but certainly over say the next five years, when it kept on being better and most people kept preferring it when they had a choice.” + “This entire history has led to a series of vaguely absurd outcomes on various modern Unixes. On Solaris derivatives more is of course the traditional version with source code that can probably trace itself all the way back to 3BSD, carefully updated to SUS compliance. Solaris would never dream of changing what more is, not even if the replacement is better. Why, it might disturb someone. Oddly, FreeBSD has done the most sensible thing; they've outright replaced more with less. There is a /usr/bin/more but it's the same binary as less and as you can see the more manpage is just the less manpage. OpenBSD has done the same thing but has a specific manpage for more instead of just giving you the less manpage. So, now you can see why I say that less is more, or more, or both, at several levels. less is certainly more than more, and sometimes less literally is more (or rather more is less, to put it the right way around). Beastie Bits PC-BSD listed in the top 8 'best' alternatives to Windows 10 (http://www.computerworlduk.com/galleries/operating-systems/-free-alternatives-windows-10-3639433/) Creating a quick DNS server with a Rapsberry Pi2 and FreeBSD 11.0-RC1 (http://bsdimp.blogspot.co.uk/2016/08/creating-quick-dns-server-with.html) Dual Boot OpenBSD and Linux + UEFI (https://bsdlaptops.wordpress.com/2016/03/07/vaio-pro-11-part-2/) DesktopBSD 2.0 various versions available (Gnome, Lumina, KDE, LXDE) (http://desktopbsd.boards.net/board/10/announcements) FreeBSD gets new ZFS features including: Compressed ARC (https://svnweb.freebsd.org/base?view=revision&revision=305323) and ZFS Allocation Throttle (https://svnweb.freebsd.org/base?view=revision&revision=305331) One Floppy NetBSD Distribution (https://github.com/user340/fdgw2) A Compendium of BUGs (https://github.com/q5sys/BUGtracker) Feedback/Questions Galahad - OpenBSD X setup (http://pastebin.com/b7W6NHqs) Tang - Subtitles (http://pastebin.com/P4MUs3Pa) Ivan - Zpool Options (http://pastebin.com/LQ8yTp0G) Brad - Replication Issue (http://pastebin.com/XTK5gXMU) MJ - HBA (http://pastebin.com/TdYTMSj9) ***
This week on BSDNow, we have a variety of news to discuss, covering quite the spectrum of BSD. (Including a new DragonFly release!). This episode was brought to you by Headlines my int is too big (http://www.tedunangst.com/flak/post/my-int-is-too-big) “The NCC Group report (http://marc.info/?l=oss-security&m=146853062403622&w=2) describes the bugs, but not the history of the code.” “Several of them, as reported by NCC, involved similar integer truncation issues. Actually, they involved very similar modern 64 bit code meeting classic 32 bit code” “The thrsleep system call is a part of the kernel code that supports threads. As the name implies, it gives userland a measure of control over scheduling and lets a thread sleep until something happens. As such, it takes a timeout in the form of a timespec. The kernel, however, internally implements time keeping using ticks (there are HZ, 100, ticks per second). The tsleep function (t is for timed) takes an int number of ticks and performs basic validation by checking that it's not negative. A negative timeout would indicate that the caller has miscalculated. The kernel panics so you can fix the bug, instead of stalling forever.” “The trouble therefore is when userland is allowed to specify a timeout that could be negative. The existing code made an attempt to handle various tricks by converting the timespec to a ticks value stored as a 64 bit long long which was checked against INTMAX before passing to sleep. Any value over INTMAX would be truncated, so we can't allow that. Instead, we saturate the value to INT_MAX. Unfortunately, this check didn't account for the possibility that the tick conversion from the timespec could also overflow and result in a negative value.” Then there is the description of the kqueue flaw: “Every kqueue keeps a list of all the attached events it's watching for. A simple array is used to store file events, indexed by fd.” “This array is scaled to accommodate the largest fd that needs to be stored. This would obviously cause trouble, consuming too much memory, if the identifier were not validated first. Which is exactly what kqueue tries to do. The fdgetfile function checks that the identifier is a file that the process has open. One wrinkle. fdgetfile takes an int argument but ident is a uintptr_t, possibly 64 bits. An ident of 2^32 + 2 will look like a valid file descriptor, but then cause the array to be resized to gargantuan proportions.” “Again, the fix is pretty simple. We must check that the ident is bounded by INTMAX before calling fdgetfile. This bug likely would have been exploitable beyond a panic, but the array allocation was changed to use mallocarray instead of multiplying arguments by hand, thus preventing another overflow.” Then there is a description of the anonymous mmap flaw, and the “secret magic” _MAPNOFAULT flag *** FreeBSD Quarterly Status Report Q2 2016 (https://www.freebsd.org/news/status/report-2016-04-2016-06.html) It's time for another round of FreeBSD Quarterly Status Reports! In this edition, we have status updates from the various teams, including IRC/Bugs/RE/Ports/Core and Foundation We also have updates on some specific projects, including from Konstantin on the on-going work for his implementation of ASLR, including the new ‘proccontrol' command which provides the following: > “The proccontrol(1) utility was written to manage and query ASLR enforcement on a per-process basis. It is required for analyzing ASLR failures in specific programs. This utility leverages the procctl(2) interface which was added to the previous version of the patch, with some bug fixes.” Next are updates on porting CEPH to FreeBSD, the ongoing work to improve EFI+GELI (touched on last week) and more robust Mutexes. Additionally we have an update from Matt Macy and the Xorg team discussing the current work to update FreeBSD's graphic stack: > “All Intel GPUs up to and including the unreleased Kaby Lake are supported. The xf86-video-intel driver will be updated soon. Updating this driver requires updating Xorg, which in turn is blocked on Nvidia updates.” The kernel also got some feature status updates, including on the new Allwinner SoC support, an update on FreeBSD in Hyper-V and VIMAGE In addition to a quick update on the arm64 architecture (It's getting there, RPi3 is almost a thing), we also have a slew of port updates, including support for GitLab in ports, updates on GNOME / KDE and some additional Intel-specific networking tools. *** Vulnerabilities discovered in freebsd-update and portsnap (https://lists.freebsd.org/pipermail/freebsd-security/2016-July/009016.html) There are two vulnerabilities discovered in freebsd-update and portsnap, where an attacker could place files in the portsnap directory and they would be used without being subject to having their checksum verified (but this requires root access), and the second where a man-in-the-middle attacker could guess the name of a file you will fetch by exploiting the time-gap between when you download the initial snapshot, and when you fetch the updated files. There are a number of vulnerabilities that were discovered in libarchive/tar as well There is also an issue with bspatch. A security advisory for bspatch has already been released, as this vulnerabilities was also discovered by the Chromium team, which uses this same code. The patch discussed in this mailing list thread is larger, but secteam@ believes at least one of the additional checks introduced is incorrect and may prevent a valid patch from being applied. The smaller patch was pushed out first, to solve the main attack vector, while the larger patch is investigated. Automated fuzz testing is underway. Great care is being taken fixing bspatch, as if it is broken installing future updates becomes much more difficult secteam@ and core@ would like to emphasize that the FreeBSD project takes these issue very seriously and are working on it > “As a general rule, secteam@ does not announce vulnerabilities for which we don't have patches, but we concede that we should have considered making an exception in this case” Work is underway to re-architect freebsd-update and portsnap to do signature verification on all files before they are passed to libarchive/tar, to help protect users from any future vulnerabilities in libarchive. However, this requires changes to the metadata format to provide these additional signatures, and backwards compatibilities must be preserved, so people can update to the newer versions to get these additional security features There is also discussion of using HTTPS for delivery of the files, but certificate verification and trust are always an issue. FreeBSD does not distribute a certificate trust store by default. There will be more on this in the coming days. *** OpenSSH 7.3 Released (http://www.openssh.com/txt/release-7.3) OpenSSH 7.3 has landed! Primarily a bug-fix release, the release notes do mention the pending deprecation of some more legacy Crypto in the future, including denying all RSA keys < 1024bit, and removal of SSHv1 support. (Already disabled via compile option) On the bug side, there was a security issue addressed in sshd: “sshd(8): Mitigate a potential denial-of-service attack against the system's crypt(3) function via sshd(8). An attacker could send very long passwords that would cause excessive CPU use in crypt(3). sshd(8) now refuses to accept password authentication requests of length greater than 1024 characters” Also a timing issue was resolved in regard to password auth, which could possibly allow an attacker to discern between valid/invalid account names. On the feature side, we have the new ProxyJump option (-J flag) which allows you to do simplified indirection through various SSH jump hosts. Various bugs were fixed, and some compile failures resolved in the portable version to auto-disable some ciphers not supported by OpenSSL. News Roundup OpenBSD Ports - Integrating Third Party Applications [pdf] (http://jggimi.homeip.net/semibug.pdf) A talk from Josh Grosse, presented at SEMIBUG (South-East Michigan BSD Users Group), about OpenBSD Ports It opens by explaining the separation of the ‘base system' from ‘packages', as is common in most all BSDs It explains the contents of OpenBSD package tar file, which contain some metadata files (+CONTENTS and +DESC) and then the actual package files The talk goes on to explain the different branches (-release, -stable, and -current), and warn users that there are no official -stable packages from the project Then it goes on into the development model, including what new contributors should expect Then it walks through the entire process of creating a port and getting it contributed *** NetBSD removes last RWX page in amd64 kernel (http://mail-index.netbsd.org/source-changes/2016/07/27/msg076413.html) NetBSD has purged the last holdout RWX page on the amd64 platform > “Use UVMPROTALL only if UVMKMFEXEC is given as argument. Otherwise, if UVMKMFPAGEABLE is also given as argument, only the VA is allocated and UVM waits for the page to fault before kentering it. When kentering it, it will use the UVMPROT flag that was passed to uvm_map; which means that it will kenter it as RWX. With this change, the number of RWX pages in the amd64 kernel reaches strictly zero.” Break out the party favors! Hopefully any last stragglers in any of the other BSD's gets retired soon as well. *** DragonFly BSD 4.6 launches with home-grown support for NVMe Controllers (http://linux.softpedia.com/blog/dragonfly-bsd-4-6-0-launches-with-home-grown-support-for-nvme-controllers-506908.shtml) Softpedia picked up on the release of DragonFlyBSD 4.6, specifically about their new home-grown NVMe driver. > “We now have a NVMe driver (PCIe SSDs). It currently must be kldloaded with nvme_load="YES" in /boot/loader.conf. The driver uses all concurrency features offered by the chip and will distribute queues and interrupts across multiple CPUs to maximize performance. It has been tested up to around 1.05M IOPS @4K, and roughly 6.5 GBytes/sec @32K (random read from urandom-filled partition, physio, many threads), with the 2xE5-2620v4 (xeon) test server 78% idle in the IOPS test and 72% idle on the bandwidth test. In other words, we maxed out the three NVMe devices we had plugged in and the system still had plenty of suds left over. Please note that a machine's ability to boot from an NVMe device depends on the BIOS, and not DragonFly. Most BIOSes cannot boot from NVMe devices and those that can probably only do it through UEFI. Info on device state is available with the new utility nvmectl.“ In addition to this improved support, 4.6 also brings in the improved graphics support, matching what is in Linux 4.4 and support for Broadwell/Skylake. SMP also got some love: > “SMP performance was already very good. As part of the NVMe driver work we revamped the buffer cache subsystem and a number of other I/O related paths, further reducing lock contention and IPI signalling overheads. We also put topology-aware cpu cache localization into the kernel memory allocator (primarily helps multi-socket systems and systems with high core counts). The network subsystem also continues to receive significant improvement, with modest machine configurations now capable of handling upwards of 580K conns/sec.“ +Full Release Notes (https://www.dragonflybsd.org/release46/) *** The powerd++ daemon monitors the system load and adjusts the CPU clock accordingly and is a drop-in replacement for FreeBSD's native powerd(8). (http://www.freshports.org/sysutils/powerdxx/) As mentioned in our EuroBSDCon 2016 rundown, Dominic Fandrey will be giving a presentation about his powerd replacement, powerd++ The source code is already available on github, and is in ports The major difference is the newer design handle many-core systems much better. The original powerd was written at a time when most laptops only had a single core, and maybe a hyperthread. The new design decides which CPU frequency to use by looking at the busiest core, rather than the average across the cores, resulting in a more meaningful result. It also supports averaging over a longer period of time, to avoid jumping to a higher frequency to quickly powerd++ also avoids ‘slewing' the cpu frequency, ratching it up and down one step at a time, and instead jumps directly to the target frequency. Often times, you will use less battery by jumping to maximum frequency, finishing the work, and going back to a low power state, than trying to do that work over a longer period of time in low power mode *** Beastie Bits Hyper-V: Unmapped I/O improves userland direct disk performance by 35% ~ 135% (https://svnweb.freebsd.org/base?view=revision&revision=303474) One does not simply remove FreeBSD (https://imgur.com/a/gjGoq) A new BSD Podcast "BSD Synergy" has started (https://www.youtube.com/channel/UCBua6yMtJ6W5ExYSREnS3UQ) KnoxBug - Next Meeting - Aug 30th (http://knoxbug.org/content/2016-08-30) Feedback/Questions Daniel - Root/Wheel (http://pastebin.com/8sMyKm6c) Joe - IPV6 Frag (http://pastebin.com/r5Y0gbxf) Paul - ChicagoBug (http://pastebin.com/iVYPYcVs) Chris - SSH BruteBlock (http://pastebin.com/597m9gHa) Todd - Jails (http://pastebin.com/xjbKwSaz) ***
Today on the show, we are going to be chatting with Michael Dexter about a variety of topics, but of course including bhyve! That plus This episode was brought to you by Headlines NetBSD Introduction (https://bsdmag.org/netbsd_intr/) We start off today's episode with a great new NetBSD article! Siju Oommen George has written an article for BSDMag, which provides a great overview of NetBSD's beginnings and what it is today. Of course you can't start an article about NetBSD without mentioning where the name came from: “The four founders of the NetBSD project, Chris Demetriou, Theo de Raadt, Adam Glass, and Charles Hannum, felt that a more open development model would benefit the project: one centered on portable, clean and correct code. They aimed to produce a unified, multi-platform, production-quality, BSD-based operating system. The name “NetBSD” was suggested by de Raadt, based on the importance and growth of networks, such as the Internet at that time, the distributed and collaborative nature of its development.” From there NetBSD has expanded, and keeping in line with its motto “Of course it runs NetBSD” it has grown to over 57 hardware platforms, including “IA-32, Alpha, PowerPC,SPARC, Raspberry pi 2, SPARC64 and Zaurus” From there topics such as pkgsrc, SMP, embedded and of course virtualization are all covered, which gives the reader a good overview of what to expect in the modern NetBSD today. Lastly, in addition to mentioning some of the vendors using NetBSD in a variety of ways, including Point-Of-Sale systems, routers and thin-clients, you may not have known about the research teams which deploy NetBSD: NASA Lewis Research Center – Satellite Networks and Architectures Branch use NetBSD almost exclusively in their investigation of TCP for use in satellite networks. KAME project – A research group for implementing IPv6, IPsec and other recent TCP/IP related technologies into BSD UNIX kernels, under BSD license. NEC Europe Ltd. established the Network Laboratories in Heidelberg, Germany in 1997, as NEC's third research facility in Europe. The Heidelberg labs focus on software-oriented research and development for the next generation Internet. SAMS-II Project – Space Acceleration Measurement System II. NASA will be measuring the microgravity environment on the International Space Station using a distributed system, consisting of NetBSD.“ My condolences, you're now the maintainer of a popular open source project (https://runcommand.io/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) A presentation from a Wordpress conference, about what it is like to be the maintainer of a popular open source project The presentation covers the basics: Open Source is more than just the license, it is about community and involvement The difference between Maintainers and Contributors It covers some of the reasons people do not open up their code, and other common problems people run into: “I'm embarrassed by my code” (Hint: so is everyone else, post it anyway, it is the best way to learn) “I'm discouraged that I can't finish releases on time” “I'm overwhelmed by the PR backlog” “I'm frustrated when issues turn into flamewars” “I'm overcommitted on my open source involvement” “I feel all alone” Each of those points is met with advice and possible solutions So, there you have it. Open up your code, or join an existing project and help maintain it *** FreeBSD Committer Allan Jude Discusses the Advantages of FreeBSD and His Role in Keeping Millions of Servers Running (http://www.hostingadvice.com/blog/freebsd-project-under-the-hood/) An interesting twist on our normal news-stories today, we have an article featuring our very own Allan Jude, talking about why FreeBSD and the advantages of working on an open-source project. “When Allan started his own company hosting websites for video streaming, FreeBSD was the only operating system he had previously used with other hosts. Based on his experience and comfort with it, he trusted the system with the future of his budding business.A decade later, the former-SysAdmin went to a conference focused on the open-source operating system, where he ran into some of the folks on its documentation team. “They inspired me,” he told our team in a recent chat. He began writing documentation but soon wanted to contribute improvements beyond the docs.Today, Allan sits as a FreeBSD Project Committer. It's rare that you get to chat with someone involved with a massive-scale open-source project like this — rare and awesome.” From there Allan goes into some of the reasons “Why” FreeBSD, starting with Code Organization being well-maintained and documented: “The FreeBSD Project functions like an extremely well-organized world all its own. Allan explained the environment: “There's a documentation page that explains how the file system's laid out and everything has a place and it always goes in that place.”” + In addition, Allan gives us some insight into his work to bring Boot-Environments to the loader, and other reasons why FreeBSD “just makes sense” + In summary Allan wraps it up quite nicely: “An important take-away is that you don't have to be a major developer with tons of experience to make a difference in the project,” Allan said — and the difference that devs like Allan are making is incredible. If you too want to submit the commit that contributes to the project relied on by millions of web servers, there are plenty of ways to get involved! We're especially talking to SysAdmins here, as Allan noted that they are the main users of FreeBSD. “Having more SysAdmins involved in the actual build of the system means we can offer the tools they're looking for — designed the way a SysAdmin would want them designed, not necessarily the way a developer would think makes the most sense” A guide to saving electricity and time with poudriere and bhyve (http://justinholcomb.me/blog/2016/07/03/poudriere-in-bhyve-and-bare-metal.html) “This article goes over running poudriere to built packages for a Raspberry Pi with the interesting twist of running it both as a bhyve guest and then switching to running on bare metal via Fiber Channel via ctld by sharing the same ZFS volume.” “Firstly, poudriere can build packages for different architectures such as ARM. This can save hours of build time compared to building ports from said ARM device.” “Secondly, let's say a person has an always-on device (NAS) running FreeBSD. To save power, this device has a CPU with a low clock-rate and low core count. This low clock-rate and core count is great for saving power but terrible for processor intensive application such as poudriere. Let's say a person also has another physical server with fast processors and a high CPU count but draws nearly twice the power and a fan noise to match.” “To get the best of both worlds, the goal is to build the packages on the fast physical server, power it down, and then start the same ZFS volume in a bhyve environment to serve packages from the always-on device.” The tutorial walks through setting up ‘ahost', the always on machine, ‘fhost' the fast but noisy build machine, and a raspberry pi It also includes creating a zvol, configuring iSCSI over fibre channel and exporting the zvol, booting an iSCSI volume in bhyve, plus installing and setting up poudriere This it configures booting over fibre channel, and cross-building armv6 (raspberry pi) packages on the fast build machine Then the fast machine is shut down, and the zvol is booted in bhyve on the NAS Everything you need to know to make a hybrid physical/virtual machine The same setup could also work to run the same bhyve VM from either ahost or fhost bhyve does not yet support live migration, but when it does, having common network storage like the zvol will be an important part of that *** Interview - Michael Dexter - editor@callfortesting.org (mailto:editor@callfortesting.org) / @michaeldexter (https://twitter.com/michaeldexter) The RoloDexter *** iXSystems Children's Minnesota Star Studio Chooses iXsystems' TrueNAS Storage (https://www.youtube.com/watch?v=FFbdQ_05e-0) *** News Roundup FreeBSD Foundation June 2016 Update (https://www.freebsdfoundation.org/wp-content/uploads/2016/06/FreeBSD-Foundation-June-2016-Update.pdf) The FreeBSD Foundation's June newsletter is out Make sure you submit the FreeBSD Community Survey (https://www.surveymonkey.com/r/freebsd2016) by July 7th: In addition to the opening message from the executive director of the foundation, the update includes details to sponsored work on the FreeBSD VM system, reports from a number of conferences the Foundation attended, including BSDCan The results of the foundation's yearly board meeting People the foundation recognized for their contributions to FreeBSD at BSDCan And an introduction to their new “Getting Started with FreeBSD” project *** [How-To] Building the FreeBSD OS from scratch (http://www.all-nettools.com/forum/showthread.php?34422-Building-the-FreeBSD-OS-from-scratch) A tutorial over at the All-NetTools.com forums that walks through building FreeBSD from scratch I am not sure why anyone would want to build Xorg from source, but you can It covers everything in quite a bit of detail, from the installation process through adding Xorg and a window manager from source It also includes tweaking some device node permissions for easier operation as a non-root user, and configuring the firewall *** Window Systems Should Be Transparent (http://doc.cat-v.org/bell_labs/transparent_wsys/) + Rob Pike of AT&T Labs writes about why Window Systems should be transparent This is an old paper (undated, but I think from the late 80s), but may contain some timeless insights “UNIX window systems are unsatisfactory. Because they are cumbersome and complicated, they are unsuitable companions for an operating system that is appreciated for its technical elegance” “A good interface should clarify the view, not obscure it” “Mux is one window system that is popular and therefore worth studying as an example of good design. (It is not commercially important because it runs only on obsolete hardware.) This paper uses mux as a case study to illustrate some principles that can help keep a user interface simple, comfortable, and unobtrusive. When designing their products, the purveyors of commercial window systems should keep these principles in mind.” There are not many commercial window systems anymore, but “open source” was not really a big thing when this paper was written *** Roger Faulkner, of Solaris fame passed away (http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/12877) “RIP Roger Faulkner: creator of the One and True /proc, slayer of the M-to-N threading model -- and the godfather of post-AT&T Unix” @bcantrill: Another great Roger Faulkner story (https://twitter.com/bcantrill/status/750442169807171584) The story of how pgrep -w saved a monitor -- if not a life (https://news.ycombinator.com/item?id=4306515) @bcantrill: With Roger Faulkner, Tim led an engineering coup inside Sun that saved Solaris circa 2.5 (https://twitter.com/bcantrill/status/750442169807171584) *** Beastie Bits: Developer Ed Maste is requesting information from those who are users of libvgl. (https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084843.html) HEADS UP: DragonFly 4.5 world reneeds rebuilding (http://lists.dragonflybsd.org/pipermail/users/2016-June/249748.html) Chris Buechler is leaving the pfSense project, the entire community thanks you for your many years of service (https://blog.pfsense.org/?p=2095) GhostBSD 10.3-BETA1 now available (http://ghostbsd.org/10.3_BETA1) DragonFlyBSD adds nvmectl (http://lists.dragonflybsd.org/pipermail/commits/2016-June/500671.html) OPNsense 16.1.18 released (https://opnsense.org/opnsense-16-1-18-released/) bhyve_graphics hit CURRENT (https://svnweb.freebsd.org/base?view=revision&revision=302332) BUG Update FreeBSD Central Twitter account looking for a new owner (https://twitter.com/freebsdcentral/status/750053703420350465) NYCBUG meeting : Meet the Smallest BSDs: RetroBSD and LiteBSD, Brian Callahan (http://lists.nycbug.org/pipermail/talk/2016-July/016732.html) NYCBUG install fest @ HOPE (http://lists.nycbug.org/pipermail/talk/2016-June/016694.html) SemiBUG is looking for presentations for September and beyond (http://lists.nycbug.org/pipermail/semibug/2016-June/000107.html) Caleb Cooper is giving a talk on Crytpo at KnoxBUG on July 26th (http://knoxbug.org/content/2016-07-26) Feedback/Questions Leif - ZFS xfer (http://pastebin.com/vvASr64P) Zach - Python3 (http://pastebin.com/SznQHq7n) Dave - Versioning (http://pastebin.com/qkpjKEr0) David - Encrypted Disk Images (http://pastebin.com/yr7BUmv2) Eli - TLF in all the wrong places (http://pastebin.com/xby81NvC) ***
It's only one-week away from BSDCan, both Allan and I are excited to meet some of you in person! However, the show keeps on This episode was brought to you by Headlines dotSecurity 2016 - Theo de Raadt - Privilege Separation and Pledge (http://www.dotsecurity.io/) Video (https://www.youtube.com/watch?v=a_EYdzGyNWs) Slides (https://www.openbsd.org/papers/dot2016.pdf) Interested in Privilege Separation and security in general? If so, then you are in for a treat, we have both the video and slides from Theo de Raadt at dotSecurity 2016. Specifically the the talk starts off looking at Pledge (no copyright issues with the pictures I hope??) and how their NTP daemon uses it. After going through some internals, Theo reveals that around 10% of programs “pledged” so far were found to be trying to do actions outside of their security scope. On the future-work side, they mention going back and looking at OpenSSH privilege separation next, as well as working with other OS's that may want pledge support. *** bhyve now supports UEFI GOP (https://lists.freebsd.org/pipermail/freebsd-virtualization/2016-May/004471.html) The log awaited UEFI GOP (Graphics Output Protocol (https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#GOP)) features has landed in bhyve This provides emulated graphics via an internal VNC server, allowing users to have full graphical access to the guest OS This allows installation of Windows guests without needing to create a modified ISO with an unattended installation script The code has not actually landed in FreeBSD head yet, but has been committed to a project branch Following a few simple commands, you can compile the new bhyve binary on your -CURRENT system and get started right away This feature is expected to be included in the upcoming FreeBSD 11.0 This commit drop also brings with it: XHCI -- an emulated usb tablet device that provides exact mouse positioning in supported OSs PS2 mouse for fallback if the guest does not support XHCI (Windows 7) PS2 keyboard “The code has been tested with Windows 7/8/8.1/10 and Server 2k12/2k16, Ubuntu 15.10, and FreeBSD 10.3/11-CURRENT” “For VNC clients, TightVNC, TigherVNC, and RealVNC (aka VNC Viewer) have been tested on various hosts. The OSX VNC client is known not to work.” The VNC server supports an optional ‘wait' parameter, that causes the VM to not actually boot until the VNC client connects, allowing you to interrupt the boot process if need be Related user blog post (http://justinholcomb.me/blog/2016/05/28/bhyve-uefi-gop-support.html) SVN commit (https://svnweb.freebsd.org/base?view=revision&revision=300829) *** zfsd lands in FreeBSD HEAD, in time for 11.0-RELEASE (https://svnweb.freebsd.org/base?view=revision&revision=300906) zfsd has been committed to FreeBSD -CURRENT in time to be included in FreeBSD 11.0 zfsd is the missing piece required to make ‘hot spares' work properly in FreeBSD ZFS “zfsd attempts to resolve ZFS faults that the kernel can't resolve by itself. It listens to devctl(4) events, which is how the kernel notifies of events such as I/O errors and disk removals. Zfsd attempts to resolve these faults by activating or deactivating hotspares and onlining offline vdevs.” “The administrator never interacts with zfsd directly. Instead, he controls its behavior indirectly through zpool configuration. There are two ways to influence zfsd: assigning hotspares and setting pool properties. Currently, only the autoreplace property has any effect. See zpool(8) for details.” So, what example does it do? Device Removal: “When a leaf vdev disappears, zfsd will activate any available hotspare.” Device Arrival: “When a new GEOM device appears, zfsd will attempt to read its ZFS label, if any. If it matches a previously removed vdev on an active pool, zfsd will online it. Once resilvering completes, any active hotspare will detach automatically.” So if you disconnect a drive, then reconnect it, it will automatically be brought back online. Since ZFS is smart, the resilver will only have to copy data that has changed since the device went offline. “If the new device has no ZFS label but its physical path matches the physical path of a previously removed vdev on an active pool, and that pool has the autoreplace property set, then zfsd will replace the missing vdev with the newly arrived device. Once resilvering completes, any active hotspare will detach automatically.” If the new drive is in the same slot in your hot swap array as a failed device, it will be used as a replacement immediately. vdev degrade or fault events: “If a vdev becomes degraded or faulted, zfsd will activate any available hotspare. If a leaf vdev generates more than 50 I/O errors in a 60 second period, then zfsd will mark that vdev as FAULTED. zfs(4) will no longer issue any I/Os to it. zfsd will activate a hotspare if one is available.” Same for checksum errors. So if zfsd detects a drive is going bad, it brings the hotspare online before it is too late Spare addition: “If the system administrator adds a hotspare to a pool that is already degraded, zfsd will activate the spare.” Resilver complete: “zfsd will detach any hotspare once a permanent replacement finishes resilvering.” Physical path change: “If the physical path of an existing disk changes, zfsd will attempt to replace any missing disk with the same physical path, if its pool's autoreplace property is set.” In general, this tool means less reliance on the system administrator to keep the pool healthy *** W^X now mandatory in OpenBSD (http://undeadly.org/cgi?action=article&sid=20160527203200) We've talked a bit about W^X in the past. (Refresher: Memory being writable and executable at once) Well, this major security no-no is no-more on OpenBSD. Theo has committed a change which now prevents violations of this policy: “W^X violations are no longer permitted by default. A kernel log message is generated, and mprotect/mmap return ENOTSUP. If the sysctl(8) flag kern.wxabort is set then a SIGABRT occurs instead, for gdb use or coredump creation.” There are a few cases where you may still need W^X, which Theo points out can be enabled on a file-system basis. “W^X violating programs can be permitted on a ffs/nfs filesystem-basis, using the "wxallowed" mount option. One day far in the future upstream software developers will understand that W^X violations are a tremendously risky practice and that style of programming will be banished outright. Until then, we recommend most users need to use the wxallowed option on their /usr/local filesystem. At least your other filesystems don't permit such programs.” This is a great ability to grow, since now users can begin doing auditing of programs that violate this principle and making noise to upstream. *** Interview - Kristof Provost - kp@freebsd.org (mailto:kp@freebsd.org) @kprovst (https://twitter.com/kprovst) pf improvements on FreeBSD *** News Roundup GELI Support for the EFI Loader (https://ericmccorkleblog.wordpress.com/2016/05/28/freebsd-geli-support/) We've had Allan's work to bring GELI support to the GPT / BIOS / ZFS loader for a while now, but the missing piece has been support for EFI. No longer, Eric McCorkle has posted a blog entry (with relevant github links) introducing us to his work to bring GELI encryption support to EFI. First the bad-news. This won't make it into 11.0. (Maybe PC-BSD, TBD) Next he explains why this is more than just a new feature, but a re-factor of the EFI boot code: I have already written extensively about my EFI refactoring here. The reason for undertaking this effort, however, was driven by GELI support. Early in my work on this, I had implemented a non-EFI “providers” framework in boot1 in order to support the notion of disk partitions that may contain sub-partitions. This was deeply unsatisfying to me for several reasons: It implemented a lot of the same functionality that exists in the EFI framework. It involved implementing a GPT partition driver to deal with partition tables inside GELI partitions (GPT detection and support is guaranteed by the EFI spec). The interface between the EFI framework and the custom “providers” framework was awkward. The driver was completely boot1-specific, and exporting it to something like GRUB probably involved a total rewrite. Implementing it within loader was going to involve a lot of code duplication. There was no obvious was to pass keys between boot1, loader, and the kernel. With the issues known, Eric seems pleased with the results of the conversion so far: The GELI driver can be extracted from the FreeBSD codebase without too much trouble. While I was unable to go all the way to the EFI driver model, the only blocker is the bcache code, and once that is resolved, we can have hotplug support in the boot loader! The boot1 and loader codebases are now sharing all the backend drivers, and boot1 has been reduced to one very small source file. An interesting read, looking forward to playing with EFI more in the future! *** Faces of FreeBSD 2016: Michael W. Lucas (https://www.freebsdfoundation.org/blog/faces-of-freebsd-2016-michael-lucas/) On this edition of “Faces of FreeBSD”, Michael W Lucas tells the story of how he got started with FreeBSD After an amusing re-telling of his childhood (The words “Purina Monkey Chow” were mentioned), he then tells us how he got into BSD. His being thrown into the project may sound familiar to many: I came in at 11 PM one night and was told “The DNS administrator just got walked out the door. You're the new lead DNS administrator. Make those servers work. Good luck.” From there (because he wanted more sleep), he began ripping out the systems that had been failing and waking him up at night. Good-bye UnixWare, Good-bye Solaris, hello BSD! A very amusing read, check it out! *** High Availability with PostgreSQL on FreeBSD (https://www.youtube.com/watch?v=ugct9-Mm7Ls) A talk by Sean Chittenden, who we interviewed previously on episode Episode 95 (http://www.bsdnow.tv/episodes/2015_06_24-bitrot_group_therapy) Explains how to setup Multi Data Center High Availability for PostgreSQL using consul Goes into how consul works, how it does the election, the gossip protocol, etc The HA setup uses DNS Failover, and the pros and cons of that approach are discussed Then he walks through the implementation details, and example configuration *** New FreeBSD i915 testing images (http://www.bsddesktop.com/images/) Still need users to test the Linux Kernel 4.6 DRM update to FreeBSD's graphics stack Download the test image and write it to a USB stick and boot from it It will not modify your installed system, it runs entirely off of the USB drive Allows you to test the updated drivers without having to install the development branch on your device you can tell them that ATI/AMD support will be coming shortly and that stability has been steadily improving and that I'll do another announcement as soon as I've had a chance to test the newest Xorg bits *** Beastie Bits Comfortable on the CLI: Series Part 1 (https://www.cotcli.com/post/The-Very-Basics/) FreeBSD Booting on the Netgate uFW, a smaller-than-a-raspberry-pi dual port firewall (https://gist.github.com/gonzopancho/8e7df7a826e9a2949b36ed2a9d30312e) Picture of uFW (https://twitter.com/gonzopancho/status/737874921435594753) uFW OpenSSL Benchmarks (https://gist.github.com/gonzopancho/8f20b50487a4f7de56e99448866a147d) ***
This week, we are going to be talking with Aaron Poffenberger, who has much to share about his first-hand experience in infiltrating Linux conferences with BSD-goodness. This episode was brought to you by Headlines Alexander Motin implements CTL High Availability (https://svnweb.freebsd.org/changeset/base/r287621) CTL HA allows two .head. nodes to be connected to the same set of disks, safely An HA storage appliance usually consists of 2 totally separate servers, connected to a shared set of disks in separate JBOD sleds The problem with this setup is that if both machines try to use the disks at the same time, bad things will happen With CTL HA, the two nodes can communicate, in this case over a special TCP protocol, to coordinate and make sure they do not step on each others toes, allowing safe operation The CTL HA implementation in FreeBSD can operate in the following four modes: Active/Unavailable -- without interlink between nodes Active/Standby -- with the second node handling only basic LUN discovery and reservation, synchronizing with the first node through the interlink Active/Active -- with both nodes processing commands and accessing the backing storage, synchronizing with the first node through the interlink Active/Proxy -- with second node working as proxy, transferring all commands to the first node for execution through the interlink The custom TCP protocol has no authentication, so it should never be enabled on public interfaces Doc Update (https://svnweb.freebsd.org/base?view=revision&revision=287707) *** Panel Self-Refresh support lands in DragonFlyBSD (http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/d13e957b0d66a395b3736c43f18972c282bbd58a) In what seems almost weekly improvements being made to the Xorg stack for DragonFly, we now have Panel Self-Refresh landing, thanks to Imre Vadász Understanding Panel Self-Refresh (http://www.anandtech.com/show/7208/understanding-panel-self-refresh) and More about Panel Self-Refresh (http://www.hardwaresecrets.com/introducing-the-panel-self-refresh-technology/) In a nutshell, the above articles talks about how in the case of static images on the screen, power-savings can be obtained by refreshing static images from display memory (frame-buffer), disabling the video processing of the CPU/GPU and associated pipeline during the process. And just for good measure, Imre also committed some further Intel driver cleanup, reducing the diff with Linux 3.17 (http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/6b231eab9db5ef4d4dc3816487d8e3d48941e0e2) *** Introducing Sluice, a new ZFS snapshot management tool (https://bitbucket.org/stevedrake/sluice) A new ZFS snapshot management tool written in Python and modeled after Apple.s Time Machine Simple command line interface No configuration files, settings are stored as ZFS user properties Includes simple remote replication support Can operate on remote systems with the zfs://user@host/path@snapname url schema Future feature list includes .import. command to moved files from non-ZFS storage to ZFS and create a snapshot, and .export. to do the inverse Thanks to Dan for tipping us about this new project *** Why WhatsApp only needs 50 engineers for 900 million users (http://www.wired.com/2015/09/whatsapp-serves-900-million-users-50-engineers/) Wired has a good write-up on the behind-the-scenes work taking place at WhatsApp While the article mentions FreeBSD, it spends the bulk of its discussion about Erlang and using its scalable concurrency and deployment of new code to running processes. FB messenger uses Haskell to accomplish much the same thing, while Google and Mozilla are currently trying to bring the same level of flexibility to Go and Rust respectively. video (https://www.youtube.com/watch?v=57Ch2j8U0lk) Thanks to Ed for submitting this news item *** Interview - Aaron Poffenberger - email@email (mailto:akp@hypernote.com) / @akpoff (https://twitter.com/akpoff) BSD in a strange place + KM: Go ahead and tell us about yourself and how did you first get involved with BSD? + AJ: You.ve presented recently at Texas Linux Fest, both on FreeBSD and FreeNAS. What specifically prompted you to do that? + KM: What would you say are the main selling points when presenting BSD to Linux users and admins? + AJ: On the flip side of this topic, in what areas to do you think we could improve BSD to present better to Linux users? + KM: What would you specifically recommend to other BSD users or fans who may also want to help present or teach about BSD? Any things specifically to avoid? + AJ: What is the typical depth of knowledge you encounter when presenting BSD to a mostly Linux crowd? Any surprises when doing so? + KM: Since you have done this before, are you mainly writing your own material or borrowing from other talks that have been done on BSD? Do you think there.s a place for some collaboration, maybe having a repository of materials that can be used for other BSD presenters at their local linux conference / LUG? + AJ: Since you are primarily an OpenBSD user have you thought about doing any talks related to it? Is OpenBSD something on the radar of the typical Linux conference-goer? + KM: Is there anything else you would like to mention before we wrap up? News Roundup GhostBSD 10.1 released (http://ghostbsd.org/10.1_release_eve) GhostBSD has given us a new release, this time it also includes XFCE as an alternative to the MATE desktop The installer has been updated to allow using GRUB, BSD loader, or none at all It also includes the new OctoPKG manager, which proves a Qt driven front-end to pkgng Thanks to Shawn for submitting this *** Moving to FreeBSD (https://www.textplain.net/blog/2015/moving-to-freebsd/) In this blog post, Randy Westlund takes us through his journey of moving from Gentoo over to FreeBSD Inspired in part due to Systemd, he first spent some time on Wikipedia reading about BSD before taking the plunge to grab FreeBSD and give it a whirl in a VM. "My first impression was that installation was super easy. Installing Gentoo is done manually and can be a "fun" weekend adventure if you're not sure what you're doing. I can spin up a new FreeBSD VM in five minutes." "There's a man page for everything! And they're well-written! Gentoo has the best documentation of any Linux distro I've used, but FreeBSD is on another level. With a copy of the FreeBSD Handbook and the system man pages, I can actually get things done without tabbing over to Google every five minutes." He goes on to mention everything from Init system, Jails, Security, Community and License, a well-rounded article. Also gives a nice shout-out to PC-BSD as an even easier way to get started on a FreeBSD journey, thanks! Shout out to Matt for tipping us to this blog post *** OpenBSD Enables GPT by default (https://marc.info/?l=openbsd-cvs&m=144190275908215&w=2) Looks like OpenBSD has taken the plunge and enabled GPT by default now Ken Westerback does us the honors, by removing the kernel option for GPT Users on -CURRENT should give this a whirl, and of course report issues back upstream Credit to Jona for writing in about this one *** DISCUSSION: Are reproducible builds worth-while? (http://www.tedunangst.com/flak/post/reproducible-builds-are-a-waste-of-time) In this weeks article / rant, Ted takes on the notion of reproducible builds being the end-all be-all for security. What about compiler backdoors? This does not prevent shellshock, or other bugs in the code itself Personally, I.m all in favor, another .Trust but verify. mechanism of the distributed binaries, plus it makes it handy to do source builds and not end up with various checksum changes where no code actually changed. *** Feedback/Questions David writes in (http://slexy.org/view/s20Q7XjxNH) Possnfiffer writes in (http://slexy.org/view/s2QtE6XzJK) Daniel writes in (http://slexy.org/view/s20uloOljw) ***
This time on the show, we'll be talking with Ed Schouten about CloudABI. It's a new application binary interface with a strong focus on isolation and restricted capabilities. As always, all this week's BSD news and answers to your emails, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines FreeBSD quarterly status report (https://www.freebsd.org/news/status/report-2015-01-2015-03.html) The FreeBSD team has posted a report of the activities that went on between January and March of this year As usual, it's broken down into separate reports from the various teams in the project (ports, kernel, virtualization, etc) The ports team continuing battling the flood of PRs, closing quite a lot of them and boasting nearly 7,000 commits this quarter The core team and cluster admins dealt with the accidental deletion of the Bugzilla database, and are making plans for an improved backup strategy within the project going forward FreeBSD's future release support model was also finalized and published in February, which should be a big improvement for both users and the release team Some topics are still being discussed internally, mainly MFCing ZFS ARC responsiveness patches to the 10 branch and deciding whether to maintain or abandon C89 support in the kernel code Lots of activity is happening in bhyve, some of which we've covered recently (http://www.bsdnow.tv/episodes/2015_04_29-on_the_list), and a number of improvements were made this quarter Clang, LLVM and LLDB have been updated to the 3.6.0 branch in -CURRENT Work to get FreeBSD booting natively on the POWER8 CPU architecture is also still in progress, but it does boot in KVM for the time being The project to replace forth in the bootloader with lua is in its final stages, and can be used on x86 already ASLR work (http://www.bsdnow.tv/episodes/2014_08_27-reverse_takeover) is still being done by the HardenedBSD guys, and their next aim is position-independent executable The report also touches on multipath TCP support, the new automounter, opaque ifnet, pkgng updates, secureboot (which should be in 10.2-RELEASE), GNOME and KDE on FreeBSD, PCIe hotplugging, nested kernel support and more Also of note: work is going on to make ARM a Tier 1 platform in the upcoming 11.0-RELEASE (and support for more ARM boards is still being added, including ARM64) *** OpenBSD 5.7 released (http://www.openbsd.org/57.html) OpenBSD has formally released another new version, complete with the giant changelog we've come to expect In the hardware department, 5.7 features many driver improvements and fixes, as well as support for some new things: USB 3.0 controllers, newer Intel and Atheros wireless cards and some additional 10gbit NICs If you're using one of the Soekris boards, there's even a new driver (http://bodgitandscarper.co.uk/openbsd/further-soekris-net6501-improvements-for-openbsd/) to manipulate the GPIO and LEDs on them - this has some fun possibilities Some new security improvements include: SipHash (https://en.wikipedia.org/wiki/SipHash) being sprinkled in some areas to protect hashing functions, big W^X improvements (https://www.marc.info/?l=openbsd-tech&m=142120787308107&w=2) in the kernel space, static PIE (http://www.bsdnow.tv/episodes/2015_04_15-pie_in_the_sky) on all architectures, deterministic "random" functions being replaced (https://www.marc.info/?l=openbsd-tech&m=141807224826859&w=2) with strong randomness, and support for remote logging over TLS The entire source tree has also been audited to use reallocarray (http://lteo.net/blog/2014/10/28/reallocarray-in-openbsd-integer-overflow-detection-for-free/), which unintentionally saved (https://splone.com/blog/2015/3/11/integer-overflow-prevention-in-c) OpenBSD's libc from being vulnerable to earlier attacks (https://guidovranken.wordpress.com/2015/02/04/full-disclosure-heap-overflow-in-h-spencers-regex-library-on-32-bit-systems/) affecting other BSDs' implementations Being that it's OpenBSD, a number of things have also been removed from the base system: procfs, sendmail, SSLv3 support and loadable kernel modules are all gone now (not to mention the continuing massacre of dead code in LibreSSL) Some people seem to be surprised about the removal of loadable modules, but almost nothing utilized them in OpenBSD, so it was really just removing old code that no one used anymore - very different from FreeBSD or Linux in this regard, where kernel modules are used pretty heavily BIND and nginx have been taken out, so you'll need to either use the versions in ports or switch to Unbound and the in-base HTTP daemon Speaking of httpd, it's gotten a number of new (http://www.openbsd.org/papers/httpd-slides-asiabsdcon2015.pdf) features (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/httpd.conf.5), and has had time to grow and mature since its initial debut - if you've been considering trying it out, now would be a great time to do so This release also includes the latest OpenSSH (with stronger fingerprint types and host key rotation), OpenNTPD (with the HTTPS constraints feature), OpenSMTPD, LibreSSL and mandoc (http://www.bsdnow.tv/episodes/2014_11_12-a_mans_man) Check the errata page (http://www.openbsd.org/errata57.html) for any post-release fixes, and the upgrade guide (http://www.openbsd.org/faq/upgrade57.html) for specific instructions on updating from 5.6 Groundwork has also been laid for some major SMP scalability improvements - look forward to those in future releases There's a song and artwork (http://www.openbsd.org/lyrics.html#57) to go along with the release as always, and CDs should be arriving within a few days - we'll show some pictures next week Consider picking one up (https://www.openbsdstore.com) to support the project (and it's the only way to get puffy stickers) For those of you paying close attention, the banner image (http://www.openbsd.org/images/puffy57.gif) for this release just might remind you of a certain special episode (http://www.bsdnow.tv/episodes/2014_09_03-its_hammer_time) of BSD Now... *** Tor-BSD diversity project (https://torbsd.github.io/) We've talked about Tor on the show a few times, and specifically about getting more of the network on BSD (Linux has an overwhelming majority right now) A new initiative has started to do just that, called the Tor-BSD diversity project "Monocultures in nature are dangerous, as vulnerabilities are held in common across a broad spectrum. Diversity means single vulnerabilities are less likely to harm the entire ecosystem. [...] A single kernel vulnerability in GNU/Linux that impacting Tor relays could be devastating. We want to see a stronger Tor network, and we believe one critical ingredient for that is operating system diversity." In addition to encouraging people to put up more relays, they're also continuing work on porting the Tor Browser Bundle to BSD, so more desktop users can have easy access to online privacy There's an additional progress report (http://trac.haqistan.net/blog/tor-browser-ports-progress) for that part specifically, and it looks like most of the work is done now Engaging the broader BSD community about Tor and fixing up the official documentation are also both on their todo list If you've been considering running a node to help out, there's always our handy tutorial (http://www.bsdnow.tv/tutorials/tor) on getting set up *** PC-BSD 10.1.2-RC1 released (http://blog.pcbsd.org/2015/05/pc-bsd-10-1-2-rc1-now-available/) If you want a sneak peek at the upcoming PC-BSD 10.1.2, the first release candidate is now available to grab This quarterly update includes a number of new features, improvements and even some additional utilities PersonaCrypt is one of them - it's a new tool for easily migrating encrypted home directories between systems A new "stealth mode" option allows for a one-time login, using a blank home directory that gets wiped after use Similarly, a new "Tor mode" allows for easy tunneling of all your traffic through the Tor network IPFW is now the default firewall, offering improved VIMAGE capabilities The life preserver backup tool now allows for bare-metal restores via the install CD ISC's NTP daemon has been replaced with OpenNTPD (http://www.bsdnow.tv/episodes/2015_02_11-time_for_a_change), and OpenSSL has been replaced with LibreSSL (http://www.bsdnow.tv/episodes/2015_03_25-ssl_in_the_wild) It also includes the latest Lumina (http://www.bsdnow.tv/episodes/2014_09_10-luminary_environment) desktop, and there's another post dedicated to that (http://blog.pcbsd.org/2015/05/pc-bsd-10-1-2-rc1-lumina-desktop-0-8-4-released/) Binary packages have also been updated to fresh versions from the ports tree More details, including upgrade instructions, can be found in the linked blog post *** Interview - Ed Schouten - ed@freebsd.org (mailto:ed@freebsd.org) / @edschouten (https://twitter.com/edschouten) CloudABI (https://www.bsdcan.org/2015/schedule/track/Security/524.en.html) News Roundup Open Household Router Contraption (http://code.saghul.net/index.php/2015/05/01/announcing-the-open-household-router-contraption/) This article introduces OpenHRC, the "Open Household Router Contraption" In short, it's a set of bootstrapping scripts to turn a vanilla OpenBSD install into a feature-rich gateway device It also makes use of Ansible playbooks for configuration, allowing for a more "mass deployment" type of setup Everything is configured via a simple text file, and you end up with a local NTP server, DHCP server, firewall (obviously) and local caching DNS resolver - it even does DNSSEC validation All the code is open source and on Github (https://github.com/ioc32/openhrc), so you can read through what's actually being changed and put in place There's also a video guide (https://www.youtube.com/watch?v=LZeKDM5jc90) to the entire process, if you're more of a visual person *** OPNsense 15.1.10 released (https://forum.opnsense.org/index.php?topic=365.0) Speaking of BSD routers, if you're looking for a "prebuilt and ready to go" option, OPNsense has just released a new version 15.1.10 drops some of the legacy patches they inherited from pfSense, aiming to stay closer to the mainline FreeBSD source code Going along with this theme, they've redone how they do ports, and are now kept totally in sync with the regular ports tree Their binary packages are now signed using the fingerprint-style method, various GUI menus have been rewritten and a number of other bugs were fixed NanoBSD-based images are also available now, so you can try it out on hardware with constrained resources as well Version 15.1.10.1 (https://twitter.com/opnsense/status/596009164746432512) was released shortly thereafter, including a hotfix for VLANs *** IBM Workpad Z50 and NetBSD (https://www.ibm.com/developerworks/community/blogs/hpcgoulash/entry/ibm_workpad_z50_netbsd_an_interesting_combination1?lang=en) Before the infamous netbook fad came and went, IBM had a handheld PDA device that looked pretty much the same Back in 1999, they released the Workpad Z50 (http://www.hpcfactor.com/reviews/hardware/ibm/workpad-z50/) with Windows CE, sporting a 131MHz MIPS CPU, 16MB of RAM and a 640x480 display You can probably tell where this is going... the article is about installing NetBSD it "What prevents me from taking my pristine Workpad z50 to the local electronics recycling facility is NetBSD. With a little effort it is possible to install recent versions of NetBSD on the Workpad z50 and even have XWindows running" The author got pkgsrc up and running on it too, and cleverly used distcc to offload the compiling jobs to something a bit more modern He's also got a couple (https://www.youtube.com/watch?v=hSLVnSZKB9I) videos (https://www.youtube.com/watch?v=mIA-NWEHLM4) of the bootup process and running Xorg (neither of which we'd call "speedy" by any stretch of the imagination) *** FreeBSD from the trenches (http://freebsdfoundation.blogspot.com/2015/04/from-trenches-tips-tricks-edition.html) The FreeBSD foundation has a new blog post up in their "from the trenches" series, detailing FreeBSD in some real-world use cases In this installment, Glen Barber talks about how he sets up all his laptops with ZFS and GELI While the installer allows for an automatic ZFS layout, Glen notes that it's not a one-size-fits-all thing, and goes through doing everything manually Each command is explained, and he walks you through the process of doing an encrypted installation (http://www.bsdnow.tv/tutorials/fde) on your root zpool *** Broadwell in DragonFly (http://lists.dragonflybsd.org/pipermail/users/2015-May/207671.html) DragonFlyBSD has officially won the race to get an Intel Broadwell graphics driver Their i915 driver has been brought up to speed with Linux 3.14's, adding not only Broadwell support, but many other bugfixes for other cards too It's planned for commit to the main tree very soon, but you can test it out with a git branch for the time being *** Feedback/Questions Bostjan writes in (http://slexy.org/view/s216QQcHyX) Hunter writes in (http://slexy.org/view/s21hGSk3c0) Hrishi writes in (http://slexy.org/view/s20JwPw9Je) Clint writes in (http://slexy.org/view/s2x1GYr7y6) Sergei writes in (http://slexy.org/view/s2swXxr2PX) *** Mailing List Gold How did you guess (https://lists.freebsd.org/pipermail/freebsd-advocacy/2015-May/004541.html) ***
Coming up this week on the show, we'll be talking to Kamila Součková, a Google intern. She's been working on the FreeBSD pager daemon, and also tells us about her initial experiences trying out BSD and going to a conference. As always, all the week's news and answers to your emails, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines Major changes coming in PCBSD 11 (http://blog.pcbsd.org/2015/04/huge-announcement-for-pc-bsd/) The PCBSD team has announced that version 11.0 will have some more pretty big changes (as they've been known to do lately with NTP daemons and firewalls) Switching from PF to IPFW provided some benefits for VIMAGE, but the syntax was just too complicated for regular everyday users To solve this, they've ported over Linux's iptables, giving users a much more straightforward configuration (http://dpaste.com/2F1KM6T.txt) While ZFS has served them well as the default filesystem for a while, Kris decided that Btrfs would be a better choice going forward Since the FreeBSD kernel doesn't support it natively, all filesystem calls will be through FUSE from now on - performance is Good Enough People often complain about PCBSD's huge ISO download, so, to save space, the default email client will be switched to mutt, and KDE will be replaced with DWM as the default window manager To reconfigure it, or make any appearance changes, users just need to edit a simple C header file and recompile - easy peasy As we've mentioned on the show, PCBSD has been promoting safe backup solutions for a long time with its "life preserver" utility, making it simple to manage multiple snapshots too To test if people have been listening to this advice, Kris recently activated the backdoor he put in life preserver that deletes all the users' files - hope you had that stuff backed up *** NetBSD and FreeBSD join forces (http://www.freebsddiary.org/fretbsd.php) The BSD community has been running into one of the same problems Linux has lately: we just have too many different BSDs to choose from What's more, none of them have any specific areas they focus on or anything like that (they're all basically the same) That situation is about to improve somewhat, as FreeBSD and NetBSD have just merged codebases... say hello to FretBSD Within a week, all mailing lists and webservers for the legacy NetBSD and FreeBSD projects will be terminated - the mailing list for the new combined project will be hosted from the United Nations datacenter on a Microsoft Exchange server As UN monitors will be moderating the mailing lists to prevent disagreements and divisive arguments before they begin, this system is expected to be adequate for the load With FretBSD, your toaster can now run ZFS, so you'll never need to worry about the bread becoming silently corrupted again *** Puffy in the cloud (http://homing-on-code.blogspot.com/2015/03/puffy-in-cloud.html) If you've ever wanted to set up a backup server, especially for family members or someone who's not as technology-savvy, you've probably realized there are a lot of options This post explores the option of setting up your own Dropbox-like service with Owncloud and PostgreSQL, running atop the new OpenBSD http daemon Doing it this way with your own setup, you can control all the security aspects - disk encryption, firewall rules, who can access what and from where, etc He also mentions our pf tutorial (http://www.bsdnow.tv/tutorials/pf) being helpful in blocking script kiddies from hammering the box Be sure to encourage your less-technical friends to always back up their important data *** NetBSD at AsiaBSDCon (https://blog.netbsd.org/tnf/entry/asiabsdcon_2015) Some NetBSD developers have put together a report of what they did at the most recent event in Tokyo It includes a wrap-up of the event, as well as a list of presentations (https://www.netbsd.org/gallery/presentations/#asiabsdcon2015) that NetBSD developers gave Have you ever wanted even more pictures of NetBSD running on lots of devices? There's a never-ending supply, apparently At the BSD research booth of AsiaBSDCon, there were a large number of machines on display, and someone has finally uploaded pictures of all of them (http://www.ki.nu/~makoto/p15/20150315/) There's also a video (https://www.youtube.com/watch?v=K1y9cdmLFjw) of an OMRON LUNA-II running the luna68k port *** Interview - Kamila Součková - kamila@ksp.sk (mailto:kamila@ksp.sk) / @anotherkamila (https://twitter.com/anotherkamila) BSD conferences, Google Summer of Code, various topics News Roundup FreeBSD foundation March update (https://www.freebsdfoundation.org/press/2015marchupdate.pdf) The FreeBSD foundation has published their March update for fundraising and sponsored projects In the document, you'll find information about upcoming ARMv8 enhancements, some event recaps and a Google Summer of Code status update They also mention our interview with the foundation president (http://www.bsdnow.tv/episodes/2015_03_11-the_pcbsd_tour_ii) - be sure to check it out if you haven't *** Inside OpenBSD's new httpd (http://sdtimes.com/inside-openbsds-new-httpd-web-server/) BSD news continues to dominate mainstream tech news sites… well not really, but they talk about it once in a while The SD Times is featuring an article about OpenBSD's in-house HTTP server, after seeing Reyk's AsiaBSDCon presentation (http://www.openbsd.org/papers/httpd-slides-asiabsdcon2015.pdf) about it (which he's giving at BSDCan this year, too) In this article, they talk about the rapid transition of webservers in the base system - apache being replaced with nginx, only to be replaced with httpd shortly thereafter Since the new daemon has had almost a full release cycle to grow, new features and fixes have been pouring in The post also highlights some of the security features: everything runs in a chroot with privsep by default, and it also leverages strong TLS 1.2 defaults (including Perfect Forward Secrecy) *** Using poudriere without OpenSSL (http://bsdxbsdx.blogspot.com/2015/04/build-packages-in-poudriere-without.html) Last week we talked about (http://www.bsdnow.tv/episodes/2015_03_25-ssl_in_the_wild) using LibreSSL in FreeBSD for all your ports One of the problems that was mentioned is that some ports are configured improperly, and end up linking against the OpenSSL in the base system even when you tell them not to This blog post shows how to completely strip OpenSSL out of the poudriere (http://www.bsdnow.tv/tutorials/poudriere) build jails, something that's a lot more difficult than you'd think If you're a port maintainer, pay close attention to this post, and get your ports fixed to adhere to the make.conf options properly *** HAMMER and GPT in OpenBSD (https://www.marc.info/?l=openbsd-tech&m=142755452428573&w=2) Someone, presumably a Google Summer of Code student, wrote in to the lists about his HAMMER FS (http://www.bsdnow.tv/tutorials/hammer) porting proposal He outlined the entire process and estimated timetable, including what would be supported and which aspects were beyond the scope of his work (like the clustering stuff) There's no word yet on if it will be accepted, but it's an interesting idea to explore, especially when you consider that HAMMER really only has one developer In more disk-related news, Ken Westerback (http://www.bsdnow.tv/episodes/2015_02_25-from_the_foundation_2) has been committing quite a lot of GPT-related fixes (https://www.marc.info/?l=openbsd-cvs&w=2&r=1&s=gpt&q=b) recently Full GPT support will most likely be finished before 5.8, but anything involving HAMMER FS is still anyone's guess *** Feedback/Questions Morgan writes in (http://slexy.org/view/s20e30p4qf) Dustin writes in (http://slexy.org/view/s20clKByMP) Stan writes in (http://slexy.org/view/s20aBlmaT5) Mica writes in (http://slexy.org/view/s2ufFrZY9y) *** Mailing List Gold Developers in freefall (https://lists.freebsd.org/pipermail/freebsd-current/2015-April/055281.html) Xorg thieves pt. 1 (https://www.marc.info/?l=openbsd-cvs&m=142786808725483&w=4) Xorg thieves pt. 2 (https://www.marc.info/?l=openbsd-cvs&m=142790740405547&w=4) ***
This time on the show, we've got an interview with Kristaps Džonsons, the creator of mandoc. He tells us how the project got started and what its current status is across the various BSDs. We also have a mini-tutorial on using PF to throttle bandwidth. This week's news, answers to your emails and even some cheesy mailing list gold, coming up on BSD Now - the place to B.. SD. This episode was brought to you by Headlines Updates to FreeBSD's random(4) (https://svnweb.freebsd.org/base?view=revision&revision=273872) FreeBSD's random device, which presents itself as "/dev/random" to users (https://news.ycombinator.com/item?id=8550457), has gotten a fairly major overhaul in -CURRENT The CSPRNG (cryptographically secure pseudo-random number generator) algorithm, Yarrow, now has a new alternative called Fortuna Yarrow is still the default for now, but Fortuna can be used with a kernel option (and will likely be the new default in 11.0-RELEASE) Pluggable modules can now be written to add more sources of entropy These changes are expected to make it in 11.0-RELEASE, but there hasn't been any mention of MFCing them to 10 or 9 *** OpenBSD Tor relays and network diversity (https://lists.torproject.org/pipermail/tor-relays/2014-November/005661.html) We've talked about getting more BSD-based Tor nodes (http://lists.nycbug.org/mailman/listinfo/tor-bsd) a few times in previous episodes The "tor-relays" mailing list has had some recent discussion about increasing diversity in the Tor network, specifically by adding more OpenBSD nodes With the security features and attention to detail, it makes for an excellent dedicated Tor box More and more adversaries are attacking Tor nodes, so having something that can withstand that will help the greater network at large A few users are even saying they'll convert their Linux nodes to OpenBSD to help out Check the archive for the full conversation, and maybe run a node yourself (http://www.bsdnow.tv/tutorials/tor) on any of the BSDs The Tor wiki page on OpenBSD is pretty out of date (https://lists.torproject.org/pipermail/tor-dev/2014-November/007715.html) (nine years old!?) and uses the old pf syntax, maybe one of our listeners can modernize it *** SSP now default for FreeBSD ports (https://lists.freebsd.org/pipermail/freebsd-ports/2014-November/096344.html) SSP, or Stack Smashing Protection (https://en.wikipedia.org/wiki/Buffer_overflow_protection), is an additional layer of protection against buffer overflows that the compiler can give to the binaries it produces It's now enabled by default in FreeBSD's ports tree, and the pkgng packages will have it as well - but only for amd64 (all supported releases) and i386 (10.0-RELEASE or newer) This will only apply to regular ports and binary packages, not the quarterly branch that only receives security updates If you were using the temporary "new Xorg" or SSP package repositories instead of the default ones, you need to switch back over NetBSD made this the default on i386 and amd64 two years ago (https://www.netbsd.org/releases/formal-6/NetBSD-6.0.html) and OpenBSD made this the default on all architectures twelve years ago (https://www.marc.info/?l=openbsd-cvs&m=103881967909595&w=2) Next time you rebuild your ports, things should be automatically hardened without any extra steps or configuration needed *** Building an OpenBSD firewall and router (https://www.reddit.com/r/BSD/comments/2ld0yw/building_an_openbsd_firewall_and_router/) While we've discussed the software and configuration of an OpenBSD router, this Reddit thread focuses more on the hardware side The OP lists some of his potential choices, but was originally looking for something a bit cheaper than a Soekris Most agree that, if it's for a business especially, it's worth the extra money to go with something that's well known in the BSD community They also list a few other popular alternatives: ALIX or the APU series from PC Engines, some Supermicro boards, etc. Through the comments, we also find out that QuakeCon runs OpenBSD on their network Hopefully most of our listeners are running some kind of BSD as their gateway - try it out (http://www.bsdnow.tv/tutorials/openbsd-router) if you haven't already *** Interview - Kristaps Džonsons - kristaps@bsd.lv (mailto:kristaps@bsd.lv) Mandoc, historical man pages, various topics Tutorial Throttling bandwidth with PF (http://www.bsdnow.tv/tutorials/openbsd-router#queues) News Roundup NetBSD at Kansai Open Forum 2014 (https://mail-index.netbsd.org/netbsd-advocacy/2014/11/08/msg000672.html) Japanese NetBSD users invade yet another conference, demonstrating that they can and will install NetBSD on everything From a Raspberry Pi to SHARP Netwalkers to various luna68k devices, they had it all As always, you can find lots of pictures in the trip report *** Getting to know your portmgr lurkers (http://blogs.freebsdish.org/portmgr/2014/11/04/getting-to-know-your-portmgr-lurker-ak/) The lovable "getting to know your portmgr" series makes its triumphant return This time around, they interview Alex, one of the portmgr lurkers that joined just this month "How would you describe yourself?" "Too lazy." Another post (http://blogs.freebsdish.org/portmgr/2014/11/08/getting-to-know-your-portmgr-lurker-ehaupt/) includes a short interview with Emanuel, another new lurker We discussed the portmgr lurkers initiative with Steve Wills a while back (http://www.bsdnow.tv/episodes/2014_10_01-the_daemons_apprentice) *** NetBSD's ARM port gets SMP (https://blog.netbsd.org/tnf/entry/working_arm_multiprocessor_support) The ARM port of NetBSD now has SMP support, allowing more than one CPU to be used This blog post on the website has a list of supported boards: Banana Pi, Cubieboard 2, Cubietruck, Merrii Hummingbird A31, CUBOX-I and NITROGEN6X NetBSD's release team is working on getting these changes into the 7 branch before 7.0 is released There are also a few nice pictures in the article *** A high performance mid-range NAS (http://pivotallabs.com/high-performing-mid-range-nas-server-part-2-performance-tuning-iscsi/) This blog post is about FreeNAS and optimizing iSCSI performance It talks about using mid-range hardware with FreeNAS and different tunables you can change to affect performance There are some nice graphs and lots of detail if you're interested in tweaking some of your own settings They conclude "there is no optimal configuration; rather, FreeNAS can be configured to suit a particular workload" *** Feedback/Questions Heto writes in (http://slexy.org/view/s2xGCUj8mC) Brad writes in (http://slexy.org/view/s2SJ8xppDJ) Tyler writes in (http://slexy.org/view/s20Ktl6BMk) Tim writes in (http://slexy.org/view/s2AsrxU0ZQ) Brad writes in (http://slexy.org/view/s21yn0xLv2) *** Mailing List Gold Suspicious contributions (https://www.marc.info/?t=141379917200003&r=1&w=2) La puissance du fromage (https://www.marc.info/?l=openbsd-cvs&m=141538800019451&w=2) Nothing unusual here (https://mail-index.netbsd.org/tech-ports/2002/07/05/0000.html) ***
This week on the show we'll be talking with Hiroki Sato about the status of BSD in Japan. We also get to hear about how he got on the core team, and we just might find out why NetBSD is so popular over there! Answers to all your emails, the latest news, and even a brand new segment, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines BSD talks at XDC 2014 (https://www.youtube.com/channel/UCXlH5v1PkEhjzLFTUTm_U7g/videos) This year's Xorg conference featured a few BSD-related talks Matthieu Herrb, Status of the OpenBSD graphics stack (https://www.youtube.com/watch?v=KopgD4nTtnA) Matthieu's talk details what's been done recently in Xenocara the OpenBSD kernel for graphics (slides here (http://www.openbsd.org/papers/xdc2014-xenocara.pdf)) Jean-Sébastien Pédron, The status of the graphics stack on FreeBSD (https://www.youtube.com/watch?v=POmxFleN3Bc) His presentation gives a history of major changes and outlines the current overall status of graphics in FreeBSD (slides here (http://www.x.org/wiki/Events/XDC2014/XDC2014PedronFreeBSD/XDC-2014_FreeBSD.pdf)) Francois Tigeot, Porting DRM/KMS drivers to DragonFlyBSD (https://www.youtube.com/watch?v=NdM7_yPGFDk) Francois' talk tells the story of how he ported some of the DRM and KMS kernel drivers to DragonFly (slides here (http://www.x.org/wiki/Events/XDC2014/XDC2014TigeotDragonFlyBSD/XDC-2014_Porting_kms_drivers_to_DragonFly.pdf)) *** FreeBSD Quarterly Status Report (https://www.freebsd.org/news/status/report-2014-07-2014-09.html) The FreeBSD project has a report of their activities between July and September of this year Lots of ARM work has been done, and a goal for 11.0 is tier one support for the platform The release includes reports from the cluster admin team, release team, ports team, core team and much more, but we've already covered most of the items on the show If you're interested in seeing what the FreeBSD community has been up to lately, check the full report - it's huge *** Monitoring pfSense logs using ELK (http://elijahpaul.co.uk/monitoring-pfsense-2-1-logs-using-elk-logstash-kibana-elasticsearch/) If you're one of those people who loves the cool graphs and charts that pfSense can produce, this is the post for you ELK (ElasticSearch, Logstash, Kibana) is a group of tools that let you collect, store, search and (most importantly) visualize logs It works with lots of different things that output logs and can be sent to one central server for displaying This post shows you how to set up pfSense to do remote logging to ELK and get some pretty awesome graphs *** Some updates to IPFW (https://svnweb.freebsd.org/base?view=revision&revision=272840) Even though PF gets a lot of attention, a lot of FreeBSD people still love IPFW While mostly a dormant section of the source tree, some updates were recently committed to -CURRENT The commit lists the user-visible changes, performance changes, ABI changes and internal changes It should be merged back to -STABLE after a month or so of testing, and will probably end up in 10.2-RELEASE Also check this blog post (http://blog.cochard.me/2014/10/ipfw-improvement-on-freebsd-current.html) for some more information and fancy graphs *** Interview - Hiroki Sato (佐藤広生) - hrs@freebsd.org (mailto:hrs@freebsd.org) / @hiroki_sato (https://twitter.com/hiroki_sato) BSD in Japan, technology conferences, various topics News Roundup pfSense on Hyper-V (https://virtual-ops.de/?p=600) In case you didn't know, the latest pfSense snapshots support running on Hyper-V Unfortunately, the current stable release is based on an old, unsupported FreeBSD 8.x base, so you have to use the snapshots for now The author of the post tells about his experience running pfSense and gives lots of links to read if you're interested in doing the same He also praises pfSense above other Linux-based solutions for its IPv6 support and high quality code *** OpenBSD as a daily driver (https://www.reddit.com/r/openbsd/comments/2isz24/openbsd_as_a_daily_driver/) A curious Reddit user posts to ask the community about using OpenBSD as an everyday desktop OS The overall consensus is that it works great for that, stays out of your way and is quite reliable Caveats would include there being no Adobe Flash support (though others consider this a blessing..) and it requiring a more hands-on approach to updating If you're considering running OpenBSD as a "daily driver," check all the comments for more information and tips *** Getting PF log statistics (https://secure.ciscodude.net/2014/10/09/firewall-log-stats/) The author of this post runs an OpenBSD box in front of all his VMs at his colocation, and details his experiences with firewall logs He usually investigates any IPs of interest with whois, nslookup, etc. - but this gets repetitive quickly, so.. He sets out to find the best way to gather firewall log statistics After coming across a perl script (http://www.pantz.org/software/pf/pantzpfblockstats.html) to do this, he edited it a bit and is now a happy, lazy admin once again You can try out his updated PF script here (https://github.com/tbaschak/Pantz-PFlog-Stats) *** FlashRD 1.7 released (http://www.nmedia.net/flashrd/) In case anyone's not familiar, flashrd is a tool to create OpenBSD images for embedded hardware devices, executing from a virtualized environment This new version is based on (the currently unreleased) OpenBSD 5.6, and automatically adapts to the number of CPUs you have for building It also includes fixes for 4k drives and lots of various other improvements If you're interested in learning more, take a look at some of the slides and audio from the main developer on the website *** Feedback/Questions Antonio writes in (http://slexy.org/view/s20XvSa4h0) Don writes in (http://slexy.org/view/s20lGUXW3d) Andriy writes in (http://slexy.org/view/s2al5DFIO7) Richard writes in (http://slexy.org/view/s203QoFuWs) Robert writes in (http://slexy.org/view/s29WIplL6k) *** Mailing List Gold Subtle trolling (https://marc.info/?l=openbsd-cvs&m=141271076115386&w=2) Old bugs with old fixes (https://marc.info/?l=openbsd-cvs&m=141275713329601&w=2) A pig reinstall (https://lists.freebsd.org/pipermail/freebsd-ports/2014-October/095906.html) Strange DOS-like environment (https://lists.freebsd.org/pipermail/freebsd-doc/2014-October/024408.html) ***
We're back from EuroBSDCon! This week we'll be talking with Steve Wills about mentoring new BSD developers. If you've ever considered becoming a developer or helping out, it's actually really easy to get involved. We've also got all the BSD news for the week and answers to your emails, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines NetBSD at Hiroshima Open Source Conference (http://mail-index.netbsd.org/netbsd-advocacy/2014/09/26/msg000669.html) NetBSD developers are hard at work, putting NetBSD on everything they can find At a technology conference in Hiroshima, some developers brought their exotic machines to put on display As usual, there are lots of pictures and a nice report from the conference *** FreeBSD's Linux emulation overhaul (https://svnweb.freebsd.org/ports?limit_changes=0&view=revision&revision=368845) For a long time, FreeBSD's emulation layer has been based on an ancient Fedora 10 system If you've ever needed to install Adobe Flash on BSD, you'll be stuck with all this extra junk With some recent work, that's been replaced with a recent CentOS release This opens up the door for newer versions of Skype to run on FreeBSD, and maybe even Steam someday *** pfSense 2.2-BETA (https://blog.pfsense.org/?p=1449) Big changes are coming in pfSense land, with their upcoming 2.2 release We talked to the developer (http://www.bsdnow.tv/episodes/2014_02_19-a_sixth_pfsense) a while back about future plans, and now they're finally out there The 2.2 branch will be based on FreeBSD 10-STABLE (instead of 8.3) and include lots of performance fixes It also includes some security updates, lots of package changes and updates and much more You can check the full list of changes (https://doc.pfsense.org/index.php/2.2_New_Features_and_Changes) on their wiki *** NetBSD on the Raspberry Pi (http://www.cambus.net/netbsd-on-the-raspberry-pi/) This article shows how you can install NetBSD on the ever-so-popular Raspberry Pi As of right now, you'll need to use a -CURRENT snapshot to do it It also shows how to grow the filesystem to fill up an SD card, some pkgsrc basics and how to get some initial things set up Can anyone find something that you can't install NetBSD on? *** Interview - Steve Wills - swills@freebsd.org (mailto:swills@freebsd.org) / @swills (https://twitter.com/swills) Mentoring new BSD developers News Roundup MidnightBSD 0.5 released (http://www.midnightbsd.org/notes/) We don't hear a whole lot about MidnightBSD, but they've just released version 0.5 It's got a round of the latest FreeBSD security patches, driver updates and various small things Maybe one of their developers could come on the show sometime and tell us more about the project *** BSD Router Project 1.52 released (http://sourceforge.net/projects/bsdrp/files/BSD_Router_Project/1.52/) The newest update for the BSD Router Project is out This version is based on a snapshot of 10-STABLE that's very close to 10.1-RELEASE It's mostly a bugfix release, but includes some small changes and package updates *** Configuring a DragonFly BSD desktop (http://www.dragonflydigest.com/2014/09/19/14751.html) We've done tutorials on how to set up a FreeBSD or OpenBSD desktop, but maybe you're more interested in DragonFly In this post from Justin Sherrill, you'll learn some of the steps to do just that He pulled out an old desktop machine, gave it a try and seems to be pleased with the results It includes a few Xorg tips, and there are some comments about the possibility of making a GUI DragonFly installer *** Building a mini-ITX pfSense box (http://pakitong.blogspot.com/2014/09/jetway-j7f2-four-lan-mini-itx-for.html) Another week, another pfSense firewall build post This time, the author is installing to a Jetway J7F2, a mini-ITX device with four LAN ports He used to be a m0n0wall guy, but wanted to give the more modern pfSense a try Lots of great pictures of the hardware, which we always love *** Feedback/Questions Damian writes in (http://slexy.org/view/s2184TfOKD) Jan writes in (http://slexy.org/view/s20uAdTwLv) Dale writes in (http://slexy.org/view/s20es52IgZ) Joe writes in (http://slexy.org/view/s2mjulpac6) Bostjan writes in (http://slexy.org/view/s2BvNC8cgi) ***
It's our 50th episode, and we're going to show you how to protect your internet traffic with a BSD-based VPN. We'll also be talking to Robert Watson, of the FreeBSD core team, about security research, exploit mitigation and a whole lot more. The latest news and answers to all of your emails, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines MeetBSD 2014 is approaching (http://www.ixsystems.com/whats-new/ixsystems-to-host-meetbsd-california-2014-at-western-digital-in-san-jose/) The MeetBSD conference is coming up, and will be held on November 1st and 2nd in San Jose, California MeetBSD has an "unconference" format, which means there will be both planned talks and community events All the extra details will be on their site (https://www.meetbsd.com/) soon It also has hotels and various other bits of useful information - hopefully with more info on the talks to come Of course, EuroBSDCon is coming up before then *** First experiences with OpenBSD (https://www.azabani.com/2014/08/09/first-experiences-with-openbsd.html) A new blog post that leads off with "tired of the sluggishness of Windows on my laptop and interested in experimenting with a Unix-like that I haven't tried before" The author read the famous "BSD for Linux users (http://www.over-yonder.net/~fullermd/rants/bsd4linux/01)" series (that most of us have surely seen) and decided to give BSD a try He details his different OS and distro history, concluding with how he "eventually became annoyed at the poor quality of Linux userland software" From there, it talks about how he used the OpenBSD USB image and got a fully-working system He especially liked the simplicity of OpenBSD's "hostname.if" system for network configuration Finally, he gets Xorg working and imports all his usual configuration files - seems to be a happy new user! *** NetBSD rump kernels on bare metal (and Kansai OSC report) (https://blog.netbsd.org/tnf/entry/an_internet_ready_os_from) When you're developing a new OS or a very specialized custom solution, working drivers become one of the hardest things to get right However, NetBSD's rump kernels - a very unique concept - make this process a lot easier This blog post talks about the process of starting with just a rump kernel and expanding into an internet-ready system in just a week Also have a look back at episode 8 (http://www.bsdnow.tv/episodes/2013_10_23-a_brief_intorduction) for our interview about rump kernels and what exactly they do While on the topic of NetBSD, there were also a couple of very detailed reports (http://mail-index.netbsd.org/netbsd-advocacy/2014/08/09/msg000658.html) (with lots of pictures!) of the various NetBSD-themed booths at the 2014 Kansai Open Source Conference (http://d.hatena.ne.jp/mizuno-as/20140806/1407307913) that we wanted to highlight *** OpenSSL and LibreSSL updates (https://www.openssl.org/news/secadv_20140806.txt) OpenSSL pushed out a few new versions, fixing multiple vulnerabilities (nine to be precise!) Security concerns include leaking memory, possible denial of service, crashing clients, memory exhaustion, TLS downgrades and more LibreSSL released a new version (http://marc.info/?l=openbsd-tech&m=140752295222929&w=2) to address most of the vulnerabilities, but wasn't affected by some of them Whichever version of whatever SSL you use, make sure it's patched for these issues DragonFly and OpenBSD are patched as of the time of this recording but, even after a week, NetBSD and FreeBSD are not (outside of -CURRENT) *** Interview - Robert Watson - rwatson@freebsd.org (mailto:rwatson@freebsd.org) FreeBSD architecture, security research techniques, exploit mitigation Tutorial Protecting traffic with a BSD-based VPN (http://www.bsdnow.tv/tutorials/openvpn) News Roundup A FreeBSD-based CGit server (https://lechindianer.de/blog/2014/08/06/freebsd-cgit/) If you use git (like a certain host of this show) then you've probably considered setting up your own server This article takes you through the process of setting up a jailed git server, complete with a fancy web frontend It even shows you how to set up multiple repos with key-based user separation and other cool things The author of the post is also a listener of the show, thanks for sending it in! *** Backup devices for small businesses (http://www.smallbusinesscomputing.com/biztools/6-data-backup-devices-for-small-businesses.html) In this article, different methods of data storage and backup are compared After weighing the various options, the author comes to an obvious conclusion: FreeNAS is the answer He praises FreeNAS and the FreeNAS Mini for their tight integration, rock solid FreeBSD base and the great ZFS featureset that it offers It also goes over some of the hardware specifics in the FreeNAS Mini *** A new Xenocara interview (http://blog.bronevichok.ru/2014/08/06/testing-of-xorg.html) As a follow up to last week's OpenSMTPD interview, this Russian blog interviews Matthieu Herrb about Xenocara If you're not familiar with Xenocara, it's OpenBSD's version of Xorg with some custom patches In this interview, he discusses how large and complex the upstream X11 development is, how different components are worked on by different people, how they test code (including a new framework) and security auditing Matthieu is both a developer of upstream Xorg and an OpenBSD developer, so it's natural for him to do a lot of the maintainership work there *** Building a high performance FreeBSD samba server (https://not.burntout.org/blog/high_performance_samba_server_on_freebsd/) If you've got to PXE boot several hundred Windows boxes to upgrade from XP to 7, what's the best solution? FreeBSD, ZFS and Samba obviously! The master image and related files clock in at over 20GB, and will be accessed at the same time by all of those clients This article documents that process, highlighting some specific configuration tweaks to maximize performance (including NIC bonding) It doesn't even require the newest or best hardware with the right changes, pretty cool *** Feedback/Questions An interesting Reddit thread (http://www.reddit.com/r/BSD/comments/2ctlt4/switched_from_arch_linux_to_openbsd_reference/) (or two (http://www.reddit.com/r/BSD/comments/2dcig9/thinking_about_coming_to_bsd_from_arch)) PB writes in (http://slexy.org/view/s21t7L5bqO) Sean writes in (http://slexy.org/view/s20MFywDqZ) Steve writes in (http://slexy.org/view/s2Td6nq11J) Lachlan writes in (http://slexy.org/view/s215MlpJYV) Justin writes in (http://slexy.org/view/s2N4JKkoKt) ***
The long-awaited meetup is finally happening on today's show. We're going to be interviewing the original BSD podcaster, Will Backman, to discuss what he's been up to and what the future of BSD advocacy looks like. After that, we'll be showing you how to track (and even cross-compile!) the -CURRENT branch of NetBSD. We've got answers to user-submitted questions and the latest news, on BSD Now - the place to B.. SD. This episode was brought to you by Headlines FreeBSD and OpenBSD in GSOC2014 (https://wiki.freebsd.org/SummerOfCode2014) The Google Summer of Code is a way to encourage students to write code for open source projects and make some money Both FreeBSD and OpenBSD were accepted, and we'd love for anyone listening to check out their GSOC pages The FreeBSD wiki has a list of things that they'd be interested in someone helping out with OpenBSD's want list was also posted (http://www.openbsdfoundation.org/gsoc2014.html) DragonflyBSD and NetBSD were sadly not accepted this year *** Yes, you too can be an evil network overlord (http://bsdly.blogspot.com/2014/02/yes-you-too-can-be-evil-network.html) A new blog post about monitoring your network using only free tools OpenBSD is a great fit, and has all the stuff you need in the base system or via packages It talks about the pflow pseudo-interface, its capabilities and relation to NetFlow (also goes well with pf) There's also details about flowd and nfsen, more great tools to make network monitoring easy If you're listening, Peter... stop ignoring our emails and come on the show! We know you're watching! *** BSDMag's February issue is out (http://bsdmag.org/magazine/1858-openbsd-5-4-configure-openbsd-basic-services) The theme is "configuring basic services on OpenBSD 5.4" There's also an interview with Peter Hansteen (oh hey...) Topics also include locking down SSH, a GIMP lesson, user/group management, and... Linux and Solaris articles? Why?? *** Changes in bcrypt (http://marc.info/?l=openbsd-misc&m=139320023202696&w=2) Not specific to any OS, but the OpenBSD team is updating their bcrypt implementation There is a bug in bcrypt when hashing long passwords - other OSes need to update theirs too! (FreeBSD already has) "The length is stored in an unsigned char type, which will overflow and wrap at 256. Although we consider the existence of affected hashes very rare, in order to differentiate hashes generated before and after the fix, we are introducing a new minor 'b'." As long as you upgrade your OpenBSD system in order (without skipping versions) you should be ok going forward Lots of specifics in the email, check the full thing *** Interview - Will Backman - bitgeist@yahoo.com (mailto:bitgeist@yahoo.com) / @bsdtalk (https://twitter.com/bsdtalk) The BSDTalk podcast, BSD advocacy, various topics Tutorial Tracking and cross-compiling -CURRENT (NetBSD) (http://www.bsdnow.tv/tutorials/current-nbsd) News Roundup X11 no longer needs root (http://undeadly.org/cgi?action=article&sid=20140223112426) Xorg has long since required root privileges to run the main server With recent work (http://marc.info/?l=openbsd-cvs&;m=139245772023497&w=2) from the OpenBSD team, now everything (even KMS) can run as a regular user Now you can set the "machdep.allowaperture" sysctl to 0 and still use a GUI *** OpenSSH 6.6 CFT (https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-March/032259.html) Shortly after the huge 6.5 release, we get a routine bugfix update Test it out on as many systems as you can Check the mailing list for the full bug list *** Creating an OpenBSD USB drive (http://undeadly.org/cgi?action=article&sid=20140225072408) Since OpenBSD doesn't distribute any official USB images, here are some instructions on how to do it Step by step guide on how you can make your very own However, there's some recent emails (http://undeadly.org/cgi?action=article&sid=20140228231258) that suggest official USB images may be coming soon... oh wait (http://marc.info/?l=openbsd-cvs&m=139377587526463&w=2) *** PCBSD weekly digest (http://blog.pcbsd.org/2014/02/pc-bsd-weekly-feature-digest-19/) New PBI updates that allow separate ports from /usr/local You need to rebuild pbi-manager if you want to try it out Updates and changes to Life Preserver, App Cafe, PCDM *** Feedback/Questions espressowar writes in (http://slexy.org/view/s2JpJ5EaZp) Antonio writes in (http://slexy.org/view/s2QpPevJ3J) Christian writes in (http://slexy.org/view/s2EZLxDfWh) Adam writes in (http://slexy.org/view/s21gEBZbmG) Alex writes in (http://slexy.org/view/s2RnCO1p9c) ***
After a wildly successful debut episode, BSD Now is BACK to talk with Glen Barber from the FreeBSD Release team, show you how to build your own binary package repository and discuss the latest BSD news! Headlines 64bit time in OpenBSD (http://undeadly.org/cgi?action=article&sid=20130813072244) Many operating systems face an upcoming challenge, similar to (but more complicated than) Y2K: Y2038. All of the BSDs and most other operating systems track time by counting the seconds since Jan 1st, 1970. In 2038 this value will reach the maximum value of a signed 32 bit integer. Simply changing to a 64 bit counter may not be the best solution, because there may still be 32 bit systems in use for embedded applications Theo will be giving the keynote at EuroBSDCon on the subject, explaining how OpenBSD has implemented the solution ABI incompatibility. Updating to this kernel requires extra work or you won't be able to login: install a snapshot instead. Upgrading by source is for the insane only. (http://www.openbsd.org/faq/current.html#20130813) AESNI pipelining gets a speed boost (http://freshbsd.org/commit/freebsd/r255187) AES-NI is a new processor instruction available on modern Intel and AMD chips that provides hardware acceleration for AES encryption and decryption. This feature is especially useful for encrypted disks, because it removes most of the performance penalty traditionally associated with encryption The new commit has the instructions pipelined, so there is no latency between the instructions Uses SSE2 instructions for calculating XTS tweak factor for further increased performance GELI based disk encryption performance increased by 3x on capable CPUs Should affect PEFS and other AES backed encryption schemes as well Full disk encryption should be more or less transparent now *** OpenBSD 5.4 Preorders (http://openbsd.org/orders.html) Every 6 months there is a new OpenBSD version They include a fun song and nicely-packaged CD set The proceeds from sale of these products is the primary funding of the OpenBSD project The official ISOs will be uploaded on November 1st *** GCC no longer built by default on FreeBSD -CURRENT (https://svnweb.freebsd.org/base?view=revision&revision=255321) On platforms where clang is the default compiler, don't build gcc or libstdc++ GCC is still enabled on PC98, because the PC98 bootloader requires GCC to build While the base FreeBSD system has been built by clang for a long time, this change also covers the ports tree *** Patch to update Xorg and MESA on FreeBSD (http://lists.freebsd.org/pipermail/freebsd-x11/2013-September/013599.html) Updates xorg drivers Expected to be committed in about 2 weeks Adds option to use devd instead of HAL for X configuration Updates the MESA stack (9.1.6), libGL, DRI, etc Enables KMS for AMD/ATI cards Mesa 9.2 is available with xorg-dev, OpenBSD has also recently upgraded to Mesa 9.2 for their stable version of Xorg *** Interview - Glen Barber - gjb@freebsd.org (mailto:gjb@freebsd.org) / @evilgjb (https://twitter.com/evilgjb) FreeBSD Release Engineering Tutorial Making your own binary repository (http://www.bsdnow.tv/tutorials/poudriere) The Place to B...SD iXsystems hosts FreeBSD Anniversary party (http://www.ixsystems.com/resources/ix/news/ixsystems-to-once-again-host-freebsd-anniversary-celebration.html) Celebrating FreeBSD's 20th anniversary Saturday, November 2nd at the DNA Lounge in San Francisco Notable FreeBSD figures will contribute words of wisdom on the past, present, and future of FreeBSD *** News Roundup NetBSD gets basic support for the cubieboard 1 & 2 (http://mail-index.netbsd.org/source-changes/2013/09/04/msg047155.html) Very preliminary support for cubieboard 1 & 2 based on the Allwinner A10 & A20 SoCs Many drivers are "stubs with autoconf glue" Contributed by Matt Thomas *** Rayservers ditches Linux for BSD (http://rayservers.com/blog/the-freebsd-daemon-is-off-to-do-battle-in-the-name-of-christ) Used them all, Windows, Mac, OpenBSD, Linux Needed PF, ZFS, disk encryption, lots of networking features, better security In Linux, "The new cgroups based memory management ran out of memory - on a 256 GB RAM system whilst it was not using more than 40." BSD now protects the privacy of their email users *** HPN for OpenSSH 6.2 (https://lists.mindrot.org/pipermail/openssh-unix-dev/2013-August/031614.html) High Performance Networking (http://www.psc.edu/index.php/hpn-ssh) is an SSH patchset to improve transfer speeds by removing the fixed window size and take better advantage of TCP Maintained as a patchset separate from OpenSSH First integrated into FreeBSD base as of 9.0 Updated to support 6.2 (available in the ports tree as security/openssh-portable) The HPN patch set also includes threaded AES-CTR support to increase performance and take advantage of multiple CPU cores for encryption. In this latest patch, threaded AES-CTR now works in all situations (it failed in some specific situations previously). Expected performance increase is ~50% NONE cipher is now separate from the main patch set. The NONE cipher allows tools like scp and sftp to switch off the encryption for file transfers (when specifically told to do so) to keep encryption from bottlenecking performance and wasting CPU time *** Call for testing: OpenSSH-6.3 (https://lists.mindrot.org/pipermail/openssh-unix-dev/2013-July/031550.html) Mostly a bugfix release SFTP now supports resuming partially-downloaded or uploaded transfers More logging features Six weeks after the initial email, still no release. des@ is not pleased. *** pkgsrc gets signing support (http://mail-index.netbsd.org/pkgsrc-users/2013/08/30/msg018511.html) pkgsrc is used on NetBSD, DragonflyBSD and other OSes Comes from an EdgeBSD developer Uses GPG for signing package files Currently just a patch on github and in its infancy Provides a short howto *** FreeBSD vs. Linux: 10 points of superiority (https://forums.freebsd.org/showthread.php?t=41750) New FreeBSD user, ex-Linux user writes about his experience Mentions consistency, documentation, security, filesystems, updates, jails, community Really long post, definitely worth a read *** Feedback/Questions hoopla writes in (http://slexy.org/view/s21SpCcisW) Juergen writes in (http://slexy.org/view/s20vHY9qAK) Sam writes in (http://slexy.org/view/s23uf4vzfQ) Frank writes in (http://slexy.org/view/s2Y0qiXJan) ***
In this episode: Dann Washko's discussion of Linux in schools in Episode 182 of The Linux Link Tech Show; the Ohio Linux Fest; a discussion of the X Window System and its configuration file, xorg.conf; several listener emails, including a mention of the Intel drivers and firmware for the 3945 wireless cards, Ralink wireless cards, and Puppy Linux.
Overview In this edition, we get an update from openSUSE developer and community advocate Martin Lasarsch about what’s new in openSUSE 10.2. Time: 31:40 Size: 21.7 MB Segment Times openSUSE: 3:08-29:47 Links for this Episode: openSUSE Wiki Download openSUSE 10.2 Funny Little Men Behind the Curtain: With the news that ATI may soon release Xorg […]
© 2020-2025 Ivy Podcast Discovery LLC
