My shiny Mac Pro just arrived along with a pair of Dell 28 Ultra HD (P2815Q) Monitors (2160p). I anxiously plugged everything in, fired up Google Chrome, and waited…and waited…and waited…and waited. The dreaded spinning pinwheel of death greeted me and it took minutes for each page to load. Not even the chrome://settings/ or chrome://version/ pages would load. Chrome was basically unusable.
Odd, since everything was running fine when I had the Mac Pro plugged into my Sony R550A 60″ HDTV (1080p). I begrudgingly switched to Safari and started to do some digging.
Turns out the latest Chrome Stable and Chrome Beta (as of 13-Mar-2014) eat themselves right in the face when plugged into 4K or UHD displays. I’m unable to find a specific bug report but I did manage to find a single general complaint thread in the Google Product Forums from Oct/Nov 2013. Turns out I’m not the only one experiencing this problem.
Luckily the problem has been fixed in the latest Chrome Dev 35.0.1883.0 and Chrome Canary 35.0.1888.0 builds so just download either of those versions. Chrome now completely screams on the Mac Pro.
Version information: Mac Pro Late 2013 MacPro6,1 running Mac OS X 10.9.2 Mavericks.
Short of a server going down, one of the quickest and most effective ways for a Blog to die is for it to drop out of search engines. Sure, you might have a ton of repeat visitors, but no search ranking means no new visitors because, well, no one can find you. What a blinding flash of the obvious.
Continue reading How to murder a Blog
Just in case you’ve been keeping track, this is the seventh time a Spammer has forged one of the domains under my control as the return address of their Spam run. The first time it happened I felt shocked, angered, and betrayed. After I lost count of the incidents on my left hand and had to move on to my right hand to keep track it now just feels old-hat. Sure, it still pisses me off, but I now just chalk it up to being the owner of many high profile domain names.
Previously I noticed Spam runs immediately because the mail server started choking on the influx of bounces. This time the domain in question had a Barracuda Spam Firewall 200 sitting on the front lines in the DMZ; I didn’t notice the barrage until the midnight reports ran and I received the pretty pie charts showing a 600% increase in e-mail (and that was just the first day).
Days 2 and 3 jumped up to a 800% to 900% increase in e-mail before starting to plateau and drop off on Day 4. All in all around 350,000 bounces were blocked which is pretty routine for a forged run but the Barracuda performed without so much as a hiccup.
And, for the more visual among you, I’ve of course attached the obligatory pretty graph to show what a Spam forgery looks like. Green is legitimate e-mail, red is blocked Spam, magenta is bad recipient, and blue is rate control (too many connections).
By default, UNIX-based servers running Plesk and the Courier-IMAP e-mail server drastically limit the number of inbound connections to prevent users from opening up too many concurrent sessions. Unfortunately, this artificially-low restriction can impact legitimate users who have multiple computers connecting to the Courier-IMAP server from behind a firewall or a single computer that runs an IMAP client that takes advantage of mailbox caching.
Plesk comes configured with a limit of 4 connections per IP address and a limit of 40 connections total. Modern IMAP clients such as Mozilla Thunderbird use mailbox caching to open up multiple connections to increase performance. In the case of Thunderbird, it opens up 5 connections by default which is already 1 connection more than Courier-IMAP’s default restriction. Add another few family or corporate computers behind a firewall and those additional users won’t be able to connect at all since a single Thunderbird client is already utilizing all 4 connections.
To increase this restriction, modify the
/etc/courier-imap/imapd configuration file and change
MAXPERIP to a more sane number. In the case of my configuration, I changed
MAXDAEMONS from 40 to 80 and
MAXPERIP from 4 to 40. This allows all the machines behind my home firewall to connect to multiple accounts on the e-mail server with mailbox caching enabled.
But even those numbers may be too low for a corporate colocated server that services an entire company. Tweak those numbers based on your employee base; if 50 employees are connecting to the e-mail server from behind the same firewall then
MAXPERIP could need to go as high as 250 (50 employees times 5 cached mailbox connections). Add e-mail clients of people working from home and
MAXDAEMONS could go as high as 300 or 400.
Obviously, the connection limits are to prevent the Courier-IMAP server from using too many memory and CPU resources on the machine. Tweak the numbers based on the memory footprint of each daemon process and how much memory you have.
The most recent batch of RedHat Enterprise (RHEL) fixes rolled out this past week break DNS (bind) on servers running Plesk. My Plesk 7.5.4 installation was effected as well as many other Plesk 7.x and 8.x users. The problem appears to be with a conflict between RedHat’s bind-chroot RPM and Plesk’s chroot system.
When the latest RHEL RPMs were rolled out the
/etc/named.conf symlink which should point at Plesk’s
/var/named/run-root/etc/named.conf config file was changed to point at RedHat’s default
/var/named/chroot/etc/named.conf file. Post-install scripts then munged the location of the Plesk config files. This resulted in the following error when starting or restarting the nameserver:
none:0: open: /etc/named.conf: file not found
A thread was started in the Plesk forums reporting the problem and a Rackspace employee replied in an earlier thread with a fix.
rpm -e bind-chroot to remove the RedHat RPM that conflicts with Plesk and then re-symlink
/etc/named.conf to point back at the proper
/var/named/run-root/etc/named.conf config file. This drops Plesk’s config files back into place.
One of my co-workers called me over to his desk this afternoon to show me an e-mail thread that had been bouncing around between a few of his family members. It went something like this:
Save those old phone bills!
If you can’t access those articles for some reason, you can Google phone tax Spanish and get several articles that tell about the decision to end the 108-year-old tax that had been implemented to help pay for the Spanish-American war.
Bottom line – you may be able to get refunds on taxes paid. 3% – may be worth it to you. I don’t know how much hassle will be involved.
According to the USA Today article, you can file for refunds back to 3/1/03 (2003, not 1903).
Crap! I just shredded all of those.
Call up NSA – they should have the records [VBG]
Werd. I love the Internet.
I’m running a combination of IOG and MRTG to keep track of network traffic and ran into a little bit of MRTG cronjob retardedness. In my haste to get MRTG up and running I forgot that it’s enabled by default on RedHat Enterprise Server even if you haven’t configured it yet. So, when I manually added it to my crontab, it actually ended up running twice in parallel. The result was MRTG eating its logfiles a few times per day so I had no history.
So, for any of you receiving the following errors, double-check your crontab and make sure MRTG is only running once!
Rateup WARNING: /usr/bin/rateup could not read the primary log file for colo1.pixoul.com_2
Rateup WARNING: /usr/bin/rateup Can't remove foo.old updating log file
Rateup WARNING: /usr/bin/rateup Can't rename foo.tmp to foo.log updating log file
Mac OS X Mail.app doesn’t properly work out of the box when connecting to a Courier IMAP (Plesk) mail server. If Mailbox Behaviors is configured to save Drafts, Sent, Junk, or Trash on the server then Mail.app will constantly report the error The message could not be saved. Quite annoying and, in the case of the Sent mailbox, Mail.app will happily just send the message to the bit bucket and not tell you.
To solve the problem go to Preferences, Advanced, and use INBOX as your IMAP Path Prefix. Problem solved!
Many thanks go out to MacFixIt and SpamapS.
Update (03/29/2007): Please note that this fix is not a magic bullet and is specifically for Courier IMAP mail servers running on Linux managed by a Plesk control panel environment because that’s the only place I’ve tested it. There are literally hundreds of different IMAP servers out there and each one has its own quirks and configuration options.
One of my co-workers was having problems connecting to the VPN at work and fired me an e-mail:
Looks like my IP address at home changed. Would that irritate the SonicWall? My new IP is XXX.XXX.XXX.XXX, can you feed that to the SonicWall? I’ll sacrifice a chicken or two over here, maybe together we can get it to work.
I updated his IP address on the firewall and got the best response evar:
OMG it works now!!!11
Ha. I love my co-workers.