Crossed Wires

Vic’s Blog

Posts Tagged Linux

LDAP-backed DNS and DHCP…?

Jul 22

Posted by Vic in Linux, Networks

I’m having a bit of an infrastructure redesign here at the Crossed Wires campus.  Each time I have an outage (the last one was caused by a power failure) I learn a little more about the holes in my current setup and what I can do better.

I’m implementing a router box on an old low(-ish)-power PC that will be backed up by a virtual machine on my main virt-box.  I’ve already done most of the preparation of using keepalived to implement VRRP, and a colleague has given me some pointers in using the Linux-HA tools like Heartbeat and DRBD to make services like e-mail and Samba redundant.

I’ve had a soft spot for LDAP for ages; I’ve always thought that putting as much backend data into LDAP as you can would be a really good way to get failover and redundancy.  Instead of having to deal with every single server’s different way of doing replication and failover, just bung everything into LDAP and get that replicating.  Sounds good in theory, but in a nutshell it’s not working out that way for the two least-celebrated but most important components of my (arguably any) network: DNS and DHCP.

There are a number of LDAP-backed DNS projects out there.  If I’m willing to go to the bleeding edge with BIND on my Gentoo build I can get access to the two most talked-about ones (bind9-sdb-ldap and the BIND DLZ LDAP driver), and other solutions like PowerDNS and ldapdns are available.  But none of them offer integration with DHCP, and I’m currently using dhcpd’s “interim DDNS update method” to make sure that hostnames are seen in my DNS when a lease is granted (okay, there’s a Perl daemon that goes with bind9-sdb-ldap, but it seems like a sort-of clunky afterthought).

Speaking of DHCP, LDAP backends for it are virtually non-existent.  The only LDAP-enablement I’ve found for ISC DHCP involves putting the config file into LDAP, not the leases…  I actually used that for a few days a while ago and pulled it out because it was actually more work to do it that way (and for no benefit in failover).

It seems to me it would be a project ripe for the picking: take an integrated DNS/DHCP server like dnsmasq and make it write into LDAP instead of to a file.  If I had more free time I’d probably have a go at it, except for the fact that no-one really seems to be that interested in storing DNS and DHCP in LDAP: that it hasn’t been done says to me that there’s no demand for it, and it’d end up being a big waste of time and effort.

Over to you, lazyweb…  Is this a yawning chasm of unfulfilled networking dreams, or a case of me trying to make something more complex than it needs to be?  After all, the rest of the world gets by with DNS master-slave and DHCP failover, they should be good enough for me too, right?  ;-)

Tags: , , , ,

Comments

FreePBX device-and-user mode, part two

Jul 12

Posted by Vic in Telephony

In part one, I described how I reconsidered device-and-user mode in FreePBX, and did the initial changeover.  Read on to find out how I overcame a major issue with the configuration!

I have an ISDN phone line coming into my Asterisk system.  One of the indials is for our home number, the other is one I use for work.  Before I found FreePBX, I had manually worked the Asterisk dialplan to have calls made from my work phone(s) appear from the work phone number–useful not just for Caller-ID, but also required for the long-distance provider I use to bill calls for work.  With FreePBX I was able to use a custom context to pre-select a route that dialled the provider override prefix to send the calls through the other provider, but it was a bit of a hack using hand-written dialplan code and a bit of luck.

Before I changed to device-and-user, I naively assumed that FreePBX would allow a user to be associated with a context in the same way a device/extension can be.  This is not the case, and the context of the device is still used for routing.  This meant that I could not use a device for either work or personal calls without having to log onto FreePBX and change the device context (logging on as the work user was not enough).  I was back to square one…

I did a little research.  Firstly, I rediscovered how I was making the existing routing work.  The ISDN interface I use (driven by chan_capi in Asterisk) simply uses the outgoing caller-id of the call to select from available MSNs[1].  So I had one route that had the “normal” MSN set as the outbound caller-id, another route with the “work” MSN (plus the rewrites to add the long-distance override code at the front), and a custom context for the work devices that made only the route with the work MSN available.

Looking more closely at the user definition page, I saw that there is an “Outgoing Caller-ID” field.  By using this field, I was able to do away with the separate route and the custom context and set the work MSN there instead.  This gives me just what I need: a way to control my outbound MSN on a per-user basis!  This got me half-way there, as I still needed a way to set the long-distance override codes for work calls.  A bit more research turned up a predialling macro hook that the FreePBX folks made available.  With a bit of code to test the caller-id and the number dialled (the long distance company doesn’t handle free calls, for instance) I get just what I need.

Here’s the macro hook (this is added to extensions_custom.conf):

[macro-dialout-trunk-predial-hook]
exten => s,1,NoOp(Trunk is ${OUT_${DIAL_TRUNK}}, CallerID ${CALLERID(num)} calling ${OUTNUM} )
exten => s,n,GotoIf($["${CALLERID(num)}" != "xxxxxxxxx"]?endit)
exten => s,n,GotoIf($["${OUT_${DIAL_TRUNK}:4:11}" != "CAPI/contr1"]?endit)
exten => s,n,GotoIf($["${OUTNUM}:0:4}" = "1800"]?endit)
exten => s,n,Set(OUTNUM=1xxx${OUTNUM})
exten => s,n(endit),MacroExit()

So I’m now a happy device-and-user user!

[1] Actually I don’t know if that’s chan_capi doing it for me or whether it’s just the way the ISDN network works.

