Note: This howto requires a patch to your FreeBSD ports tree. The patch has been submitted to the FreeBSD port maintainers. I hope that it will eventually end up in the ports tree.

My initial readings about this was on the official Icinga docs covering installing Icinga on FreeBSD with IDOUtils.
However, as it turned out, the docs our a bit outdated, and yet do not reflect a way of doing the install using ports.

So here’s just a short primer on what I did do install Icinga from ports, imposing as little additional work four you, my fellow reader, as well

Now let’s turn to Icinga, which has a port on it’s own, which you’ll find it at /usr/ports/net-mgtm/icinga. First change to that directory.

cd /usr/ports/net-mgtm/icinga

Now download the patch file I made into your ports directory.
The patch will inject a new rc-script for ido2db and enable your port to build IDOutils.

[root@localhost /usr/ports/net-mgmt/icinga]# fetch http://phaq.phunsites.net/files/2012/01/patch_icinga_1.5.1_idoutils_fbs_port.txt

Then apply the patch like this:

[root@localhost /usr/ports/net-mgmt/icinga]# patch -p0 < patch_icinga_1.5.1_idoutils_fbs_port.txt
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- Makefile.org	2012-01-28 16:36:46.000000000 +0000
|+++ Makefile	2012-01-28 17:51:38.000000000 +0000
--------------------------
Patching file Makefile using Plan A...
Hunk #1 succeeded at 27.
Hunk #2 succeeded at 109.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2012-01-28 18:00:51.000000000 +0000
|+++ files/ido2db.in	2012-01-28 18:00:30.000000000 +0000
--------------------------
(Creating file files/ido2db.in...)
Patching file files/ido2db.in using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- files/pkg-message.in.org	2012-01-28 17:48:37.000000000 +0000
|+++ files/pkg-message.in	2012-01-28 17:49:38.000000000 +0000
--------------------------
Patching file files/pkg-message.in using Plan A...
Hunk #1 succeeded at 4.
done

Now you’re ready to configure the port:

[root@localhost /usr/ports/net-mgmt/icinga]# make config

Note the now IDOUtils option that now has appeared. Check it to enable IDOUtils.

Then compile and install as usual. The port will install also all required dependies, two of them being mysql55-client and libdbi-drivers, both to be found at /usr/ports/databases.

[root@localhost /usr/ports/net-mgmt/icinga]# make install clean

Afterwards, you should end up with a few additional files, which would not be installed with the stock FreeBSD port.

[root@localhost /usr/ports/net-mgmt/icinga]# ls -l /usr/local/bin/ido*
-rwxrwxr--  1 root  wheel  238326 Jan 28 16:53 /usr/local/bin/ido2db
-rwxrwxr--  1 root  wheel   80419 Jan 28 16:53 /usr/local/bin/idomod.o

[root@mgmp-bs01 /usr/ports/net-mgmt/icinga]# ls -l /usr/local/etc/rc.d/ido2db
-r-xr-xr-x  1 root  wheel  738 Jan 28 18:00 /usr/local/etc/rc.d/ido2db

Now you can enable Icinage and IDO2DB in /etc/rc.conf by adding these lines:

icinga_enable="YES"
ido2db_enable="YES"

Of course, you still need to perform the usual Icinga configuration steps, which are not covered in this post.
Please check with the official docs for this procedure.

If your configuration is proper, you should notice this in your logs indicating that IDOMOD (IDOUtils) is really working.

