Customizing Scripts on the Opengear ACM5004

As I mentioned in my “Auto-Response First Steps” post where I was configuring triggers and responses on the Opengear AC5004, I wanted to edit a built-in email alerting script to ensure that it was logging activity to syslog, but the script was in a readonly location. So what to do?

Multiple Approaches

Depending on exactly what you need to do with your customized response, there are a few of approaches that might work.

• Create and reference a totally new custom script
• Create a custom script that overrides the built-in script
• Create a custom firmware build that includes your script

I’ll look at these options in the order they’re shown above.

Create A New Script

This is the easiest option if you need to do something unique in response to a trigger. For example, if you need to send a string of text to a serial port when you detect particular activity occurring, you’ll create a bash script that sends the desired characters to the appropriate port. But where to create the script so that it persists through reloads?

Scripting as a whole is an area where, based on what I’ve found so far, it would be really helpful to have better documentation to get you started. Instead I’ve found myself reading scores of FAQs and slowly gathering enough tidbits of information to piece together the appropriate next steps. There is a handy area of the filesystem that is readwrite:

# mount | grep config
/dev/flash/configblock on /etc/config type jffs2 (rw,relatime)

So, /etc/config can be used to store scripts perhaps. Reading through the built-in scripts, as we’ll see in the next section, they check for the existence of scripts in /etc/config/scripts – a good sign that this is an appropriate place to put things. You’ll have to create that directory, mind you – it doesn’t exist out of the box.

So, SSH to the Opengear device, create the directory /etc/config/scripts, and then create your new script in that directory. To edit scripts, you’ll need to be handy with ‘vi’ – it’s the only text editor that’s installed by default as far as I can tell. The only installed shell is shells are ‘bash’ and ‘sh’, so that’s likely to be your default starting point although of course you can call other utilities from there, remembering that this is a very stripped down system.

Once your script is created (and tested, perhaps?) you can go back to the web interface and edit an Auto-Response action to point to your script, then see what happens. To debug the scripts, you could perhaps use the ‘logger’ utility to write information to syslog.

Override a Built-In Opengear Script

If you look back at my previous post where I needed to simply add an option to an existing script, this is probably the simplest way to go about it. As with the previous approach, you’ll need to create /etc/config/scripts first.

The built-in scripts are located in /etc/scripts, and all of them have a built-in override capability. Right at the start, they look for a script with the same name but located in /etc/config/scripts. Here’s an example from the alert-email script:

#!/bin/sh
if [ -f "/etc/config/scripts/alert-email" ]; then
exec "/etc/config/scripts/alert-email" $@
fi

This very simply means that if it finds a file called ‘alert-email’ in /etc/config/scripts, it will call that script and pass all its parameters over. Therefore, to customize the alert-email script, I need to take three steps. First, copy the built-in script:

cp /etc/scripts/alert-email /etc/config/scripts/alert-email

Second – and this is critical – edit /etc/config/scripts/alert-email and comment out or delete the code shown above that checks for the existence of another script. Think about it – if it runs with that code in place, the first thing it will do is to find itself, then call itself again, which will call it again, and again, and…likely repeating until the device falls over.

Then finally, you can make any changes you want. In my case I simply wanted to change this line:

options="--connect-timeout=60"

to

options="--connect-timeout=60 --syslog"

Now when I test any trigger that sends an email using the built-in email response, the original script it called, it finds my copied script (with the syslog option enabled) and runs that instead. Bingo – easy override with minimal new scripting required. I like very much that Opengear put this capability in – it makes it very easy to override default actions without making everything into a custom script and dealing with figuring out how to pass information back and forth to the script.

Create a Custom Opengear Firmware Build

Yes, this is complete overkill for the 9-character change that I wanted to make above, and is therefore a silly choice for this particular change. However, I wanted to experiment with custom firmware anyway, and this is certainly one way to achieve the end goal.

As I mentioned in my original overview of the Opengear devices, their devices are built on uClinux and other open source software, and they give you full access to them. This extends to the entire software build that’s installed on the device. There is a downside of course – as you’d expect, once you start fiddling with the firmware, the support you get from Opengear is going to drop significantly as you move to, effectively, an unsupported platform. In all likelihood though, the kind of people who are likely to create their own firmware build are also likely to be advanced enough to support themselves, and Opengear commented that this is exactly how it seems to work out.

I’ll create a separate post going through the exact steps I took to create a new firmware build, but at a high level it involved:

• Creating a VM running Ubuntu Server
• Installing the necessary dev tools and firmware images
• Expanding the file structure containing the alert-email script
• Editing /etc/scripts/alert-email to add the –syslog option
• Running a ‘make’ to create the new firmware image
• Installing the firmware

I don’t want to over-trivialize the steps here, and again the documentation is not quite as hand-holding as I personally needed (!), but in principal this is very cool indeed. I only edited a script, but I could have added more software to the build as well, within the limits of the hardware’s storage, memory and CPU capabilities. So now, custom responses could involve calling software that would not even be on the box by default. How many terminal servers like this can you think of that allow this level of customization?

After completing the script editing and build process, I uploaded my firmware to the device and it worked perfectly. Now every email send attempt will have a syslog entry generated, which is what I wanted.

Conclusions

When Opengear presented to us at NFD4, they really tried to show us the flexibility of their Advanced Console Management solution, and I think the fact that there are three options available to me just to hack around an email alert is proof of that. I’d try installing software in a custom firmware build, but so far everything I’ve wanted to do has been covered by built-in utilities so I’ve not yet got an excuse.

As I dig deeper, it’s evident that I am barely scraping the surface with what I’m asking of the device so far, and I’m looking forward to seing what I can do with the ACM5004 next. Upcoming posts:

• Building custom firmware
• Trying a custom response script to protect by devices from a user reset
• I’ve started playing with an ACM5004-G-E which has TTL input/output ports on the side for integration with sensor devices. I’m sure something will come from that!

Disclosure

Opengear was a paid presenter at Networking Field Day 4, and while I received no compensation for my attendance at this event, my travel, accommodation and meals were provided. I was explicitly not required or obligated to blog, tweet, or otherwise write about or endorse the sponsors, but if I choose to do so I am free to give my honest opinions about the vendors and their products, whether positive or negative. Opengear provided me with an entry-level console management device (ACM5004-G), and more recently an ACM5004-G-E, both of which I am using as test hardware to create the content for these posts.

Please see my Disclosures page for more information.