Tags: , , , ,

Comments

Revisiting device-and-user mode in FreePBX

Jul 12

Posted by Vic in Telephony

Buoyed by the success of a colleague I introduced to Asterisk and FreePBX a little while ago, I decided to have another look at the extension configuration mode I use on our system.

Check this post for a recap of the FreePBX configuration modes and my first thoughts.

Last time I looked at this I thought there were some problems with the way it was implemented that meant it didn’t work for my installation, so I ended up hacking together a mess of fake extensions, ring groups and queues that more-or-less reimplemented the good parts of device-and-user mode and still letting me use things from extensions mode.  Doing this however meant that FreePBX always complained about what it called “invalid destinations”, and I had to use some custom logic for doing something simple like a common voicemail access number.

What won me over to device-and-user mode again though was the ability to log a device on and off from a number.  I have a couple of Nokia handsets that have SIP clients now, and it’s handy to just have one device that all my work calls (for example) arrive on.  After-hours though, I didn’t want that device to still be tied up to the work line; it made more sense to be able to use that device for home calls.  To do that with extensions mode and my ring-group hack would mean reprogramming the ring-group (and one other change, which I’ll talk about later) when I wanted to switch over.  Presumably I could write some script or AGI logic that I could tie to a feature code in FreePBX, but I’d simply be making more custom modifications for little real gain.

In the end, I realised that the main thing keeping me in extensions mode–the ability to call a device by it’s “extension” number regardless of who’s logged on to it–wasn’t something I used often enough to warrant all the work I’d have to do to make extensions mode do what I needed.  With that in mind, I edited amportal.conf and made the all-important change:

AMPEXTENSIONS=deviceanduser

I had to reload the FreePBX admin page a couple of times, but eventually the “Extensions” tab changed into two tabs, “Devices” and “Users”.  True to the description of extension and device-and-user modes given in the FreePBX doco, the Devices and Users tabs had the same number of entries.  All I needed to do was delete the users that were no longer required (i.e. almost all of them) and the devices that belonged to the voicemail extensions from my original setup.  I then ran through each of the device definitions and correctly assigned them as either “Fixed” (statically allocated to a user) or “Ad-Hoc” (able to be logged on to a user).

This was the point at which I worked out a solution to my original dial-a-device-directly problem.  I realised that the majority of times I need that functionality is when testing.  So, for those devices that I use for testing, I left the user definition in place and made it the “default” user for that device.  This means that when I log out of the real user from that device it is reachable by the default user number, and I can dial it directly for testing.  The other use for direct-connection to a device, the intercom, requires a separate SIP endpoint anyway (due to the Cisco phones not adhering to the SIP command for remote off-hook) so I need to keep those as separate users too.

I’m quite happy with how it’s turned out–at least, I was once I’d overcome the showstopper I found!  Read about that in part two.

Tags: , , , , ,

Comments

Are we letting Microsoft define our industry?

Mar 10

Posted by Vic in Operating Systems, Soapbox

I’ve been trying to solve a problem at work for a few weeks now — one of those tricky “it’s only software so it shouldn’t be this hard” sort-of problems for which you know the solution is just a matter of putting the right bits and pieces together. At work, I’m more-or-less forced into using Red Hat Enterprise Linux (the distro formerly known as RHEL), and one of the pieces I’m looking at is OpenLDAP.

My first stage in the process was to get OpenLDAP set up with the right config — but when I started it, slapd complained about an error in slapd.conf. The overlay I was trying to use, it claimed, was not found. I spent the next couple of hours trying to find additional packages, trying different things, reading doco, searching Google, to no avail. The overlay I want is missing from Red Hat’s build of OpenLDAP.

So “boo hoo”, you say, “just build from source”. Well, remember how I said I was forced into RHEL? The corollary to that is that I am only allowed to use exactly what the Shadowman ships on the DVD. No build-from-source, no other OSS, is allowed.

But what does any of this have to do with Microsoft?

In my research, I found the release notes for Red Hat Enterprise Linux 5. In it was the following text (highlighting mine):

OpenLDAP Server and Red Hat Directory Server
Red Hat Directory Server is an LDAP-based server that centralizes enterprise and network data into an OS-independent, network-based registry. It is set to replace OpenLDAP server components, which will be deprecated after Red Hat Enterprise Linux 5. For more information about Red Hat Directory Server, refer to http://www.redhat.com/software/rha/directory/.

You guessed it: Red Hat Directory Server is a pay-for product. So Red Hat’s setting a direction here: server platforms comprising only the base OS, and additional function provided through extra-cost modules — now where have we seen this before?

Does this now mean that on RHEL-next, in order to run a Samba server with an LDAP IDMAP backend, companies will have to pay for RDS? That won’t fly at my work: “we already have a corporate directory, we’re not paying for another” will the customer sayeth.

“Okay”, you say, “so don’t use Red Hat”. As far as I’m allowed (this is at my employer remember) the only other choice is SLES… from Novell… that organisation that felt the need to cross-licence with Microsoft to “protect” against undisclosed and unproven patent infringement.

(Note that this post is not about Novell-Microsoft, nor is their deal a reason not to use SLES in my opinion. The thought only popped into my head because I was already thinking about Microsoft as a result of the Red Hat thing with RDS.)

So it seems like the two biggest names in corporate Linux are marching to Microsoft’s drum. Have I misread something? Am I overreacting?

Tags: , ,

Comments