[1327773651] Icinga 1.5.1 starting... (PID=95448)
[1327773651] Local time is Sat Jan 28 18:00:51 UTC 2012
[1327773651] LOG VERSION: 2.0
[1327773651] idomod: IDOMOD 1.5.1 (09-09-2011) Copyright (c) 2005-2008 Ethan Galstad (nagios@nagios.org), Copyright (c) 2009-2011 Icinga Development Team (http://www.icinga.org))
[1327773651] idomod: Successfully connected to data sink.  26 queued items to flush.
[1327773651] idomod: Successfully flushed 26 queued items to data sink.
[1327773651] Event broker module '/usr/local/bin/idomod.o' initialized successfully.
[1327773651] Finished daemonizing... (New PID=95450)

That’s it, you conquered the beast!

Now, I made up a similar script to do the same on OS X.

The basic idea, now and then, was that I would not want to send all traffic through the VPN.
Thus the script will assist in restoring your local default route after the VPN connection is established.
Furthermore, it’ll add some specific routes directed to the VPN.

This way, all your usual traffic (internet, surfing, skype, whatever) is sent through your default gateway, while more specific routes (your business stuff) is sent through the VPN.

Below’s the code for the initial release. It may lack some details yet, like auto-detecting the tunnel device name, but it does the job already.

Just copy the code into Apple Script Editor and save it to a convenient location. Make sure you save it as “Application” and not as “Script” (which is the default). You you don’t, double-clicking the script will open the Script Editor instead of executing the script. Surely, not what you want.

Pay attention to the variables on the top, which need to be edited before you save the Script: _vpn_name, _default_gw, _networks, and _sudo_password (optional).
I hope directions are clear enough from the comments sections.

# VpnInit
# ---
# an AppleScript utility to connect your vpn,
# restore local default route and add selected
# routes directed to the VPN only
# thus you'll end up sending only selected
# traffic through the VPN, while the rest
# goes through your local default gateway
# as usual
# ---
# released "as is" under the terms of GPL v2.
# Copyright © 2011 Gianpaolo Del Matto
# 
# r0.1 initial release 2011/12/29
#
# ToDo:
# - hardcoding the "sudo" password is a bad idea, maybe
#	need a better way to get away with it
# - vpn tunnel (utun0) is still hardcoded,
#	should be auto-detected
#

# the name of your vpn connection
#
set _vpn_name to "My VPN"

# your local default gateway
#
set _default_gw to "192.168.1.1"

# your remote networks to pass via VPN, separate multiple with comma
# like so: {"1.2.3.4/30", "5.6.7.8/30"}
#
set _networks to {"192.168.2.1/24"}

# your super-user (root) password
# actually needed to bypass the prompts
# leave empty to get prompted
#
set _sudo_password to ""

# ##################################################################
# DO NOT CHANGE ANYTHING BELOW
# ##################################################################

# kindly borrowed from
# http://www.macosxautomation.com/applescript/uiscripting/index.html
# make sure that support for assistive devices is enabled
#
tell application "System Events"
	if UI elements enabled is false then
		tell application "System Preferences"
			activate
			set current pane to pane id "com.apple.preference.universalaccess"
			display dialog "This script requires access for assistive devices be enabled." & return & return & "To continue, click the OK button and enter an administrative password in the forthcoming security dialog." with icon 1
		end tell
		set UI elements enabled to true
		if UI elements enabled is false then
			display dialog "This script cannot run while access for assistive devices is disabled." & return & "Exiting now." buttons {"OK"} with icon 2
			return "user cancelled"
		end if
	end if
end tell

# now dive into the VPN setup part
#
tell application "System Events"
	set _if_tunnel to "utun0" #	do not change, will be auto-detected, just giving a reasonable default
	tell current location of network preferences
		if exists service _vpn_name then
			# try to connect the VPN service if it's disconnected
			#
			if current configuration of service _vpn_name is not connected then
				connect service _vpn_name
			end if

			# give it some time to settle
			#
			set _retval to false
			repeat until (_retval) is true
				set counter to 0
				repeat while counter is less than 16
					# exit if we get connected
					#
					if current configuration of service _vpn_name is connected then
						set _retval to true
						exit repeat
					end if

					# opt for exit if still not connected after 15 seconds
					#
					if counter is equal to 15 then
						display dialog "VPN '" & _vpn_name & "' is still not connected after 15 seconds. Do you want to keep waiting?" with title "VPN still not connected" buttons {"Yes", "No"}
						if button returned of result is "No" then
							# bail out if user decided not to wait any longer
							#
							set _retval to true
							return
						else
							# otherwise reset the counter so we can trigger again
							#
							set counter to 0
						end if
					end if

					set counter to counter + 1
					delay 1
				end repeat
			end repeat

			# now go to post processing and to the following:
			# - delete default route via vpn
			# - restore original default route
			# - add specific routes to vpn
			#
			if current configuration of service _vpn_name is connected then
				# restore local default route
				#
				do shell script "route delete default" password _sudo_password with administrator privileges
				do shell script "route add default " & _default_gw password _sudo_password with administrator privileges

				# inject custom routes via VPN
				#
				repeat with _network in _networks
					do shell script "route add -interface " & _network & " utun0" password _sudo_password with administrator privileges
				end repeat
			end if
		else
			# bail out if the VPN service does not exist
			#
			display dialog "Given VPN '" & _vpn_name & "' does not exist. Please check the name"
		end if
	end tell
end tell

Auch wenn der CentroGrande als Consumer-Gerät positioniert ist, wäre für mich – und wohl auch einige andere – SNMP das Mittel der Wahl zur Überwachung des Geräts wie auch des Netzwerks.

Wenn man die normalerweise deaktivierte Pirelli Management Console auf dem Router aktiviert, gelangt man zwar an einige offiziel nicht zugängliche Funktionen, SNMP ist da aber definitiv nicht dabei. Zwar kann man über die Pirelli Console die Konfigurationsdatei einsehen – und findet dort auch Hinweise auf SNMP – doch selbst wer des SNMP-Feature in der Konfiguration manuell aktiviert, wird nach einem Neustart bitter enttäuscht: Weit und breit kein SNMP aktiv

Glücklicherweise kann man aber auch für den CentroGrande Interface-Statistiken erzeugen, auch wenn man dafür gewissermassen mit der Kirche ums Dorf herum gehen muss.

Der Trick liegt im Command Line Interface, welches per Telnet und SSH erreichbar ist. Hier kann mit dem Befehl “net ifcnt all” für jede Schnittstelle des Routers eine Statistik ausgegeben werden.
Ersetzt man das Schlüsselwort “all” durch die Interface-Bezeichnung, bspw. “wl0″, erhält man die jeweiligen Einzelstatistiken.

Im folgenden Beispiel werden die Statistiken zur WAN-Schnittstelle angezeigt:


[~] # ssh admin@192.168.100.254
OpenRG> net ifcnt eth5.10
---- Driver statistics: port "LAN Fiber VLAN 10" ----
Device name: eth5.10 - Type: 48, Ethernet
Network = WAN
Port status = Connected
Counters
Rx Packets: 2006090
Tx Packets: 2477100
Rx Bytes: 835058499
Tx Bytes: 2356068887
Rx Pkts Errors: 0
Tx Pkts Problems: 0
Rx Dropped Pkts: 0
Tx Dropped Pkts: 0
Rx Multicast Pkts: NA
Tx Multicast Pkts: NA
Rx Broadcast Pkts: NA
Tx Broadcast Pkts: NA
Collisions: NA

Returned 0
OpenRG>


Wer sich in der Pirelli Console schon umgesehen hat, ist vielleicht angesichts der vielen Schnittstellen etwas überfordert.
Die gute Nachricht: Die meisten davon braucht’s nur für interne Zwecke und sind für die Überwachung kaum relevant. Daher hier eine Auflistung der notwendigen Schnittstellen und deren Funktion:

eth0         Switchport 1
eth1         Switchport 2
eth2         Switchport 3
eth3         Switchport 4
wl0          WLAN Access Point
eth5.10      WAN Schnittstelle (Fiber oder DSL)

Damit diese Daten nun für Cacti nutzbar werden, bedarf es eines Hilfsprogramms, welches folgende Schritte durchführt:

• Login auf den Router
• Abrufen der Interface-Ststistiken
• Ausgabe der bereinigten Informationen

Gerade letzterem kommt eine grosse Bedeutung zu, da die Ausgabe wiederum scriptbasiert verarbeitet werden soll und somit normalisiert werden muss.
Wie dies im Detail aussieht, beschreibt die Cacti-Dokumentation.

Basierend auf einem Beispiel-Script aus dem py-expect Package habe ich eine stark abgewandelte Version erstellt, welche allein dem Auslesen des CentroGrande dient und vollständig parametrisierbar ist.
Damit das Script ausführbar wird, sind zum Beispiel unter Debian die Packages python2.5 und python-pexpect erforderlich.

Das ganze sieht beim Ausführen dann wie folgt aus:

[~] # /opt/sbin/cg_ifstats.py -u admin -p password -h 192.168.100.254 -i wl0
RxBytes:4230422745 TxBytes:3249795610

Damit steht bereits der erste Baustein bereit. Nun muss Cacti noch entsprechend eingerichtet werden, damit die Script-Ausgabe zur Erstellung von Statistiken verwendet werden.

Anweisungen dazu finden sich ebenfalls in der Cacti-Dokumentation.

Die nachfolgenden Schritte verdeutlichen dies anhand einiger Screenshoots.
Man kann – und darf – es sich aber auch ein bisschen einfacher machen und einfach das Data Template mit den Abhängigkeiten direkt importieren.
Das Data Template kann zusammen mit dem Python Script hier heruntergeladen werden.

Wer die erforderlichen Schritte selbst durchführen möchte, erstellt zuerst eine sogenannte Date Input Method nach dem gezeigten Vorbild.
Dabei müssen insbesonders die Input wie auch die Output Fields erfasst werden (auf Schreibweise achten).
Die Data Input Method wird unter der Bezeichnung “CentroGrande – IFSTATS” gespeichert.

Anschliessend wird ein neues Data Template mit der Bezeichnung “CentroGrande – Traffic” erzeugt.
Unter Data Input Method wird die zuvor erstellte Datenquelle “CentroGrande – IFSTATS” verwendet.

Weiterhin benötigt das Data Template die Quelldatensätze, “traffic_in” und “traffic_out”. Diese werden mit den einzelnen Zählern der Data Input Method “CentroGrande – IFSTATS” verbunden, also “traffic_in” mit “RxBytes” und “traffic_out” mit “TxBytes”.
Wichtig ist, dass als “Data Source Type” der Typ “COUNTER” verwendet wird.

Unter “Custom Data” wird bei allen Feldern die Checkbox “User Per-Data Source Value” markiert.
Dies ist erforderlich, damit beim folgenden Erzeugen der Graphen die Werte pro Host und Datenquelle einzeln definiert werden können.

Nun fehlt das Graph Template. Hierfür klont man am einfachsten eines der bestehenden Graph Templates, beispielsweise “Interface – Traffic (bits/sec, Total Bandwidth)”.
Das geklonte Graph Template bedarf noch einiger Anpassungen, insbesonders bei den Graph Template Items und Graph Item Inputs.
Als Letztere dienen die bereits zuvor definierten Datenquellen “traffic_in” und “traffic_out”.

Die Datenquell muss auch bei den Graph Template Items noch entsprechend zu “traffic_in” und “traffic_out” angepasst werden.

Damit wäre soweit alles vorbereit, dass nun ein Host-Objekt für den Centro Grande erfasst werden kann.
Anschliessend werden dem Host-Objekt neue Graphs hinzugefügt.

Je nach Bedarf werden für einzelne oder alle Schnittstelle (wl0, eth5.10, eth0, usw) die Graphen erzeugt.
Dazu muss man zur besseren Unterscheidung unter Title auch die jeweilige Schnittstellenbezeichnung ergänzt werden.
Ferner sind in den Feldern für Username, Passwort, Hostname und Interface die erforderlichen Daten einzutragen.

Nach Abschluss aller Schritte lassen sich fortan die erzeugten Graphs in Cacti bewundern.

Angesichts der Komplexität der vielen Funktionen mag es für die breite Masse durchaus Sinn machen, hier den vielfältigen Funktionen, die das von Pirelli Broadband Solutions stammende Gerät eigentlich mitbringt, einen Riegel vorzuschieben – schliesslich werden dann weniger versierte Anwender auch nicht dazu verleitet, etwas zu verkonfigurieren.
Wer allerdings etwas tiefergehende Konfigurationswünsche hat, wird es zu schätzen wissen, dass man über die Hintertür dennoch an die erweiteren Funktionen des Geräts rankommt.

Ich möchte an dieser Stelle noch darauf hinweisen, dass das nachfolgend beschriebene Vorgehen von Swisscom NICHT unterstützt wird, und dass man bei allfälligen Problemen auf sich alleine gestellt ist. Wer auf dem Centro Grande die versteckten Funktionen freischaltet, tut dies also auf eigene Verantwortung.

Bitte beachten: Die Anleitung gilt für die Pirelli-Router und nicht für die Motorola-Geräte!

Darum sollten die an dieser Stelle nur die Hartgesottenen weitermachen, die wissen was sie tun.

Wie kommt man nun also an diese “Magic Features” ran? Sehr simpel, einfach über die Befehlszeile eine Telnetverbindung auf die IP-Adresse des Centro Grande aufbauen:


telnet 192.168.2.1


Ach ja, wer Windows Vista/7 einsetzt, hat standardmässig kein Telnet mehr installiert. Dies kann über die Systemsteuerung nachinstalliert werden. Alternativ kann ich auch PuTTY empfehlen.

Nach erfolgten Login mit dem admin-Konto (das Passwort dazu kann man bei Bedarf im Swisscom Kundencenter abfragen), muss man folgenden Befehl eingeben:


conf set wbm/admin_wbm a25B06c81


Dies aktiviert die originale Pirelli Management Console, allerdigs erst nach einem Neustart, der mit folgendem Befehl ausgelöst wird:


system reboot


Und hier das ganze am Stück:

mbp:~ Gianpaolo$ telnet 192.168.2.1
Trying 192.168.2.1...
Connected to 192.168.2.1.
Escape character is '^]'.
Username: admin
Password: ***********
OpenRG> conf set wbm/admin_wbm a25B06c81

Returned 0
OpenRG> system reboot
Connection closed by foreign host.
mbp:~ Gianpaolo$

Nach dem Neustart verfügt der Router über zwei Web-Interfaces, einmal das Bekannte von Swisscom unter http://router-ip/ und ein zweites unter http://router-ip/admin.html.

Zugang erhält man mit dem bereits zuvor verwendeten admin-Konto. Gut, es sieht zwar nicht so hübsch aus, wie das Swisscom-eigene GUI, aber dafür kommt man an all die schönen Funktionen ran

Und was kann das Ding nun so alles?

Neben den USB-Ports, an die man beispielsweise USB-Festplatten oder -Drucker anschliessen kann, sind vor allem die VPN-Funktionen oder der Zugang zum lokalen DNS-Server häufig genutzte Power-Features. Ebenso kommt man an die erweiteren Einstellungen fürs WLAN heran, kann manuelles Routing oder Bridging konfigurieren. Auch lässt sich Remote Management konfigurieren und – auch bisweilen hilfreich – die DHCP Lease Time heraufsetzen.
Dazu kommt noch jede Menge weiterer Brimborium, aber das findet ihr am besten selber raus.

Kleiner Tipp am Rande: Von den TR069-Einstellungen unterhalb der Fernverwaltung sollte man tunlichst die Finger lassen – ebenso wie vom händischen Editieren der Konfigurationsdatei
Diese sind für das Remote Management und Upgrade durch Swisscom erforderlich. Im dümmsten aller Fälle könnte eine Fehlkonfiguration dazu führen, dass man kein neues Firmware-Upgrade bekommt, was einen unter Umständen plötzlich Offline und mit abgesägten Hosenbeinen dastehen lässt.

Viel Spass mit dem aufgebohrten Centro Grande

Since no ‘sleep’ exists, the ‘after’ command will do. Just supply it with the timeout in milliseconds, like this for a 10-second timeout:

after 10000

Or, with a bit more overhead, but some may think it’s more readable:

after [expr {int(10 * 1000)}]

So here’s a snippet, that makes them look neat, so I can work with simple and unified looking device IDs.

Just make sure to fill in your hostnames and the SNMP community.

#!/usr/local/bin/perl -w

foreach $_SITE ('hostname1', 'hostname2', 'hostname3', 'hostname4') {

        my $_cpe_snmp_router_type = `/usr/local/bin/snmpget -v2c -c SNMP_COMMUNITY_NAME $_SITE .1.3.6.1.4.1.9.3.6.11.1.3.1`;

        print "debug: $_snmp_router_type \n";

        if ( $_snmp_router_type =~ /.*=\sSTRING:\s\"[cC]?(\d+[a-zA-Z0-9]+?)(?:\s.*)?\"/ ) {
                print "router type: $1 \n";
        } else {
                print "error: failed on extracting device ID!\n";
        }
}

And here’s what we get as output from this script:

debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "886"

router type: 886
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "887VDSL2"

router type: 887VDSL2
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "c2851 Motherboard with 2GE and integrated VPN"

router type: 2851
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "C836"

router type: 836
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "887VDSL2"

router type: 887VDSL2
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "C836"

router type: 836
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "877"

router type: 877
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "871"

router type: 871
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "1803"

router type: 1803
debug: SNMPv2-SMI::enterprises.9.3.6.11.1.3.1 = STRING: "876"

router type: 876

Well, yes, but this does apply to each and every situation.
Splitting the authoritative server and the cache has it’s benefits (and I’d recommend to do this in most cases), especially when it comes to service availability and – to some degree – protection against DDoS. Though it has some drawbacks, amongst them the need for more resources, either in the form of separate boxes, virtual servers or even running the daemon twice on the same box.
In some scenarious, you’re just bound to the fact, that you’re limited in resources and simply can’t run two daemons. Or you need to take extra steps to have your operating system support running two daemons concurrently. Most do not allow that out-of-the-box, so you’ll find yourself struggling with copying init-scripts and directory structures. This may even break on the next distro upgrade, so maybe it’s better to not even bother

Si, even if it may not be best practice, I want to look into a all-in-one solution for the scenario below:

I have a server, that is connected to the internet on one network interface. The machine acts as authoritative nameserver for a few domains, thus effectively hosting some DNS zones and being the master for them.
As I’m not too happy with static DNS zone files, I configured the host to serve out it’s authoritative zone data dynamically through the BIND-DLZ (dynamically loadable zones) extension.
Let’s call this the ‘external’ view, so it’s actually what we see from the public internet.

Now, the very same server runs some services locally, like an MTA (mail transfer agent) for example.
The DNS server also listens to the loopback interface 127.0.0.1, which was added as first name server in /etc/resolv.conf. Why should we use an external name server if we have one locally already?

Everyone familiar with this kind of topic may notice, that this could actually lead to some issues in a real production environment.
Let’s asume that a new DNS zone for ‘microsoft.com’ is being added to our authoritative name server.

Since we didn’t take any special precaution, the following will happen when we send an email message to microsoft.com through our local MTA: First the MTA will look in /etc/resolv.conf for any valid name server. Since we listed 127.0.0.1 as first name server, that’s the one being queried first.

Remember that we added ‘microsoft.com’ as authoritative (primary) zone to our local name server?

Well, for sure, we wouldn’t want to host ‘microsoft.com’ on our own system. That can only be wrong. You may as well substitute any other domain here, which will propably never be hosted with you (yahoo.com, google.com, etc). But as soon as you run some sort of hosting business, you may well end up in situation, that some dumbass will eventually bypass your nice input filters

So we end up with our own local name server replying to us with a obviously wrong SOA for the zone ‘microsoft.com’. Even worse, we get wrong MX records as well, so our MTA will deliver the messages to a totally wrong destination. Sure not what we want!

To solve this when running with traditional BIND zone files, you’d simply extended your named.conf to have multiple views. So you’d add your authoritative zones to an outside view (requests coming through the public/outside interface), while adding an inside or local view (for requests coming through the local network or loopack interface), where no zones are to be added.

So the question arises if it is possible to incorporate this kind of setup with BIND-DLZ zones setup?

After some testing, the answer to this is clearly yes. Though I must admit I have only tested this with DLZ’s file-system driver, I think it should actually work with other DLZ drivers as well.

Let’s look at a very basic named.conf (I omitted most of the options for better readability) with DLZ:


options {
directory "/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on { any; };
};

dlz "file system zone" {
database "filesystem ./dns-root/ .dns .xfr 0 ~";
};


This would just enable a authoritative and recursing name-server, which has it’s dynamic DLZ zones within the ‘dns-root’ directory, but with that exact behaviour as mentioned before.

So, we should now add two views, and external view and a internal view. How do we take them apart? Simple answer: by their source address. Since we run our local cache only through the localhost interface, any request coming from that source should be directed into the internal view.
On the other hand, all requests not coming from the localhost source shall be put into the external view. It may especially important that we then disable recursion on the external view.


options {
directory "/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on { any; };
};

zone "." { type hint; file "/etc/namedb/named.root"; };
};


