Recently enabled IPv6 on your local switched network? Getting odd timeouts connecting to an OS X Server? Here’s (possibly) why: the out-of-the-box server configuration is firewalling link-local IPv6 traffic. To diagnose this in my network I used ssh, since it’s easy to use and has good verbose output. So turn on secure shell conncections if you haven’t already. Server -> Settings -> Remote access -> Secure shell connections. Now from a neighbouring device, first confirm that IPv4 ssh to the server is working e.g.
So I recently received an RDS maintenance notification: From: Amazon Web Services, Inc. Subject: Upgrade now available for your Amazon RDS PostgreSQL database instances Dear Amazon RDS Customer, A system update is now available for any Amazon RDS PostgreSQL database instances you created before 13 October 2015. We recommend installing this update to take advantage of several performance improvements and security fixes. You may choose to install this update immediately, or during your next scheduled maintenance window.
The theatrical demand from OSX and iOS for constantly re-entering the Apple ID password is a substantial enemy of security. I just upgraded two laptops, a server, an iPhone, and restored an iPad. I think I had to enter the same passwords six times per device. In general use they’re no better, regularly nagging for a password for piddling tasks like updating an app or downloading a song. For me with separation-of-concern accounts and 20+ character generated passwords this is a major annoyance, especially on a tablet keyboard.
I’ve just moved some of our code to run asynchronously and found that URL helpers aren’t available inside ActiveJob jobs; at least, not the way they are within Rails views, controllers and mailers. We can fix this; read on for how. I wanted to simply write: class NotificationJob < ActiveJob::Base def perform(object, message) NotificationService.send(url_for(object), message) end end … but invocation threw a NoMethodError because jobs don’t have url_for available. At first I tried to just invoke the helper directly: class NotificationJob < ActiveJob::Base def perform(object, message) NotificationService.send(Rails.application.routes.url_helpers.url_for(object), message) end end but this url_for threw a TypeError message, unable to handle being passed a model object!
Back in the dim & distant past – late 1999, although no records capture the exact date – I was asked to compromise a server and gain root access. I said yes. This is the first and only time I have deliberately cracked a live, production server. This was not as questionable an undertaking as it sounds. I knew of the machine in question, and I knew its operator, and he still had a working secure shell login.
I am rather fond of the Stethoscope gem for monitoring, since it lives inside the runtime Ruby process and can directly check on Rails without being subject to it. Returning HTML or JSON as required it also makes a nice responder for health checks from Nagios and AWS Elastic Load Balancers. Using Stethoscope is as simple as adding the gem in your Gemfile and installing an initializer, e.g.: However, in this modern paranoid age, many apps (including practically everything I write) include config.force_ssl true in config/environments/production.rb to require SSL, HSTS and secure cookies.
We have AWS RDS instances that send lifecycle notifications to an SNS topic. This was ending up in email, but I prefer to receive notifications in a Slack channel. Fortunately they are easy to integrate using AWS Lambda and Slack’s webhooks. Here’s the Lambda function I’m using, which parses the message object (if it can) and formats the notifications before posting. Note: the following links will require both AWS and Slack logins.