AWS S3 Endpoint Gateway Access for Linux 2 AMIs (Resolving HTTP 403 Forbidden Error)

An AWS Linux 2 EC2 instance running in a VPC configured with an S3 Endpoint Gateway to access update repositories received the following error when running the yum update command:

# yum update
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
Could not retrieve mirrorlist error was
14: HTTP Error 403 - Forbidden

The S3 Endpoint Gateway was configured in the VPC using the following documentation:

The error persisted even though the configuration was triple-checked, including Network ACLs, Security Groups, and the Endpoint Policy (which was copied from the setup documentation).

The issue was resolved by extending the VPC Endpoint Policy to allow access to Linux 2 repositories; the specific change was to add "arn:aws:s3:::amazonlinux.**" to the Resource list.

{"Version": "2008-10-17",
"Statement": [
{"Sid": "Amazon Linux AMI Repository Access",
"Effect": "Allow",
"Principal": "*",

"Action": "s3:GetObject",
"Resource": [ "arn:aws:s3:::packages.**", "arn:aws:s3:::repo.**", "arn:aws:s3:::amazonlinux.**" ]

Enabling Auto Standby Mode on the Denon PMA-600NE

Denon PMA-600NE

The Denon PMA-600NE integrated amplifier can be configured to automatically enter standby mode if not operated for more than 30 minutes. Instructions for enabling auto standby mode can be found under the Settings section of the online Owner’s Manual:

The Owner’s Manual is available for download in PDF format here:

And the instructions for enabling/disabling auto standby mode, copied from the Owner’s Manual, are:

Press and hold AMP POWER Power Button for 5 seconds or more to switch it on and off. The power indicator changes as follows each time it is switched on and off.

  • When auto standby mode is on: The power indicator blinks in green three times.
  • When auto standby mode is off: The power indicator blinks in green once.

The [System Administrator’s] Oath

Bob Martin (author of Clean Code, The Clean Coder, and evangelist of software craftsmanship) recently posted The Programmer’s Oath. Let’s say we have jobs as System Engineer’s or System Administrator’s. We may write code to automate our work, to manage, maintain, and operate our systems and environments, but we don’t necessarily work as Programmer’s do writing applications for business functions. Would the Programmer’s Oath apply? Are its promises relevant to systems engineering/administration work? Perhaps it does. Here’s a version with some of the words changed as The System Administrator’s Oath.

In order to defend and preserve the honor of the profession of systems engineers and administrators,
I Promise that, to the best of my ability and judgment:

1. I will not create harmful infrastructure or systems.

2. The infrastructure and systems that I create will always be my best work. I will not knowingly make changes to infrastructure or systems that are defective either in behavior or structure.

3. I will produce, with each change, a quick, sure, and repeatable proof that every element of the infrastructure and systems work as it should.

4. I will make frequent, small, changes so that I do not impede the progress of others.

5. I will fearlessly and relentlessly improve the infrastructure and systems at every opportunity. I will never make the infrastructure worse.

6. I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.

7. I will continuously ensure that others can cover for me, and that I can cover for them.

8. I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.

9. I will never stop learning and improving my craft.

Regardless of how you might feel about taking oaths, Uncle Bob’s promises are something to contemplate as we constantly work to become better IT Professionals.


Reimagining the Implementation of TeX (and the Luxury of Modern Programming Methods)

Glenn Vanderburg, Engineering Director for Architecture at LivingSocial (@glv, has a personal project underway to implement TeX’s algorithms in the Clojure programming language. His work was recently described in an article published on InfoQ. Glenn also presented his work at the Clojure/conj conference last year in 2014, his excellent talk is posted on YouTube.

The InfoQ article and YouTube presentation provide a high-level summary of the state of technology and software development capabilities available in the early 1980’s which influenced (really restricted and confined) the creativity and results of a programmer at the time. By implementing TeX in Clojure, a functional programming language with capabilities for multi-threaded processing, Glenn applies modern methods, and makes several now-and-then observations along the way, to the implementation of a large-scale programming masterwork created by Professor Knuth more than 30 years ago.

“The ways we can program today are luxuries made possible by decades of small advances.”

Glenn also describes the potential benefits for reuse that would be available with a modern implementation giving several examples of how Web publishing and eBook readers might take advantage of using TeX’s excellent typesetting algorithms creating beautiful page layouts and more natural reading experiences.


When Feelings, Emotions, and Love of Objects Occurs

Designers Jony Ive and Marc Newson recently collaborated on a collection of objects, some chosen and some designed and manufactured by them, for an auction supporting Bono’s (PRODUCT)RED brand and charity. Charlie Rose interviewed and toured the Sotheby’s auction floor with them.  While the discussion was interesting in several ways, comments by Jony Ive on his motivations for design are deeply thoughtful and inspiring:

“I think, one of the things, that you get a sense of is the degree of care. How much did this group of people care to make this and make it right. And they didn’t do it for themselves, it’s in service to the people that are going to use or buy the product. And I think there’s something, the humanity of that, I think is extraordinary. But I do think, as Marc was saying, how something’s finished on the inside, you can argue that you’ll never see that. But I think, we believe, and it’s very difficult to explain why, but I think part of the human condition is that we sense care. And sometimes it’s easier to realize you sense carelessness. And I think we’re surrounded, our manufactured environment, so much of it you know, testifies to a complete lack of care. Which isn’t, you know, that’s not about your attitude toward an object, it’s about your attitude to each other. And so I think that sort of commitment and passion become fanaticism of just really caring to get something right whether you’re going to see it or not. But we do that for each other.” – Jony Ive, Apple, Inc.

That is exactly the perspective that makes Jony Ive, and Apple, great. The quote comes at approximately 16:50 in the video interview. See it here on Hulu too.

2013 Henning Koppel %22Pregnant Duck%22 RED Pitcher

2013 Henning Koppel “Pregnant” Duck Pitcher

Resolving Data Connection Problems on an iPhone 4S in Spain

While traveling around Southern Spain in April 2013, I had a very difficult time getting a data connection on my iPhone 4S. The phone was purchased in the US with locked service from AT&T. Prior to my trip, I purchased the Global Data, Phone, and Messaging services from AT&T so I was not expecting any troubles.

The phone automatically connected to the Orange network and most of the time indicated a 3G connection. Voice calls worked Ok, and so did text messaging, however, Internet data access was not working (for example, no email access and no Web browsing) and SMS messaging with attachments (such as photos) was not working.

To fix the problem I tried to change carriers (by turning Automatic off from the iPhone’s Settings->Carrier menu) but no other carriers appeared in the list; the phone was searching for carriers but only Orange appeared. Ultimately I left the phone searching for carriers for several minutes (maybe as long as 3-4 minutes) and several other networks were found. Selecting “vodaphone ES” and the data services on the phone started working reliably.

Remember to switch back to automatic carrier selection after the trip.

25 Seconds Before Joy: Time Annotations For The Curiosity Rover’s Landing Video

Adam Steltzner, the NASA Engineer responsible for the Mars Curiosity Rover’s Entry Descent and Landing system, was interviewed by National Public Radio. In the article he described the jargon used in the Control Room during the final moments of the Rover’s descent on Mars. The article is here:

NASA Television published a 9 minute YouTube video of the Control Room which is viewable here:

The climax of the event occurs in the 25 seconds between 2:50 and 3:15 when the three conditions for declaring the landing a success unfolded. The audio version of the NPR article overlays sounds from the JPL Control Room with Steltzner’s comments which provides an interesting explanation for the operations speak used to choreograph and confirm the information coming back to Earth during the landing. Here is a time annotation of the three conditions mapped to the YouTube video:

  • [2:52] One of our teammates called out “tango delta nominal,” and that meant that the rover had sent a little postcard with its touchdown velocity, and where it thought it was on the surface of Mars.
  • [3:01] And I had another guy call out “RIMU stable,” which meant the rover’s not moving.
  • [3:08] And then as soon as RIMU stable was announced, Brian Schratz, who was sitting in the control room with us, was to count to 10 and confirm that the UHF telemetry stream from the rover was continuous. And that meant that the sky crane hadn’t fallen back down on top of it. “UHF is good,” Schratz reported.
  • [3:10] He said that… oh, I remember like, pointing to Al [Chen, JPL engineer], like I’m throwing success into his body. You know, like “Yes! Let’s do it, Al.

For the full experience of the tense moments just before the landing, watch the vid from the start up until approximately 3:30. The entire 9:21 minute video is worth watching for the excitement experienced as the initial images from the Rover were downloaded and displayed in real-time.

Update (08/22/2012): Doug Ellison (@doug_ellison), the Founder of, Virtualization Producer at JPL, and the Technical Director of NASA Eyes on the Solar System (, released a YouTube video which syncs the MARDI landing images with Control Room audio:

Update (08/22/2012): Jody Davis, the person who called “tango delta nominal,” has joined Twitter as @TangoDeltaNom.

Your Last 30 Days

When a new US President is elected there is a focus on their first 100 days in office. The process seems to be credited to Franklin D. Roosevelt who met with Congress each of those first 100 days to pass new laws and establish new programs that quickly made a difference at the time.

When managers take new jobs some also start with a specific agenda for their first 100 days. I remember reading a good list of references on the Social, Agile, and Transformation blog which is written by Isaac Sacolick.

That’s all well and good, but how about when you leave a job? How should you handle the time immediately after your resignation as your notice period starts, your last 30 days (or maybe it’s your last two weeks)?

Leaving a job is in someways more important than starting. Resignations will be more important to the people who need to carry-on their functions and yours (the responsibilities you are vacating). In leaving a role, it’s important that a proper transition occurs so that the work, and especially the people (your soon to be former colleagues), are not impacted by your departure. An organized and proper transition is not only the professional thing to do, it is also the right thing to do.

Here are some ideas on how to organize a transition during your resignation period.

  • Create a transition document: On the day of your resignation be prepared with a transition document in outline form. There is no need at this point to have anything more than an outline because what you really want to achieve is to establish a forum with your colleagues (the ones who will carry your work forward) to identify the information that is important cover. Share the outline with your manager on the first day of your resignation and with anyone else your manager feels should be part of your transition process.
  • Summarize your time at the firm with an Introduction section: Include your first day with the firm and your last. Describe your function and your responsibilities (in your own words) and summarize the major contributions that you feel are important for your successors to know about. Provide a reference to your job description, and describe any promotions you may have received, or ways in which your job or your role changed over time.
  • Highlight Key Projects: Do a look-back of your work and write summaries for key projects that you accomplished. Include references to any exhibits or project artifacts (so that people can easily find the information), people who contributed to the projects with you (including outside vendors), and any future strategies for the project work that may have been discussed at that time or afterward. If there are projects that are still in-flight, considering labeling your project descriptions as completed (referencing a date) or active.
  • Highlight Vendor Relationships and Agreements: If you were responsible for managing (or coordinating) the relationships with any outside vendors, list contact names, phone numbers, and email addresses so those relationships can be re-established after you leave (or during your transition period). Summarize the external parties (including attorneys) who may have worked on contracts and agreements with you. Provide references to contract exhibits and summarize important contract points that will help your successors manage those agreements going forward.
  • Be a good citizen, clean-up after yourself: Sure, you’ll clean your desk and throw out unneeded documents and office supplies and you’ll return equipment (such as a laptop and Blackberry), but don’t forget about your system access. Create a list of your usernames and logins, any special permissions you may have had to applications, remote access methods, entries on emergency call lists (or call trees), and access cards to remote facilities; this list will help your colleagues decommission your access when you leave. Also check your calendar for any recurring meetings you may have organized and create a list so that meeting invites can be easily reissued.
  • Summarize Strategy: If you were in a role responsible for product architecture or strategy, or responsible for an important function within the firm, then your forward looking approach and plan will be important for your successors to understand. Describe your perspective for managing the function, any initiatives you were anticipating to start, or any ideas that you were contemplating but may not have had the chance to execute. New managers will certainly bring their own ideas and approach to your former function, but they will also appreciate all the help you can provide to get them started.
  • Take care of your people: If you are a manager responsible for people, make sure your manager (and/or your Human Resources department) is aware of any ongoing activities or promises that were made to your team members. Were you mentoring someone? Was someone promised a raise, a promotion, or a title change? Provide references to any performance review documents. Highlight the good (and the not so good) work habits of your team members so that your successors will be fair to your people as the management and the leadership of the function changes to accommodate your resignation.

When you resign from a firm you in fact take-on new responsibilities; and you will leave behind a large group of people who will assess your performance. It’s your opportunity to organize your transition so that others are not adversely impacted by your individual decision.

Agile is not fast, it’s frequent.

The principles (and the intention) of Agile Development are often confused with the word agile which people interpret to mean fast (in the sense of being quick and doing things other than in a thorough way). Of course that is an incorrect interpretation. Agile methods are not intended to be fast, if anything Agile teaches us to be iterative, repetitive, and to break down larger problems into smaller pieces that can be more easily understood, completed with higher quality, and delivered on an expected schedule. From that perspective, Agile teaches us to be Frequent in the way we approach our work.

So Frequent may in fact be another principle of Agile Development. As a principle it doesn’t only have to apply to software development work. We can apply Frequent methods to other disciplines too.

“Reviewing performance is good; it should happen every day.”

NPR posted an interesting article on a interview with Samuel Culbert, a UCLA business professor and author of the book Get Rid of the Performance Review! You can access the NPR article here.

The article (and I would expect the book) offer some excellent perspectives on performance reviews in the workplace. Feedback on employee performance is not something that can be scheduled for once or twice a year. To be effective, and to create cohesive and high performing teams, feedback must be constant and ongoing. Managers should be observers of performance and should develop skills for understanding human nature and giving accurate and helpful feedback to enhance and improve performance.

If there is anything more insidious than a once or twice yearly performance review it is a 360-degree review process. If managers, whose job it is to be responsible for people, to provide useful feedback, and to understand human nature, don’t have the proper communications and collaboration skills to provide proper feedback, how can individuals (ie, managers and non-managers alike) contribute to a 360-degree review process in a way that is productive or even fair? It’s a rhetorical question, obviously they can’t.

I like the perspective communicated in this part of the article:

How often have you heard a manager say, “Here is what I believe,” followed by, “Now tell me, what do you think?” and actually mean it? Rarely, I would bet. Bosses seldom show that kind of respect.

That type of dialog initiated by managers is not only respectful, it’s collaborative and it also sets an important precedent in the way people work with each other at all levels inside an organization. That type of dialog is in fact cultural. And corporate cultures based on solid principles that empower and treat people fairly create the best organizations.