Now let’s check if this holds true. First I query my authoritative domain ‘example.org’ through the hosts public IP on 192.0.2.11


$ dig @192.0.2.11 example.org

;; AUTHORITY SECTION:
example.org. 3600 IN SOA mynameserver.example.org. hostmaster.example.org. 2004070101 10800 3600 604800 86400


Now I do the same for the domain ‘microsoft.com’:


$ dig @192.0.2.1 microsoft.com

;; QUESTION SECTION:
;microsoft.com. IN A


As expected I get no reply (actually it’s refused, since recursion is turned off).

Now I query again for example.org, but this time not on the external but on the loopback interface.


$ dig @localhost example.org

;; ADDITIONAL SECTION:
a.iana-servers.net. 1800 IN A 199.43.132.53
a.iana-servers.net. 1800 IN AAAA 2001:500:8c::53
b.iana-servers.net. 1800 IN A 199.43.133.53


Here I get the reply through dns recursion. Thus indeed my local zone for ‘example.org’ is completely ignored, despite we run the authoritative zone from the same instance.

So to summarize: Even when running my authoritative zones off BIND-DLZ, adding views to BIND can still divide one single BIND instance into authoritative and recursing-only instance without interfering with local services, even if a domain is erronously added the the authoritative view.

As a plus, I tested if it’s possible to run different BIND-DLZ namespaces for external and internal views. The good news: This also works fine. The config, in the example of the DLZ file system driver, may look like this:


