I don't understand why the backup option wasn't to boot the one customer whose traffic was killing the company, instead of losing several other clients and going out of business. Yes, try to fix things, and he succeeded, but it seems like he didn't even consider getting rid of the problem customer to save the company.
Should note that this is from (2011), guess it's not an issue as this is a testimonial which is timeless. Michael writes many *BSD flavored books, but my favorite book that every OpenSSH user should have is his "SSH Mastery" book.
There is also Michael's "Sudo Mastery" book, and like his "SSH Mastery" book, it's full of useful lessons for just about anyone working with UNIX-based systems, including Linux and MacOS 10+.
Earlier this month, Michael gave a talk based on the "Sudo Mastery" book, titled "Sudo: You're Doing it Wrong":
Love this war story. Partially because to a less dramatic extend, I solved a similar situation also with 'traffic shaping' using Linux a year ago. So that's why it resonates for me. I'm not an OpenBSD user but I do respect it's capabilities.
Can someone how traffic shaping reduces latency rather than simply lowering the amount of load required to cause significant latency? I understand that the aim here is to prevent the router from having to queue packets, but by doing this haven't we just shifted the queue and source at which packets are dropped from the router to the Linux box?
The problem is that the router does not drop packets (as soon as a proper traffic shaper does). It queues them up, megabytes at a time. Packets that do make it to their destination take longer and longer to get there (due to waiting in the queue).
Eventually most of the buffered packets are so late that they're considered missing/dropped, though they took bandwidth to send and caused other packets to wait behind them. Then TCP adjusts to a long series of lost packets by dropping the rate dramatically.
The feature he needed was an optional feature which did cost a lot of money and wasn't available right away so it was useless for this problem at hand as clients were threatening to leave the next day.
You almost never had to consult with a vendor, development team who wrote the stuff you're using, or otherwise 3rd party who supplied you with a piece of software or hardware you're using with your own software in those 20 years or was it in almost all cases a miserable experience? I agree paying a lot of money for simple additional features (the well known 'enterprise features') is in most cases unjustified, but support is IMHO something else.
It usually goes, identify problem, contact vendor, wait interminably, in the meantime find a fix or a workaround ourselves, get back in business, sometimes tell the vendor, sometimes not, depending. Vendor support almost never involves the guys who wrote the software, they're off in an ivory tower somewhere and would never deign to speak to a mere paying customer.
Oh yeah very recognizable (I'm a professional software dev now for over 20 years too ;)). It's indeed key to have the dev of the software used to do support as well, at least for some time. I try to do support for my own work as well to stay in touch with what customers have to deal with so I can improve it. Has worked well over the years even though it's not always the greatest work.
Better? Absolutely not. Cheaper? Definitely. In his story, however accurate, he didn't have the time to wait, or the money to spend, on a better firewall. OpenBSD has the advantage of being free, and instantly available.
Years ago I worked as a developer for a company that also owned a small ISP. The sysadmin for the ISP had quit and they didn't bother to replace him, as another guy could usually keep things running. Until a huge wave of spam hit and the mail server went unresponsive. Typical for that time, the mail server was sendmail with an unholy, gnarly config including SpamAssassin with an unholy, gnarly config. The guy handling sysadmin duties was out of his depth. He gave me access, showed me around the configs, and asked me to help. Sure, I could help. But not in any kind of acceptable time frame. So I went back to my desk and thought about it a bit.
A while before I had installed OpenBSD on an old box to play with. I recalled seeing something about a transparent bridge setup, so I got the idea of putting a transparent bridge with greylisting in front of the mail server. So I grabbed a slow cast off desktop, slapped an extra NIC in it, got it configured so I thought it would work, and put it in place. A few tweaks later and the load was off the mail server and it began responding to legitimate requests and clearing out its queue.
From idea to working solution took about 4 hours, including scrounging up parts, installing, and everything. I'm sure something similar could have been done with another OS, but what level of expertise would it have required? I was pretty much an OpenBSD newbie then, doing things I'd never even played with before, and that stuff just worked.
Michael W. Lucas has written many technical books, all useful and all with the same wry humor. His earlier books were published by No Starch Press. He has self-published more recent works at Tilted Windmill Press.
"If it didn’t work, I would either lay someone off or file for unemployment myself."" If I hadn’t already been stressed out, the prospect of choosing a minion to lay off would have done the trick. (Before any of those minions start to think I care about them personally: I work hard training minions, and swinging the Club of Correction makes my arms sore. Eventually. I don’t like to replace them.)"
You have a point. I used to work with/for a few of them, and sometimes the online persona was perhaps more aligned with their IRL personality than was good for them. But for the most part it was a way to vent frustration.
In my current workplace the joke is for the newcomers to be called "undervisors" (in contrast to shift supervisors).
I found it common to get called a "minion", "drone" or "padawan" while working in IT. No one usually gets offended (if someone does usually the nickname gets dropped immediately in his/her presence).
