Thoughts about Cloud Computing and the LAMP stack

Thoughts about Cloud Computing and the LAMP stack

Summary: James Urquhart, CNET Blogger, posted Does cloud computing need LAMP? on May 23rd.

SHARE:

James Urquhart, CNET Blogger, posted Does cloud computing need LAMP? on May 23rd. In this post, he considered whether cloud computing needed the LAMP stack. He makes several good points, but in the end, he points out that he's comparing a delivery and consumption model to a collection of open source application development and deployment software. Is LAMP a requirement? Thanks for posting that interesting article.

What is LAMP?

LAMP is an acronym for a collection of open source software tools that is often seen as a platform for Web-based workloads. Typically this acronym is explained as meaning the combination of Linux, the Apache Web server, the MySQL database engine and PHP, an application development tool.

Over time, the definition was broadened to allow other database software, such as PostgreSQL. Other scripting software, such as Perl or Python, was allowed as a replacement to PHP.

What is cloud computing?

What defines cloud computing is still in play. Some suppliers are trying to use that tag for anything delivered over the Web even though it doesn't meet many of the requirements for cloud computing. We call that "Cloudwashing." In general, it is a services delivery and consumption model rather than a specific set of software tools.

The 451 Group (includes 451 Research, Tier1 Research and the Uptime Institute) continues to examine this and other cloud computing topics in CloudScape, a cloud computing research service. A document, the cloud codex, presents our view of what is and isn't cloud. Please feel free to download the Codex if you'd find it interesting.

Summary

None of the cloud computing services models, Software as a Service (SaaS), Platform as a Service (PaaS) nor Infrastructure as a Service (IaaS) require LAMP. These service could be offered using many different software stacks, LAMP is only one example of what could be used.

Topics: Hardware, Cloud, Servers, Virtualization

About

Daniel Kusnetzky, a reformed software engineer and product manager, founded Kusnetzky Group LLC in 2006. He's literally written the book on virtualization and often comments on cloud computing, mobility and systems software. In his spare time, he's also the managing partner of Lux Sonus LLC, an investment firm.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

