Set up a LAMP server on Ubuntu for local development

A LAMP server bundles Linux, Apache, MySQL and PHP into a practical workspace for building web applications without relying on shared hosting or a remote development box. It lets a developer reproduce the routing, database and scripting behaviour of a public site while keeping source code, test records and credentials on one machine. That arrangement suits Australian homes and small offices in the mid-2000s: an ADSL connection in Sydney or Melbourne could handle package downloads, while a regional DSL line or mobile data connection made a hosted preview slower and less predictable. A local stack provided a consistent baseline regardless of the connection.

Ubuntu 6.06 LTS made the combination approachable because APT could install Apache 2.2, MySQL 5.0 and PHP 5 with matching support packages. The finished machine should be treated as a deliberate workspace rather than a pile of software. Its document root, virtual host, database account, PHP settings and deployment commands need to follow one documented path. The sequence below runs from a clean installation to a repeatable server for local development.

Choose the right Ubuntu foundation

Ubuntu Desktop and Ubuntu Server contain the same core components, so the choice depends on how the machine will be used. Server avoids a graphical session and suits a dedicated workstation or spare PC, while Desktop is convenient when the developer also needs a browser, image editor or other desktop tools. On older hardware, memory matters more than the choice of installation image: 512 MB is a workable minimum for a modest application, while 1 GB leaves room for Apache, MySQL and a browser without constant swapping. Confirm that the machine uses a supported processor architecture and that every application has a Linux build.

The second decision is whether to install the services directly or run Ubuntu in a virtual machine. Native packages are quick and efficient, but they change the host system and can conflict with desktop software. A VMware or equivalent virtual machine offers isolation and can be copied between an office desktop and a home computer, although it consumes disk space and needs enough RAM. A remote shared host saves local administration, yet shared PHP settings, noisy neighbours and weak support can make debugging misleading. In Australian workplaces, where many businesses still relied on Windows, Active Directory and Microsoft Office, keeping an Ubuntu guest available for a project avoided changing the whole desktop just to test a Linux service.

Choose a source location and a host name before configuring Apache. A reserved local name such as lamp.test cannot accidentally reach a public site, although lamp.local may also be useful with a local resolver. Keep the working source tree in the developer's home directory and expose a release directory through the web server. This avoids mixing editor files, private settings and public assets. The host preparation sequence in Abhay Chauhan's setup guide offers a useful cross-check for the initial Ubuntu installation and account setup.

Prepare and secure the host

Install Ubuntu, update the package cache and create a named administrator account rather than working as root throughout:

sudo apt-get update
sudo apt-get upgrade
sudo adduser developer
sudo usermod -aG sudo developer

Choose a strong password and retain the original installation account as a documented recovery option. A separate daily account reduces accidental system-wide changes, particularly on a shared development PC. Record the host name, local address and recovery details in the project's operations notes, not in a public Subversion repository or a loose file beside the source code.

Secure remote access before exposing any other service. Install OpenSSH if the host must be reached from another computer, restrict the addresses permitted to log in through /etc/ssh/sshd_config, and restart the SSH daemon after checking its configuration. The database should listen on the loopback interface only. A workstation used solely for development does not need a public SSH route, Apache, FTP or MySQL; exposing them to an ADSL address adds risk without helping the application.

Set the locale and clock deliberately. Australia/Sydney handles daylight saving, while Brisbane remains on a fixed offset. The en_AU.UTF-8 locale supports Australian spelling and punctuation and can prevent small formatting differences in imported records. If the environment will contain real personal information, remember that the Privacy Act 1988 and its National Privacy Principles applied to Australian organisations; development databases are safer with invented or altered records. Keep an encrypted copy of the database and its recovery procedure away from the working copy of the project.

Configure Apache, MySQL, and PHP

Install the Apache web server, MySQL database server, PHP 5 runtime and common extensions from Ubuntu's repository so that package versions remain aligned:

sudo apt-get install apache2 mysql-server php5 php5-cli php5-mysql \
  libapache2-mod-php5 php-pear

Create an Apache virtual host for lamp.test, point its document root at the release directory and grant the www-data user read access. An Apache 2.2 configuration keeps the access rule explicit:

<VirtualHost *:80>
    ServerName lamp.test
    DocumentRoot /home/developer/lamp/public
    <Directory /home/developer/lamp/public>
        Options FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

Enable the site, add 127.0.0.1 lamp.test to /etc/hosts, and restart Apache with /etc/init.d/apache2 restart. The AllowOverride All directive lets a framework supply its own .htaccess rules for clean URLs and access controls. Set permissions so the developer can write source files while Apache can read them, but avoid 777 as a shortcut. Confirm the result with curl http://lamp.test and read /var/log/apache2/error.log when the response is not the expected test page.

