Tuesday, 27 October 2015

Nagios Script to Monitor HP/Kyocera Printer Toner Levels via SNMP

We look after a client that has a large number of printers spread over multiple sites.  Here's a quick and dirty script I created to monitor their toner levels using Nagios and SNMP:


It works surprisingly well as a reminder to check they've got supplies on hand, and when historical performance data is gathered (we use pnp4nagios) you get useful trends to estimate how often replacement toner cartridges are required:

Adding it as a command is fairly straightforward:

define command {
    command_name check_toner
    command_line /usr/local/lib/nagios/plugins/check_toner -H '$HOSTADDRESS$'

You can then use check_toner in any service definition but I recommend creating a hostgroup for printers and defining the check for the whole hostgroup.

Preventing Ransomware and Other Malware with Software Restriction Policy


Please be certain you know the impact of any Group Policies you implement.  Releasing a misconfigured Software Restriction Policy on a production system can and will stop key applications working.  There is a famous example here:
Please check, before rolling out any Group Policy Object, that Active Directory is healthy, that functions such as replication are working correctly.


The steps below summarise how to configure Software Restriction Policies to allow a whitelist of applications, or folders where it is acceptable for applications to run, in an Active Directory domain environment.  For simplicity’s sake, it is assumed that the end user is not a local administrator on their own work PC.  This is an important point.  In order to safely whitelist “C:\Program Files\”, for example, it is necessary that the end user cannot write to that directory.  This procedure will not work and should not be followed in an environment where users have local administrator access.

To implement SRP

Run Group Policy Management on a computer that will allow access to the AD domain’s Group Policy Objects.  The example below is from an SBS Server.

From the Group Policy Objects container, select Action Menu then New.  Create two new Group Policy Objects named “SRPs - enable” and “SRPs - remove”.  Note:  these already shown in the above screenshot.  The reason for the second GPO is to allow for a particular PC to be removed from SRP restrictions quickly if required.

At this point, pause in the Group Policy Management tool and create two Active Directory Security Groups in an OU accessible to the computers that will have the SRP implemented.  These can be called “SRPs - enable” and “SRPs - remove” again (the names of the groups and the GPOs are arbitrary. If a naming convention exists, it should be used).  Eventually, PCs will be brought in to the SRP by making them members of the “SRP - enable” AD group, but for the moment to not add any members to either of these.

Returning to Group Policy Management, set the “Filtering” on the Group Policy Objects that have been created so that only PCs that are members of the AD groups are impacted by SRP.  Under “Security Filtering” click the Add button.  For the “SRPs - enable” GPO add the “SRPs - enable” AD group here and, similarly add the “SRPs - remove” group to the “SRPs - remove” GPO.  See below:

Still in Group Policy Management, right click on the “SRPs - enable” and select Edit.  Expand Computer Configuration - Policies - Windows Settings - Software Restriction Policies.
Under “Security Levels” right click “Disallowed”.  Go to Properties in the menu and click on “Set as Default” (This is already set below, which is why it is greyed out.)

Now go to “Enforcement” and set as below.  Note that there are no certificate based exceptions in this implementation.

Continuing, go to “Designated File Types” and remove “LNK” from the list.  This allows the use of Desktop shortcuts, for example.

At this point it is necessary to add the exceptions - ie the locations where programs will be allowed to run.  Go to “Additional Rules”.  The screen will look something like this (some names have been removed for privacy):

What is entered here will depend on each environment.  Usually as a minimum it is necessary to add:
C:\Program Files\
C:\Program Files (x86)
\\SERVERNAMEDC1\netlogon  (in a domain environment)
\\SERVERNAMEDC2\netlogon  (if there are multiple domain controllers, list each netlogon share)

If there are Windows 8 clients add:
C:\Program Files\WindowsApps

If network paths are required UNC notation must be used - ie \\server\share.  Variables such as %appdata% can be used.

The "SRPs - enable" GPO is now configured.  To bring PCs under the SRP umbrella all that is now required is to make the PC a member of the "SRPs - enable" AD group.  PCs should be added in a controlled manner to allow for testing.  There will almost certainly be a requirement for the Additional Rules to evolve in a large or diverse environment.

To configure the "SRPs - remove" GPO, right click on it and select Edit.  Go to “Security Levels” and change the default to “Unrestricted”.

It will now be possible to apply/remove the SRP based on membership of the AD groups, remembering that it will probably be necessary to run “gpupdate /force” on the client after making changes.

Thursday, 22 October 2015

NBN Users - will your phone work when the power is off?

An "old fashioned" telephone line will work during a power outage. If you have a handset that does not need power (ie an old fashioned one) you will be able would be able to make a call when the power is off. With an NBN service this is not the case. NBN installations have included battery backups so that phones will work during power cuts. But, it seems these batteries were not of the highest quality...

Tuesday, 20 October 2015

If you ever wondered what those pesky license agreements actually say...

Thanks to Rob Shecter here is a summary.


Combating ISP Bill Shock

When starting a new data service, one of the common issues is bill shock. Excess usage can often lead to a bill in the hundreds or even thousands of dollars, and by the time you know this is happening, it's too late. Arguing the point with your provider can often be difficult - when all you have is your word versus their potentially incorrect data.

To try and improve our odds in this situation, we keep tabs on the data usage ourselves. With a Raspberry Pi (or other computer) and any half-decent router, you can automatically gather the necessary data and have something to challenge your ISP with in the event any excessive bills arrive. Generally speaking we like to use Mikrotik routers, but we have also set this up with Cisco and Snapgear devices too.

The advantage of a Raspberry Pi is that it's cheap, tiny and if you know Linux - easy to set up.


The Raspberry Pi (or other Linux-based device) is up and running.
You have SNMP enabled on your router.
You have created a user on your Pi called "monitor" - which you'll use to run RTG.


Install mysql if it's not already installed:
$ sudo apt-get install mysql-server
- Remember the root password you enter here. We'll need it later.

Set up email:
$ sudo apt-get install exim4 exim4-config
$ sudo dpkg-reconfigure exim4-config
Tell it you have a smarthost but no local mail. When it asks for a smarthost, give it the address of your ISP's mail server.

Installing RTG (version 0.7.4 is current at the time of writing):
$ sudo apt-get install libmysqlclient-dev libsnmp-dev zlib1g-dev libdbi-perl libsnmp-session-perl mysql-client libsnmp15 screen
$ wget http://downloads.sourceforge.net/project/rtg/rtg/0.7.4/rtg-0.7.4.tar.gz
$ tar xzf rtg-0.7.4.tar.gz
$ cd rtg-0.7.4
$ ./configure --bindir=/home/monitor/rtg --sysconfdir=/home/monitor/rtg --with-mysql=/usr --with-snmp=/usr --prefix=/home/monitor/rtg
$ make
$ make install
$ mkdir ~/rtg
$ cp etc/createdb bin/report.pl etc/rtg.conf etc/rtgtargmkr.pl ~/rtg
$ cd ~/rtg
Create the database:
$ ./createdb mysqlrootpassword
- Substitute your root password here.

Configure RTG:

Edit the "/home/monitor/rtg/etc/routers" file. Delete the existing entries there, and add the following line to the file:
- substitute the IP address of your router for the address here.

Now create a targets.cfg file with the rtgtargmkr.pl script. You should see something along the lines of the following:
$ ./rtgtargmkr.pl
Poking (public) (32 bit)...
No router id found for
No id found for ether1 on device 1...adding.
No id found for ether10 on device 1...adding.
Now, tell RTG's polling script to run on bootup. Add the following to /etc.rc.local, before the "exit" line:
su -l monitor -c "screen -dmS rtgpoll /home/monitor/rtg/rtgpoll -vvv -t /home/monitor/rtg/targets.cfg -c /home/monitor/rtg/rtg.conf"

And lastly, set up a daily report email:
$ crontab -e
23 59 * * * /home/monitor/rtg/report.pl \% -01d | mail -s "Daily bandwidth utilisation" [email protected]
Now, what we hope to achieve with all of this, is a daily email that looks like the following:
                                In      Out  Avg In Avg Out   Util   Util  Max In Max Out Max Ut Max Ut
Connection                  MBytes   MBytes    Mbps    Mbps   In %   Out%    Mbps    Mbps    In%   Out%
ether1      281    7,800    0.03    0.72   0.00   0.07    0.22    7.04   0.02   0.70
ether3       12       62    0.00    0.01   0.00   0.00    0.01    0.24   0.00   0.02
ether5       24       64    0.00    0.01   0.00   0.01    0.01    0.01   0.01   0.01
ether10    9,410      406    0.87    0.04   0.87   0.04    8.58    0.26   8.58   0.26
wlan1    2,429    3,879    0.23    0.36   2.09   3.27    5.99    5.18  54.45  47.09
bridge1      350    9,338    0.03    0.87   0.03   0.87    0.19    8.49   0.19   8.49
ISP    9,217      281    0.86    0.03   8.60   0.30    8.40    0.16  84.00   1.60

Total:                      21,723   21,830    2.02    2.04                  23.4   21.38
Here, we can see exactly how much data went in and out of the Internet interface - we can then take those figures and compare them against what our ISP claims we used.

The small amount of time spent on setting this up will pay for itself when it comes to bill time - and if you're keeping an eye on the daily usage mail, hopefully you can spot excessive usage before it becomes a bigger problem.

Thursday, 15 October 2015

Office Relocations - what to consider for ICT

Moving offices can be expensive and disruptive.  The ICT side of an office move can add pain, expense and disruption.  Over the years we have managed many office moves from the perspective of making sure that the the technology is working on day one.  There are plenty of things that can go wrong during a move, technology or otherwise.  Avoiding a situation where no one can send an e-mail or make a phone call is not difficult.  Some things to look out for to assist with a smooth move.

It is never too early to talk to telcos

Telcos can handle relocations and provisioning for voice and data services on specific dates.  Telstra, for example, will carry out what they call a “relocation” on a booked date.  It just helps to give considerable time for the wheels of bureaucracy to turn.  As soon as dates are fixed book your telco.  In fact, this is so important, don’t fix the moving dates without having your telco(s) on board; unless you fancy a quiet e-mail and phone call free first few days in the new place.

Consider duplicating data services

From our own experience “relocating” (ie moving data services at the time of an office move) is a recipe for raised blood pressure and strained conversations with service providers, typically late on a Friday afternoon.  Consider connecting duplicate services at the new premises in advance.  This only works for data, not voice because of the way phone numbers are transferred.  If you have data services provisioned and tested at new premises you do bring things back into your control, for example amending DNS records.

Do the new premises have what we need?

This possibly should have been at the top of the list.  But, if you’ve got far enough to be booking in the telco you really should know by now that the infrastructure in the new premises meets your requirements.  Just in case you need to double check:  the cabling is OK (or finished)?  You have access to telephony frames and risers?  There is adequate capacity on telephony frames and risers?  The lift or building access is spacious enough for your equipment?  A removal team, paid by the hour, waiting by a 2m high lift with a 2.1m comms cabinet won’t improve your mood.

Beware the NBN

Continuing from the paragraph above and assuming you are in Australia.  For reasons that are not really clear getting an NBN connection to a new building, that the NBN Co address check says is NBN connected, can take months.

No to scope creep

It is very tempting to think “I could just install this” whilst you have some downtime.  Think long and hard about adding to the list of variables you may be wondering about come Monday morning.  Monday morning’s after office moves are for accepting congratulations for how smoothly it’s all gone and pretending the last 72 hours have not aged you prematurely, not fire fighting.

Beware Murphy’s

We have had telcos booked months in advance say words to the effect of “not going to happen today” on Friday afternoon (not often, but it has happened).  Back in the days before ubiquitous fast data connections I have had to motorcycle courier large quantities of data, have booked and paid for two couriers for the entire day (in case one fell off!) only to have the first one take four hours to so 100kms (the Gantt chart allowed two hours for this).  We have had equipment go missing, and defamed the perfidy of movers, only for it to turn up in a hidden box two years later.  One for TCP/IP types:  you would never expect to have your new premises inadvertently connected to another tenant in your building (and this was a large office on Haymarket, in London, not a home help cabling job) and for them to share your IP address range!