Spiceworks is it....
Funny how about 2 paragraphs in I was chanting "Spiceworks, Spiceworks, Spiceworks".... and the author appears to hit on it based on his last sentence!
Definitely the tool to go for and priced where we like it - FREE!
I am on a quest to lower my computer power usage. If you have read my previous article, you know that this is not by choice - it’s a necessity driven largely by cooling requirements in the spaces where my systems live. The project at hand is Lights out Management (LOM), the ability to configure and control my systems even when …
Funny how about 2 paragraphs in I was chanting "Spiceworks, Spiceworks, Spiceworks".... and the author appears to hit on it based on his last sentence!
Definitely the tool to go for and priced where we like it - FREE!
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.
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.
Your opinion is as valid as everyone else's, and frankly...they are issues I myself am not entirely comfortable with.
To be honest, while Spiceworks is awesome, the fact that after two solid weeks of research I could find nothing comparable from the open source community was deeply saddening. I have about 30 VMs on my test server at home with various combinations of open source packages that I tried to lash together to Get The Job Done, and while some combos could do it /with enough tinkering/...the level of effort required was more than i had available.
I prefer open source whoever possible, but I am generally software agnostic. I recognise the value open source provides, but I will not let my preference for the software license blind me to good, or at least usable software from other sources.
In this case, open source lost. Badly.
Frankly, the only thing close to doing what I wanted was Nagios, but Nagios doesn’t have much in the way of MANAGEMENT…just a lot of monitoring. If the same people behind Nagios decided to throw their unbelievably fantastic talents at creating a network management application that could back onto Nagios like Spiceworks…
…that would be bloody revolutionary. As far as I am concerned, the developers who work on Nagios absolutely walk on water; I have more respect for those folk than just about any other group of coders on the planet. Sadly, neither they nor anyone comparable in the open source community has cared about network management, (and specifically lights out management) enough to put something like Spiceworks or Microsoft’s SCCM together.
Maybe I should be grateful though. I’m halfway convinced that if the Nagios dev team turned their attentions to full-fat network management, they’d put half my profession out of a job virtually overnight.
So for now, despite my reservations…
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.
If you have the spare people with talent and time, this is a great idea. The only problem is that when you have to get 200 nodes sporting a dozen different operating systems hosting about 500 varies services across them...
...writing a script for everything isn't going to get done in two weeks. Not only that, but the TCO on script-based maintenance and monitoring is obscene. It takes a lot of time and effort to keep something like that up to date and troubleshot; perfect if you have a dedicated script admin. A nightmare if you are an already overloaded small group of sysadmins trying to reduce your workload.
In an ideal world, the approach you mention is by far preferable. Relying on something like Spiceworks of SCCM is relying on a third party company to develop modules or plug-ins for each device and service you offer, and you have to wait on this third party for bugfixes and patches. Wherever possible keep your development and code in-house.
The caveat of course is that you can only kept that development and code in house if you have staff dedicated to their eternal upkeep.
I dislike the tradeoffs, but what can you do?
Spiceworks was interesting enough to me to get it's own article...
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.
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.
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…
I don't pay for open source, I get paid. That is, I did a stint at an open source consultancy, becoming a core committer to the project we consulted for the most. Before that I ran a sysadmin shop in a development company on open source, mainly not linux, but a large chunk of that too. Yes, I understand the business side of open source. At least some of it.
But suppose there was no open source. And you couldn't find the right mix in a single offering. Who has failed? All the vendors who didn't offer you just what you wanted? Every single one of them? Even if they're not in the software business?
That was my point: The community isn't a corporation. It isn't even a single community. The developers involved in open source mostly cater to themselves, that is they're in it because they like writing the software, or maybe they like the thank-yous from the hangers-on, or maybe still some other reason, and the hangers-on are useful in a myriad small and not so small ways making the result even better. Which is more than just the software.
You're treating "the open source community" as if it was a single thing, which is not just as much as "the internet" is not a single network, and certainly not under control of a single entity. There's no single salesman or CEO who you can complain to with "all your offerings suck, get me something better".
As a developer I look at your complaint and shrug. "The world has failed me." Sure mon. That's not bringing anything constructive to the table. Yeah, I have an inbox full of those already. As someone who likes to do constructive things, I'm telling you that complaining the forest has failed you because none of the trees is the right shade of green isn't helpful. None of the trees care. You're free to grow your own tree, or join a project and help out, or even just pick one or more projects that come close to what you want and tell them, nicely, you'd like this capability and maybe they'd like to consider it as a feature request.
You could even do another writeup and tell us how you fared.
But misunderstanding the community just because you're running a business is still misunderstanding the community, even if you think you paid for the privilege. Call it an opportunity for improvement.
If no corporations offer the product I require, then the corporate community has indeed failed to deliver. "The open source community" doesn't get a free pass just because it's open source. If I went to a car dealership and required a car that had both anti-lock breaks and an MP3 player, I would consider it a failure of car manufacturers to anticipate demand if there were no models available with both options.
I don’t care if “the open source community” has no single CEO or board of directors. “The open source community” gets no slack, special favours or happy meal points from me simply because of their business model. If it wants to think of itself either as a bunch of individuals with no cohesive direction, or a hivemind monstrosity there is no difference to me. “The open source community” in whatever format he/she/it/they/pie chooses to look at itself as simply hasn’t produced the right shaped peg for this particular hole.
It is not up to the implementers of software to adapt to the whims of developers; it is up to developers to anticipate the needs of implementers. In this case, developers have failed to recognise and exploit an open niche. To me that is a (to date) failure. You can disagree with that all you like, or try to argue semantics or terminology, but as far as I am concerned it simply is a failure to recognise need and opportunity.
You choose to take my words as complaint; they aren't. They are merely statement of fact. In the case of "delivering what I require for desktop management software," the open source community has failed. For that matter, the paid community has largely failed as well. As good as Spiceworks is, there are some holes in it that need work.
Pointing out gaps in offerings isn’t complaining. It’s merely being observant. There’s also dash of holding everyone, regardless of business model or software licensing terms, to a high standard.
You can of course take the typical open source evangelists’ approach of “well, if there isn’t the application/script/etc. that you want, then you write it and quite expecting someone else to.” I’m not a developer by trade; I’m a sysadmin. I can script, but I certainly can’t write anything the quality of Nagios or Spiceworks. I also shouldn’t be expected to have to be a developer of that calibre just to maintain a network. “IT” is so large that it requires many different people of many different skill sets to keep operational. My job is to find the best of what is available and put it to use. It is the job of other people to identify software niches and fill them.
Those people have in this case failed. With luck, a group of developers is right now working on a product to fill exactly this gap; if so, I applaud them and look forward to trying their software out.
Interesting take. I'll buy your assertion that you ment it impartially, but I'll observe that I read it differently and you could've worded it so that I would've read it how you ment it the first time. I'll also observe that you don't quite as often see assertions "industry has failed to provide" when reviewing a number of commercial applications where none of them do exactly what the reviewer was looking for.
I do maintain that the goals that open source communities pursue (making software that does what they want) and commercial vendors pursue (making money) are quite different, and that assuming they're the same doesn't make for a meaningful comparison.
If you do insist on treating open source like you would a commercial entity, then make the comparison fair and hire an open source consultancy that can tailor the application so that it does what you want it to do. You can then compare it on equal or at least comparable footing and you get the warm fuzzy feeling of having contributed back to the community too.
In neither case does it make much sense to claim other people fail, unless you had a contract with them that specified they perform and you can demonstrate they didn't, or didn't completely. You failed in your pursuit, and you found a niche. That's an opportunity that someone, possibly you, might take up to fill the niche. And that, bringing something to market that wasn't there before, is innovation.
Getting people to fill the niche requires getting the message out at the very least, and we're back at communication again. If you think asking for features from open source communities is too much like following evangelism, well, you could call a sales agent and ask for the feature in a commercial application. A good sales agent will be happy with the question and pass it on to the developers. Because they, too, need to know what the client wants.
"I do maintain that the goals that open source communities pursue (making software that does what they want) and commercial vendors pursue (making money) are quite different, and that assuming they're the same doesn't make for a meaningful comparison."
If we were having this debate ten years ago, I would have agreed with you wholeheartedly. Times have changed however, and I feel your statement reflects a small minority of extant open source contributors. Open source software is about business now, just as closed source software is. I am sure there are the odd programmers out there who contribute a bit of code for the fluffy bunny cause. Perhaps they wrote something cool and they wanted the world to be able to share in it. (I’ve written a few of those myself.)
These are more and more occurring in the minority. Open source has become nothing more than another element in various business models. Like all of IT, regardless of the original intentions or philosophy, the religion was jettisoned and it is now about nothing more than business.
As to the community, be it proprietary or open source having failed; I maintain that they have. They have failed to see the requirement for a LOM network management application and create one.
Again; your assertion is that it is my duty as a systems administrator to get custom code done for anything I desire; a very programmer-centric view of the universe. I have a sysadmin-centric view of the universe: it is the duty of the programming community to have software for every conceivable need already available “on the shelf.” Preferably more than one option, so that competition can drive refinement of the applications and expansion of features.
You and I will probably never be able to agree on this, because we have different views of whose responsibility it is to recognise the need. As a sysadmin I say that it is the responsibility of entrepreneurs and developers to see a need, take the risks and write an application. This then gives them the intellectual property rights to the application, either to release it under a proprietary or open source license, and to recoup expenses via whatever business model they desire.
If the onus is on my to identify and then commissions these works, then the intellectual property belongs to me, as the individual who commissioned the work, and it would be lunacy to ever release that software into the wild. By commissioning it to meet the specific purposes of my business, it’s existence provides me with an advantage I have over my competitors. No business man is going to give away their edge.
Thus in the case of most businesses, if they follow your advice, they get the software they want, but that software is never released into the wild. Good for the company, (they get what they want,) good for the developers, (they are paid to develop it,) but bad for anyone else. The burden of risk here is on the individual business commissioning the work, and they would be the sole beneficiaries.
In my case, the developers take on the risk of funding the project based on the idea that they will be able to recoup expenses by selling their application. (Or support for their application, or what-have-you.) If the developers are good, and market savvy, it works out well for them. If not, they lose. If they write a good product, then all of their customers benefit, the developers benefit, everyone wins.
That this particular niche hasn’t been identified and exploited I continue to see as a failure. Maybe some companies have commissioned custom apps. For obvious reasons they never made it into the wild. Others have been bought up by the large OEMs. Lacking competition from third parties, the large OEMs can charge exorbitant rates for software that does what I am seeking. (Worse yet, they tie it specifically to their hardware and software stacks in an attempt at vertical integration.)
I am sorry the statement rubs you in the wrong way, sir…but my view on who “should” be assuming the risks, and who bears the responsibilities in this are based on the “rules” of the capitalist society I inhabit. (Not all that willingly, I might add. I am a socialist at heart, but paid to think like a capitalist as part of my job.)
In the meantime, I’ll just use Spiceworks.
Biting the hand that feeds IT © 1998–2017