Skip to content. | Skip to navigation

Personal tools
You are here: Home TBSI Technology Blog 2009 November

November

Sub-archives

Nov 23, 2009

Problem resolving DNS names with Verizon FiOS

by Eric Smith — last modified Nov 24, 2009 05:57 AM

I recently upgraded my FiOS service and had a problem resolving some DNS names. The solution was simple but frustrating.

I've been using Verizon FiOS for Internet service for years. In general I've been pleased with the service: it's very fast and very reliable.

I've been running FiOS without using the Verizon supplied router. Instead, I plugged the incoming CAT5 cable directly into my Linux server. This did require that I use a slightly complicated configuration supporting PPPoE, but once I finally got it set up it has been problem-free. My Linux server has also been my DNS server and my DHCP server. I'm sure Verizon doesn't like this configuration, as it gives them less control over and less visibility into my network. But that's fine with me.

However, I recently switched to using FiOS TV. Because of the way the TV set top boxes (STB's) need to communicate upstream for program information, I'm forced to use the ActionTec router that Verizon supplies. As long as I'm forced to use this router I decided to use a more normal, less techy configuration and just let the ActionTec be my DNS and DHCP server. This has generally worked without issue, at least for the first few days.

Last night I decided to change the default domain name that the router uses. It defaults to "home", but it's better for me if it uses "trueblade.com", that way I can more easily resolve domain names. In any network I've ever worked on, this would not be a problem. The only thing it should affect is that when a client asks for a name like "mail", it would first query for "mail.trueblade.com".

However this morning my home network wasn't able to connect to my mail servers. After a lot of poking around I discovered that my internal systems were not able to resolve fully qualified DNS names like mail.trueblade.com. After a lot more poking around, I discovered that the ActionTec would not resolve domain names ending in trueblade.com if its default domain were also trueblade.com.

So the solution was simply to change the default domain name on the ActionTec back to "home", or indeed any other string. That's frustrating, because it means that I can't type domain names like "mail", but I need to use the fully qualified "mail.trueblade.com". But it's only a minor frustration. The only time I don't use fully qualified names is when I'm debugging. All of my systems use fully qualified names for their configuration files.

I'll probably switch away from using the ActionTec as my DNS and DHCP servers. In addition to this problem, you're limited in the amount of configuration you have over the DHCP server in particular. I'll post more when I've made the decision to switch off of the ActionTec for DNS and DHCP.

Nov 03, 2009

User input during a Fedora Kickstart

by Eric Smith — last modified Nov 04, 2009 08:55 PM
Filed Under:

Kickstart is Fedora's automated installation facility. Sometimes we need to get user input on the computer being built. Read on for how to do that.

In order to reliably build our servers, we use kickstart and PXE to give us a simple, repeatable process. During this build process, we need user input to decide exactly which configuration to apply to the system being built.

In order to do that, we run a Python script in the ks.cfg %pre section that uses the snack library to get information from the user. Snack is the (poorly documented) UI toolkit that comes with kickstart/anaconda. Here's how you use it in %pre.

First, you need a %pre section that runs the python interpreter. To do that, start the section with:

%pre --interpreter /usr/bin/python

Next, you need to realize that the kickstart screen you usually see runs on tty3. But the snack UI will show up on tty1. So we use a little routine to switch tty's:

def set_tty(n):
    f = open('/dev/tty%d' % n, 'a')
    os.dup2(f.fileno(), sys.stdin.fileno())
    os.dup2(f.fileno(), sys.stdout.fileno())
    os.dup2(f.fileno(), sys.stderr.fileno())

Next comes the function that actually calls snack to get the user input. Don't worry about the host_config parameter, instead focus on how snack is used. This code build a dialog box with a listbox and an OK button:

def get_user_input(host_config, default=None):
    # get the hostname, from it the other params are computed
    # return the hostname and everything that's derived from it
    # which for now is just the disk layout scheme

    from snack import SnackScreen, Listbox, Grid, Label, Entry, Button, GridForm

    def host_list():
        def hosts():
            return sorted(host_config.keys())

        lb = Listbox(height=len(host_config), returnExit=True)
        for host in hosts():
            lb.append(host, host)
        if default in host_config.keys():
            lb.setCurrent(default)
        return lb

    screen = SnackScreen()
    form = GridForm(screen, 'Select host to configure', 1, 2)
    form.add(host_list(), 0, 0, (0, 0, 0, 1))
    form.add(Button('OK'), 0, 1)

    # now run the form
    result = form.runOnce()
    screen.finish()

    hostname = form.childList[0].current()
    return {'layout': host_config[hostname],
            'hostname': hostname,
            }

Finally, put it all together:

set_tty(1)  # change to tty1, we're called by kickstart with stdout as tty3
user_args = get_user_input(host_config, args.args.get('tb-host'))
set_tty(3)  # restore

If you ever need to find information on snack, it helps to know that it's a wrapper for newt. So you can Google on "snack newt python" to get some useful answers. But be warned that there's not much there and you might have to look through the source code to snack.