options {
directory "/etc/namedb/working";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
listen-on { any; };
};

dlz "file system zone" {
database "filesystem ./dns-root-int/ .dns .xfr 0 ~";
};
};


In this example, I just added two separate DNS root directories, each of which can hold different authoritative zone data. Thus you can really take full adtvange of the BIND split views by having the very same domains an external and an internal set of records, each separate of the other.

Quiet cool, isn’t it?


!
interface BRI0
no ip address
encapsulation hdlc
shutdown
!


And here the same again without the ‘stutdown’ statement:


!
interface BRI0
no ip address
encapsulation hdlc
!


Thinking about a case where you want to extract just these blocks from multiple config files, but only if they don’t contain the ‘shutdown’ statement. The solution to this with Regular Expressions is called negative look-ahead, so to speak “match something not followed by something else”.

The trick is to make anchored matches within the context we’re searching.
Looking at the block, we get multiple anchors:

• ‘interface’ following by the interface name and line feed/carriage return as our beginning marker
• a line starting with an exclamation mark marking the end of the block
• any number of lines in between starting with at least 1 whitespace character

So an extended expression, which would match just this criteria looks like this:

/^interface .*[\r\n]+(?:^\s.*[\r\n])+(?:^![\r\n]+)+/m

This would match any interface configuration block.
Now if we want only the interface in ‘no shutdown’ state, we add a negative look-ahead which can be spoken of as this:

