Category: "LAMP"

RIA server filesystem architecture

The /opt directory can be used to store shared components, as follows:

  • /opt/os - All open source components

  • /opt/common - All common scripts, such as form validation for contact us forms, anti-spam code.

    • /antispam

      • /html - (html and javascript) - to assist the user
      • /php - to protect the server
    • /footer - Footer text, specifically the company name and copyright indicator. This ensures it can be changed in one place to update every page on the server.

New accounts could access these components like so:


ln -s /opt/os/dojo 
ln -s /opt/os/Smarty 
ln -s /opt/os/Zend
ln -s /opt/common/html 
ln -s /opt/common/php
ln -s /opt/common/footer

These links allow relative references to the common resources, while providing central sourcing.

GUI vs. Command Line

There are many powerful GUIs to assist web professionals, and, they are excellent. They often allow people to perform tasks that they would not otherwise be able to. This is valuable for inexperienced users, however, it is not an excuse to be casual with skills.

When you must get something done, and the GUI is the fastest way to achieve the goal, the GUI is vital. However, when you have a little bit of time, it is definitely worth understanding what the GUI is doing, and learning how to do it on the command line.

Most GUIs provide displays to show the underlying actions. phpMyAdmin provides a GUI to create the queries, but also displays the MySQL. It can be a great learning tool.

Command line control is usually faster than a GUI. The GUI protects you from errors, by guiding you through the operations step by step. On the command line, you can enter exactly what you want. If there is an error, you’ll usually get a message. Potential catastrophic operations are usually preceded with some sort of warning or confirmation.

Finally, there are times when the GUI won’t work, or you won’t have one. If you can use the command line, you will still be able to do all the work.

RPM Compliant Web Applications

RPM compliant web applications and toolkits must meet the following requirements:

  • Dissociation of customization and extensions from the application. This includes all configuration parameters, such as database access settings, design elements, and plug-ins from the core application files. Thus, a web application can be installed as an RPM, accessed through a symbolic link, and customized for an account with the appropriate directories at the account level. In this way, multiple accounts can use the same core code, while remaining independent. This requirement can be waived if the application will be used with dedicated servers.
  • Packaging with careful attention to Provides and Requires to ensure interdependencies are observed.
  • Conflict resolution must be established to ensure incompatible components are not installed.

Popular web applications should consider an RPM compliant file system architecture for the following reasons:

  • Disk space Most powerful applications require a significant amount of disk space. RPMs allow a single installation to serve an entire server.
  • Security and maintenance RPMs can be managed with automatic updates, ensuring security and update patches are applied promptly, automatically.
  • Local security Managed properly, using a common source to serve an application can allow a server administrator to provide the application, but prevent account holders from modifying it. This would be extremely valuable for hosting companies.
  • Ease of installation/distribution By making RPMs available, distributing them with operating systems, and publishing them in repositories, they are easier to install and use.
  • Standardization RPMs can ensure that web applications are always installed in the same place. This can be very helpful for technical support.
  • Bandwidth RPMs may reduce the bandwidth required for distributing applications, by making them available from more sources.

Risks and disadvantages of this approach include:

  • Loss of flexibility, all accounts will use the same core code. Extensions will have to be used to customize the applications.
  • Skill level of the server administrator and application engineers must be adequate to ensure graceful use of the application within a shared architecture.
  • Security, if the core code is compromised, all accounts on the server will be affected.
  • Many web applications would require significant changes to use an RPM compliant filesystem architecture.

At this time, the best candidates for distribution as RPMs are javascript libraries. These libraries offer very powerful features for web sites and applications, and are very rarely changed. They are usually executed on the client side, and the CSS can be overridden easily, eliminating concerns about customization. A single symlink from the account makes them accessible for a site.

unexpand for speed

Editing files often introduces extraneous spaces. The unexpand command will convert the spaces into tabs. This can result in a tremendous reduction in file size, code that is easier to read, and pages which are faster.

unexpand INFILE.php > OUTFILE.php

Key Site Architecture Considerations

Virtually every site or web application should consider the following:

  • Multilingual capable - even if the content is not immediately available in other languages. Retrofitting translation into a site is extremely costly.
  • Common components - any code that will execute in more than one place should be shared through includes or other mechanisms.
  • Hierarchical templates - this provides a more consistent interface and more efficient code. Templates must be general enough to support this.
  • Appropriate user assistance - help, at both the field and page level
  • List of browsers supported - you can’t support every browser. Identify those you will.
  • Graceful error handling - don’t just issue a print or echo and die
  • Security - close the windows and doors into your application. Ensure error handling prevents disclosure of code and database elements
  • Configuration - database access constants should be sourced from a single point, as should all other configuration directives. This ensures all elements of the application, including backend/offline scripts. Otherwise, the constants can’t be changed without risking the integrity of the system.
  • Server configuration - prevent access to areas the site visitor should not see at the server level.
  • Multi-mode deployment - only put the code required on the server. Set up the distribution/installation process accordingly.
  • Use mod_security.
  • Let the web server be the only reader of script files. This makes it more difficult for hackers to get to the web code.
  • Use robots.txt and meta tags to keep things out of search engines unless necessary.
  • Change off port 22 for SSH, or close it entirely from public access
  • Enforce these practices across the entire team, and audit for them during development