Canonical Voices

What LaMont Jones talks about

LaMont Jones

The question came up “how do I add an authoritative (secondary) name server for a domain that is managed by MAAS?”

Why would I want to do that?

There are various reasons, including that the region controller may just be busy enough, or the MAAS region spread out enough, that we don’t want to have all DNS go through it.  Another reason would be to avoid exposing the region controller to the internet, while still allowing it to provide authoritative DNS data for machines inside the region.

How do I do that?

First, we’ll need to create a secondary nameserver.  For purposes of simplicity, we’ll assume that it’s an Ubuntu machine named, and that you have installed the bind9 package.  And we’ll assume that  you have named the domain maas, that the region controller is named, with an upstream interface having the IP address a.b.c.d, and that you have a MAAS session called admin.

On, we add this to /etc/bind/named.conf.local:

zone "maas" { type slave; file "db.maas"; masters { a.b.c.d; }; };

Then reload named there via “rndc reload”

With the MAAS CLI, we then say (note the trailing “.” on rrdata):

maas admin dnsresource-records create name=@ domain=maas rrtype=ns

At that point, mysecondary is both authoritative, and named in the NS RRset for the domain.

What else can I do?

If you call the MAAS domain, then you could add NS records to the DNS zone delegating that zone to the MAAS region and it’s secondaries.

What are the actual limitations?

  • The region controller is always listed as a name server for the domain.  For domains other than the default.  See also bug 1672220 about address records.
  • If MAAS is told that it’s authoritative for a domain, it IS the master/primary.
  • The MAAS region does not have zones that are other than “type master”.

Read more
LaMont Jones

Once a process is running under apparmor, changing the profile is as simple as updating the profile and reloading it.  Initially getting it into apparmor normally requires a restart, but sometimes you just don’t want to restart the daemon.

The situation

Lets say that you’ve deployed a production service and managed to not actually enable the apparmor profile that you wrote for it.  Now you want to enable it without a restart, since a restart would be disruptive (and would involve admitting that you didn’t actually deploy it under apparmor like you claimed…)

In order to have a binary name for use in our example, let’s call our program “/usr/sbin/inspircd”.  Throughout the following text, my input is in red.


Create the apparmor profile and make it active

(Actually creating the profile is beyond the scope of this process.)

apparmor_parser -r /etc/apparmor.d/usr.sbin.inspircd.

Make sure we have gdb

apt-get install gdb

Find the process

ps auxf | grep /usr/sbin/inspircd

(For our example, we will use pid 22143)

Confine the process

If we could do this from outside of the process, this would be trivial.  Then again, there are sound reasons for why only the process itself is permitted to change its profile.

What we want to do here is call: aa_change_profile(“/usr/sbin/inspircd”) from within the process, but it is nearly certain that aa_change_profile is not in the symbol table for our daemon.  So we do it the hard way, by doing what aa_change_profile does: write a particular string to /proc/self/attr/current (the 32 in the write call is the length of the string: no trailing null is needed.)

(Note that while we are in gdb, the process is stopped in the debugger, and users might tend to notice this… I pasted all 5 lines of text into the debugger, which meant that I was stopped in the debugger for under 2 seconds.)

# gdb -p 22143
(gdb) call open("/proc/self/attr/current",2)
$1 = 13
(gdb) call write($1,"changeprofile /usr/sbin/inspircd",32)
$2 = 32
(gdb) call close($1)
$3 = 0
(gdb) q
A debugging session is active.

 Inferior 1 [process 22143] will be detached.

Quit anyway? (y or n) y
Detaching from program: /usr/sbin/inspircd, process 22143

And now we have a happily confined process, no file descriptors leaked, no daemon restart, and only a second or so of interruption masquerading as lagginess.

Read more
LaMont Jones

Hello world!

Welcome to Canonical Voices. This is your first post. Edit or delete it, then start blogging!

Read more