Slashdot Mirror
Ask Slashdot: Uses For a Small Office Server?
ragnvaldr writes "I'm the 'IT guy' for an office of about a dozen people. And when I say IT guy, I mean I'm the only one here who can use google well enough to figure out how to make things work. We have a 500GB Mac server with a Drobo with 6TB of storage attached. So far all this server does is back up data, and I want to make it a little more useful. We also have a Filemaker server on it, which I have yet to learn how to use at all, let alone efficiently. Any suggestions to make this machine a little more useful?"
Porn server, of course!
Great minds think alike; fools seldom differ.
...you let a perceived need dictate a use, not the other way around.
Seriously, data backups are crucial in every enterprise, even small ones. That's a *great* use for your server. Are you checking on your process by restoring files once per month? Once per quarter? I joined a bioscience center that had faithfully been making backups for half a year before I joined but five months of the backups had no data. So do check, please.
I have more questions about your backup methods than I can easily list here. Still, there are other good uses for *every* server. They can all:
1) Provide DHCP addresses
2) Offer NTP to keep the clocks synchronized
3) Provide comprehensive system logging (for all systems of concern)
4) Store and/or offer common utilities like print services
Ah yes, the good old "if you don't know, don't even bother asking just fuck off"! Thank god not ALL slashdotters are as worthless as you are, but that argument comes up waaay too often.
Yeah, I'm sure a 12-person office has an extra 100k sitting around for an IT guy.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
It sounds to me like you haven't identified a business need and are fishing for one. Wouldn't it be better to look at how the business operates and from there see if there is something that can be done more efficiently? If there is, then ask yourself how this server can be used to address that problem. A server can do a lot of things, but don't look at those things and try to force it on the business when the need doesn't necessarily exist. It may create more problems then it solves.
If what you are really looking for is something to play with, then Filemaker sounds like a great place to start. It could be your introduction to databases. Once you understand the power of databases, you may find areas of the business that might benefit from a database. But until you have the knowledge, you aren't in a position to implement and support one. Just remember, if you're going to play with something, don't do it on a production server. Backups are a real business need. Even if that is the only thing the box is used for, it is a perfectly good reason for its existence.
Why? It's doing backups, and it's a full-fledged Unix machine.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
It's generally better to start a project from "I want to accomplish [x], so what do I need?" rather than "I have [x], so what can I accomplish with it?" The first approach will be much more focused and more likely to succeed.
Second thing to keep in mind: you don't want to experiment on a production server. I don't care if the "production server" is only a backup server-- if you don't want to endanger your backups, then it's still a production server. This means you shouldn't do anything with this server until you've planned what you want to install on it, and you've already set up a test implementation and you know what you're doing.
Third thing to keep in mind: in current IT practices, it's often not worth it for a small company to do things for themselves unless they need to. You probably need a local file server and therefore also a backup scheme. Aside from that, things like web hosting, email, and chat are usually better handled by a big company that can afford a datacenter. If you do try to do email internally, make sure you back it up and have a plan for outages and disaster recovery.
All that aside, you could start with basic services: directory services, file sharing, email, etc. Filemaker has its uses, but let the use determine the tool. Don't go around pounding on everything just because you've found yourself a hammer. Define the job, and then pick the best tool for the job.
It isn't that at all. I've worked in the field and taken plenty of calls from guys like this. Guys who thought, yeah, I know just enough to be dangerous, let's see what I can do. Then he's sitting there, no backups, no duplication of media, nothing to keep his ass out of the frying pan, and then he's on the phone to me because he's got some hot project that he needs the system for and it suddenly becomes my priority to unfuck the mess he's in.
Either way, he should call the pro. It's cheaper if he calls before he fucks everything up beyond belief.
You non-science, non-engineering types, especially in IT, love to exaggerate and use pontificating language. You clearly don't mean "fucks everything up beyond belief" because it's a meaningless phrase that you picked up from your stupid colleagues in IT. "nothing to keep his ass out of the frying pan" -- is that really necessary? Get to the point and move on.
How hard are backups? rsync, RAID, different storage media, onsite and offsite backups, and cost / benefit analysis to defend the choices. Some of it will be subjective (the "benefit" of something is obviously difficult to gauge and liable to debate). You could suggest some points of reference. That's what every good scientist and every good engineer I've met does -- because they know their worth is not limited to learning some quirks about programs. They design and build stuff. They often debug it. The bad ones constantly overstate their worth and present themselves with a really irritating know-it-all attitude. The bad ones think that by communicating their ideas and helping others out, they are risking job security. The good ones help others learn how to learn. The good ones demonstrate that they know their stuff and understand their worth is not rooted just in knowledge or wisdom, but also in interpersonal skills, often overlooked or downplayed in STEM fields.
I used to be like you in high school. I had worked at a few Fortune 100 companies as a coder / sysadmin type and I didn't realize my douchiness until I left the field in college for computer science, electrical engineering, physics, and chemistry. I know my comments sound a bit harsh, but maybe my tone may make you reevaluate how you behave.
Call the pro?
Call him for what? If you don't have a problem and you "call a pro" you're going to get a solution you didn't need for a problem you didn't have.
You have this backwards. First he comes to slashdot to figure out how to make it useful, once he's done that only THEN can we tell him to hire a pro.
Admittedly there are many people who follow your model of thinking. They invariably end up spending the rest of the year figuring out where all the money went while reading their emails on an iPad sitting next to their computer.
It's rare to see such a combination of technical experience, and familiarity with the realities of implementing a solution in a small business environment.
Usually you can only get one or the other from any particular individual. This is solid advice and a good starting point. It should be modded up.
It is a miracle that curiosity survives formal education. - Einstein
There's nothing wrong with doing things oneself, if one does them right.
I frequently have to pick my jaw off the floor when I look at what professionals have done. Which, mind you, isn't always the fault of the professionals, but can be because those professionals aren't mind readers and don't now what's so obvious to a company's manager that he never tells them. Or a manager who has to stay within a budget, and orders a half-assed job. Or a manager who can't write contracts and don't have anyone technical enough to verify specs.
Sure, I just as often have seen internal snafus, where someone hacked up something terrible.
That's "just as often", not "more often".
'Cause quite frankly, the "professionals" can be quite incompetent too, and often are. They hire people based on the demand for work they get, and are legally obligated to fulfill a contract and give a customer what he asks for, not what he needs. The professionals are the ones who ask the customer "what browser do you use?" and then proceed to code a project for that browser, and are the assholes responsible for why so many companies are still at IE6. Who uses authentication that works for the test user, but won't work for remote users, or the sysadmin who doesn't use Windows. Who foists upon the customer completely idiotic platform requirements (including both OS versions, JVM versions and network specifics). Who take shortcuts, including hardcoding and incorrect assumptions.
Because robustness was never a consideration; just getting the job done and move on. Hell, if it breaks, it's a good chance they get hired back to fix it!
In short, professionals are dangerous. What you want are experts. And most professionals aren't; they are consultants on a H1B or in-between real jobs, who know just enough to be dangerous, working for profit, not pride.
In this case, I too think the OP should leave well enough alone, but not for your flawed reasons.
If a system is already used for backups, it is one of the most important systems the business has. It should be treated as blessed, and not to be messed with, only replaced when that day comes. It's so critical that it deserves the "legacy" stamp from day one, no matter how modern it is at that point.
Do not look for unused capacity on critical systems. There is a chance that you break them, but also the reverse risk that what you implement itself becomes critical to the business, and that higher demand on the existing system will break your new functionality.
Do you really want to be responsible for restores not working the day lightning strikes, because your app needed a patch that invisibly broke backups? Or do you want your app to become a favourite of managers, and then suddenly become sluggish or not work at all once someone decides to back up the new Hawaii or Europe office during what's business hours for you?
Also, untangling two critical functions running on the same system without business impact can be a daunting task, which is best avoided.
tl;dr: Don't mess with critical systems. This is not the unused capacity you are looking for. Move on.
And I say this as an IT guy myself.
You can put together all the fancy features you like. I don't care what they are, what is important is what the business can benefit from.
So you need to do two things:
1. Don't speak to us. Speak to the people in your company who are driving the business.
2. Stop thinking in terms of "clever things I can do with the server" and start thinking in terms of "things I can do that offer a tangible benefit to the business". 99 times out of 100, those things will fall into one of four categories:
a. Bring money in - either directly or indirectly.
b. Save money.
c. Reduce risk.
d. Make life easier for someone else in the business.
B and C are relatively easy. A is seldom found in IT; D often requires people to change the way they work. Getting people to change the way they work is generally very difficult, so unless the benefit is so absolutely vast that even the most deluded, stuck-in-the-mud person would see huge benefits to it before you've even finished explaining your idea, you may well be wasting your time. If you have an idea that offers only small benefits but requires significant changes to how people work, forget it.