views:

690

answers:

12

Being a Windows developer I'm currently working on my own project using LAMP. I understand what I need to know of PHP and MySQL, but Linux looks huge and it's not clear where to start and what is enough given my goals.
And my goals are to grasp general concepts, being able to deploy the project to a hosting provider and to be able to monitor the site's performance in order to spot problems, load issues, etc.
I know, the best solution is to get a Linux admin to do that but before I can do that I need to do it myself.

Tell me how!

It would be great if people expand their answers about what to learn with how to learn it (should I buy a particular book, or is there a good online tutorial or ...?).

+1  A: 

You might consider, based on your introduction, a WAMP option (Windows Apache MySQL Python/Perl/PHP).

Learning Linux isn't hard, but it's certainly not a short task, either. There're a lot of sysadmin tasks that carry over platform-to-platform, but the real answer to your question is to be come at least a hobbyist Linux admin, and then go from there.

warren
I'm developing on WAMP, but Windows hosting is not an option for me.
z-boss
that's kind of a shame :-| learning a whole new OS and environment is not pleasant
warren
+5  A: 

Off the top of my head you'll need to:

  1. Learn your way around the file system.
  2. Learn how to start/stop the processes (services) you are using.
  3. Find or learn a basic text editor (vim, joe, pico)
  4. Learn to check for processes to see if things are running (ps, top)
  5. If you are maintaining the server, you'll need to learn how to install packages.

These are only the basics, the next step is to realize when you have a problem and know where you can go to find out more information about it. Even with all this it is only scratching the surface and many things may not make sense, it is a good start though.

vfilby
+1  A: 

I would learn vi and bash. vi is lightweight and tends to be installed everywhere. It can be a big pain until you get used to it, but if you want to know linux it tends to pretty much always be available, and you'll need a text editor a lot. I'd also learn bash, because it tends to be the default shell.

vfilby's suggestions are good.

Definitely learn the package manager for whichever linux you choose. I would spend some time with Apache, because it's a bit of a monster just because it has a LOT of configuration options.

I try to keep my linux testbed off the public internet because I know I'm not a good enough sysadmin to keep it secure. At least put it behind a firewall. It's pretty easy to find iptables scripts to block everything coming in, so you might want to check out iptables for some good firewalling/address/port manipulation.

Good luck!

Sam Hoice
Whilst vi is handy to know, pretty much every Linux system comes with nano now, and for casual use it is far simpler to use.
JeeBee
+1  A: 

First you should decide if you are going to be managing the system using GUI tools (gnome or KDE) or if you will be accessing mainly from SSH using a command line. (This usually is a decision based on where the server is located). Learning a little of both GUI and CLI goes a long way. CLI is super powerful, much more than the Command Prompt on Windows (I know about PowerShell...)

From a GUI perspective, I typically have the terminal (CLI) running anyway, from a Debian/Ubuntu perspective:

  1. Start/Stop Processes: sudo /etc/init.d/apache stop or sudo /etc/init.d/apache start
  2. Text editors: gedit (GUI - gnome), kate (GUI - KDE), vim (CLI) or nano (CLI)
  3. Processes running: ps -aux
  4. Terminate process sudo kill -s TERM <process_id>
  5. Add a package: sudo apt-get install php5-cli
  6. Upgrade/Patch a system: sudo apt-get update && sudo apt-get upgrade