Create the application database and a dedicated database user from the MySQL administrative prompt. Give that account only the privileges needed for the project and keep the server bound to localhost. Store the connection values in a local configuration file excluded from source control rather than in a committed script. Adjust PHP's error display in /etc/php5/apache2/php.ini, but never leave detailed errors enabled on a shared host. Test PHP with a small page that reads a database record, then remove diagnostic pages such as phpinfo() from any shared environment. Checking each layer separately—routing, PHP execution and SQL access—makes later failures much easier to isolate.

Compare native, virtual, and shared environments

A native installation gives the shortest route from a clean Ubuntu machine to a working site. Apache and PHP start quickly, file access is direct and the host can be tuned for the application. It works well when the development project is the main reason for the machine. The drawback is that the operating system gradually becomes part of the application environment, so major library or server upgrades require deliberate maintenance rather than an occasional package command.

A virtual machine places Apache, PHP and MySQL inside an isolated guest operating system. Shared folders make source code available to both environments, while snapshots or copied disk images preserve a known-good state. The approach is slower than native installation and depends on the host's memory and virtualisation support, but it is valuable on a Windows machine that must remain unchanged for commercial applications. It also gives a colleague a reproducible server image to unpack after a hardware failure.

The main choices look like this:

Environment	Setup effort	Isolation	Typical performance	Strongest use
Native Ubuntu	Low	Low	Full host speed	A dedicated development machine
Ubuntu virtual machine	Medium	High	Good, subject to host resources	Windows desktop or disposable server images
Shared hosting	Low	Medium	Shared and variable	A small public demonstration
Remote managed server	Medium	High	Dependent on network latency	Team testing and external review

A remote server complements a local stack rather than replacing it. It provides a realistic network boundary and allows a colleague to inspect the same schema, but every request carries connection latency and may rely on a provider outside Australia. For an Australian team, compare support hours, backup terms and the cost of transferring data to and from a facility in Sydney or Melbourne. The strongest arrangement is often hybrid: native Ubuntu handles daily coding, while a remote copy receives release candidates and occasional review requests.

Connect code, data, and team workflows

Keep infrastructure configuration beside the application, but separate it from runtime secrets. An infra directory can hold the Apache virtual host, PHP settings and package notes, while a sample environment file records variable names without values. Version the database schema as upgrade scripts, seed known test records and run the same migration command on every machine. Subversion, PEAR and a simple shell script can reproduce a fresh checkout with a short, reviewable sequence. This matters most when pair programming or a small agile team shares one project across several workstations.

Use the same local host name for browser requests and application clients. Mail is a common source of accidental delivery, so a development application should use a fake SMTP transport or an on-machine sink rather than sending test messages to customers. For a web service client, point requests at the local virtual host and document the headers, certificates and outbound addresses it may use. Where a component requires HTTPS, install a development certificate locally instead of weakening the application's normal security checks.

Make the setup legible to colleagues who were not present when it was built. Australian teams should specify dates as day/month/year and store timestamps in UTC, then convert them for AEST or AEDT in the interface. These conventions matter when a tester in Melbourne compares a log with a colleague in Brisbane. Plain Australian wording is welcome in internal notes, but product copy still needs an agreed style; “no worries” may suit a note to a colleague, while customer-facing text may need another register. A short runbook covering installation, credentials, database reset and known quirks removes dependence on memory.

Troubleshoot and maintain the environment

Start failures at the layer where they occur. apache2ctl configtest catches malformed Apache configuration, /etc/init.d/apache2 status and /etc/init.d/mysql status reveal failed services, and the logs under /var/log/apache2 usually identify missing files or permission errors. The MySQL error log can separate connection failures from bad SQL. netstat -ltnp shows whether the expected ports are listening, while curl -v exposes redirects and response headers that a browser may conceal. Checking the host name in /etc/hosts also prevents a surprisingly long hunt for a simple resolution fault.

Keep the system current with regular apt-get update and apt-get upgrade runs, and watch Ubuntu's security announcements for Apache, PHP and MySQL fixes. Review enabled Apache modules, PHP extensions and installed libraries as the project changes, removing packages that no longer serve a documented need. Database backups should be simple enough to perform: use mysqldump for a small development dataset and test restoring it into a disposable database. Configuration belongs in version control after review, while database exports and local secrets need a separate, access-controlled location.

Security checks belong in the same routine as functional tests. Confirm that MySQL and Apache are not exposed to the internet, use least-privilege database accounts, and replace demonstration passwords before connecting a shared environment. If Australian personal data is involved, keep production records out of local copies and document any transfer to a hosted provider. A documented, repeatable Ubuntu LAMP setup gives developers a dependable place to build, test and diagnose web projects without borrowing production credentials or depending on a remote workstation.