A friend of mine recently had a solar panel system installed on his acreage. Besides being interesting because of the renewable/green aspect of the project, the system itself—from SolarEdge—is actually highly digital.

• A mobile app is used for commissioning the system.
• SolarEdge operates a cloud service which collects telemetry from the system and reports various performance metrics in a user-friendly dashboard.
• The inverters can connect to the IP network and provide a means to collect telemetry from them directly.

The last point interested me the most because any time a device exposes its data or a control connection, it means there's an opportunity to integrate it with other software. In this case, I wanted to create my own dashboard to display (near) real-time performance data for the system.

Whereas other blogs and articles on this topic describe how to monitor a single inverter system, this post will describe how I built a performance dashboard for a multi-inverter system.

Whether it's Dropbox, LinkedIn, MySpace, PlayStation, or whatever the latest breach happens to be, it's almost inevitable that you will be caught up in one of these breaches and have your username, password and possibly other information exposed in a data dump. Here's how to respond when that happens.

I wanted to jot down some quick notes relating to running a virtual Firepower sensor on ESXi and how to validate that all the settings are correct for getting traffic from the physical network down into the sensor.

Firepower is the name of Cisco's (formerly Sourcefire's) so-called Next-Gen IPS. The IPS comes in many form-factors, including beefy physical appliances, integrated into the ASA firewall, and as a discrete virtual machine.

Since the virtual machine (likely) does not sit in-line of the traffic that needs to be monitored, traffic needs to be fed into the VM via some method such as a SPAN port or a tap of some sort.

At the time that I'm writing this I've been working at Cisco for just over 3 years as a Systems Engineer. Prior to that I worked for multiple Cisco customers and was heavily involved in Cisco technologies. I know what a monster cisco.com is and how hard it can be to find what you're looking for.

Since starting at Cisco, the amount of time I've spent on cisco.com has shot up dramatically. Add to that studying for my CCIE and it goes up even more. In fact, cisco.com is probably the number 1 or 2 site I visit on a daily basis (in close competition with Google/searching).

After spending all this time on the site and given how vast the site is and how hard it can be to find that specific piece of information you're looking for, I'm writing this post as an aid to help other techies, like myself, use the site more effectively.

This post is about finding and fixing a memory leak I discovered in the SNMP daemon, snmpd(8), in OpenBSD. This sort of analysis is foreign territory for me; I'm not a software hacker by day. However, using instructions written by Otto Moerbeek as my Rosetta stone and Google to fill in the blanks when it came to usage of the GNU debugger, gdb(1), I was able to find and fix the memory leak.

I'm documenting the steps I used for my future self and for others.

I've had enough real life experience with replacing drives in the ZFS pool in my home NAS that I feel comfortable sharing this information with the community.

I've been working on something that at this point in my career I never thought I'd be doing: another Cisco Certified Network Associate (CCNA) certification. The CCNA Voice, to be exact. Now that I'm in a job role where I'm expected to be somewhat of a jack-of-all-trades, I can no longer avoid learning voice :-) For a long time I've focused on just the underlying network bits and left the voice "stuff" to others. Since I now need to talk intelligently about Cisco voice solutions, products, and architectures, I decided to go through the CCNA Voice curriculum as a way to establish some foundational knowledge.

This post is about the tools and methods I used to build a small lab to support my studies.

I installed OmniOS on my home filer over the Christmas break. Jumping from a Solaris Nevada build to OmniOS meant figuring out what software packages are available in the OmniOS repositories, what third-party repos are available and what software I would have to compile by hand. Given that this machine is only acting as a filer and isn't running any other services to speak of, the list of software to get up and running is small; however a critical component is apcupsd which talks to the Uninterruptible Power Supply (UPS) and cleanly powers down the filer if the power goes out for an extended time.

The hangup for me is that my UPS connects to the filer via USB, not a serial connection. It took me some hours to figure out how to get apcupsd installed with USB support. Here's how.

Ahh the Christmas break. The perfect time for good food, enjoying the company of family and friends and of course.... IT projects at home! My project last year was to immerse myself in the source code for OpenBSD's snmp daemon so that I could integrate my patch-set for Net-SNMP directly into the native OpenBSD daemon. That was time well spent as I was able to integrate my code in the following weeks. This year I have maintenance to do in the home lab. It looks like 2013 is going to be a busy year as far as getting my hands on new stuff so I want the lab ready to rock.

First project: upgrade my VMware ESXi server from 4.1 to 5.1.

Cisco's Identity Services Engine (ISE) is a powerful rule-based engine for enabling policy-based network access to users and devices. ISE allows policy enforcement around the Who?, What?, and When? of network access.

• Who is this user? A guest? An internal user? A member of the Finance department?
• What device is the user bringing onto the network? A corporate PC? A Mac? A mobile device?
• When are they connecting? Are they connecting to the secure network during regular business hours or at 02:00 in the morning?

These questions can all be answered easily within ISE and are all standard policy conditions that are relatively easy to implement. In the post below I'm going to focus on the How? — How is the user or device connecting to the network? Asked another way, the question is Wired? or Wireless?

Although it would be awesome to ditch Net-SNMP altogether now that the base OpenBSD SNMP daemon has support for all of the OpenBSD-related MIBS (CARP, PF, kernel sensors), reality is that Net-SNMP still offers some features that are needed. OpenBSD doesn't have any SNMP tools (snmpwalk, snmpset, etc) so these are still required from Net-SNMP. There's also some unique features in the Net-SNMP daemon that are still useful if you want to do things like monitor BIND9 or Postfix statistics.

Here's how to run both at the same time and leverage snmpd for the OpenBSD-related MIBs and the Net-SNMP daemon for its ability to retrieve data from scripts and extend itself using loadable modules and smux sub-agents.

Update: For help running both snmpds at the same time, see Net-SNMP and snmpd Coexistence on OpenBSD

Now that OPENBSD-CARP-MIB and OPENBSD-PF-MIB have been added to the base snmpd in OpenBSD (CARP-MIB will be in 5.1-release, PF-MIB in 5.2, and the SENSOR MIB has been there since 4.5), I wanted to document the differences between these MIBs and the corresponding implementation of the MIBs that I wrote for Net-SNMP.

Both implementations provide the same set of OIDs and allow the same data to be retrieved. Whatever you were querying via Net-SNMP is available via snmpd.

What has changed is the base OID where the CARP and PF MIBs are rooted at as well as the name of certain OIDs.

A great little "feature" of Cisco's Identity Services Engine is that out of the box, the administrator account expires after 45 days if the password is not changed during that time. The documentation says that if you have trouble logging in you should click the "Problem logging in?" link and use the default administrative user/pass. This is of course ridiculous and does not work.

Below are the steps for properly resetting an admin password and for changing the security policy so the lockout doesn't happen again.

As part of the recent hardware upgrade to my ZFS file server I replaced the motherboard. I'd never replaced the motherboard on an active Solaris system before and was curious whether it would be at the easy end of the spectrum (like OpenBSD is) or at the impossible end (like any recent version of Windows). This is what I learned.