• any number of lines in between starting with at least 1 whitespace character NOT followed by the word ‘shutdown’

Thus, our expression now looks like this:

/^interface .*[\r\n]+(?:^\s(?!shutdown).*[\r\n])+(?:^![\r\n]+)+/m

This will return just the matches for interfaces in ‘no shutdown’ state.


$ cd ~/Downloads


Now fire up the web server like this:


$ python -m SimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...


This will bind to port 8000 by default. To use another port, just give the TCP port as an additional argument on the command line:


$ python -m SimpleHTTPServer 8100
Serving HTTP on 0.0.0.0 port 8100 ...


To access the server, open the link as http://Your-Macs-IP-Address:8000 (or http://Your-Macs-IP-Address:8100 for the second example).
This will provide you with a simple file list to browse and access your files.

You won’t be able to bind to the HTTP default port 80 with regurlar user accounts however. This will only yield a “socket: [Errno 13] permission denied” error message.

To bind to port 80, you need to run the command through ‘sudo’ like this:


$ sudo python -m SimpleHTTPServer 80
Password:
Serving HTTP on 0.0.0.0 port 80 ...


The server will stay in foreground of the Terminal and keep running until you hit CTRL-C.

If you want to know why I needed this, then read on my efforts on upgrading Squeezebox Radio firmare.

