Dazzle CMS » Apache

Benefits of Running IIS7.5 Over IIS6 Or Apache

Dazzle CMS — Fri, 18 Dec 2009 05:42:54 +0000

IIS7.5 – The latest and greatest from Microsoft.

IIS7.5 is the latest iteration of the Microsoft’s web server. Formerly know as the Internet Information Server, IIS has come to dominate most of the servers belonging to Fortune 100 companies though Apache remains the market leader overall. According to the latest statistics over a third of all sites are backed by IIS.

Benefits of IIS7.5 over IIS6

IIS7.5 is one of the more significant updates to the IIS platform. The biggest change is the modular nature of the engine. This means that one can configure IIS7.5 to support only features that are needed, adding more as and when necessary. In addition to improving it’s flexibility, this leads to a significant leap in security. For example, you can add modules from scripting and even backward compatibility.

Another significant improvement, is the use of an XML based web.config file (just like in .NET applications) to handle the configuration of the entire server configuration. This leads to improvements in portability, fine tuning as well as ease of access compared with the previous hierarchical metabase storage up until IIS6.

There is also good news for VPN users. IIS7.5 has improved it’s remote management capability by providing secure HTTP connections though you have to enable remote management manually. But that can be good as some viewed the earlier setup as more vulnerable.

Though there are many more improvements, let us look at some reasons why you should an IIS7.5 engine over a more traditional server like Apache.

Benefits of IIS7.5 over Apache

For most people the ability to use PHP scripts on IIS used to deter them from using a Windows platform. Even a hosting provider like Godaddy disallows the use of a PHP based application like WordPress on a Windows server. However, the latest releases of IIS and especially IIS 7.5 give massive performance improvements while running PHP scripts to the extent that PHP is no longer the sole reason not to choose IIS.

Today more and more site owners are turning to Windows to host their PHP based applications, and WordPress on windows is picking up a huge following. Thanks to improvements around PHP and IIS through the cooperative efforts of Zend and Microsoft, PHP performance is much more stable, reliable and faster than it was on earlier versions.

Of course, if you plan to make use of the awesome .NET platform, then IIS 7.5 is your only choice. With the latest release of ASP.NET 3.5 and full support for the MVC framework there has never been a more compelling time to develop applications in .NET. In addition, Microsoft’s Web PI has made it easier than ever to install all .NET related components. IIS 7.5 has also significantly improved it’s usability interface eschewing the full MMC framework it had earlier.

IIS7.5 also features improved diagnostics capability with advanced error tracking that allows you to trace errors based on the conditions you want IIS to look out for. This could be tracking down timed out pages or other errors through it’s “failed request tracing” capability.

Summary

All in all, this is the time to switch over to a Windows platform if you’ve been sitting on the fence till now. The new security features coupled with the flexibility, ease of use and diagnostics have made IIS 7.5 quite an irresistible choice for those looking to host their web applications.

FTP Servers Being Replaced With Online Services

Dazzle CMS — Fri, 18 Dec 2009 05:08:13 +0000

FTP Servers are still the most popular way to store and transfer large files. As browsers get better suited to dealing with file uploads and downloads, new web services are emerging to replace FTP. Online file transfer and sharing services provide an affordable, easy-to-use alternative to traditional FTP servers.

Why should you consider replacing your FTP server?

1. Easy to Use: Online file transfer sites are easier to use than FTP, can be accessed through a web browser, require no additional downloads and can be accessed from anywhere.

2. More Secure: With most web-based transfer services, passwords are always sent over an encrypted connection.

3. Branded Experience: You can customize the look and style of your file transfer service and upload your company logo for a branded experience.

4. Activity Notifications: Receive notifications when users upload or download files, leave comments, or make any changes to files.

5. View Files Online: With file previews, you can view images and common office documents online without the need to download.

6. Search: Quickly find documents by searching through the title and content of Word documents, PowerPoint files, Spreadsheets, PDF documents and more.

7. Integrate with Your Website: Web-based services can be easily linked to from your existing website to provide a seamless experience to your clients and partners.

8. Manage Users: Controlling access to files is simple and does not require calling the IT department any time you need to add users, remove users, or reset your password.

9. Comments: Post comments on files to leave messages and communicate with other members of the Hub.

10. Version Control: Version history lets you view the history of previous versions, compare them to one another and restore an older document.

svn + apache2

Dazzle CMS — Sun, 25 Oct 2009 00:20:50 +0000

