Research and Development
LAMP is an acronym for a solution stack of free, open source software, originally coined from the first letters of Linux (operating system), Apache HTTP Server, MySQL (database software), and PHP, Python or Perl (scripting language), principal components to build a viable general purpose web server.
The precise combination of software included in a LAMP package may vary, especially with respect to the web scripting software, as PHP may be replaced by Perl or Python. Similar terms exist for essentially the same software suite (AMP) running on other operating systems, such as MS Windows (WAMP), Mac OS (MAMP), Solaris (SAMP), or OpenBSD (OAMP).
Michael Kunze coined the acronym LAMP in an article for the German computing magazine c't in April 1998. The article aimed to show that a bundle of free software could provide a viable alternative to commercial packages. Knowing the IT-world's love of acronyms, Kunze came up with LAMP as a marketing-like term to increase the popularity of free software. O'Reilly and MySQL AB have made the term popular among English-speakers. Indeed, MySQL AB has since based some of its marketing efforts on the popularity of the LAMP stack.
The scripting component of the LAMP stack has its origins in the Common Gateway Interface protocol that became popular in web servers in the early 1990s. This technology allows the user of a web browser to execute a program on the web server, and thereby receive dynamic as well as static content. Often programmers would use scripting languages such as Perl for these programs because of their ability to manipulate text streams from multiple sources easily and efficiently.
The LAMP stack widely used because it offers a great number of advantages for developers:
In this tutorial I use the following parameters:
server1.example.com192.168.100.250192.168.100.253These settings might differ for you, so you have to replace them where appropriate.
This is one of the most often asked questions about Linux. Usually the answer is It depends.
Linux requires only separate / (root) and swap partitions. But it is a bad idea to install everything into a single / partition. Even if you don't need separate partitions, the practice you get from partitioning disks and learning how much space each partition needs in a given situation will be invaluable when someone asks you to build a server for them.
Spend a few minutes before installation considering the functions of the machine you are building and this will yield a useful and efficient partition table. The more often you do it the more of a feel you will get for how much space a distribution needs for different tasks. Now that you have the above information there is no excuse for poor partitioning, and you can help make the world a safer place for data.
Here is a list of the basic folders in Linux and why you might or might not want to put them on their own partitions.
/
Root partition. Contains all folders that have files or mount points. This has to be on its own partition because it is the root folder for all other folders. Typically, you would want a few Gigabytes for /. If you create separate partitions for /usr, /home, and /var, root could be much smaller (maybe 500MB.)
/usr
Contains files that don't change very often. Usually program files installed by the operating system. You will want at least 500 MB for /usr. A few GB is better if you can spare it. /usr contains /usr/local, which is where programs you install yourself usually end up.
If you are installing software to build from a tar ball or installing software that isn't part of a vendor's distribution, like an RPM or a DEB is, you will probably want to install it in the /usr/local file system. This file system is usually left untouched by the installation or upgrade process of a linux distribution and is ideal for installing third party software. If you plan on doing a lot of this, a separate partition is a great idea, because if you want to do a re-install rather than an upgrade, you can simply tell your distribution not to format the /usr/local file system when installing and you will leave your third party software in tact. The format of the /usr/local file system is almost identical to the / file system.
/usr/local/bin and /usr/local/sbin are also the correct places to put any scripts you may write after you have your system up and running. This is preferable to place them in /usr/bin and /usr/sbin or even /bin and /sbin, as these should really be static and left the way the distribution intended them. It also makes backing up a system much easier if all your locally created scripts are in one convenient place.
/home
Contains users' files. Although /home doesn't require its own partition, I highly recommend it. That will make upgrading, backup, and recovery of the system much simpler and faster.
/home is also where the storage file system for a file server should go. The same is true for web server pages, and ftp server data. Obviously if you are building a web server, have a separate /home/httpd file system on a nice fast SCSI disk. Same with /home/ftp.
/var
Contains files that change often, or are variable. Making this a separate partition helps keep you from running out of disk addresses. Since /var contains lots of small files, sometimes log files will accidentally use up too much disk space and temporarily crash the system if /var is on the same disk partition as /.
The /var file system is the most varying file system, hence its name. The function of the machine will determine how much you need. For example, 400 MB is usually sufficient for a workstation. If you are building a proxy server, you will need a separate partition, but preferably a separate disk, for /var/spool/squid. The same goes for a mail server, except the file systems of interest are /var/spool/mqueue and /var/spool/mail. The size of /var/spool/mail will depend on how much storage you want for user's mailboxes, and the size of /var/spool/mqueue will depend on how much mail in transit you wish to spool. Mail servers acting as a secondary MX might need a lot here.
There are other smaller directories in /var/spool that are of interest, so I would recommend a /var/spool of 300 to 500 Meg for any server application in conjunction with the /var of 400 Meg. For a workstation you may be able to use the 400 Meg /var partition to house your /var/spool as well, but it may pay to enlarge it a bit.
/var/log, as the name suggests, is the final resting place for logs. Once again the size of this will depend on the function of the system, but as a general rule it is highly recommended that you have a separate /var/log to your /var partition, regardless of the machine's function. This way any stray system logs that fill up will have no effect on your system other than stopping logging. This goes for both servers and workstations alike. If you are running a heavily loaded proxy, mail or web server, you will need heaps and heaps of disk space here. Fully loaded proxy servers in peering arrangements can easily generate hundreds of thousands of bytes of log files an hour. The same goes for mail servers. The mail can come in and go out very quickly on a fast link, but the log files stay around. You also don't want a slash-dotted web site to fill up your logging directory, so careful thought here will pay off in the future.
The /var file system is also often used for the storage of database data. /var/db or /var/lib is the file system that is used, and you will need to keep this big enough to hold your data. Often a separate fast SCSI disk or RAID will make your database much faster. IO is often the biggest bottleneck in database systems, and an IDE drive in /var/db or /var/lib won't help.
/tmp
Contains temporary files. Usually 100MB is more than enough, but again, check your distribution installation instructions if you aren't sure.
/boot
This contains the files needed to boot the system, including the kernel and any initial ram disks. You only need to make this a separate partition if you want to use software RAID or other disk structure. If you don't know why you need a separate /boot partition then you probably don't – it is safe to include this on the / partition. If you do make it a separate partition, 100MB should be more than enough. You can get away with 50MB if you don't plan to do very many upgrades.
The /boot directory is probably the most useful file system, and often the most forgotten. Having your kernels on a separate partition will make rescuing a system that has crashed a whole lot easier. This means that booting the system and recovering the partitions can be attacked as two separate tasks.
/bin and /sbin
These contain binary files. These are usually commands and tools to help you interact with the operating system. /sbin has security sensitive binary files. I usually just put this on the root partition.
/etc
Contains configuration files for the operating system and programs. This folder has to be on the root partition. The system will not boot correctly if this is on a separate partition, because the system needs to read the /etc/fstab file in order to mount disks during startup.
/dev
This folder doesn't actually exist on your disk. It only exists in memory. It contains all the devices (or hardware addresses) for your system. You normally don't need to interact with this directory.
/proc
This also only exists in memory. It contains information about your system status, such as the speed or your processor and the amount of available memory.
/root
The root user's home directory. This normally doesn't have much in it and can usually be included on the same partition as /.
/mnt
Commonly used to mount things like a CD-ROM or a USB flash disk. Does not need its own partition.
/lib
Contains libraries. Does not normally need its own partition.
swap
It is a conventional wisdom to create swap space equal to the amount of RAM, or just accept the proposed value during the installation.
Servers typically are configured with more swap space than their desktop counterparts. Even though a given amount of swap is sufficient for its operations, the server might come under transient heavy loads which cause it to page out at a high rate. Some administrators prefer this to the server crashing altogether. In these cases, swap might be several times the size of RAM.
It is often a good idea to place this in the physical middle of the drive. Then the heads have less far to travel to swap out data when the system gets loaded.