Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Networking IT

Server Optimization For Newbies? 295

supaneko writes "I recently took a new job as a network and server administration for a small IT company. I am absolutely shocked at how much is taking place within this company that I have little to no experience with. To help bolster my experience, I purchased a used server to use for hands-on training and practice. My ultimate goal is to have a complete, secure LAMP server available to the public running CentOS. I have been browsing the Net for various guides and tips on setup, optimization, security, and maintenance, but nothing I've found really gives me a hands-on approach to the topics I want to learn about. When you all started out, what route did you take to pick up the server setup and maintenance skills you have now? Is there anything in particular that you would recommend to someone who has excellent skills with consumer PCs and servers but is a total newbie to corporate and enterprise networking and servers?"
This discussion has been archived. No new comments can be posted.

Server Optimization For Newbies?

Comments Filter:
  • Virtualization (Score:5, Informative)

    by bigtallmofo ( 695287 ) * on Saturday September 13, 2008 @04:21PM (#24992913)
    Learn about virtualization. Take your pick of free offerings: ESXi and Virtual Server from VMWare, Xen, Virtual Server from Microsoft, etc.

    Using virtual servers that are hosted on your new physical server will allow you to set up any kind of operating system you want and any applications on that operating system again and again and again with no fear of messing anything important up. Also, you can run (depending on memory) multiple operating systems side by side.

    From there, you can start diving into learning all the operating system, application server, database server, etc minutia you like!

    Oh, and don't forget learning about P2V. That will allow you to do all kinds of "what if" scenarios without affecting real servers.
    • Re:Virtualization (Score:5, Insightful)

      by sskinnider ( 1069312 ) on Saturday September 13, 2008 @04:34PM (#24993037)
      Virtualization is probably the greatest training technologies ever created, especially for the Network Administrator and Server Administrator.
    • Re:Virtualization (Score:5, Insightful)

      by foo fighter ( 151863 ) on Saturday September 13, 2008 @04:43PM (#24993113) Homepage

      I disagree, strongly.

      He already said he's using his own server for educational purposes. If he breaks something, he'll have to fix it.

      We learn by doing, there is no other way.

      Also, the virtual platform can be hard to set up and optimize itself, and can cause confusing or misleading stats from your platform's performance monitoring tools.

      • by arth1 ( 260657 )

        Plus, you don't optimize by adding another abstraction layer, and that was what the OP asked for. Virtualization has many advantages, but increased speed with the same amount of resources is not one of them. If anything, you can expect a measurable slowdown by going the virtualization route, unless you also bump the hardware.

        • Re:Virtualization (Score:5, Informative)

          by Glonoinha ( 587375 ) on Saturday September 13, 2008 @06:13PM (#24993797) Journal

          Spend some time playing with vmware - I think you will be pleasantly surprised with just how close it is to running on the bare metal.

          The only thing I don't use virtualization for is playing games that rely on frames per second - other than that, I honestly doubt you could tell the difference (and funny thing is - some things run FASTER - backup and recovery of the entire machine is as simple as copying some files from one hard drive (your backup set of vm files) to another. I can have a complete restore in about 5 minutes, and I can dupe a machine in about 6 minutes.)

        • Re:Virtualization (Score:5, Insightful)

          by Pseudonym ( 62607 ) on Saturday September 13, 2008 @07:45PM (#24994359)

          Plus, you don't optimize by adding another abstraction layer [...]

          No, but you enable optimisation thereby.

          In system design, abstraction is one of the best things you can do for performance, because it forces you to insulate your components from each other, and forces you to think about the interfaces through which they interact.

          In an appropriately abstracted system, if you find a performance problem, you can then swap out a piece and swap in a new one, and everything should still work. Or you can move a virtual server onto a new physical server, and everything should still work.

    • Re: (Score:3, Insightful)

      While your advice is good, it's off topic and not directly related to his question, which was optimization. You can run an unoptimized VM just as easily as you can run an unoptimized real machine. Furthermore, the VM host can benefit from optimizations and must be at least stable to run VM's in the first place. This guy is new, lets not ask him to run 2 servers (VM Host + VM) on 1 system right out of the gate. It's all in a days work for some of us, but this guy is new and wants to learn.

      That said, I'll

      • Re:Virtualization (Score:5, Interesting)

        by COMON$ ( 806135 ) * on Saturday September 13, 2008 @06:36PM (#24993957) Journal
        It was not off topic, the guy is a noob and had the wrong title for his question. Read again:

        When you all started out, what route did you take to pick up the server setup and maintenance skills you have now? Is there anything in particular that you would recommend to someone who has excellent skills with consumer PCs and servers but is a total newbie to corporate and enterprise networking and servers?

        The guy is asking how to work with serving apps in general, he is light years from optimizing them. Like most noobs they post something not knowing what the hell they are doing, way over their heads, asking about something trying to be smart by saying I am trying to set up a PDC in server 2008, but cannot get my exchange 2007 running because it says I am getting a conflict with another IP. Reading things like this and the question in this forum make me shiver and want to scream because there are so many things wrong with the statements I barely know where to start. And in my example the guy was thinking there was just an IP problem, when in actuality "Can open, Worms everywhere".

    • Re:Virtualization (Score:5, Insightful)

      by COMON$ ( 806135 ) * on Saturday September 13, 2008 @06:25PM (#24993907) Journal
      Virtualization is a wonderful learning tool. However, this being slashdot I am feeling a bit rantish.

      Taking a job where you don't have any experience is fine when you have someone to learn from. However, having cleaned up my fair share of messes, or as I call them 'live learning environments'. I would suggest you start working for someone with experience AND play in a virtual environment.

      Virtualization is the future but this career field is beyond the infantile stage of hiring someone with no experience and having them in charge of your business. Entry level admins aren't THAT expensive. What do I mean by that? Most IT workers can halt a business if not destroy it completely with less than a day's work. There is a certain working order to getting to know how to do things right. Do tech work, watching the seasoned admins do their job well and getting in on the front lines. When you have learned all you can from them, move on to a new business or move up where you are. Don't take someones business and brag about how good you are because you are too proud to take an entry level position. Then then call up /. crying because you are in over your head.

      I mean good lord, the number of people in the last 6 months I have had to work with in forums because they didnt understand what FSMO roles were, or what a port was, or get this having to clean up a router because the idiot thought that /24 meant 1-24. (their router had been like that for almost a year).

      My advice? Quit and take a job where you can learn from someone, check your ego and learn. All you are going to do by yourself is pick up a bunch of bad habits and a HUGE ego because no one is going to be there to tell you how much of an idiot you are being.

      • Re:Virtualization (Score:5, Informative)

        by masdog ( 794316 ) <masdog@@@gmail...com> on Saturday September 13, 2008 @09:00PM (#24994837)

        At the same time, virtualization will enable him to learn multiple skills at the same time. Not only will he learn the virtualization platform, but he can run multiple OSes serving multiple apps. He could have Server 2003/Server 2008 Active Directory and Sharepoint running on one machine, Exchange on another, Centos with LedgerSMB on a third, a FreeBSD machine running App X on a fourth, etc with a safety net to roll back to a snapshot if he makes a mistake.

        As for quitting, that wouldn't be advisable yet. It would be a red flag to any HR person who is hiring him in the near future, and that may hurt him more than help him. I had trouble getting my resume in to places and I was at my current job for a year and a half.

    • Re:Virtualization (Score:4, Informative)

      by BitZtream ( 692029 ) on Saturday September 13, 2008 @08:21PM (#24994539)

      This is a great idea.

      I'd like to add that your two basic options for learning to optimize are: hiring someone that already knows it and you can learn from and time.

      The first is obvious as to how it works, though it may be difficult for you to find someone to learn from since you lack the experience to know what you need to learn at this point. Keep in mind though, the most experienced admins have not seen EVERYTHING that can be a problem, so they too are going to be in the same position you are on occassion. You can still learn from them in that situation by watching how they go about finding a solution.

      The second is pretty much a brute force method, and the way most of the IT industry learns it. You'll simply get better over time as you gain experience. Occasionally you'll have a problem that will require you to figure out the solution sooner than you'd like, especially if your business does well and the servers become loaded sooner rather than later.

      I'm all for setting up your server to be as optimium as possible from the start, but that also has its problems. Most of the time when you start you don't actually know what you need to optimize. Sometimes you do, like a SPAM type company needs mail servers that can handle large volumes of traffic and deal with large queues for sites that don't respond on the first try. 10 years ago, pretty much every site was going to accept your mail on the first try, now, due to greylisting for instance, many sites outright reject everyone on the first attempt. You could at best have built for that when you started just out of luck (or perhaps you have great natural insight ;). But like the most of us, you wouldn't have predicted that you'd need to change your configuration later to deal with the new sending delays.

      I'm currently in the process of rewriting our companies core service engine, fortunately I have a good idea of where the load and performance issues are based on the current system and I've planned in ways to deal with those situations. But in the process, I've also subtly changed the service and the users are no longer going to use it the EXACT same way they did previously. We've add new features, removed old ones that were hardly used or can be done differently, ect. As such I can only make an educated guess at how to setup the load balancing, web farms and database servers. I won't get the perfect setup on the first try, and even if I did, it would for all intents and purposes be just luck.

      Read a lot about the software you are using. Get on the users or developers mailing lists. You absolutely want to be on the users lists as they will see many questions from people just like you, and while you may not have the same problem now, you may have it in the future, and just remembering that you saw the problem before can in itself be a massive help when you are faced with it and know that someone else has seen it, so you can search for it. The developers mailing lists are generally not for users of the software, but I've learned that its sometimes the best way to find solutions to my problems as many times any actual problem with the software will make it to the developers lists and be discussed there, in which case I can tell if its been resolved or if I have to work around it until someone thinks its a big enough problem to resolve it (or I pay someone to resolve it because its that important to my needs).

      If you take the parents idea of virtualization into the picture you can accelerate all of the learning to an extent by setting up various test scenarios and figuring out how to work around the problems in those scenarios. You can setup a mirror images of your production systems and when you start to notice problems or potential problems on the production systems you can duplicate it in the test enviroment and figure out how to fix it there, trying several different options to find the one that yeilds the best results without screwing up your production servers.

      Its more important that

  • Google (Score:5, Informative)

    by A non-mouse Coward ( 1103675 ) on Saturday September 13, 2008 @04:25PM (#24992929)
    Back when I learned, Google was around. Turns out, it still is.

    Most of the modern linux distributions have excellent package management. Most of them take care of 99% of the deploy "correctly" or "securely" issues. The only downside is that no two packages put everything in the same place on the local file system. But that's no big deal, especially if you compare/contrast to other distros.

    Shoot, you can get an Ubuntu server installed as a VM in 15 minutes. (I don't see the need for dedicated server hardware, unless you're focusing on nuances of driver and hardware setup.)

    Follow these steps:
    1) Install base
    2) Install app from package
    3) Add custom content to package
    4) Scan with the whole slew of freebie security scanning tools
    5) Realize that at this point, you're better than most orgs already.
    • Re: (Score:3, Interesting)

      by mysidia ( 191772 )

      Most of the modern linux distributions have excellent package management. Most of them take care of 99% of the deploy "correctly" or "securely" issues.

      The default setups are suitable for dedicated servers and intranet servers.

      They are not suitable for hosting multiple sites, say two different department's or organization's sites on one shared server.

      For example, the default install of Apache + PHP on Redhat Enterprise Linux uses mod_php.

      In a hosted environment, you have to be concerned that one us

    • Re:Google (Score:4, Interesting)

      by jd ( 1658 ) <imipak AT yahoo DOT com> on Saturday September 13, 2008 @06:32PM (#24993943) Homepage Journal
      I'd probably add the use of Tripwire or something similar to detect malware or other evidence of intrusions, and disable all unused services and processes. This will improve performance, reduce memory footprint, increase stability, increase security and mow the lawn. If you're into kernel building, remove unnecessary kernel options and specify your hardware rather than using generic options. If network loads may be a problem, you might want to investigate patches like Web100, if it'll work with the distro version of the kernel. Swap space should be 2.5-3 times the size of RAM for a server and /tmp should probably be on an isolated partition. I'd probably put /var/log on an isolated partition too. If you're paranoid, put a proxy server in the company's DMZ network (there is a DMZ network, right?) and only permit connections to (and from) the server via the proxy. Then put a honeypot on the proxy that traps all services and IP ports you've disabled on the server.
      • Re: (Score:3, Insightful)

        by Lennie ( 16154 )

        Doing custom kernel builds has a few disadvantages:
        - possible no easy updates/upgrades/security-patches
        - with Linux it's really easy to change hardware in case of a failure, if you compile a custom kernel, you can't just copy the filesystems and start it up on different hardware (which is an option I prefer to keep open)

    • The only downside is that no two packages put everything in the same place on the local file system.

      Amen to that. This is the biggest issue I have with Linux - the author's documentation says "edit the file in /usr/local/app/etc" but the distro decided to put it in /etc instead.

      Now which one is right is another matter - ie put your apps in the right place, like all config files in /etc so no-one needs to hunt for them, or put them where the author decided they should go.

      If you use yum/rpm then you can see where rpm put the files using "rpm -ql "

  • Slackware (Score:3, Insightful)

    by The Lyrics Guy ( 539223 ) on Saturday September 13, 2008 @04:25PM (#24992933)

    Slackware. Forget about Redhat and all the other GUI-fied distributions. Install Slackware and do everything yourself. It's the only way to learn.

    • Re:Slackware (Score:4, Insightful)

      by A non-mouse Coward ( 1103675 ) on Saturday September 13, 2008 @04:28PM (#24992963)

      Slackware. Forget about Redhat and all the other GUI-fied distributions. Install Slackware and do everything yourself. It's the only way to learn.

      This is good advice. I did the same back when I was in school thinking it was pre-requisite knowledge for an IT job. Then I got my first IT job and became disillusioned at all the idiots that were making more money than me that had no clue how it all worked. They kept looking for the next--> next--> finish buttons.

      • Re:Slackware (Score:5, Insightful)

        by nabsltd ( 1313397 ) on Saturday September 13, 2008 @05:34PM (#24993507)

        Slackware. Forget about Redhat and all the other GUI-fied distributions. Install Slackware and do everything yourself. It's the only way to learn.

        This is good advice.

        Actually, it's not very good advice.

        Last I checked, Red Hat/Fedora/CentOS all have the exact same command line as every other distribution, and the system is configured using the same text files that have been used for nearly 20 years. All the GUI tools do is modify the config files.

        For a newbie, having the GUI there to change a config then looking at what text file got changed (and how it got changed) is an excellent learning tool.

        Also, last I looked, Slackware isn't one of the distributions that make a good bullet point on a resume. Red Hat, CentOS, and SUSE are good for real-world server skills, while Ubuntu, Debian, and maybe some Fedora would be good for Linux desktop skills.

        • I think the point was that Slackware is rigid enough that it forces to you learn linux at a (slightly) lower level. You can't click through the installer and end up with a magically working system.

          Which is good experience for when something goes wrong, and it doesn't magically fix itself. Of course, Slackware will probably draw some chuckles on a CV, but there's always the chance that the guy hiring is a SubGenius, and will hire you on the spot :D
        • Re: (Score:3, Informative)

          by xhunter ( 552459 )
          Interesting you pick the "commercial" linuxes as good for real-world server skills and list debian as good for desktop. My experience would say debian spanks red hat for ease of server admin, particularly if you want access to more packages to help you do your job. For instance, say you want to install shorewall as a firewall, slony1 for postgresql database replication or ntop for network monitoring. Is redhat repository going to help you with that? No, at least not in my experience. On top of that th
      • And then you get the great Eliminator; X11 gets broken and all you've got is an SSH prompt to work from. This is where the men are separated from the boys.
    • by Anonymous Coward on Saturday September 13, 2008 @04:32PM (#24993021)

      Assembler. Forget about Slackware and all the other already-coded distributions. Learn assembler and code everything yourself. It's the only way to learn.

    • Re: (Score:3, Interesting)

      by piojo ( 995934 )

      Learning Slackware has certainly served me well. I think it gives the most rounded education of how a system works--it's said that "when you learn Red Hat, you know Red Hat. When you learn Slackware, you know Linux." Learning how to install software and run servers in Slackware, I learned a bunch. (And yes, the knowledge you take away from that is more generally applicable than what you learn from Gentoo.)

    • Although Slackware is a good distro to learn Linux on (that's the route I took and it has served me well), it is not production-worthy. I'd say install it at home to play around with, but don't use it for a production-level server. For an enterprise-level server, I'd go with Debian. Debian is fairly easy to use and has the best package management system (apt). We run CentOS where I work for our production servers, and that's served us well also, but had we been running Debian, my job would have been a l
    • by pembo13 ( 770295 )
      You do know you can do everything in RedHat/Fedora/Centos from a console, right? That includes the install.
    • Or you can run Gentoo [gentoo.org], and really do everything yourself. Like most other Linux distros, Slackware is a package based system - still kind-of user-friendly. By comparison, Gentoo is user-hostile.

  • by millisa ( 151093 ) on Saturday September 13, 2008 @04:26PM (#24992939)

    If you want a more hands on, how do I accomplish a specific task type approach to things, I've been very happy with the books in the O'Reilly Cookbook [oreilly.com] line. They usually run 35-50 bucks depending on topic and you'll want to page through one in a store before purchasing. All the information in the books can be found online, but they usually organize them nicely in the books. Most of the topics are 1-2 pages responding to a specific "How do I do X" type question. The Linux Networking Cookbook, bash cookbook, and Linux Cookbook and Linux Security cookbook might be a good set to start with for what you are currently playing with.

    • Re: (Score:2, Informative)

      by ibmjones ( 52133 )

      . They usually run 35-50 bucks depending on topic and you'll want to page through one in a store before purchasing.

      Or for 40 bucks a month, you can get the whole O'Reilly Library at:

      http://safari.oreilly.com/ [oreilly.com]

      Well worth the money.

  • One question (Score:5, Insightful)

    by jalefkowit ( 101585 ) <jason@noSpaM.jasonlefkowitz.com> on Saturday September 13, 2008 @04:27PM (#24992951) Homepage

    How did you get a job as a company's sole "network and server administration" (sic) when you are a "total newbie to corporate and enterprise networking and servers"?

    In every case I've experienced where someone was hired for a sysadmin job with absolutely no experience, there was a more senior person on staff there to mentor/train them. But it doesn't sound like that's the case here.

    So... either (a) you were completely up front with your employer about your lack of experience and they hired you anyway, in which case there's no problem because they have limited needs, know you're learning and don't expect much; or (b) you lied to them, in which case the answer is "quit and go get a job you're actually qualified for".

    • Re:One question (Score:5, Interesting)

      by perlchild ( 582235 ) on Saturday September 13, 2008 @04:30PM (#24992985)

      You forgot c) they fired the mentor with the junior barely trained and now the junior has to do the whole job by himself

      Happens a lot more than you think

      • Sure, but you would think he/she would have mentioned that if that's how it went down. And besides, even if the mentor got fired, they still exist, so you could still approach them with questions like this over a beer after work if you had to (unless they got the job by getting the more senior guy fired, in which case they deserve their fate).

        • Why would they have to mention that in the question? They asked for pointers on setting up servers, not career advice. In all seriousness, if you're into office politics more than tech, I recommend The Daily WTF over slashdot.

          Consider the following: an IT shop may not need a big-time sysamdin, since everyone knows enough to keep things running. Perhaps this person was hired to keep things organized, act as an intermediary, audit software licenses, and in general do everything *but* set up the servers. But
      • Because the mentors don't know how to plan to take vacation for a week, ending one week before their employee reviews...

        "Yes, it does feel good to be back and caught up again, and I will accept that raise"
    • Re:One question (Score:4, Interesting)

      by cdrudge ( 68377 ) on Saturday September 13, 2008 @04:49PM (#24993181) Homepage

      Not everyone works for a company with hundreds of people that already has an fleet of network admins. Sometimes you get put into a role that you have no experience in because you have the available time, expressed a desire previously, or maybe you just happened to be walking by an open door when the PHB thought "we need a network admin".

    • Re:One question (Score:5, Insightful)

      by Peet42 ( 904274 ) <Peet42@NetUMLAUTscape.net minus punct> on Saturday September 13, 2008 @05:06PM (#24993307)

      Or... He listed his experience, and the potential employer just nodded and pretended it meant something to them.

    • Interviewer: so, hw much do you know about server admin?

      Poster: well, I freely admit I don't know everything, obviously nobody can know everything, but I know how to find the information for those things I'm not too familiar with.

      Interviewer: good answer, you're hired.

      Poster: excellent. You do, err, allow work-related internet access don't you....

    • Company Owner: My admin quit today, I'm hosed cause I have no one to run the servers. You're pretty good with computers, can you help me?

      Poster: Uhm, I make web pages for fun, I'm not really an IT guy.

      Company Owner: Well, you know more than anyone else I know, can you at least help me out in the mean time and do what you can?

      Poster: uh, okay I'll do what I can.

      -- 5 years later --
      Company Owner: Well, we're going to need to talk about this budget you put together, its just too much!

      Poster: We haven't upgrade

  • by nurb432 ( 527695 ) on Saturday September 13, 2008 @04:29PM (#24992971) Homepage Journal

    Just hire me as a consultant and ill take care of it for you.

  • by jkorz ( 1088471 )
    Setting up a secured lamp server (secured from being hacked, not secure as in ssl) isn't all that difficult. First, set up your lamp server just as you need it. Then install iptables (firewall), webmin and openssh. Set webmin and openssh to use random high (>2048) ports rather than standard. Set up openssh to use public key authentication (disable password auth) and set up webmin to NOT use local user accounts to login (you will have to set up webmin users). Then use the iptables module in webmin to bloc
  • Optimization (Score:5, Informative)

    by foo fighter ( 151863 ) on Saturday September 13, 2008 @04:39PM (#24993093) Homepage

    Optimization is about finding bottlenecks and then using the scientific method.

    The typical bottlenecks are CPU, RAM, Disk, and Network. A little research will reveal the tools that give you insight into those subsystems on your platform.

    Using those tools, you can identify which processes are stressing each subsystem. Then a little more research will reveal the tools that give you insight into that process.

    Then a little-to-a-lot more research will reveal what you can do to reduce the stress or beef-up your platform.

    After you do this for a bit, you'll see why LAMP is usually referred to as a stack, and not as a turn-key server. Different parts of the stack need to be optimized for different subsystems.

    Another very useful bit of research would be finding or writing your own tools to stress each of the subsystems.

    • The typical bottlenecks are CPU, RAM, Disk, and Network.

      That narrows it down then...

      • Not to mention the GP didn't mention that the bottleneck could easily be in various software layers.... some servers/databases are faster than others... but only for certain tasks or in certain setups. Some operating systems are more efficient than others, but only at certain tasks.

        Optimization is a lot more complicated that figuring out what new hardware you need to buy, especially if you've got a limited budget.

        Bill

    • Optimization is about finding bottlenecks and then using the scientific method.

      10 years later ...

       

  • the person is honestly asking for advice. most replies seem helpful; what's with the self-absorbed minority who think it's more productive to denigrate the poster/ his or her company than just lend a hand?
  • When you all started out, what route did you take to pick up the server setup and maintenance skills you have now?

    We went to school and took a job at something we're good at.
  • The FreeBSD Handbook (Score:5, Informative)

    by psergiu ( 67614 ) on Saturday September 13, 2008 @04:49PM (#24993177)
    The FreeBSD HandBook [freebsd.org] and a FreeBSD install cd.

    Read-it end to end. Yes, i know it's huge. You won't regret spending the time to read it. Install FreeBSD (even in a VM) and use it. Even if you'll use other operating systems in the furture it's a good read and you'll learn a lot.
  • by johndmartiniii ( 1213700 ) on Saturday September 13, 2008 @04:50PM (#24993193) Homepage
    Today is one of those days that I wish I had mod points.

    First, the question at hand, get yourself some virtualization, and get a box that you can just plug in at home and fiddle around with when you aren't doing anything else. Trial and error will help you.

    Just make sure that you do your trials and errors on a testing environment and not in production. It is alright to make mistakes until you sort stuff out, just don't bring down the house.

    Second, shame on you naysayers. Let this guy learn stuff as he goes. Where did our curiosity and creativity go? You could give him advice instead of being a rude, mean, naysaying bastard. Thanks for posting as anonymous cowards too. Real nice.
    • Re: (Score:3, Informative)

      I also wish I had mod points as this is a constructive response rather than the mean spirited "I'm so great, you're a waste of space" answers. We all started out once (some of us some years ago!!)

      Remember when trying stuff out -- take plenty of backups. There are two types of people: those who back up fervently and those who haven't yet had a disaster !

      One other point of personal experience I'd add (which no-one else seems to have mentioned) is buy yourself a notebook (a paper one, not a PC) and a pen. Th

      • by gbjbaanb ( 229885 ) on Saturday September 13, 2008 @06:55PM (#24994107)

        I'd recommend the notebook approach, but I prefer to use a wiki. There's less chance of it being destroyed ... because the first thing you learned was how to make backups wasn't it.

        A Wiki is better because:

        you can cut and paste commands into it without errors - including urls
        you can always read what you type into it
        you will never spill coffee over it
        age will never destroy it
        you will never lose it in the office moves
        you can share it with your colleagues
        it will always be there when you're doing things at your computer (assuming you work with LAMP)
        you can upload zips of config files, packages, etc

        Whilst you could store passwords on it, I'd recommend against doing that :) a notebook (or keepass) is much better for them.

        • by zrq ( 794138 )

          I'd recommend the notebook approach, but I prefer to use a wiki ...

          I agree with you that a wiki is very useful, particularly for sharing information within a team.
          But is this an example of recursive advice ?

          • Student : Advice on how to setup a server ?
          • Guru : Use a wiki to keep notes.
          • Student : Advice on how to setup a wiki ?
          • Guru : First setup a web server.
          • Student : Um ....
      • The backups note here is the best advise, and if you do use VMWare or something, make sure it supports snapshots. When testing they are the single most useful tool you will have to save from screw ups.

        Sure it won't teach you how to fix the mess you just created, but it'll teach you how not to create it in the first place since you can undo/redo until you get it right. This is also one of the powers of using VM's in production. A full VM snapshot is better than any Windows system restore point or remove wi

      • Another thing to remember: comments are your friend! In setting up the server and getting it configured Just Right, you're going to have to edit config files. Every time you do, add a comment, giving the date, and the reason for the edit. If you have to change one of the default settings, don't just change it; comment it out and put a new line with your new value in beneath it, so that if things go wrong, you don't have to worry about remembering how it was before. We all know about documenting our work
  • I hate plugging companies in a forum, but Slicehost maintains a repository of articles covering the configuration of CentOS, Debian, Ubuntu, Apache, nginx, MySQL, etc. They give you great step-by-step information on the installation and basic configuration of a server.

    It's free and open to whoever wants to read. http://articles.slicehost.com/ [slicehost.com]

  • Some Words (Score:5, Informative)

    by RAMMS+EIN ( 578166 ) on Saturday September 13, 2008 @04:51PM (#24993201) Homepage Journal

    While many other posters give you heat for not being knowledgeable, I commend you for making the effort to learn. Keep that attitude, and you will eventually get good at it!

    As for optimization, my advice to you is:

    1. Know what you need to optimize
    2. Measure, don't guess

    It's good to read some generic "how to optimize foo" advice, but be careful you don't end up spending your time and effort optimizing something that doesn't need it. Know what things need to be fast, and focus on those. Very often, you will find that, actually, everything is fast enough, which means you don't need to optimize anything at all.

    Once you have determined what, if anything, needs optimizing (by measuring, of course), the main thing is to identify the bottlenecks. If your pages take a long time to render, is it the web server that's slow, the network connection, the web browser, the code on the page, the code that generates the page, the database, the filesystem, or something else? Once you know where the slowdown is, find out what's causing it. Again, measure, don't guess.

    Then, once you know the cause, you need to think about how you can solve it. In many cases, this will be clear to someone who is skilled at working with whatever technology it is. For example, a good programmer will know how to improve a program, a good DBA will know how to optimize database access, etc. In some cases, however, you will find that the performance at your bottleneck can't be improved significantly. You can have a skilled programmer spend a couple of days to squeeze the last few percents of performance out of some function, but that isn't going to help if you need things to go twice as fast. In that case, you may be able to solve the problem by using more hardware or faster hardware, or you may simply not be able to solve the problem.

  • Unfortunately I think you'll find that most of us started out in junior positions where we had an opportunity to learn from someone more experienced than ourselves in addition to our own learning.

    Without that benefit the best thing you can do is to get a test environment (as you've already done), set up some form of virtualization (as has already been suggested) and jump in head-first with Google open nearby.

    It's crucial that you're not afraid of breaking things - and, in fact, I'd recommend going out of yo

  • if( porn || P2P ){

    blow it away such as /dev/null

    } else{

    send it on its way

    }

  • by Pathway ( 2111 ) <pathway@google.com> on Saturday September 13, 2008 @04:56PM (#24993229)

    First off, Optimization is less important.

    You can spend days, week, or even longer... trying to make your systems run better and with fewer problems... but problems will crop up. And if you spent all that time just "Optimizing," you might find yourself between a rock and a hard place...

    I learned early on that Backups are ever so important. Our shop doesn't do tape backups, but we do Disk-to-Disk backups of our virtual machines, and the backups are off-site. We also do a traditional file backup as well, with versioning.

    Depending on your shop, money may or may not be an issue. Whatever you want to do, it can be done for every budget. The cheaper ways just require more time/expertise on your part, and that means it might not pass the "Mack Truck Test*." If your company wants something somebody else can step in with a basic training of how things work, you'll have to go with a more expensive solution.

    Once everything is working like it should, then start working on improving it.

    --Pathway

    *: The Mack Truck Test - If a system requires some expertise to operate, and the sysadmin is hit by a Mack Truck, how long will it take for somebody else to fill the role of sysadmin? If the amount of time is acceptable to the employer, then it passes the Mack Truck Test.

  • Owned!!! (Score:3, Insightful)

    by codepunk ( 167897 ) on Saturday September 13, 2008 @05:00PM (#24993263)

    10 bucks says he is owned in under a week....

    Nothing beats experience, throw a box up on the net unprotected with no real data on it and
    see how long you can make it survive. Hint: securing the machine at the os level is the easy
    part, securing the crap code someone wrote running on it is the real challenge. In my experience
    it is very seldom someone gains access using a os exploit as a means to gain entry. More often than
    not the box is behind a firewall, nothing but port 80 open to the world. Also, do yourself a favor
    and read up a little on implementing a dmz which is a absolute must.

    • Good point, that's why App Armor and VMs are critical.

      However, you need to be prepared to say what stuff is worth all that extra work too. I don't have the time to isolate everything exactly as I'd like and maintain it, but that's where the art comes in I suppose. You have to triage security, I'd love to analyze tripwire logs every day (well not really) but I just don't have the time to do it for anything but a few key systems.

      Now, if he's just running a LAMP stack, he probably won't get owned that fast, if

  • I read this as, "hey can you guys help me keep a job I got by schmoozing and am completely unqualified for?"

    This is a real kick in the nuts to someone like me, who as a certified Linux administrator with more than 6 years of real working experience, can't find work because I'm too expensive or not such a good bullshit artist as yourself. I'm an honest guy who gets the job done and always has professional behavior in the workplace.

    You should be ashamed of yourself. This is why I would love to see a profess

    • This is a real kick in the nuts to someone like me, who as a certified Linux administrator with more than 6 years of real working experience, can't find work because I'm too expensive or not such a good bullshit artist as yourself. I'm an honest guy who gets the job done and always has professional behavior in the workplace.

      I know so many people who got into jobs not knowing what they were doing by a little judicious bluffing. In fact I know two who went from just such a state to running a successful web design and hosting company, even though neither have any 'proper' qualifications in anything related to computing.

      It happens a lot, and for the most part the people who do it do rather well. There's nothing quite a heavy dose of fear for ones job to get someone stuck into doing their homework.

      Quite whining and be more aggressi

      • I've definitely priced myself out of this market. I live in Miami, FL. There's always someone who will do it cheaper here, no matter what your price is.

        But definitely good advice.

        • I didn't actually mean to be mean, it does look like I came over that way.

          I got in the same position back when I was a nurse. After months unemployed my best friend said more or less what I said above, only with more expletives..

          The advice made me stop trying to get a critical care position, and instead got me into Alzheimer's care. Less pay, less glamor, but enough to get me back in the market, and I ended up in management.

          Nursings long in the past for me, and I'm now, as a new minted CS Ph.D, taking any a

    • by dodobh ( 65811 )

      League of Professional System Administrators. Ask, and thou shalt receive.

    • I read this as, "hey can you guys help me keep a job I got by schmoozing and am completely unqualified for?" This is a real kick in the nuts to someone like me, who as a certified Linux administrator with more than 6 years of real working experience, can't find work because I'm too expensive or not such a good bullshit artist as yourself. I'm an honest guy who gets the job done and always has professional behavior in the workplace. You should be ashamed of yourself. This is why I would love to see a professional administrators association. Human Resources and others in charge of hiring aren't very effective at separating the wheat from the chaff.

      You'd be surprised how far having good people skills will get you in life....especially in the job-seeking arena...Seriously, most people that make hiring decisions value good people skills over technical knowledge. Those who possess both rarely find themselves unemployed.

    • by hjf ( 703092 )

      Take a moment to think. You say you hate people who bluff about their skills and get a job. If they don't have the skills and they still succeed, then you, a certified admin, do have the skills. You're just a PUSSY, you're scared, you should try something else if you don't like this industry. This is how it works -- get used to it. Next time, bluff about your skills and you will get a job. Don't get scared if it seems too big: you're a cert. linux admin, you CAN do it. You know very well that training only

  • by sakusha ( 441986 ) on Saturday September 13, 2008 @05:03PM (#24993295)

    Post a link to your server on Slashdot. I guarantee you'll get a fast and furious lesson in server optimization and security.

  • First off, RTFM [centos.org]. CentOS is pretty much a RedHat clone, and their documentation is great and easy to understand.

    Some general hints in no specific order:

    - Go through all files in /etc/sysconfig, learn what they're doing and configure them as needed.
    - Run chkconfig --list, find out what each and every one of those services do and enable/disable them as required.
    - Don't plug in the network cable before you've done a rough setup of iptables. There's even a console based GUI for that.
    - Never, never e
  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Saturday September 13, 2008 @05:20PM (#24993415)

    You're headed the right way. Just keep going. I'd recommend Debian over CentOS, because it's the generic professionals distro, but that's not that important.
    If you're feeling overwelmed by what is required to get a webstack up and running, you're absolutely right in that respect - its a non-trivial amount of stuff. Allthough it is a tag irresponsible to take such a job without the basic knowlege, mind you.

    The classic LAMP webstack is solid but has lot's of components. Start with making a list of what you *don't* know, but would like to know. Formulate these out in questions and sidenotes to your self and write then down in a simple indented list in a text editor. Notch them of as you go deeper into each issue throughout the next few weeks.

    Here's a list of things from the top of my head you need to know your way around as a professional admin:

    - daemons on Linux/Unix

    - cron-jobs

    - the cli/Bash

    - cli tools: wget, mc, emacs, ssh, scp, sort, ls, less, the concept of piping, rm, chmod, chgrp (these two will help you FUBAR your LAMP-stack a few times before you get a hang of it. Don't worry, we've all been there. :-) )

    - learn VI or Emacs (the "No X" versions!!!). Get a book/download the docs/print out the cheatsheets. I personally recommend Emacs. Start today. Either are a pain in the ass and you won't bare any of those longer than 2 minutes in the beginning - their handling is bizar beyond any words - but 6 weeks from now, when you know your way about the 20 basic editing actions in Emacs and are logged in via SSH and have to digg through a script or a huge Apache config you'll be very thankfull.

    - Learn Apache. Start with 2.2. Get a book. Oreilly is a safe bet.

    - If the P in LAMP is PHP, learn PHP and do your maintenance scripting with the CLI version of PHP, thats what I do. Copying, maintenance, cron-jobs ... all in PHP. Very neat. You swat two flies in one move, as you can look into PHP code at app-level and find your way around should that be needed in an emergency.

    - Replace PHP in the above paragraph with Python or Perl if required. If Emacs is your choice of CLI editor, Elisp is a good choice for scripting aswell.

    - try to understand the file system and directory standard of Linux before you implement your own little world. A lot of the dirtree in Linux is a historically grown mess and up to individual disposition, but the essential security related stuff is not(!!). So don't mess around. Plan ahead. Take notes (on paper!) and be prepared for a reinstall after a week or two when you've totally borked your system or your systems rights.

    - Learn a versioning system. I recommend SVN, as the newest hype, Git, is still to unwieldy to handle in most cases (not enough tried and true 3rd party tools). Learn the CLI of your versioning system and use it too, so you get a hang of it. Put your docs, custom configs and other files like scripts into versioning and use it. I strongly recommend "Pragmatic Version Control with [fill in favorite vcs here]" from the Pragmatic Programmers Bookshelf guys. Real world versioning without the useless theoretical bullcrap. A very good line of books that finally made me understand versioning the way it was meant to be. AND USE VERSIONING! F*CKING VERSION YOUR SHIT. At every occasion. I'm dead serious. Learn to use revert, diff, etc. DO PRACTICE IT! It seperates the pros from the wannabees. You'll eventually find out why. Trust me on this one.

    - MySQL. Well, it sucks just as much as any other SQL RDBMS. If you hate SQL and all that comes with it with your mind, soul and body like I do, you'll just have to bite the bullet. Get a book with a good index and keep it around for hard times. Play with a few basics of the mysql cli client so you can get up to speed when you are in a jam. Don't waste to much time with it though. It takes a strange state of mind to deal with this kind of stuff. I've never quite gotten the hang of it. A GUI-tool can take the pain out of DB admining.

  • I suggest that you do not start by attempting to 'optimize' anything on the server. A small company likely depends heavily on that little server. They will be very unhappy if you break it by trying to tweak something to run a little bit faster. Honestly, most small companies just want the server to work and don't care if it is a little slow. If you speed up their file access by twenty percent, you'll probably get a, "Uh, that's nice." but it is probably not important to them -- just ask them. More important

  • If possible, make an image of the production LAMP server at work and deploy it at home. Putz around with it, try to break it and fix it. I think you might be able to use g4u to clone that LAMP server so that you could make a lab environment. CentOS is a good environment for learning that kind of thing. It is pretty easy to setup and you could also do some virtualization too.
    • I agree with Qbertino & DaMattster. Using a version control system for every config file & script is important. Testing a similar config at home is important. Learning all the basic Unix stuff is important. In addition, implement a backup strategy and test it regularily.
  • I found the following 2 books quite helpful:

    http://www.amazon.com/Practice-System-Network-Administration-2nd/dp/0321492668/ref=pd_bbs_sr_1 [amazon.com]

    http://www.amazon.com/UNIX-System-Administration-Handbook-3rd/dp/0130206016/ref=pd_sim_b_1 [amazon.com]

    Neither is a "Do A,B,C and execute, voila! $service!" type of book. They're more about understanding the concepts. Once you understand the lay of the land you're generally far better able to solve things for yourself rather than relying on someone else's tutorial.

    As many others have

  • As far as training materials go, I'd wholeheartedly recommend any of the CBT courses by LinuxCBT.com. Also, the Cisco series of CBT courses from CBTNuggets are good too. Lastly, Todd Lammle has a CCNA DVD series at lammle.com. They're all excellent. Other books, like 'Linux Systems Administration' and the 'The Practice of Systems and Network Administration' are excellent places to start. Finally, creating your own lab or administrating your own server are good learning experiences too.
  • by jimicus ( 737525 ) on Saturday September 13, 2008 @06:52PM (#24994091)

    Which, unfortunately, isn't that common.

    Experience is the best teacher, but unfortunately it's not a particularly fast one. Anyone on /. can point you at a few interesting things like Slackware, Google and O'Reilly's back catalogue, and plenty of people already have.

    What I would advise is:

    1. Learn to see past the bullshit. There's a lot of it in IT, generally being spewed by salesmen and managers who pretend they know more than they do. In my experience, the less intelligible the communication (ie. the more buzzwords), the more likely it is you're talking to someone who doesn't have a clue. The word "Enterprise" is a good barometer there - it's often used completely unnecessarily and in the IT world has almost zero meaning.

    Example: A Dell 2950 with every component that can be made redundant made redundant isn't an "Enterprise Server". It's a server. If you haven't specced it with redundant power supplies and disks, I wouldn't even class it as a server. It's a PC in a very expensive case.

    2. Sometimes it's worth paying for a solution. /. would have you believe that Open Source is the Answer to All Our Prayers, and that Richard Stallman is the Messiah. Not true - there are plenty of products which don't have a half-decent open source alternative. Courier is a great IMAP server but at the end of the day, Exchange is a very capable product and is fantastically hard to beat feature-wise. Zimbra comes close but who knows what kind of a future it's got as it's owned by Yahoo. And I defy you to find a F/OSS business accounts system which isn't half-arsed. You can't say to the tax authorities "Errr... about those accounts we're due to submit - yeah, we just realised that our accounts system hasn't been updated to account for the recent changes in tax law and so we're having to wait until it is. Don't know how long that will take".

    3. Security, security, security. Understand the ideas rather than just mindlessly installing the patches - a hardened Apache installation with a locked down PHP configuration behind a firewall operating some fancy layer 7 intrusion prevention system is great, and will help mitigate many forms of attack - but at the end of the day if you've got a badly designed PHP application all that'll happen is that intruders will access your data through a pretty web-based user interface.

    4. Look at what the business does right now, think of how things could be made better and put together a system to make things better. It doesn't necessarily have to be something that will see the light of day - it could just be feasibility checking - but it'll give you something useful to do with definite goals which will teach you a great deal and at the same time may very well benefit the business.

  • Just a few words of general advice:

    1) Keep your own testing server somewhere else. You bought a pc for LAMP? Good. Use it. Virtualize, do it in a sandbox, don't do any of your own stuff in enterprise server.
    2) Create a backup plan. Do whatever it takes, so you can restore to any point in time. This migth mean that you have to ask for mode budget for backup solutions, but just do it. Tell them it is this, or they lose all data on potential attack.
    3) Get ready for an attack. If some services go down, be sure

  • This is a fairly common fallacy which most less experienced sysadmins fall into. You can only optimize a particular software stack performing a particular task with particular load characteristics in a particular server/network environment. In other words you could optimize your CentOS 5.2/Apache/TWiki corporate intranet running on hardware XYZ on whatever the specific network configuration is, but you CANNOT simply 'optimize a server'.

    In general any competent Enterprise Class Linux distro (CentOS, SLES, RH

  • by GaryOlson ( 737642 ) <slashdot@gaAUDENryolson.org minus poet> on Saturday September 13, 2008 @07:43PM (#24994343) Journal
    Set up an application server for a social group of people with whom you have a common interest; and with no connection to your employer. Don't spend an extra-ordinary amount of time on this outside project. This will teach you:
    1) time management -- managing technology is 90% about managing time and non-technical people's expectations. People in social groups tend to understand this server is not a priority. Business users of business systems tend to be more demanding. Learning what is important is key.
    2) communication skills -- when people's primary income is not dependent upon you providing a technical service, the users will often be more forthcoming in helping you maintain the server by being more communicative.
    3) mentoring -- you will learn your technology much faster when you have to teach another. Working on an application server a couple nights a month in a relaxed social situation often provides insights the pressured environment of the workplace cannot provide.

Adding manpower to a late software project makes it later. -- F. Brooks, "The Mythical Man-Month"

Working...