ArchLinux and I aren’t the best of friends, its rolling release system just doesn’t jive with me. I only really installed it on a couple personal servers for experience with another distribution, so usually the boxes sit there doing their thing until I feel like setting up something new. When I run its first update in six months, something usually goes wrong, and I make my way over to their forums to figure out how to give
pacman a kick in the butt to get things sorted.
This time around, I’m installing metasploit to test some equipment against the recent security flaws in UPnP that have been making some waves. A binary package isn’t available in the official repositories so in this case the Arch User Repository (AUR) picks up the slack to automate building from source. I’ve used this in the past with some success, but last year Arch finally implemented package signing. Turns out this complicates installing these personally built packages unless you temporarily disable it. Let’s not do that though, let’s stay consistent with package signing. In a larger environment with your own custom repo, you would definitely want to have this working, and there’s nothing wrong with learning more about your system.
$ sudo pacman -U metasploit-4.5.0-0-any.pkg.tar.xz
error: 'metasploit-4.5.0-0-any.pkg.tar.xz': invalid or corrupted package (PGP signature)
Working at a service provider for hundreds of VoIP customers with thousands of phones means you’re going to encounter problems that make you scratch your head. Every now and then one of those problems gets escalated to me and I’m left figuring out why something is happening. Sometimes that means running packet captures on all sorts of equipment, installing in-line network taps to grab traffic off the wire, or trudging through debug logs. Every now and then I get lucky, figure out the problem before we get started and look like a wizard. More often though, I’m left just as confused as everyone else.
This problem has come to me in a number of iterations, but it’s always intermittent, unexplained phone reboots that appear to have no rhyme or reason. Mid-call or sitting untouched, whatever the usage scenario, the customer was complaining that their phones were rebooting, affecting multiple Aastra models. The last time this was happening with noticeable frequency was several months back, and we thought we nabbed the problem when a provisioning error related to an access control list (ACL) on a switch was fixed. Phones stopped rebooting, the ticket was closed and the customer was happy.
Fast forward to the other day when the problem reared its ugly head again after multiple phones in their office rebooted unexpectedly. The ACL was still in place, so this was something new. What could it be this time?