Asterisk, and other worldly endeavours.

A blog by Leif Madsen

Docker container results in x509: failed to load system roots and no roots provided

leave a comment »

We have a small system running in AWS as a CentOS 7 image. It has a few containers that we’re using to host a few Golang API proxies. We migrated a customers API proxy that was running on the local VM into a container, and spun it up. Upon testing, we ran into the following error:

x509: failed to load system roots and no roots provided

We get that failure when trying to connect to an HTTPS endpoint (remote API that we’re proxying to Asterisk).

Figured it had to do with the fact we were using a scratch disk to build the container image, and that there were no certs loaded. Did some Googling and found some people with similar problems, but their solutions didn’t work for us on our CentOS 7 host system.

Then I thought maybe there was some issue with following a symlink as the source since we were loading in the ca-bundle.crt file as a volume. I didn’t test enough to determine if that was the issue (it probably wasn’t), but this post gave me a hint:

So we did the following:

docker run -d -p 8085:8085 -v /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem:/etc/ssl/certs/ca-certificates.crt [etc...]

After linking that file and mounting it in the container, all was well. I suspect it’s the path to the ca-certificates.crt that was the real trick.

Written by Leif Madsen

2015/10/30 at 3:30 pm

Posted in Asterisk, DevOps, Docker

Tagged with , , , , ,

Configuring powerline to show working Git branch

So the documentation for Powerline kind of sucks. I followed this pretty good article on getting started with it. First thing I noticed however is that the if statement on the article doesn’t work if you don’t have powerline installed (which kind of defeats the purpose of having the if statement there at all).

# if powerline is installed, then use it
command -v powerline-daemon &>/dev/null
if [ $? -eq 0 ]; then
powerline-daemon -q
. /usr/share/powerline/bash/

Next up is the configuration. I primarily use my bash prompt as a way to indicate which branch I’m working in within a Git repository. You need to point at the default_leftonly theme which is pretty easy to find when you web search for it. The issue is everything seems to just point you at the powerline docs, which aren’t the most clear.

First, start by creating a local configuration directory that will override the configuration for powerline for your user.

$ mkdir -p ~/.config/powerline

Then the next thing is to copy over the config.json from the main powerline configuration directory where you can find the available color schemes and other shell, i3, vim, etc themes.

(Again, the documentation kind of sucks on where the root of these configurations live…)

On my Fedora 22 system they live in /etc/xdg/powerline/. I then copy the config.json from that directory to ~/.config/powerline

To get the Git branch stuff going, I modified the configuration file in the following way:

