Recently, I was working on an update for the PAC files we use at work. Had a clever idea for making clients more resilient in the event of an individual proxy failing – just list all the proxies in the PAC file, and use a bit of MATH to spread the load. This initially failed, but not for any of the reasons you might expect…Continue reading “PAC Files and the Inconstant Constant”
While Windows Subsystem for Linux (WSL) isn’t perfect, it’s coming along nicely as a replacement for many of the Unix-y things I used to do with Cygwin. And since most of my server work involves Linux as opposed to generic *nix, it’s nice to have handy access to something that more closely resembles my work environment.
Just a few days ago, the Debian project announced “Buster,” the first major upgrade in a couple years. (If you want to be boring, it’s also “Debian 10.0”.) As of this writing, the Microsoft app store doesn’t have Buster ready-to-go. And even if it did, there’s not a super-clean way to migrate any custom work, home directories, etc. from an old Debian installation to a new one. So here, I throw caution to the wind and update my existing Debian WSL installation from “Stretch” (9.x) to Buster.Continue reading “Updating your WSL Debian Image to “Buster””
I wanted to tinker with the Red Hat Enterprise Linux 8 beta at work. Since it’s work, I’m technically not supposed to use the free-as-in-beer version of VMware Player, even though it seems like everyone does. And hey, my Windows laptop comes with Hyper-V, which should do the job just fine.
Hyper-V is a younger product, and it seems like it’s not as well-supported. In particular, if I’d spun up a RHEL 8 guest under VMware, I strongly suspect that changing the screen resolution wouldn’t be a problem at all. But Hyper-V only appears to present a single default resolution from its virtual frame buffer to the guest.
Anyway, if you go into the GUI settings on a RHEL 8 guest, I didn’t see any other resolutions available to me, just an odd “1152×864” default. And there’s no obvious way to change that, even though the guest video card is capable of more.
To change how the frame buffer is presented to the guest, you actually have to provide a kernel command-line option. You could probably do this at boot-time via the GRUB interface, but the lazy way to do it is just to use grubby to make the change permanent:
sudo grubby --update-kernel=ALL --args="video=hyperv_fb:1440x900"
You can of course enter any resolution you like. (If you like to full-screen your guests, you might want 1920×1080, or whatever matches your monitor.)
Since this is a kernel option, you can’t just logout and login again; you must reboot before you’ll be able to use the new resolution. And you still won’t be able to resize the guest screen dynamically; any time you want to change it, you’ll have to reboot the guest after. This seems like something that will probably get hammered out by the time RHEL 8 is released.
One of the jobs currently posted at Bandcamp is a “Senior Fraud/Risk Engineer”. To apply, you have to finish a small puzzle, to demonstrate your infosec basics. Note that if you have to read a blog post to figure it out, you almost certainly are not qualified for the job. (I’m not qualified for the job either, but I like puzzles.)
Spoilers abound, obviously…Continue reading “How to apply for a nerdy job at Bandcamp”
The Cisco Web Security Appliance (WSA) has a lot of options for scanning “content” (whatever that means, I think it’s a fancy way of saying Web pages) to make sure it doesn’t contain any malware. No viruses, no pop-up ad machines, things like that. And on the surface, that’s all well and good. Defense in depth, because you should also have some sort of anti-malware on your workstation too (as soon as you take your machine home with you for the evening, you’re probably no longer protected by the proxy).
Someone has to set the darn thing up, though. Continue reading “A Tale of Three Anti-Viruses”
I recently worked, briefly, for Automattic (the company that hosts this Web site, and approximately a zillion others, and whose founder created the WordPress software that powers roughly 1/3 of the whole Web). This is part of their hiring process — they believe the best way to see how a candidate would work with them, is to have this candidate actually work with them on a trial basis. Given the unique nature of their work environment (they’re a global, distributed company with no offices to speak of), this is not only possible, but essential.
Automattic has a company creed (like a mission statement but longer), and part of it is:
I will communicate as much as possible, because it’s the oxygen of a distributed company.
That sentence, more than anything else, made me think the whole project might work out. Regrettably, my experience was utterly unlike anything I might have hoped for.
While most of Automattic uses Slack, the team I worked with is a holdout and communicates primarily with IRC — think Slack, but ephemeral, if you’re not old enough to remember IRC (also, get off my lawn). Because of Automattic’s globally distributed nature, most of the folks on my team were unavailable when I was able to work on my trial project, probably asleep. (I could only work on things during my evenings and weekends; most of this team is a few hours ahead of me.)
The other mechanism this team used for communication is a WordPress blog (of course) using the P2 theme. Nothing wrong with this in and of itself, of course; I’ve used P2 for other projects before. It’s good for status updates and checkins, but not so good for a knowledge base or for documentation. When I wrote posts describing my progress, and asking for information I needed to proceed with my project, in general I was met with silence. Once, after a week, one team member provided partial answers to some of my questions, which was as good as I ever got.
I don’t know if this was a unique trait of this team, or if the “creed” is a bit of overblown puffery, but if they treat communication as oxygen my experience was nothing short of suffocating.