Installing QPKG packages is made easy, just download the QPKG to your computer and install them from the QNAP admin panel.
You’ll find further readings on this topic on the QNAP homepage.

If you have just a brand new setup of Optware, you must enable it to run startup scripts automatically as pointed out in QNAP Wiki in section Running /opt/etc/init.d/* on startup.

If have you have already some services installed through Optware, like cron or snmpd, then the next step is not required.
Otherwise, you may need to create a few directories and set proper permissions, as these may not yet exist.

mkdir -p /opt/sbin /opt/etc/init.d
chown admin:administrators /opt/sbin /opt/etc/init.d
chmod 755 /opt/sbin /opt/etc/init.d

So, after you successfully installed Optware (IPKG), let’s move on with our backlight stuff.
Save the code below to a new file at /opt/sbin/lcd_backlight.

#!/bin/sh
#
# lcd_backlight - tries to keep front lcd lit at all times 
#
while [ : ]; do
	# redirect lcd_tool output to nirvana
	# occasionally there'll be a 'cannot control LCD' message
	# but well, actually, who cares? 
	/sbin/lcd_tool -o > /dev/null 2>&1
	/bin/sleep 5
done

Don’t forget to make the new script executable:


# chmod 755 /opt/sbin/lcd_backlight


Now, you can always login through SSH and run /opt/sbin/lcd_backlight to have LCD backlight permanently turned on.

Maybe you want this to start automatically every time you reboot the box?
Add another script at /opt/etc/init.d/S99lcd-backlight with this contents:

#!/bin/sh

RETVAL=0
QPKG_NAME="LCD_Backlight"
QPKG_DIR=

_exit()
{
    echo -e "Error: $*"
    echo
    exit 1
}

case "$1" in
  start)
	echo "Enabling permanent LCD backlight ..."
	/opt/sbin/lcd_backlight &
	RETVAL=$?
	;;
  stop)
	echo "Disabling permanent LCD backlight ... "
	/bin/ps aux|/bin/grep lcd_backlight|/bin/grep -v grep|/bin/grep -v stop|/bin/awk '{ print $1 }'|/usr/bin/xargs kill -9
	RETVAL=$?

	/bin/sleep 3
	;;
  restart)
	$0 stop
	$0 start
	RETVAL=$?
	;;
  *)
	echo "Usage: $0 {start|stop|restart}"
	exit 1
esac

exit $RETVAL

Make this executable as well:


chmod 755 /opt/etc/init.d/S99lcd-backlight


This hack will permanently enable the LCD backlight. Even that the output is suppressed, it shall be noted that the ‘lcd_tool’ binary spills a ‘Cannot control LCD’ message every now and then. This seems to mean no harm. However, enabling the LCD backlight permanently is probably neither intended nor supported by the vendor. You do this at your own risk.