6 comments
Log in or register to join the discussion
  • LAMP is a toolset made up of distict parts...

    and each part, like most tools, aren't necessary but can increase productivity, reduce costs and improve the final result when used properly.
    jasonp@...
  • Switch from LAMP to Plone CMS

    What is LAMP?

    <i>"LAMP is an acronym for a collection of open source software tools that is often seen as a platform for Web-based workloads. Typically this acronym is explained as meaning the combination of Linux, the Apache Web server, the MySQL database engine and PHP, an application development tool."</i>

    Hah. PHP? I am sorry legend has it that Perl was the first dynamic scripting language, not PHP.

    <i>"Over time, the definition was broadened to allow other database software, such as PostgreSQL. Other scripting software, such as Perl or Python, was allowed as a replacement to PHP.</i>"

    Yes, of course, Perl or Python were *allowed* as a replacement. This story is buggered up. Remember, Perl was there first and is alive and well.

    Quite honestly, I have about had it with PHP. It's fraught with security issues; I've always used Perl, but of late, Python has really gotten my attention.

    In terms of the LAMP stack, I have completely dispensed with Apache, MySQL, instead using Zope, Python, and Plone CMS. The stack in its totality is Plone CMS which sits on top of Zope and the framework is written in object-oriented Python.

    In terms of Cloud's attendant risks, there are security benefits to be gained by using such a stack as Plone CMS:

    ( Source: h-t-t-p:slash slash plone.org slash products slash plone slash security slash overview )

    [b]Unvalidated Input[/b]
    How Plone handles this: All input in Plone is validated, and the framework makes sure you can never input data that is not of the required type. This is probably the number one reason why Plone sites ? even when deployed and developed by people new to web security ? are not compromised.

    [b]Broken Access Control[/b]
    How Plone handles this: Plone is based on the well-proven (7 years in production), flexible and granular ACL/roles-based security model of Zope. In addition, Plone utilizes an innovative workflow-based approach to security, which means that end-users never see or modify the security settings ? they only work with security presets that have been supplied to them by the developers of the application. This greatly reduces the possibility of misconfigured security settings.

    [b]Broken Authentication and Session Management[/b]
    How Plone handles this: Plone authenticates users in its own database using a SHA-1 hash of their password. Using its modular authentication system Plone can also authenticate users against common authentication systems such as LDAP and SQL as well as any other system for which a plugin is available (Gmail, OpenID, etc.). After authentication, Plone creates a session using a SHA-1 hash of a secret stored on the server and the userid (HMAC-SHA-1). Secrets can be refreshed on a regular basis to add extra security where needed. Note: Older Plone versions (i.e. before Plone 3) use a less secure method where a session cookie containing both the loginname and password for a user are used. It is highly recommended to enforce use of HTTPS encryption for such sites.

    [b]Cross Site Scripting[/b]
    How Plone handles this: Plone has strong filtering in place to make sure that no potentially malicious code can ever be entered into the system. All content that is inserted is stripped of malicious tags like <script>, <embed> and <object>, as well as removing all <form> related tags, stopping users from impersonating any kind of HTTP POST requests. All destructive operations (like deletion of content) and privilege elevation (roles, permissions) are checked to be valid HTTP POST requests in addition to the usual security checking. On an infrastructure level, the TAL template language used to create pages in Plone quotes all HTML by default, effectively preventing cross site scripting.

    [b]Buffer Overflow[/b]
    How Plone handles this: Buffer overflow vulnerabilities are not known to exist in the current versions of Python, and is usually more common in systems based on languages that do not have strict checking for this, like C.

    [b]Injection Flaws[/b]
    How Plone handles this: Injection flaws are most common in systems that use SQL databases for content storage. Plone does not use a SQL database by default. When setting up SQL databases with Plone, they always communicate through a standard SQL connector that neutralizes injection attempts automatically.

    [b]Improper Error Handling[/b]
    How Plone handles this: Plone provides almost no error information to site visitors (no stack traces, etc.). When there is an error, Plone logs the error internally. All the front-end user will see is the log entry number of the error, allowing the error to be located in the logs if it is reported to the site admin.

    [b]Insecure Storage[/b]
    How Plone handles this: All the cryptographic methods in the Plone stack have been exposed to public scrutiny for years and have no known vulnerabilities.

    [b]Application Denial of Service[/b]
    How Plone handles this: The most common setup for a Plone site is to to deploy it behind a caching proxy like Squid, Varnish, Apache or IIS. When configured in this way, it's very hard to bring down a Plone site with DoS attacks. (Note: In versions earlier than Plone 2.1.4 and 2.5.1, there was a potential Denial of Service attack identified in the error page of Plone, which was unnecessarily heavy. This was fixed as part of a bigger security audit performed in the same timeframe, and the current releases of Plone do not suffer from this problem.

    [b]Insecure Configuration Management[/b]
    How Plone handles this: Plone has very strict security defaults out-of-the-box, and also runs as an unprivileged user on the server. Plone website users do not have access to the file system. Because of these factors, the most common security configuration vulnerabilities in this area are avoided.

    So, this isn't a Johnny-come-lately CMS. Plone has been developed over ten years and has matured (current version 3.3.5) into a flexible, rich ecosystem, designed from the ground up on Python oop, and is inherently safe.

    I recommend all Web Developers give serious consideration to Plone CMS.

    Thank you Dan.
    Dietrich T. Schmitz
    Dietrich T. Schmitz, ~ Your Linux Advocate
  • Plone

    What is LAMP?

    <i>"LAMP is an acronym for a collection of open source software tools that is often seen as a platform for Web-based workloads. Typically this acronym is explained as meaning the combination of Linux, the Apache Web server, the MySQL database engine and PHP, an application development tool."</i>

    Hah. PHP? I am sorry legend has it that Perl was the first dynamic scripting language, not PHP.

    <i>"Over time, the definition was broadened to allow other database software, such as PostgreSQL. Other scripting software, such as Perl or Python, was allowed as a replacement to PHP.</i>"

    Yes, of course, Perl or Python were *allowed* as a replacement. This story is buggered up. Remember, Perl was there first and is alive and well.

    Quite honestly, I have about had it with PHP. It's fraught with security issues; I've always used Perl, but of late, Python has really gotten my attention.

    In terms of the LAMP stack, I have completely dispensed with Apache, MySQL, instead using Zope, Python, and Plone CMS. The stack in its totality is Plone CMS which sits on top of Zope and the framework is written in object-oriented Python.

    In terms of Cloud's attendant risks, there are security benefits to be gained by using such a stack as Plone CMS:

    ( Source: h-t-t-p:slash slash plone.org slash products slash plone slash security slash overview )

    [b]Unvalidated Input[/b]
    How Plone handles this: All input in Plone is validated, and the framework makes sure you can never input data that is not of the required type. This is probably the number one reason why Plone sites ? even when deployed and developed by people new to web security ? are not compromised.

    [b]Broken Access Control[/b]
    How Plone handles this: Plone is based on the well-proven (7 years in production), flexible and granular ACL/roles-based security model of Zope. In addition, Plone utilizes an innovative workflow-based approach to security, which means that end-users never see or modify the security settings ? they only work with security presets that have been supplied to them by the developers of the application. This greatly reduces the possibility of misconfigured security settings.

    [b]Broken Authentication and Session Management[/b]
    How Plone handles this: Plone authenticates users in its own database using a SHA-1 hash of their password. Using its modular authentication system Plone can also authenticate users against common authentication systems such as LDAP and SQL as well as any other system for which a plugin is available (Gmail, OpenID, etc.). After authentication, Plone creates a session using a SHA-1 hash of a secret stored on the server and the userid (HMAC-SHA-1). Secrets can be refreshed on a regular basis to add extra security where needed. Note: Older Plone versions (i.e. before Plone 3) use a less secure method where a session cookie containing both the loginname and password for a user are used. It is highly recommended to enforce use of HTTPS encryption for such sites.

    [b]Cross Site Scripting[/b]
    How Plone handles this: Plone has strong filtering in place to make sure that no potentially malicious code can ever be entered into the system. All content that is inserted is stripped of malicious tags like <script>, <embed> and <object>, as well as removing all <form> related tags, stopping users from impersonating any kind of HTTP POST requests. All destructive operations (like deletion of content) and privilege elevation (roles, permissions) are checked to be valid HTTP POST requests in addition to the usual security checking. On an infrastructure level, the TAL template language used to create pages in Plone quotes all HTML by default, effectively preventing cross site scripting.

    [b]Buffer Overflow[/b]
    How Plone handles this: Buffer overflow vulnerabilities are not known to exist in the current versions of Python, and is usually more common in systems based on languages that do not have strict checking for this, like C.

    [b]Injection Flaws[/b]
    How Plone handles this: Injection flaws are most common in systems that use SQL databases for content storage. Plone does not use a SQL database by default. When setting up SQL databases with Plone, they always communicate through a standard SQL connector that neutralizes injection attempts automatically.

    [b]Improper Error Handling[/b]
    How Plone handles this: Plone provides almost no error information to site visitors (no stack traces, etc.). When there is an error, Plone logs the error internally. All the front-end user will see is the log entry number of the error, allowing the error to be located in the logs if it is reported to the site admin.

    [b]Insecure Storage[/b]
    How Plone handles this: All the cryptographic methods in the Plone stack have been exposed to public scrutiny for years and have no known vulnerabilities.

    [b]Application Denial of Service[/b]
    How Plone handles this: The most common setup for a Plone site is to to deploy it behind a caching proxy like Squid, Varnish, Apache or IIS. When configured in this way, it's very hard to bring down a Plone site with DoS attacks. (Note: In versions earlier than Plone 2.1.4 and 2.5.1, there was a potential Denial of Service attack identified in the error page of Plone, which was unnecessarily heavy. This was fixed as part of a bigger security audit performed in the same timeframe, and the current releases of Plone do not suffer from this problem.

    [b]Insecure Configuration Management[/b]
    How Plone handles this: Plone has very strict security defaults out-of-the-box, and also runs as an unprivileged user on the server. Plone website users do not have access to the file system. Because of these factors, the most common security configuration vulnerabilities in this area are avoided.

    So, this isn't a Johnny-come-lately CMS. Plone has been developed over ten years and has matured (current version 3.3.5) into a flexible, rich ecosystem, designed from the ground up on Python oop, and is inherently safe.

    I recommend all Web Developers give serious consideration to Plone CMS.

    Thank you Dan.
    Dietrich T. Schmitz
    Dietrich T. Schmitz, ~ Your Linux Advocate
  • -Switch from LAMP to Plone CMS

    What is LAMP?

    <i>"LAMP is an acronym for a collection of open source software tools that is often seen as a platform for Web-based workloads. Typically this acronym is explained as meaning the combination of Linux, the Apache Web server, the MySQL database engine and PHP, an application development tool."</i>

    Hah. PHP? I am sorry legend has it that Perl was the first dynamic scripting language, not PHP.

    <i>"Over time, the definition was broadened to allow other database software, such as PostgreSQL. Other scripting software, such as Perl or Python, was allowed as a replacement to PHP.</i>"

    Yes, of course, Perl or Python were *allowed* as a replacement. This story is buggered up. Remember, Perl was there first and is alive and well.

    Quite honestly, I have about had it with PHP. It's fraught with security issues; I've always used Perl, but of late, Python has really gotten my attention.

    In terms of the LAMP stack, I have completely dispensed with Apache, MySQL, instead using Zope, Python, and Plone CMS. The stack in its totality is Plone CMS which sits on top of Zope and the framework is written in object-oriented Python.

    In terms of Cloud's attendant risks, there are security benefits to be gained by using such a stack as Plone CMS:

    ( Source: h-t-t-p:slash slash plone.org slash products slash plone slash security slash overview )

    [b]Unvalidated Input[/b]
    How Plone handles this: All input in Plone is validated, and the framework makes sure you can never input data that is not of the required type. This is probably the number one reason why Plone sites ? even when deployed and developed by people new to web security ? are not compromised.

    [b]Broken Access Control[/b]
    How Plone handles this: Plone is based on the well-proven (7 years in production), flexible and granular ACL/roles-based security model of Zope. In addition, Plone utilizes an innovative workflow-based approach to security, which means that end-users never see or modify the security settings ? they only work with security presets that have been supplied to them by the developers of the application. This greatly reduces the possibility of misconfigured security settings.

    [b]Broken Authentication and Session Management[/b]
    How Plone handles this: Plone authenticates users in its own database using a SHA-1 hash of their password. Using its modular authentication system Plone can also authenticate users against common authentication systems such as LDAP and SQL as well as any other system for which a plugin is available (Gmail, OpenID, etc.). After authentication, Plone creates a session using a SHA-1 hash of a secret stored on the server and the userid (HMAC-SHA-1). Secrets can be refreshed on a regular basis to add extra security where needed. Note: Older Plone versions (i.e. before Plone 3) use a less secure method where a session cookie containing both the loginname and password for a user are used. It is highly recommended to enforce use of HTTPS encryption for such sites.

    [b]Cross Site Scripting[/b]
    How Plone handles this: Plone has strong filtering in place to make sure that no potentially malicious code can ever be entered into the system. All content that is inserted is stripped of malicious tags like <script>, <embed> and <object>, as well as removing all <form> related tags, stopping users from impersonating any kind of HTTP POST requests. All destructive operations (like deletion of content) and privilege elevation (roles, permissions) are checked to be valid HTTP POST requests in addition to the usual security checking. On an infrastructure level, the TAL template language used to create pages in Plone quotes all HTML by default, effectively preventing cross site scripting.

    [b]Buffer Overflow[/b]
    How Plone handles this: Buffer overflow vulnerabilities are not known to exist in the current versions of Python, and is usually more common in systems based on languages that do not have strict checking for this, like C.

    [b]Injection Flaws[/b]
    How Plone handles this: Injection flaws are most common in systems that use SQL databases for content storage. Plone does not use a SQL database by default. When setting up SQL databases with Plone, they always communicate through a standard SQL connector that neutralizes injection attempts automatically.

    [b]Improper Error Handling[/b]
    How Plone handles this: Plone provides almost no error information to site visitors (no stack traces, etc.). When there is an error, Plone logs the error internally. All the front-end user will see is the log entry number of the error, allowing the error to be located in the logs if it is reported to the site admin.

    [b]Insecure Storage[/b]
    How Plone handles this: All the cryptographic methods in the Plone stack have been exposed to public scrutiny for years and have no known vulnerabilities.

    [b]Application Denial of Service[/b]
    How Plone handles this: The most common setup for a Plone site is to to deploy it behind a caching proxy like Squid, Varnish, Apache or IIS. When configured in this way, it's very hard to bring down a Plone site with DoS attacks. (Note: In versions earlier than Plone 2.1.4 and 2.5.1, there was a potential Denial of Service attack identified in the error page of Plone, which was unnecessarily heavy. This was fixed as part of a bigger security audit performed in the same timeframe, and the current releases of Plone do not suffer from this problem.

    [b]Insecure Configuration Management[/b]
    How Plone handles this: Plone has very strict security defaults out-of-the-box, and also runs as an unprivileged user on the server. Plone website users do not have access to the file system. Because of these factors, the most common security configuration vulnerabilities in this area are avoided.

    So, this isn't a Johnny-come-lately CMS. Plone has been developed over ten years and has matured (current version 3.3.5) into a flexible, rich ecosystem, designed from the ground up on Python oop, and is inherently safe.

    I recommend all Web Developers give serious consideration to Plone CMS.

    Thank you Dan.
    Dietrich T. Schmitz
    Dietrich T. Schmitz, ~ Your Linux Advocate
  • buy xanax online

    The idea behind this article is excellent, and for me the first item ("Create your own damn content!") is the real gem here: most of the people spend their entire lives only consuming what is created by others, and creating nothing themselves--or never sharing what they create, which is better than not creating at all, though not the best they could do.
    <a href="http://www.mycarepharmacy.com/buy_online/alprazolam/xanax">buy xanax online</a>
    davidlee123
  • buy adderall online

    This is like my fourth time stopping over your Blog. Normally, I do not make comments on website, but I have to mention that this post really pushed me to do so. Really great post .
    [url=http://www.mycarepharmacy.com/buy_online/amphetamine_dextroamphetamine/adderall] buy adderall online[/url]
    markhanry