Slashdot Mirror
Server Optimization For Newbies?
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?"
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.
I'm a big tall mofo.
Bob, is that you? Don't forget that HR needs those forms, and your TPS report is due on Monday.
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.
libertarian: (n) socially liberal, financially conservative; neither left, nor right.
Slackware. Forget about Redhat and all the other GUI-fied distributions. Install Slackware and do everything yourself. It's the only way to learn.
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 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.
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".
Read my blog.
Just hire me as a consultant and ill take care of it for you.
---- Booth was a patriot ----
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 block all traffic but the three ports you need (80 for web and the two random ones). If you want to be extra-paranoid, block webmin as well and learn how to tunnel it through ssh.
Where do you work? I'd just like to know, so that I don't deal with your firm. If they're hiring such unskilled talent, I don't think I could trust them to store my personal and private data securely.
should you ask for advice on Slashdot.
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.
obviously no deficiencies vs. no obvious deficiencies
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?
I did the same you did a looong time ago. Got myself an old computer, put Linux on it, Apache, Sendmail (now you would use Postfix), bought a book about Linux. I ran my own website and my own mail server, and kept doing that for 15 years. It doesn't make you the ultimate expert, but at least you get to know what it's all about. I must say that back then, it was much easier to get started because security wasn't such an issue. Right now, you'll spend a considerable amount of time keeping your server secure....
no, I don't have a sig
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.
"Violence is the last refuge of the competent, and, generally, the first refuge of the incompetent" - Thing_1
I understand if you were a junior coming in to work under someone. But, how the hell do you get a job being the primary and have the skill set of a total newbie.
Many others have suggested you lied, I think the other possibility is that you are very cheap. Why hired that skilled guy for $60 / hour when you can hire this newbie for $15 / hour.
It frightens me that some company is putting their trust in you. I think you need to re-evaluate your carrier path or you are going to get in some serious trouble. After you screw up badly (being a total newbie, it will happen nothing you can do about it except get some experience) they might turn around and sue you if you lied to get the job.
I really hope whatever company you are working for wakes up quickly before you do too much damage. Like others have asked, what company do you work for ... I'd like to know who not to do business with.
You are giving the real professionals a bad name.
A lot of knowledge comes with experience. The internet is your friend. Figure out what you want to do and the search the internet for tips until you achieve it.
Unfortunately, experience takes time and until then your environment is very vunerable. Suggest you get a suport agreement in place until you have the experience you need.
Please don't just copy & paste from random blogs and tutorials. They might work just fine, but you'll have no real idea of how things work.
Buy a good book, and even more importantly, find a good mentor. Find someone whose been doing syadmin work for years to bounce ideas off of.
Depending on what your software stack looks like, finding a smaller community associated with one of your pieces of software can be very helpful. CherryPy was the first Python web framework I learned, and it has a wonderfully helpful, if small, community.
The FreeBSD HandBook 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.
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
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.
If you don't know what you're doing, you can't make mistakes.
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/
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.
Please correct me if I got my facts wrong.
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 your way to do so in a test environment - because one of the most important skill sets you'll need to learn is how to fix all the stuff you (or somebody else) has broken.
Books and Tutorials are all very well in their way, but I find that it's much harder to learn these things when I'm not actually doing the work along with it.
blow it away such as /dev/null
} else{
send it on its way
}
You mention a list of sources as not providing you the "hands-on approach", that's because non of them are hands-on. Really the only way to become a good sysadmin is with time on the boxes, and mistakes - never discount the mistakes as they can be the best lessons you get.
Also, don't even get your head into optimization yet.
Premature optimization is the root of all evil, and unless you really (and I mean really) know some tip on optimization you found on some forum is going to help you in the way you need, and not affect any other systems - then don't touch it. You will be surprised to learn the people that designed these OS's and protocols are actually pretty smart and the solutions that are delivered should cover 97% of all cases.
I got my experience the 'traditional' way, coming up the ranks from help desk to Sr. Admin, although I had the benefit of doing this over many years and was able to learn a lot by watching others. Your in a pretty tough spot.
Pluralitas non est ponenda sine neccesitate
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.
Seriously, getting a system of your own and spending all your spare time beating on it until you get comfortable is what you need to do. Have at least one spare hard drive and switch hard drives until you get virtualization sorted out.
Buy and read as many relevant books as you can find. The O'Reilly guides and Nemeth et al will pretty much cover it.
Try to find a mentor. There's a good chance there's an older person who actually knows how to do your job, but doesn't want it, but who will help guide you.
Some sugestions not often covered in the admin books:
learn to use bare RCS to track changes to configuration files. Pay particular attention to writing good comments about why the changes were made.
practice bare metal restores from backups on your home system ASAP using a USB drive
make a backup of the work system to a USB drive ASAP after that (in addition to any being made now)
Good luck
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.
Got Code?
I'd recommend using the NIST publications that are available out there in regards to security.
Second, follow the best practices of whatever platform you're supporting. (RedHat in your case).
Third, use whatever platform you're supporting. If your corporation is running RedHat then you're probably fine with learning from CentOS. On the other hand, if you're company is running CentOS.
Finally, learn about your SLAs and match your skills to support them.
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.
They're using their grammar skills there.
Post a link to your server on Slashdot. I guarantee you'll get a fast and furious lesson in server optimization and security.
1) the local linux users group. Those folks are likely to have lots of knowledge
2) Bastille (http://bastille-linux.sourceforge.net/) which is nice for locking down boxes. When last I used it, it was pretty good about walking you through what needed to be done with a fairly good explanation
3) O'Reilly books - suggested above, but I learned a lot from them
4) Setting yourself a goal - it seems that you have done this already, but it's worth mentioning that you need to set small goals as well. I found with learning linux that I would say "I want to listen to my mp3s" and would go about it from a specific task perspective.
5) google and other online resources - good once you get going. I don't know how much linux experience you have, but if you have enough to know what you want, then it shouldn't be hard to track it down.
-- Who is the bigger fool? The fool or the fool who follows him? --
You say you have experience with a personal server, so what parts of the corporate environment do you feel are missing from that experience?
In my experience, optimization is probably the last thing you want to tackle. Make it 'right', or useful before optimizing. Optimization is a lot of fun, but seldom cost effective for smaller scale environments since hardware is so cheap.
Centos security is based on SELINUX. SELINUX is a bottomless pit time-wise. You can spend hours reading background docs about the hourglass model and still not know how to hook AMAVIS, SPAMASSASIN and POSTSCRIPT together under an SELINUX environment. Maybe it has changed in the last year or two, but decent 'cookbooks' on SELINUX that dont waste a lot of your time are hard to find. IF you know of a decent SELINUX precompiled policy that would work for you I would use it.
Automate if possible. Keep the amount of logging data you have to look at manageable. Build in exception reporting. It is a real pain to have to spend time every day doing routine tasks.
Do backups. AND CHECK THAT YOUR RESTORE PROCEDURES ARE VIABLE. I.e they work, and they do not result in outages so long that you are better off not restoring at all.
I had a DB once that captured peformance data every half hour. But while we were restoring the data from the backup in case of failure (Which could take over 12 hours), we were losing new (more valuable) data. Not good.
LAMP. Most people use MySQL for the DB portion. But I think for you a better choice would be POSTGRES (unless the rest of the corp uses MySQL) or even a 'personal' version of Oracle.
pgmer6809
try using iptables. you could use them on the server host or perhaps even better, on a dedicated router/firewall and then place your servers on a protected internal network.
First off, RTFM. CentOS is pretty much a RedHat clone, and their documentation is great and easy to understand.
/etc/sysconfig, learn what they're doing and configure them as needed.
Some general hints in no specific order:
- Go through all files in
- 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 ever use easy passwords like root:root123, test:blah and similar. Believe me, if your sshd is accessible from the outside you *will* have a Brazilian script kiddie on it within minutes.
- After installing a service like apache or ntpd immediately find the config files and read through and try to understand all of them. Getting everything only half-working is of no use.
- Take your time and don't let anybody stress you about getting that server ready for production. Once there's stuff running on it any oversight will cost you.
- Do *not* optimize for performance. The server's probably fast enough as it is. Unless you know exactly what you're doing you'll probably only screw up and/or waste your time by optimizing a server that has a load of 0.02 anyway.
- Before moving to configure a different piece of software test everything as well as possible. Try logging in to your new ftpd as anonymous and start a warez archive. See if apache leaks configuration information. Use your mail server as anonymous relay.
- Learn whatever you can about the server itself. Install vendor-provided administration utilities and try to set up system event logging and notifications.
- Run yum update (or even upgrade) *before* going into production.
- Trust most default values of packages you've installed, but don't trust them blindly. If in doubt, read the man page or documentation.
- Most security stuff will be adequate out-of-the-box. Take precautions but don't be too paranoid. Trying to implement your own perfect security measures without knowing enough about the details, modifying perfectly good default PAM settings and similar will probably only decrease security.
- Don't forget why you're running a Linux distribution and not Linux From Scratch. Their packages, configuration subsystem, file paths, init scripts and so on are probably not according to the way you would have done it but customizing everything will only cause you tons of additional work down the road. Only customize when you have a good reason, no way around it or need to deploy your own setup to many servers.
- Last but not least, play with it as long as possible. Toying around and with and exploring a non-production server without breaking too much will teach you more real-life experience than any book could provide.
:/- spoon(_).
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.
We suffer more in our imagination than in reality. - Seneca
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 is recovering quickly in the event of losing a hard disk (or some other 'disaster') and learning how the business works. You want to help? Help the company make money. That's important to them. In my experience, the most successful system administrators are the ones who know how to get the most business value out of a system, not ones who know how to make the server run faster. That said, if the server is painfully slow because they're running with 256MB of RAM when they should have more like 2GB, then by all means recommend more RAM. Mostly, just listen to them. They will talk about what they want and most of it may be quite mundane, like installing printers on workstations. Don't be afraid to ask about how the company operates and how the computer system helps them get their job done.
Ouch! The truth hurts!
Shouldnt a person know this BEFORE they take a job?
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'm actually a software developer, but I work at a place with a lot of small projects and we do our own IT...meaning that we don't get budget for a dedicated IT staff and we end up doing a lot of it ourselves.
So, the way I learned what I need to know was to mess up a lot and get yelled at a lot. :-)
In all seriousness, we have finally landed at a place where we host and run our projects on Amazon's EC2. Some projects are even sophisticated enough now to leverage the EC2 platform and third-party services such as Rightscale for truly distributed cloud computing...but this isn't absolutely necessary if all you want is a place to run your production system. Best of all, since it's all virtualized so it's foolproof to learn new tech. When you're going to make significant changes you just save a snapshot of the current system, use it to start up a new instance off to the side, and screw it up any way you want to figure out a solution, and you can always easily revert to your previous snapshot if necessary. Just make sure you keep organized on which snapshots are configured with what, and be diligent about removing old snapshots that no longer have any purpose (again, purely organizational).
We've found in our business that the cost of doing this is vastly less than maintaining a rack of servers...so even though most projects don't leverage the cloud, we still benefit. (And of course there's room to grow into the cloud, which is also very beneficial.)
Get started by reading up on EC2, S3, and get the ElasticFox plugin for Firefox.
but have you considered the following argument: shut up.
... asking these guys?
Back in the day I was hired to admin pc networks, the day I started the Vax admin quit and when I told my employer I knew nothing about them - I was told 'your the only one who knows about computers'
Document EVERYTHING before you make any changes, if its working now and no-ones complaining Dont change it. When you do change something write your self detailed notes on how you did it, spend time learning how things are done and how the users think things are done.
This is a couple of hours coffee^w work... building from source code, I could almost do it in my sleep. There's no short cuts to learning this stuff and the first step is to get familiar with the unix shell as that's how you'll administer, configure and fix the system.
IMO, you really shouldn't be putting a server on the public net until you know how to admin the underlying OS. Plenty of assholes do just that, as you'll discover as soon as your server goes 'live'.
I found the following 2 books quite helpful:
http://www.amazon.com/Practice-System-Network-Administration-2nd/dp/0321492668/ref=pd_bbs_sr_1
http://www.amazon.com/UNIX-System-Administration-Handbook-3rd/dp/0130206016/ref=pd_sim_b_1
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 already said, virtualization and your home network are your friends. Being able to learn in a breakable environment is excellent.
ehintz
Start with Linux From Scratch project - it will teach you a whole lot. Then go with "perfect setup" howtos and research each and every point. Once you've got answers to most whys research optimization on per service basis: database, webserver, etc.
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.
What do you mean my sig is repetitive? What do you mean my sig is repetitive? What do you mean....
MOD PARENT UP!!!!
Oreilly is the best in tech books.
Most people aren't thought about after they're gone. "I wonder where Rob got the plutonium" is better than most get.
OP,
A lot of the advice your getting above is pretty good, and some is very good. I just have one thing to add about staying successful in this field: Read. Read every tech manual you can get your hands on, read tech forums, etc, etc. This is a field where knowledge is power, and I assure you there are very few topics you can learn that will not eventually come up in your career.
Your users will ask you amazing questions. Most will be amazingly dumb, but some will just blow your mind with what they know and/or with the insightfulness of their question. So be prepared!
Best of luck!
Typically I don't refer to setting up a "secure" LAMP server as optimization, so I'll list a couple of the technologies I use for both scenarios. One of the below posts mentioned that the biggest deal is the insecure application code you may be running -- this is very true. Security stuff--For this, I use mod_security (apache module) to chroot the directory in which apache works to /chroot/apache. This way, in case an app breaks it is at least limited to this portion of the directory tree. Chrooting made easy really.
Permissions -- once inside the chroot make sure you know everywhere that the web server has permission to write data, and keep these locations to a minimum. If an app is vulnerable, hopefully it won't be able to replace application code in itself and/or elsewhere.
Some speedup stuff:
Eaccelerator -- look it up, install it, it works great and speeds up php execution substantially.
MySQL query cache - look it up, turn it on, it helps a lot.
Ramdisk -- This goes with both optimization and security -- a lot of popular webapps use Smarty or a similar technology to create and then compile templates for code/data that is displayed. These apps need write access to whatever directory is used to store their compiled templates. I have an entry for a ramdrive in /etc/fstab that mounts a ramdrive inside of apache's chroot and then symlink all of those temporary directories there -- that way the compiled templates are both quickly accessed and I minimize the number of places apache can write data.
These are just a couple of the things I use to speed up and secure my server, some people may have more or less or disagree with how I do things, but at least you have a couple more topics to research :)
People only buy them because of their accomplishment, not realy to use the book because obviously anyone who buys those topics are either ignorant or professional. Attractive only of the small printing style, unique animal, and tacky colors. Let this die already. Save the paper.
This sounds cliche'..but LFS(http://www.linuxfromscratch.org/) is really a great way to really understand how Linux works.
Then, the distro you pick really makes no difference.
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 to know how to get them up - fast. If your company hosts something on the net, every minute server is down is lost business for that period.
4) Update your server regularly, preferably not during normal work hours. Keeping latest patches installed is a must, but you must also ensure no of the company services are affected and 0 downtime happens during work hours.
5) Make sure no normal employee has any control on server. Just make sure, everyone can access ONLY the resources they are meant to, too much rights -> they steal your Intellectual Property.
This is just common sense and not even technical. But from management perspective, this is the important stuff.
Just put the technical stuff on your TODO list, and focus on getting things stable and secure first.
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, RHEL) will out of the box be configured for reasonably optimum overall performance on common hardware. If it wasn't, they'd tweak it so it was. Not to say that whatever the defaults are ARE optimum for your given hardware, there could be driver settings or similar things that may even be horribly bad once in a while. No vendor can anticipate all configurations, but until you have specific software you know you will be running and the specific hardware it will run on, tweaking is possibly educational in a basic sense, but that's about all.
Similar comments could be made about security, although there are some pretty good general rules that will apply in most situations. Again, a competent Enterprise Class distribution WILL be pretty much locked down. The best thing to do there is obviously patch up to the latest patch levels and review the vendor's security update database to ensure there aren't any known gotchas that the patches don't cover, like sometimes an app will be fine, but the supplied default configuration may present vulnerabilities in certain situations.
I think overall your plan is not a bad one. Most of the people here (that DO know anything) learned it 'hands on' like that.
Overall security is really the sysadmin's most challenging task. I don't know if you'll be in charge of an entire network, but either way you'll want to gain an in depth understanding of things like DOS/DDOS prevention techniques, DNS security considerations, Proxies, SSH, IDS systems, etc. If you have input or responsibility for security policies and/or enforcement then there could be a LOT more to know/do. Actually a lot of that has little to do with specific applications, or even really technology itself.
There are a few dozen other things you may well want to know all about. I'd suggest maybe doing some extensive research online and find out what you do and don't know about, then you can start to fill in where you may be lacking.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
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.
Every mans' island needs an ocean; choose your ocean carefully.
Assembler? WHy not raw binary or hex, if you get tired of 1/0. Or, do it in MIXAL on a virtual Mix Machine.
That'll larn ya..
Just use windows and get your paycheck every week. Why do you want to learn stuff? Learn stuff doesn't pay your bills... Windows pretty and easy stuff do...
Help I don't know how to my job and I need you to tell me what to do?
The best way to play around with publicly accessible servers is to buy them by the hour. Services like Amazon's EC2 or, even better, NewServers.com's physical servers allow you to pay around 10 cents/hour for each server. If you want to play around with clustering, just get a couple servers for an hour or 2. If you screw things up, just launch a new server. If you want to test replication or failover, add another server, watch the failover happen properly and kill the first server.
Same boat here. Started on Slack, use RHEL at work, and Mac/FreeBSD/Slackware proper and BlueWhite64 (unofficial 64 bit Slackware port)/Fedora at home. But I have absolutely no problem running any distro (or Solaris) once I find out if its got sysV or BSD inits.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
was taught to me by the hackers that kept killing my server. Fortunately - it was all hobby and for fun, but I learned so much about security and I have managed to to be hack free for years.
You've just been hired as a new Sys Admin and do not have a lot of experience. Yet the first thing that you want to do is set up a web server and open it up to the public? As I understand it, this is not something that you have been asked to do, but something that you want to do for practice and training. Nothing like biting off more than you can chew. And possibly opening up your organization to a huge security risk. I hope that you have a good Firewall Admin...
I've been in the IT industry for about 13 years. I've been where you are now. I started out as an email administrator and worked my way into server administration. I am now a Senior Network Engineer. My advice would be to first spend time understanding the current environment and make sure that everything is being backed up and can be restored (one of the most overlooked of server admin jobs). Also, if you don't have a monitoring system, it's time to implement one. I like Solarwinds Orion, but there are a number of free systems out there such as Cacti and Nagios.
Assuming that your beyond this point, it's time to play. Like others have mentioned, VMWare is your friend. Install VMWare on a spare system. Pick an OS and learn it inside and out. Buy a couple of good books about that OS. In most cases you can charge these back to the organization as a training expense. Once you understand how to install, configure, maintain, and monitor the system, then you can get into how to secure it. Until you have a good grasp of how the OS behaves you won't have enough understanding to properly secure it. Only at this point should you build a web server.
David
CentOS and other redhat based distros have their place, but if you don't have the infrastructure in place, they are a bitch to maintain. Go for Debian or Ubuntu. Ubuntu even has a LAMP option in its install. Write some cron scripts to apt-get update; apt-get upgrade and you are already ahead of 60% of the internet.
As for performance, get a better server. Until you start running into some fairly hairy issues, new hardware is the cheaper way to go.
Virtualization? Sure, it will help you learn about managing a Linux/Unix/WhateverIx box, but it won't help you in optimization. Why do I say that? It won't teach you that SCSI rules over ATA for performance. It won't teach you that you can get better performance by separating your data from your transaction logs. It won't teach you about how easy it is (or hard) to recover from a hardware RAID failure vs. a software RAID failure (you can do the software in a VM, but not the hardware). It won't teach you the pain of recovering from dead hardware when you don't have identical hardware to replace it with (easier under Linux in some cases, much harder with Windows). Then again, virtual machines are becoming the production machine of choice for many corporations. If you want to learn something useful, learn VMware ESX and XEN (and it's commercial iterations). So maybe you don't need to know anything about real hardware.
1: Fixing more broken installations than I can remember. Working late at night on failed systems and recovering (or not as the case may be) data from disks that have failed. From this I learnt what is needed when the crap hits the spinning distribution device. 2: Leaning how to investigate, read manuals, tech notes and search for the information I need when faced with something I have never seen before. 3: Listening to advice. 4: Practice. 5: Practice 6: Practice. Also no amount of book learning can really substitute for 20 years experiance.
Security and performance are different issues though they can overlap.
The first step for security is turn off every service not needed. For remote access use ssh, not telnet.
The first step for performance is to learn to use the various monitoring tools and how to interpret their information. Some of these are top, vmstat, sar, free, netstat, ifconfig, du, df. Depending on your flavor of os and what is installed you may have some of these. You may also have vendor specific tools as well.
Sometimes just watching the various indicator lights can give you an idea of what might be a problem, like if the disk activity light is on solid for minutes at a time.
Don't wait until you have a problem, get used to the tools, how they work, and what they display when the system is running normally.
Some problems are caused by peaks in services. The boss sends an email to everyone that includes a 1mb attachment and everyone has their mail program set to check for new mail every 10 minutes. You can have very short term problems that aren't really a problem. On the other hand, if mail is always a little slow, there could be a problem.
Throwing money at a problem won't fix it if you don't know what the real problem(s) are. Most performance issues tend to be caused more by I/O bottlenecks then by cpu. Faster disks and/or more ram tend to help more then a faster cpu in many cases.
called.
VMWare's corporate owner decided to turn it into a conforming, completely not distinct, part of their bureacracy, and the founder/CEO of VMWare quit ( or Was Gotten Rid Of ), for insisting that VMWare required focus, management devoted to *its* function and survival in *its* market...
http://www.theinquirer.net/gb/inquirer/news/2008/07/09/emc-sacks-vmware-ceo-takes
http://www.marketwatch.com/news/story/vmware-shares-hit-competition-executive/story.aspx?guid={07369773-A431-4E60-9BE7-BFEE779EFD32}&dist=TQP_Mod_mktwN
Notice that competition is heating up ( Microsoft is committed to eradicating 'em ), and their overlord is committed to preventing them from having the autonomy to survive...
One thing that is consistent: if a company has focus on what it's doing, it can endure.
If it hasn't, because it does too many things, in too many directions, its profitability dies, then it starts doing the slash and burn style of management, then customer support goes to hell, then the spend time and resources taking their chunk of the market down with them.
( anyone here remember the cost of going with Caldera? )
Ah, not VBox, but VirtualBOX, I think.
... learn BSD, and you know UN*X. I like Slack (started with it back in the day), but I have never learned as much as quickly as the first 6 months of running OpenBSD on the desktop and server every day. Not having to run out to an assortment of websites and info pages to find out how things work is one of the underrated features of OpenBSD (every single piece of the system has a man page that is complete, authoritative and up-to-date. None of this "this is a placeholder, see our info page!" or "see this website" crap that's so common in the man pages of Linux distros).
Learning UN*X by means of BSD gives one a more stable foundation, IMO, than starting with Linux, due primarily to the more cohesive, clean and consistent design of the BSD operating system as compared to the relative chaos of the average ephemeral Linux distro. (one of the things I like about Slack is that it's the most BSD-like of the Linux distros.)
that said, anything that forces you to know _why_ and _how_ something works in order to get it installed and running is going to benefit you much more than any wizard, GUI or automated installer that hides what's going on under the hood.
http://darkuncle.net/OpenBSD/OpenBSD_dualboot.txt if you want to try it on a system that's already running Windows ...
illum oportet crescere me autem minui
"wire" up your own CPU,
THEN use assembler to code your GNU/HURD OS!
( then, of course, install *Duke Nukem Forever* on it :)
For me the best (but a bit unreal) advice would be: identify the problematic applications or better, the routines that consume most of the system resources.
In most cases despite a lot of "sysadmin work" (for example, tuning, recompilations, updates, etc) your performance will improve to a modest percentage (maybe around 5-20% is a reasonable number) but after discovering (and correcting) for example a cpu-bound loop, or some runaway processes, or "growing" memory leaks, you can gain an order of magnitude on performance or available resources.
The bad/unreal part is getting the cooperation from the developers, and after a solid demonstration of their "performance bugs", get management support for code rewrite. Of course this is difficult to do for most administrators because of 1) their lack of programming skills or certifications, but mainly because 2) developers are mostly uninterested in performance, specially after application deployment.
Specifically look for young Java programmers asking for more gigabytes of RAM and faster CPUs to create new threads for every little piece of data being processed... well, that were my worst experiences... In your LAMP system, depending on the application nature, a check in the query plans, database structure and indexes probably deserve most of your focus.
Hello supaneko and slashdot people,
(excuse my terrible English)
In english I recomend you
Basic level:
* Tuning LAMP systems, Part 1: Understanding the LAMP architecture
http://www.ibm.com/developerworks/linux/library/l-tune-lamp-1/
* Tuning LAMP systems, Part 2: Optimizing Apache and PHP
http://www.ibm.com/developerworks/linux/library/l-tune-lamp-2.html
* Tuning LAMP systems, Part 3: Tuning your MySQL server
http://www.ibm.com/developerworks/linux/library/l-tune-lamp-3.html
Intermediate level:
* Linux Performance and Tuning Guidelines
http://www.redbooks.ibm.com/redpieces/pdfs/redp4285.pdf
* Apache Performance Tuning
http://httpd.apache.org/docs/2.2/misc/perf-tuning.html
* MySQL 5.1 documentation, Chapter 7: Optimization
http://dev.mysql.com/doc/refman/5.1/en/optimization.html
I also write someting but it is in spanish:
http://www.xtec.net/~acastan/textos/Tuning%20LAMP.pdf
Have nice autumn. Greetings from barcelona.
Alex
Will all beings be happy
"but nothing I've found really gives me a hands-on approach to the topics I want to learn about"
Maybe if you'd care to share exactly what you're missing someone might actually be able to give you a straight-to-the-point tip or point you in the right direction. Good Luck!
The simplest and best way to learn this stuff quickly and with help is attend a Redhat training course and try to get an RHCE certification.
Try www.redhat.com/training/ for more information. Redhat and CentOS are close enough to be interchangeable.
O this learning! What a thing it is - William Shakespeare
I'm a little saddened that I see no response (at my threshold, at least) that contains the obvious: if you want to optimize something, anything, the most important thing to do is profile. Don't optimize the 99% of the process you spend 1% of your time in, optimize the 1% of the code you spend 99% of your time in.
The better you can figure out what your bottleneck is, the better you'll be able to improve performance. Other advice: watch graphs of system load and resource utilization over time, especially as you make changes. I enjoy munin for this purpose. Get comfortable with the output of programs like vmstat, iostat, etc. and use them when your server is loaded.
-bugg
I got a job as an automotive mechanic, but I've never fixed a car before. To help me learn auto mechanics, I bought an old car to fix up. What books will help me become an expert in auto repair?
Think it about it. Would you let someone posting something like this work on your car?
If you take on a job that requires technical savvy, you better have a strong aptitude and interest in the subject matter. People who excel in IT do not learn it "when they have to". They have a appetite for it. They "play" with IT and technology all of the time, for enjoyment, curiosity, learning, broadening their knowledge. If you were this type of person, you would have set up a Linux server at home sometime in the past just because you wanted to. If you are not this type of person, you are out of your league.
I concur with many other commenters that getting to learning about LAMP setups after you get a job requiring that knowledge is a bit late, but better late than never.
Setting up a LAMP server is extremely easy. Just install your favorite distro, select apache httpd, mysql and php at the installation and there you have it. That is not learning. When I got my job as a sysadmin I knew my way around Apache and PHP but did not have a frame of reference where to tweak it for the load we got. I mean you've got threads, workers and a bunch of other parameters to tweak to get the most out of this sites unique load. What I have learned is
You will have to hope that you can aquire the knowledge you need it badly. Learning how to use a fire extinguisher after your pants catch on fire is not a good idea. You might learn before you get burned if you're lucky, but don't count on it.
When you all started out, what route did you take to pick up the server setup and maintenance skills you have now?
10 years of messing around with redhat, ubuntu, debian, slackware, gentoo, solaris, openbsd, freebsd and windows. I went project by project. First I learned how to setup an eggdrop. Than IRCD. Moved on to Apache. Eventually learned perl, and combined that into Apache + PHP. I've run a personal colo for 9 years and began working as a part time Jr Admin when I was 17.
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?
Despite my experience, I to had limited experience in enterprise administration as well. That is why I was on a team of 4 Sys Admins and the other 3 are all Seniors who had worked for the company a minimum of 3 years. You sound in over your head to me. I don't blame you, that should have been clear during the interview process. Sounds to me like your boss needs to refine their hiring practice and set you up with a Sr Admin to train you while you get up on your skill set.
I suggest, based on my own recent experience, that you run up Centos 5.2, update the installation, then install Virtualmin GPL. None of this will cost a cent, it is all very high quality software with strong community support. This has enabled me to manage a web hosting server in a secure, efficient manner with very low effort. If you want experience I suggest you pursue GOOD experience, anyone can run up XP and wish they hadn't.
Reminds me of the old slashdot....
1) As others said, learn and make good use of virtualization. It gives you great flexibility, and it's the future (and the future is now...)
2) Metrics are everything. You *need* to gather performance data, as much as possible. Run cacti, run nagios, and set up tests for all the metrics you can reasonably get.. at a minimum interface bandwidth, load average, # procs, memory statistics, and disk usage. Learn to use sar. Make your first server your admin server that monitors everything else for you. You can't judge the effects of your optimizations without metrics.
3) Install. Harden. Document.
- install the OS, update it, then disable every service you don't need. Then document this, so you can repeat it the next time. (and if you are virtualizing, grab a copy of the VM at this stage so you can clone it later) Continue to keep good documents about the systems you engineer. Use a wiki.
4) Make sure you can do everything from the command line. Understand what uses what socket, what uses what port, and how the pieces communicate. Understand PHP error reporting, logging, apache virtual hosts, etc.
5) Use version control on your configuration files... lots of ways to do this, find something that works for you. It's hard to optimize if you don't have a record of your changes.
topics I want to learn about.
Ok, even small time, this is stuff you should have learned before you are in this type of position.
If you are truly 'begining', then your success at a secure public server is borderline scary, especially with CentOS or any *nix. Even OS X server is not a plug in and go public setup.
This is why Microsoft makes lots of money, as Windows Server is what someone with your level of expertise should be looking at, since locking it down is something it does well, and is virtually idiot proof. (Especially Server 2003 and 2008)
Save your company and pick up Windows Web Server for a couple hundred bucks, and work on learning more about server security and configuration in your private time.
First thing you need is a helpdesk ticketing system. Even if it's a wall covered in post-it notes.
Second thing you need is a way to rebuild a host from bare iron to working without expending any effort.
~~~~~ BigLig2? You mean there's another one of me?
Lots of good advice here.
One thing I haven't seen mentioned, is how critical it is to have a bullet-proof backup system in place, and daily monitoring of tapes, etc. to make sure the backups are working, and periodic testing to make sure you can recover both individual files as needed, and the entire system (OS, config files, user data.) Next on the list should be off-site storage of the backup sets, so a fire in the server room doesn't put you out of business. Longer term, you also need to look at a disaster recovery plan that is sized appropriately for your company (how long can it be without IT services, what needs to be brought up first, how long before full systems need to be restored.)
Next, let your key users and management know what your backup plan is (e.g. daily incremental backups, with full backups each weekend, with all tapes kept for 1 month. 1 full backup each month kept for 1 year, 1 full backup each 6 months kept until the longest relevant retention schedule requirement is met.) This will allow you to get buy-in from your key staff that your backup plan meets their business needs. This also allows you to reasonably explain why their unreasonable file recovery request can not be met.
Again, monitoring and testing the backup systems is key. Write yourself a script (and test it!) that sends you a message if there are any unexpected messages on the backup log. I have been burned far too many times by our IT dept. when a dead tape drive was ignored for well over 6 months, and several other excuses for not being able to do a simple file restore. Having your users calling for your job and your head because you can't recover a simple, but critical file is not a good thing for your long term career goals.
Check out the DOD Security Technical Implementation Guides (STIG). They are not the most complete or up-to-date, but are a reasonable baseline for a production server.
Publicly-accessible at:
http://iase.disa.mil/stigs/stig/index.html
The STIG is the human readable form, the corresponding Checklist is the technical details for each finding (and is update approximately quarterly.)
Hi, appreciate the focus on optimization, but don't do it at the expense of uptime - slow and up is better than not up.
For your LAMP stack - get it outside your own network completely to start with, get a cheap hosting account and do it externally, so any holes you leave happen on someone elses virtual server.
And if possible - hire contractors to do as much as possible. Thats hard, and expensive, but its easier to have someone tell you 'always close port X' than to discover you've had someone coming in via port X. (Yah, oversimplified, YGTP).
Is it ask slashdot week?
How do I start a project?
How do I make some extra money?
How do I do my IT job?
Seriously, WTF. First of all, stop looking to the intarwebs for how to do everything. Try using some common sense! Especially basic stuff like how to make an extra buck. And how is it people get into IT jobs in the first place, have no clue what the hell they are doing, that they need to go to slashdot to figure out how? What the hell is wrong with people? What the hell is wrong with companies that put people in these jobs?
The Practice of System and Network Administration - Limoncelli & Hogan
Unix System Administration Handbook - Nemeth, Snyder, Seebass, Hein
These are the two most important books to have on your reference shelf. I've been doing sysadmin for years and still have yet to outgrow these two. If you're working with Centos then I recommend Red Hat's Deployment Guide as a fantastic resource for learning how to set up and configure a server "the Red Hat way".
The average person here has biceps the size of a match.
I'm rather eclectic and have a wide range of interests. In high school I was torn between majoring in Computer Engineering and Marine Science or Oceanography. I eventually chose to major in CE though I sometimes regret not choosing Marine Science. As a senior the marine biology class I took went on a field trip to Mote Marine Laboratory. There one of the scientists offered me, and a friend, summer jobs. He said if we wanted to he would help us be accepted into college and pay for it with a major in a related field. By that tyme I had already decided to major in CE, if I had known then what I know now I would have done a double major, CE and a Marine Science. I didn't know such things were possible. Coming from a low income family, my dad retired as an enlisted person from the US Air Force and my mom worked her way through a 2 year technical school to become a lab technician in medicine. Not having the money to go to college, and not believing I could get financial aid to go, I enlisted in the army to save money to go to college when I got out.
However me being active in the outdoors didn't start when I went in the army, as hinted at above. I spent a lot of tyme on the beach, coast, and scuba dived. Growing up I also camped at least a couple of tymes a year, went fishing and hunting frequently, and gardened. Also, for physical fitness in high school I was on the swim and dive team and I worked out with the gymnastics team.
From what I heard the main long-term stress on the condition comes from hauling around all that high-tech these days. Is this true ?
I don't know if it's true. I was in the army in the '80s and we didn't have a lot of high tech goodies. About the only high tech stuff we had was the transmitters and receivers we used for mock combat. We'd attach a transmitter on the end of our M16 which when the M16 was fired would send a signal. We'd also wear detectors, which if the alarm went off meant you were shot and you'd have to play dead. Heck in my first unit, at Fort Benning, we didn't even have APCs, Armoured personnel carrier. When we had to go somewhere we either marched or we took duce n half trucks.
I imagine they had less gadgets back then but they didn't have light materials as well ...
Some may think we had to carry a lot but I don't. At least once a year we had to carry 40 lbs in our rucksack along with our M16, canteen, and other things on a 12 mile march. We frequently marched a lot, being a leg unit and not having APCs, so that wasn't a hard thing. Actually when we did the qualifying march, we didn't actually march. Instead we did the march individually, like a hike, and some of us would run it.
Now if you want to talk about carrying a lot of weight, when we trained with the Special Forces their rucksacks weighed at least 90 lobs. To match them we'd put big rocks in our rucksacks but we couldn't get ours to weigh as much because theirs were bigger than ours. They'd let us carry theirs some though, as some would say we were hardcore.
A friend of mine is in the army and he once explained how they had lessons in "dissecting" human faecal matter to establish the health of the opposition.
That came after I got out, we didn't do anything like that.
Falcon
Should there be a Law?
I can feel some of your pains, I got brought in under a really sharp MCSE and have been able to learn alot of the windows stuff under him. We implemented VI3 just over a year and a half ago which has been made my responsibility. We brought in a local consultant for 2 days to assist us in setting up and that is all I got. Everything from there forward has been reading white papers, online forums, etc. I would highly recommend virtualization to set up several machines and make them all work together, regardless of whether you're gonna be running Linux/Unix, Windows, or whatever.