There is a whole lot of information here and a large variety of options to choose from. I would recommend going with a Linux distro that has a friendly community (i.e. Ubuntu, CentOS (debranded/free RHEL), or RHEL (you pay them to help you).

There is definitely going to be a lot of value for you to play around with a distribution over a weekend on a virtual machine or spare machine at home/work. The Linux community is HUGE and you will find excellent support if you look for it.

Redbeard 0x0A
aptitude instead of apt-get is wiser
Wahnfrieden
+19  A: 

80% of your problems will be permissions. Windows does them differently; if you login as root (or with root-like privs) you can bypass permissions. Apache can't and won't.

  • Learn how to properly set ownership of files and directories. Any Unix book will cover this: be sure to actually understand it -- it's not Windows security spelled differently -- it's a different model for security.

Of the remaining problems, 80% will be PATH issues. PHP doesn't have as big a PATH issue as Java and Python, but they all use a PATH setting to find components and libraries. You'll get those wrong regularly. Windows has a PATH, but it also has a registry, making things either super easy or super secret. Unix keeps no secrets.

  • Learn what environment variables PHP and MySQL use. Be sure you know where and how they get set. Apache runs in it's own peculiar environment, and it has commands to provide runtime environment settings via mod_php. Write short echo $PATH shell scripts to reveal what's going on.

Of the remaining problems, 80% will be database related. After sorting out database permissions, you'll still have to get connected, and the "named pipe" vs. "localhost" stuff will be wrong in obscure, confusing ways. MySQL is very forgiving, but you'll make some mistakes here.

  • Try each alternative connection, know how they work. Don't pick one because it's Windows-like, or "simpler". Actually exercise each one. How you pass usernames and passwords from web app to database server is important, also. Apache runs as "nobody" -- and you don't want to give them default access to anything. Your app should make an intentional connection to the database without using defaults.

Of the remaining problems, 80% will be Apache configs. Apache is really simple, but has a million options. There's four ways to do everything, and you'll always try two that don't work at all, and settle for the third which will be icky. The fourth, which is much simpler, will never occur to you.

  • Read a LOT about Apache configuration. The httpd.apache.org site has lots of information. Strive for simplicity. Copy existing examples and use them. Don't make up requirements or desired implementations based on IIS experience or Windows desktop experience. Copy something that works.

Of the remaining problems, 80% will be application use of the file system. If you try to open, read or write local files, you'll find that (a) permissions aren't correct on the directory you're trying to use [see above] and (b) the Unix file paths are different. Not a lot different, but enough different that something will break in an obscure way.

  • Every programming book in Unix/Linux book covers this. It's not a lot different from Windows, just enough different to trip you up the first time. Write "hello world"-like PHP pages to spike the simplest possible version of uploads or downloads just to be sure you have all the pieces and parts in place. Then fix your full app to do it correctly.

Of the remaining problems, 80% will be subprocess creation. Windows does this differently. One of the most important things in Unix is to remember that your subprocess is your child and you must actually wait for it to finish so the OS can clean up. If you think of a subprocess as a parallel "fire-and-forget" thing, you'll have zombie processes and be forced to do periodic reboots.

  • Write very simple PHP pages to spike subprocess management. The golden rule is to manage your children and clean up after them. Then fix your full app to do it correctly.

The remaining problems will be trivial application logic, but because of the platform differences, you'll blame Unix before you track down the bug in the PHP application.

S.Lott
In a former life I built a few LAMP stacks without any prior WAMP experience and this is spot on, especially about Apache.
I Have the Hat
+1  A: 

Off the top of my head you'll need to:

  1. Learn how to read manual pages/use the help system.
  2. Learn to navigate around the file system.
  3. Learn how to start/stop the processes (services) you are using.
  4. Learn where your server logs to and how to tail the log files.
  5. Learn to check for processes to see if things are running (ps, top).
  6. Find or learn a basic text editor (vim, joe, pico)
  7. If you are maintaining the server, you'll need to learn how to install packages.

These are only the basics, the next step is to realize when you have a problem and know where you can go to find out more information about it. Even with all this it is only scratching the surface and many things may not make sense, it is a good start though.

edebill
A: 

Scrounge up an old box on Craigslist and install Gentoo Linux on it. That...experience...should give you a lot of feel for Linux and how it thinks.

Also, in the case vi vs. emacs, I rule emacs. (Though you'll want to start with pico/nano, because there's no sense in learning a full-featured editor while learning a new OS).

Paul Nathan
+1  A: 

You should

  • Learn the bash shell (especially $PATH, history)
  • Basic commandos (cd, ls, rm, tail, kill, ps, top)
  • Knowing about /proc and its main uses
  • Learn an editor (vi is always installed. If you want you can learn emacs too)
  • Basic sed replacement (sed s,orig,repl,g), a little awk
  • How to work with iptables, netstat and traceroute
  • How to get informations (man, info and --help)
  • How to install a package (pacman -S <name> for archlinux, apt-get install <name> for debian based), remove and update your system.
  • Knowing how to start/stop services in your distribution (/etc/init.d, /etc/rc.d)
  • How in general a unix file-system works (inodes, what is quota?). Understanding for example /etc/fstab. Knowing about df.
  • Understanding how to manage users and groups (useradd, groupadd). Knowing the format of /etc/passwd and /etc/group
  • Where you look out for log-files for apache and the syslog daemon.
  • Knowing about some lowlevel stuff like dmesg and hdparm
Johannes Schaub - litb
+1  A: 

Mostly, you should know how to use Linux(as in daily use). Then, you should also know how to deal with command lines.

Finally, you must learn LAMP-specific stuff. You ought to know and apply some basic(or not-so-basic) security guidelines.

luiscubal
+1  A: 

Frankly, very little if the websites you're going to be working on are either very small or very large. Very small means shared hosting and you don't need to sweat it, very large means you'll probably have a sysadmin on board to handle it.

Andrew G. Johnson
+2  A: 

I had been doing PHP/MySQL on windows and mac for a few years when I was asked to port a fairly complex intranet site from IIS/Windows to Apache/Linux. I had zero experience with Linux and blank server with no OS whatsoever. In about two days myself and another windows admin with almost no Linux experience had a copy of CentOS up and running PHP/MySQL/Apache as well as the intranet.

The lessons I learned: "yum" is your best friend when installing your services, "sudo" is your best friend when configuring your services (permissions can be a hassle), and almost every other problem was a result of case-sensitivity or slash-backslash issues. It turns out we did botch the security a bit on the FTP access but this was behind a firewall (dmz) so there was no damage done before they had a real security audit and tightened it up.

Final answer: if you are willing to roll up the sleeves and get your command line dirty getting a basic website up and running on a Linux box is not a huge task until you get to security which (IMO) is better left to someone who is an expert in that area.

Nick
+1  A: 
  • Bookmark or download the GNU coreutils manual and read it regularly

  • Learn vim. A good start is vimtutor on the shell.

  • Learn how to use the security mechanisms, do not just disable them. Windows has lax security because the available applications for it expect it this way (and would break otherwise). In a Unix-like environment, applications have always been forced to behave, and security can be tight by default.

Svante