Many of my developers work from windows including myself. Creating secure access over ssh and svn (svn+ssh://)
using Zend studio and svn (subversion plugin for zend) was the initial idea, from a quick pass over subversion, but once svnserver was up and running and I tried it, this wasn’t as simple. There are several articles on integrating subversion, ssh and windows. None of the solutions looked simple or elegant. And wide open unsecured traffic was not acceptable.

I determined best practice pointed us to subversion access through web_dav_svn -> web_dav -> apache2 (https://). This brought authentication away from centralized auth and allowed fine grained control over the access granted via htpasswd and .htaccess files. It allowed us to restrict unsecured access and redirect http to https, and encrypt using SSL. It kept us from having to work ssh onto windows for each developer, instead we could have a simple eclipse/subclipse plugin access demonstrated and from that point they were able to customize on their own.

What I wanted was:

* untar subversion-1.6.6 and subversion-deps-1.6.6 in /apps/src (they layer over each other)
* first build and install the -deps apr and apr-util into /apps/local
* then build apache2 against /usr/local/apr and /usr/local/apr-util
* install apache2
* build and install serf
* remove serf, apr, and apr-util subdirectories and source code from within subversion-1.6.6
* build 1.6.6 against apxs in apache, without Berkeley DB, without neon, and specifying /usr/local/apr, /usr/local/apr-util, and /usr/local/serf
* install and test

process

* create subdirectory /apps/src, place all tarballs in this directory
* untar subversion & subversion-deps version 1.6.6 (these tar onto each other)
* cd subversion-1.6.6/apr
* ./configure –prefix=/usr/local/subversion/apr
* make && make install
* cd ../apr-util
* ./configure –prefix=/usr/local/subversion/apr-util –with-apr=/usr/local/subversion/apr
* make && make install
* cd ../neon
* ./configure –prefix=/usr/local/subversion/neon
*
* apache2: untar httpd-2.2.14
* ./configure –prefix=/usr/local/subversion/apache –enable-dav –enable-dav-fs –enable-dav-lock –enable-expires –enable-headers –enable-info –enable-logio –enable-proxy –enable-rewrite –enable-unique-id –with-apr=/usr/local/subversion/apr –with-apr-util=/usr/local/subversion/apr-util –enable-so –enable-mods-shared=all
* make && make install

This way apache2 builds against apr and apr-util compatible with subversion 1.6.6
and then build subversion against it as well..
* ln -s /apps/apache2_2.2.14 /apps/apache2
* compile and install serf
* ./configure –-prefix=/usr/local/subversion/serf –with-apr=/usr/local/subversion/apr –with-apr-util=/usr/local/subversion/apr-util
* make && make install
* remove serf, pr and apr-util from subversion

compile subversion

./configure –prefix=/apps/svn –with-ssl –with-libs=/usr/local/ssl –without-berkeley-db –with-apxs=/apps/apache2/bin/apxs –with-openssl=/usr/local/ssl –without-neon –with-serf=/usr/local/serf –with-apr=/usr/local/apr –with-apr-util=/usr/local/apr-util

make && make install

test:

/usr/local/subversion/svn/bin/svnadmin create /usr/local/subversion/repository

chown subversion:subversion /usr/local/subversion

chown -Rv subversion.subversion /usr/local/subversion

root@dedicated[/bin] $

no core dump…

ONWARD to configure and test apache2 and subversion…
httpd.conf:

* change all references to apache2_2.2.14 to apache2 (makes the httpd.conf generic rather than subject to needing a migration after a point release upgrade…)
* change port 80 to a non-priveliged port (8080)
* check for
o LoadModule dav_module modules/mod_dav.so
o LoadModule dav_module modules/mod_dav.so
o LoadModule ssl_module modules/mod_ssl.so
* add in ServerName hostname.domain.com:8443 Some of the apache level sanity validation requires a statement of the local host.
* add in SSL stuff (this IS httpd from source – the default httpd.conf had the ssl-module load statement, but no explicit SSL configuration

#
# Note: The following must must be present to support
# starting without SSL on platforms with no /dev/random equivalent
# but a statically compiled-in mod_ssl.
#

SSLRandomSeed startup builtin
SSLRandomSeed connect builtin

# =================================================
# SSL/TLS settings
# =================================================

Listen 0.0.0.0:8080
Listen 0.0.0.0:8443

SSLEngine on
#SSLOptions +StrictRequire

#
# SSLRequireSSL
#

SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

SSLMutex file:/apps/apache2/logs/ssl_mutex

SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect file:/dev/urandom 1024

SSLSessionCache shm:/apps/apache2/logs/ssl_cache_shm
SSLSessionCacheTimeout 600

SSLPassPhraseDialog builtin
SSLCertificateFile /apps/apache2/conf/ssl.crt/server.crt
SSLCertificateKeyFile /apps/apache2/conf/ssl.key/server.key

SSLVerifyClient none
SSLProxyEngine off

AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl

* create ssl certificate (self-signed). I installed in /apps/apache2/conf/ssl.crt and ssl.key, naming the .crt and ,key files for the server hostname and then symbolically linking them to the generic “server.crt” and “server.key”.
* restart apache2 and test https://host:8443/ – you should get the “It works!” apache test page, thus validating the SSL certificate and setup from a browser level
*
* parent directory for svn

DAV svn
SVNParentPath /apps/repos