--- /etc/xdg/powerline/config.json 2015-02-18 18:56:51.000000000 -0500
+++ /home/lmadsen/.config/powerline/config.json 2015-09-09 17:11:43.937522571 -0400
@@ -18,7 +18,7 @@
"shell": {
"colorscheme": "default",
- "theme": "default",
+ "theme": "default_leftonly",
"local_themes": {
"continuation": "continuation",
"select": "select"

To make it active you can run powerline-config --reload. If you have any errors in your configuration (I actually ran into this when playing with the colorscheme setting and used “solorized” instead of “solarized”), you can check it with powerline-lint.

Written by Leif Madsen

2015/09/09 at 4:20 pm

Rumors of my death have been greatly exaggerated

It’s been way too long since I’ve blogged. And this post isn’t going to be all the impressive unfortunately. However, I recently have been running a BBS and some friends and I have been playing LORD.

We’ve been playing this for the last few months, and I think I’m going to run a tournament. Perhaps with some sort of buy in like $10 or something, winner takes all.

Going to build it out in such a way that first person to beat the dragon 3 times will win the game, and at that point that person will win the pot.

Additionally, I’ve been reading a lot about the Go language and trying to get myself up to speed on that. Very interesting programming language. Essentially C but for concurrency (multiple processors).

I’m hoping to start blogging in the near future, but my current work has just kept me too busy and I haven’t really had anything all that worth of blogging about. I hope to start changing that around soon and get back to blogging on a semi-regular basis with things I’ve learned in the world of telecommunications and cloud platforms / virtualization.

Additionally, I don’t have any confirmation yet, but I’m pretty sure I’ll be attending AstriCon in Las Vegas this year. I’m going to figure it out either way, so hopefully i can meet up with some of you this year! The last few years I’ve just kind of mostly kept to myself and hung out with those I’ve met previously. I’m going to make a better attempt at reaching out to those I haven’t met before, so if you see me, come say hi please!

Written by Leif Madsen

2014/07/24 at 9:49 pm

Posted in Life, Musings

Asterisk: The Definitive Guide 4th Edition goes to print

Howdy folks,

Sorry for the lack of updates lately. I’ve recently (December 2012) started at Thinking Phone Networks as the Lead UC Systems Engineer, and we’ve been incredibly busy there. In addition, the authors and I had been working on the final touches to the 4th edition of Asterisk: The Definitive Guide, which documents Asterisk 11 LTS.

Late last week, the book went to print, and should start to appear on store shelves and start shipping from Amazon and other locations within the next 6-8 weeks I believe. However, if you’ve purchased the digital version, it’s already available!

I got mine from O’Reilly, and sync’d it to my Dropbox and shared it with my co-workers. There are usually deals around on Amazon and the O’Reilly website that will let you purchase both the digital and printed versions. The digital should be available immediately, with the printed version shipping as soon as it’s available.

Thanks to everyone who helped make the 4th edition a success, and to get it done in the last 8 months! It’s been quite the journey since the 1st edition was released in 2005.

Written by Leif Madsen

2013/05/16 at 8:31 am

Brother printer doesn’t print in Fedora 17

Tip: If your Brother printer won’t print after installing the drivers, install glibc.i686

Today ran into an issue with my new Brother MFC-7460DN (which is a really nice laser printer with auto-feed scanner, Scan-to-FTP which creates a PDF file, and other things). I had just recently done a clean install of Fedora 17, and I could install the RPMs (which are i386 files on my x86_64 based system), add the printer to CUPS and all sorts of things that looked fine.

However when I went to print, it wouldn’t error out, but the printer wouldn’t actually print. I tried changing a file per but it didn’t help.

Then I found this post which reminded me to install glibc.i686. Wish the Brother drives would just make that a dependency in the RPM.

Written by Leif Madsen

2012/11/24 at 5:06 pm

Posted in Technology

Tagged with , , , ,

Digium D40 and D70 Phone Unboxing

Today I received a couple of phones from Digium; the D40 and D70. I’ll be using these phones for testing and documentation in the 4th edition of Asterisk: The Definitive Guide (which Jim Van Meggelen, Russell Bryant and myself are working on right now).

Here is my unboxing of the phones and some commentary about my initial impressions of the hardware itself.

Pretty boxes!

Phones arrived in some nice looking boxes.

Digium D40

Comes with a little pamphlet to help you get the phones setup on your network.

Comes with all the little things you need to get the phone up and running, including a network cable. I was just using POE to power the phone, so I didn’t end up with the 5VDC power adapter.

Nice looking base. Easy to put onto the phone. Just uses friction to hold the phones on the base. Not sure how well that’ll work over time, but this isn’t something that should be getting attached and detached a lot. The space for cables in the base is also quite large.

Holes to mount to wall. Requires adapter.

Easy access!

Lots of space for my hand to plug in cables. Much nicer than any of the Polycom bases where I usually give up and just remove it.

Boot screen

Booting up with the Digium logo.

Handset hook access

The tab on the back here is well designed so that you don’t require a tool to pull out and flip around. I prefer to have the hook for the handset so it doesn’t fall off the base easily. On the Polycoms (which have the same type of setup) it’s nearly impossible to remove with your fingers

D40 vs IP335 size comparison

.Size comparison between the D40 and IP335.

Digium D70

Open box

Hidden compartment

Back of the D70

I don’t quite get the base with the wall mount holes, but impossible mounting angles on the base. Must have something to do with the manufacturing process and not having separate molds for footing.

Update: Michael pointed out that the A-frame is actually two separate pieces, so with a (separately purchased) piece, you can attach it to the base and make the system wall mountable. With the number of phones I’ve actually wall mounted in deployments (I think the number is only one or two), I think I prefer the 2 options for steep and shallow angles. Neat idea.

Side cut outs for cables that I didn’t even notice the first time through. Michael pointed out they are for cable management. Nice!

Oh my! So much space! Very roomy :)
Side by side comparison of the D70 vs the IP650 w/ sidecar.
Front to back comparison of the D70 vs IP650 w/ sidecar.

Written by Leif Madsen

2012/10/11 at 3:43 pm

Posted in Asterisk, Musings

Tagged with , , , , ,

Selecting Chef Servers With Environment Variables

Today I got playing around with dynamically selecting different chef servers in preparation for migrating some of our nodes away from our chef-dev server to our chef-live server (which I’m currently in the process of building and populating with data). I had been talking in the #chef IRC channel a few weeks back about making things dynamic, or at least easily switchable, when using multiple chef servers for different groups of servers in an environment.

What I want to do, is be able to set an environment variable at my console in order to switch between chef servers. Previously I had been doing this with different files in my ~/.chef/ directory and changing symlinks between the files. This method works, but is kind of annoying. So with the help of some of the folks in #chef, and with this gist of a sample file that someone is using for their hosted chef environment, I was able to build my own knife.rb and commit it to our chef.git repository.

In our chef.git repository, I created a directory .chef and placed a knife.rb file in it:

$ cd ~/src/chef-repo
$ mkdir .chef
$ touch .chef/knife.rb

I then filled knife.rb with the following contents:

current_dir = File.dirname(__FILE__)

sys_user = ENV["USER"]

log_level                :info
log_location             STDOUT
node_name                sys_user
client_key               "#{ENV["HOME"]}/.chef/#{ENV["KNIFE_ENV"]}/#{ENV["USER"]}.pem"
validation_client_name   "chef-validator"
validation_key           "#{ENV["HOME"]}/.chef/#{ENV["KNIFE_ENV"]}/validator.pem"
chef_server_url          "http://chef-#{ENV["KNIFE_ENV"]}"
cache_type               'BasicFile'
cache_options( :path => "#{ENV['HOME']}/.chef/checksums" )
cookbook_path            [ "#{current_dir}/../cookbooks", "#{current_dir}/../site-cookbooks" ]

The main key is the KNIFE_ENV environment variable which I set using: export KNIFE_ENV=dev or export KNIFE_ENV=live

After setting the environment variable, which server I’m using is selected for me. Additionally, I copied my validation.pem and client.pem files into corresponding directories in my ~/.chef/ directory: $ mkdir ~/.chef/{live,dev}

With all that done, I can now easily switch between our different servers in order to start the migration of our nodes. (I might create another blog post about that in the future if I get a chance.)

“BUT HOW DO I KNOW WHICH ENVIRONMENT I’M WORKING WITH?!?!?!”, you say? Oh fancy this little PS1 and function I added to my ~/.bashrc file:

if [ "$KNIFE_ENV" == "" ]; then
 export KNIFE_ENV="dev"

function which_env {
  if [ "$KNIFE_ENV" == "live" ]; then
    echo "31"
    echo "32"

export PS1='[\u@\h \[\033[0;36m\]\W$(__git_ps1 "\[\033[0m\]\[\033[0;33m\](%s) \[\033[0;`which_env`m\]~$KNIFE_ENV~")\[\033[0m\]]\$ '

Is nice :)

Written by Leif Madsen

2012/08/22 at 1:49 pm

Posted in DevOps

Tagged with , , , , , ,


Get every new post delivered to your Inbox.

Join 2,294 other followers