Lights out management - still waiting for the bulb to glow

+1 for Spiceworks

Trevor, another fantastic article.

Almost from the beginning I was wondering, "has he heard of Spiceworks? If it doesn't come up in this article I'll make a note in the comments about it".

I started using Spiceworks about 9 months ago when I started working for a new company and wanted to put some management and system monitoring in place. I found it through Google and figured it was worth my time to check it out since if it delivered on its promises I would have everything I was looking for for free. I've never looked at anything else after that and have ever since been singing it's praises to friends in the industry.

The client is Windows only which could be a problem for some people, hopefully they will do something about that one day. Also, since it relies on WMI for Windows boxes, you have to remember to configure the Windows firewall to allow the traffic through and I've seen a couple of cases where WMI was messed up on a machine and needed fixing (though this is a Windows problem not a Spiceworks problem).

The best part though is the community which are incredibly knowledgable and very helpful.

I'll look forward to your article about it and I'm sure those in the Spiceworks community will be happy to see it get a little more recognition.

-1 for Spiceworks

Proprietary, closed-source, ad-supported and not very scalable, and requires an obsolete VMS-derived OS platform. I'm not saying it's junk, but it ticks all the 'not interested' boxes from my perspective. Just my opinion.

SSH and manageability

If you have SSH, you can manage it. It can be something as simple as Expect scripts (and autoexpect makes it really easy), or as robust as Puppet.

@El-em && @Chris Dixon

Spiceworks was interesting enough to me to get it's own article...

Not to be snooty, or anything

One of the great things of command line tools is the great ease by which I can make new ones. Making a GUI requires a design, a vision of what buttons to put where, to, well, make it all self-evident at least for the intended audience and so on. A command line tool, on the other hand, only really requires that it do something. It doesn't even have to say anything. It would help enormously to have it print "usage" information when not given useful options, and that's easily added. Adding a reference manual page is good practice also, and on unix systems there's already a typesetting package available to ease much of that work. Another useful things on unix systems is a scheduler, and several languages in which to write the software. If none are to your liking, more are available as free software. You can mix and match too.

This is how I wrote my own package to inspect and manage ports on "managed" switches. With the right configuration file and a simple command or two, any port in the network can be turned on and off at will. Haven't found a way to change vlan associations yet, but that seems to be highly vendor-specific anyway -- and often not available at all via SNMP. Too bad. But I digress. I built the package using bourne shell and tools like sed and awk, and the net-snmp tools to do the network interfacing. It was and is small and easy to extend incrementally. Something that's much harder to do on an OS that essentially forces you into marriage with windows and buttons to click on.

Your complaint of having to do things yourself is understandable in that light, but my perspective is quite different: On a platform where using external executables is cheap and almost indistinguishable from using things "native" to some package, because they all follow the same model, adding things yourself is a breeze. Adding "wol support" to such a thing may imply "an external executable", but all that thing has to do is take an address argument and send out one magic packet. One, or maybe a few just to be sure.

This ability to breezily extend and expand has its downsides: There are packages around that require several language virtual machines, half a dozen interpreters, and a metric arseload of add-ons and dependencies. That's going to be painful to have to keep up to date. But there are much simpler solutions, and a little care gets you a long way.

A little care is always required in the open source community, though. And you do deserve a mild rebuke for phrases like "the open source community has failed ..." -- who paid "the community" to not fail, hm? And do note that on much commercial software many a feature is a tick-box item, where the open source version will be much more useful since it was developed to meet a real need. If it's there, it's likely to be reasonably well tested, and otherwise, it's likely to not be there. This is for many a more desirable situation. Also, a large percentage of completely free stuff dealing with proprietary systems had to get up and learn to walk in the dark, without guidance from the people who knew, who built the proprietary system. No documentation, only reverse engineering. If you can show there was enough freely available documentation and people were paid to come up with an open version and then deliberately dropped the ball, yes, you have a legitimate complaint. Otherwise, all you can do is be grateful for what there is even if it isn't good enough for your purposes and you'd be happier with a commercial offering. Sure, go ahead and be happy with that. And yes, you can observe that some alternative didn't meet your needs. If you'd had the skill you could've fixed it for some open source project and contributed it back and see it added in the next official release. So there is really no need to look down on efforts that didn't cost you a thing even if they don't live up to what you need in your daily pay grind, thank you very much.

What about Avocent?

Not sure if they are one of the companies that you looked at, but we use their serial & KVM over IP products here, and they're a life saver. They probably don't have everything you need, but since you're probably going to have to use multiple vendors anyway, it could be worth a look.

It's not religion...it's business.

Who has paid the open source community?

Why...everyone! Open source doesn't mean free, friend. I don't know about you, but I pay for my open source. Every single time. Open source projects have support contracts, or “pro” versions, or even just the ability to donate. Only one program have I ever not been able to donate to (Notepad ++,) despite trying to. (The author told me to give to charity, which I did.)

Who am I to say the open source community has failed? Someone with a couple decades of experience in IT, that’s who. Open source is about more than Linux, and making Linux work with more Linux then there was some Linux and OH MY GOD LINUX.

This attitude is a slap in the face to great projects like Samba, who have excellent coders dedicated to bridging the gap between open source operating systems (such as Linux) and more proprietary ones, (such as Windows.) I have nothing but respect for most open source projects, and their coders…it is why I always pay for my open source usage in whatever way that I can. Even if I can’t find the budget at work, if I find a particular project has earned a spot on my roster of applications, I will dig deep into my own jeans for the cash.

You try to brush off my desire for a simple easy to use centralised management tool as “oh, he’s a GUI addicted Windows user.” I think you completely missed the point. I nowhere stated I was looking for a GUI, or a web interface, or a command line interface. I stated I was looking for something that WORKED, and contained all the bits required to work in one package. If that were commandline, then so be it…but for any package from ANY vendor to obtain my approval, it must acknowledge more than the narrow bottle of it’s own existence. I don’t need to run my management package from Windows…I’d prefer to be able to run it from a CentOS VM, but have it neatly pick up and be able to manage my network from there. Ideally, something like an open source Spiceworks that I could get via YUM.

I have little use for management applications from Microsoft, Symantec, Dell or anyone else that can’t manage Linux or Mac. No matter how pretty the interface is. I have similarly little time for Linux-centric pap. In the real world people use what tools they have available to them to get the job done, and in the IT world that often means mixed environments.

If I wanted to write my own tools from scratch using the command line, then I wouldn’t be out looking for a package to do it for me. Being a systems administrator is about more than geeking out over some scripts. It’s about actually managing your network; looking beyond your preconceptions and nerdly ideologies, and find the most efficient way to run things. It’s not personal, it’s not politics, it’s not religion. It’s business.

You can attempt to “rebuke” me all you want, but I still stand fast to my statement: in this particular case, the open source community has failed. They have failed to come up with an adequate cross-platform network management tool that is remotely easy to use and doesn’t require either a massive learning curve or massive amounts of scripting.

Maybe nobody in the open source community thought it was important to build an application like this. If that’s the case, then the community has still failed; noone saw the need, noone created the product. There are fantastic coders out there in the open source community, (the Nagios crew for example, or the Samaba guys as another,) who could take a project like this and make something spectacular.

Noone has, and that sir constitutes failure. Or opportunity, depending on how you look at it. After all, it is a now a documented hold in open source offerings. That means that there is a spot here waiting for someone to create a project, and charge for support, or a “pro” version, or somesuch. Maybe a dedicated coder could find a livelihood to be made here. Who knows? After all, IT…

…is business.