Category: App / Web Servers

Apache web server Installation Guide, know how to Install Apache web server on Windows 7?

by scmgalaxy KApp / Web ServersLeave a Comment on Apache web server Installation Guide, know how to Install Apache web server on Windows 7?

apache-web-server-on-windows-7-installation-guide

After a quick detour to install Notepad++, I’m on my way to installing Magento. Before I can get into the meat of it, though, I do require a few prerequisites.

From the installation instructions, installing Magento requires:

  • Apache 1.3.x or Apache 2
  • PHP 5.2.0 and above with Safe mode off
  • MySQL 4.1.20 and above

After a brief search, I happened upon a very handy site (Yes, my current dev machine runs Windows 7). No sense reinventing the wheel, so these instructions should do nicely.

I’ve chosen the latest stable release, 2.2.17, MD5-verified and ready to install.

Always one to put the right foot forward… The first thing I’ve done is to immediately download the wrong version (src) instead of the neatly prepped installer (msi) as per the instructions. Round 1 goes to my eagerness, but after a neat revisit to the Apache download page, I’m off in the right direction.

After kicking off the Apache installer, my first instinct was to twitch at the frozen installer progress (Did the instructions forget about that ghastly Windows 7 User Account Control?), but after only a brief pause, the UAC prompt has displayed and the Apache web server installation is back on track.

None the worse for wear, time for the next step.

PHP

I’ve pretty much kaboshed most of the PHP installation instructions, mostly due to its avoidance of the handy PHP for Windows installer. Pointing the installer to the Apache web server’s cgi-bin folder seems like a good idea.

A configuration change…

; Directory in which the loadable extensions (modules) reside.
; http://php.net/extension-dir
; extension_dir = “./”
; On windows:
extension_dir = “ext” ; Uncommented (removed the semicolon at the beginning of) this line

… and I’m back to the instructions. After an update to my environment variables, looks like it’s time for a reboot… and sleep.

I’ll be leaving the MySQL install (and testing Apache web server and PHP) ’til tomorrow.

Tagged : / / / / / / / / / / / / / / / / /

Apache Tomcat – Tomcat 7 Finalized – Tomcat 7 Introduction

by scmgalaxy KApp / Web ServersLeave a Comment on Apache Tomcat – Tomcat 7 Finalized – Tomcat 7 Introduction

tomcat-7

The volunteer developers behind Apache Tomcat have released version 7.0.6 of the open-source Java servlet container.

“This is the first stable release of the Tomcat 7 branch,” developer Mark Thomas wrote in an e-mail announcing the release on various Tomcat developer mailing lists.

While not a full application server, Tomcat implements the functionality described in the Java Enterprise Edition Web profile specifications. Most notably, it supports version 3.0 of the Servlet API (application programming interface) and version 2.2 of JavaServer Pages, both part of the recently ratified JEE 6. A servlet container manages Java-based applications that can be accessed from a Web browser.

The use of Servlet 3.0 will bring a lot of new capabilities to Tomcat, noted Tomcat contributor Tim Funk, in a presentation at the ApacheCon conference in Atlanta in November.

One big area of improvement is in configuration management for Web applications. Previous versions required all Web app configuration changes to be entered in a central file called web.xml, a process that led to unwieldy web.xml files as well as security risks.

The new approach, called annotations, breaks configuration instructions into multiple files. Separate files are kept for security, for configuring new connections, for initial parameters and for handling third-party libraries.

Other benefits of Servlet 3.0 include advanced cookie management and asynchronous thread support, which should increase the number of connections Tomcat can handle.

In preparation for the release, various beta versions of Tomcat 7 have been distributed since April 2010. Version 7.0.6 fixes some longtime memory leak issues and includes a number of other bug fixes as well.

In addition to making the source code and various binaries available, the development team has packaged a version of the software that can be embedded in other applications.

Tomcat is one of almost 150 open-source projects maintained by the Apache Software Foundation.

Tagged : / / / / / / / / / / / / / / / / /

Why and how to use Jetty in mission-critical production

by scmgalaxy KApp / Web ServersLeave a Comment on Why and how to use Jetty in mission-critical production

how-to-use-jetty

This article is a summary of a seminar I had on the topic. If it seems like it’s a continuation of an existing discussion that’s because, to some extent, it is. If you haven’t been discussing exchanging your app server, this article probably isn’t very interesting to you.

By putting the application server inside my application instead of the other way around, I was able to leap tall buildings in a single bound.

The embedded application server

This is how I deploy my sample application to a new test environment (or to production):

  1. mvn install
  2. scp -server/target/-1.0.onejar.jar appuser@appserver:/home/appuser/test-env1/
  3. ssh appuser@appserver “cd /home/appuser/test-env1/ && java -jar -1.0.onejar.jar&”

This require no prior installed software on the appserver (with the exception of the JVM). It requires no prior configuration. Rolling back is a matter of replacing one jar-file with another. Clustering is a matter of deploying the same application several times.

In order to make this work in a real environment, there are a many details you as a developer need to take care of. As a matter of fact, you will have to take responsibility for your operational environment. The good news is that creating a good operational environment is not more time-consuming than trying to cope with the feed and care of a big-a Application Server.

In this scheme every application comes with its own application server in the form of jetty’s jar-files embedded in the deployed jar-file.

The advantages

Why would you want to do something like this?

  • Independent application: If you’ve ever been told that you can’t use Java 1.5 because that would require an upgrade of the application server. And if we upgrade the application server, that could affect someone else adversely. So we need to start a huge undertaking to find out who could possibly be affected.
  • Developer managed libraries: Similar problems can occur with libraries. Especially those that come with the application server. For example: Oracle OC4J helpfully places a preview version of JPA 1.0 first in your classpath. If you want to use Hibernate with JPA 1.0-FINAL, it will mostly work. Until you try to use a annotation that was changed after the preview version (@Discriminator, for example). The general rule is: If an API comes with your app server, you’re better served by staying away from it. A rather bizarre state of affairs.
  • Deployment, configuration and upgrades: Each version of the application, including all its dependencies is packaged into a single jar-file that can be deployed on several application server, or several times on the same application server (with different ports). The configuration is read from a properties-file in the current working directory. On the minus side, there’s no fancy web UI where you can step through a wizard to deploy the application or change the configuration. On the plus side, there is no fancy web UI …. If you’ve used one such web UI, you know what I mean.
  • Continuous deployment: As your maven-repository will contain stand alone applications, creating a continuous deployment scheme is very easy. In my previous environment, a cron job running wget periodically was all that was needed to connect the dots. Having each server environment PULL the latest version gives a bit more flexibility if you want many test environments. (However, if you’re doing automated PUSH deployment, it’s probably just as practical for you).
  • Same code in test and production: The fact that you can start Jetty inside a plain old JUnit test means that it is ideal for taking your automated tests one step further. However, if you test with Jetty and deploy on a different Application Server, the difference will occasionally trip you. It’s not a big deal. You have to test in the server environment anyway. But why not eliminate the extra source of pain if you can?
  • Licenses: Sure, you can afford to pay a few million $ for an application server. You probably don’t have any better use for that money, anyway, right? However, if you have to pay licenses for each test-server in addition, it will probably mean that you will test less. We don’t want that.
  • Operations: In my experience, operations people don’t like to mess around with the internals of an Application Server. An executable jar file plus a script that can be run with [start|status|stop] may be a much better match.

The missing bits

Taking control of the application server takes away a lot of complex technology. This simplifies and makes a lot of stuff cheaper. It also puts you back in control of the environment. However, it forces you to think about some things that might’ve been solved for you before:

  • Monitoring: The first step of monitoring is simple: Just make sure you write to a log file that is being monitored by your operations department. The second step requires some work: Create a servlet (or a Jetty Handler) that a monitoring tool can ping to check that everything is okay. Taking control of this means that you can improve it: Check if your data sources can connect, if your file share is visible, if that service answers. Maybe add application-calibrated load reporting. Beyond that, Jetty has good JMX support, but I’ve never needed it myself.
  • Load balancing: My setup supports no load balancing or failover out of the box. However, this is normally something that the web server or routers in front of the application server anyway. You might want to look into Jetty’s options for session affinity, if you need that.
  • Security: Jetty supports JAAS, of course. Also: In all the environments I’ve been working with (CA SiteMinder, Sun OpenSSO, Oracle SSO), the SSO server sends the user name of the currently logged in user as an HTTP header. You can get far by just using that.
  • Consistency: If you deploy more than one application as an embedded application server, the file structure used by an application (if any) should be standardized. As should the commands to start and stop the application. And the location of logs. Beyond that, reuse what you like, recreate what you don’t.

Taking control of your destiny

Using an embedded application server means using the application server as a library instead of a framework. It means taking control of your “main” method. There’s a surprisingly small number of things you need to work out yourself. In exchange, you get the control to do many things that are impossible with a big-A Application Server.

Reference: http://www.javaworld.com/community/

Tagged : / / / / / / / / / / / / / / /

Process to Install CollabNet SVN Command Line Client in Windows

by scmgalaxy KApp / Web ServersLeave a Comment on Process to Install CollabNet SVN Command Line Client in Windows

install-collabnet-svn-command-line-client-in-windows

Link: http://www.collab.net/downloads/subversion/

1. Platform and configuration

   Product: CollabNet Subversion server

   Certified platforms: Windows XP SP2, Win 2003(Standard Edition) R2

   Apache version: 2.2.8

   ViewVC: 1.0.5 (requires ActiveState Python 2.5)

   Repository format: fsfs (bdb support not included)

   Prerequisite: The user needs administrative privileges to install

   and uninstall CollabNet Subversion.

2. IMPORTANT: Apache version upgraded from 2.0 to 2.2

   With the CollabNet Subversion 1.5.0 release, we have upgraded the included

   Apache server version from 2.0 to 2.2. This is consistent with the

   packages we provide for other operating systems, and also upgrades our

   package to the best available version of Apache.

   This is important to existing users because your current Apache 2.0 server

   configuration cannot be automatically updated to the format of the Apache

   2.2 configuration file. If you allow the installer to upgrade your existing

   installation, it backs up your Apache conf, logs, and htdocs folders so

   that you can refer to your previous configuration when configuring your new

   server.

3. Installation tips

     If you install an Apache server, the installer asks you for a

     “Repository URL.” This represents the prefix of the URL which users can

     use to connect to Subversion. If you set this URL to ‘/svn’, then users

     can checkout their repository from:

        http://hostname/svn/repos-name

     We recommend that you use ‘/svn’ as your URL prefix, as this is common

     practice.

4. ViewVC installation

   Users of the Apache web server option can now also have ViewVC automatically

   installed and configured as part of the installation. You must have

   ActiveState’s ActivePython 2.5 installed before installing CollabNet Subversion.

   Download a free version of ActivePython from:

   http://www.activestate.com/Products/activepython/index.mhtml

   You must install version 2.5.x.

5. Upgrade procedure

   When the installer detects a previous version, it offers to upgrade your existing

   installation. However, if you want to add ViewVC to your installation, we

   recommend you use the following process for an upgrade. In general, this is

   the best process for any upgrade scenario:

   1. Stop Apache or Subversion Server services, if running.

   2. Copy/back up any customizations that were done to your Apache installation.

     (For example, your httpd.conf file, a password database, any content you

      added to the htdocs folder, and so on.)

   3. Uninstall the currently installed version.

   4. Manually delete the existing folder if the installer did not remove it. The

      uninstall process does not remove files that were added or modified after

      installation.

   5. Follow the normal install instructions for 1.5.

   6. Manually put back your Apache customizations. NOTE:  You cannot simply copy

      back the previous configuration file. You must make the appropriate edits

      to your new Apache 2.2 version of the configuration file.

6. Post-installation instructions

   The installer created a folder to store your repositories. You are not required

   to use this folder, but if you let the installer install the server to run as a

   service, then the server has also been configured to serve repositories from this

   location. It is a good idea to use the location you specified in the installer.

   A. Using svnserve

      ==============

   To use svnserve as your server, follow these steps:

     1. Open a new terminal (command prompt).

        NOTE: If you have an old command prompt open (prior to the Subversion

              installation), remember to open a brand new command prompt.

     2. Create a subversion repository.

        cd <Repository_Path>

        svnadmin create <Repository_Name>

        For example:

        cd \repositories

        svnadmin create my-first-repos

     3. Setup a password database.

        Using notepad, edit the svnserve.conf file inside the conf directory of your

        repository.

        For example:

        If your repository is C:\repositories\my-first-repos

        svnserve.conf is:

        C:\repositories\my-first-repos\conf\svnserve.conf

        Inside svnserve.conf, you see the following information:

         ### The password-db option controls the location of the password

         ### database file.  Unless you specify a path starting with a /,

         ### the file’s location is relative to the conf directory.

         ### Uncomment the line below to use the default password file.

         #password-db = passwd

       Follow the above instructions, and uncomment the “password-db=passwd”

       line, so that it simply says:

          password-db = passwd

     4. Setup usernames and passwords.

       Next, edit the passwd file. This passwd file is located in the

       same directory as svnserve.conf.

       Inside the passwd file, you see the following information:

       ### This file is an example password file for svnserve.

       ### Its format is similar to that of svnserve.conf. As shown in the

       ### example below it contains one section labelled [users].

       ### The name and password for each user follow, one account per line.

       [users]

       #harry = harryssecret

       #sally = sallyssecret

       To add a new user account, add your own username and password

       inside the [users] section. For example, if your name is “joe”,

       and you want to set your password to “super-secret”, add a

       new line like this:

         joe = super-secret

       Add as many users as you like.

     5. Open Port on Windows firewall.

        Before starting the server, the firewall must be notified that

        this particular port is going to be used. To enable this port in the

        Windows firewall, follow the instructions found here:

    http://www.microsoft.com/windowsxp/using/security/internet/sp2_wfexceptions.mspx

        Note: svnserve.exe is the program name which needs to be added to the

        exceptions list. Alternatively, you can also use the port where

        you decide to run the server. By default, svnserve runs on 3690.

     6. Start svnserve.

        If you elected to have the installer setup svnserve as a service, then open

        the Services application, find the entry for the Subversion server, and take

        the Start option. The service has been configured to start automatically

        on reboot. You can also run this command from the command line:

        net start svnserve

        If you did not install svnserve as a service and want to start the server

        manually, run this command:

        svnserve -d -r <Repository_Path>

        For example: svnserve -d -r C:\repositories

     7. To provide read and write access to anonymous users, modify the

        conf/svnserve.conf file inside the repository.

        anon-access = write

        To restrict an anonymous user from the repository:

        anon-access = none

     8. Check out the repository.

        svn co svn://localhost/<Repository_Name>

        For example: svn co svn://localhost/my-first-repos

     Tip: If you check out your Subversion repository from a different computer,

     replace ‘localhost’ with the IP address or hostname of the machine which

     hosts the Subversion repository.

   B. Using Apache

      ============

   To use Apache as your server, follow these steps:

     1. Configure Apache.

        The installer did these steps automatically based on the repository location

        entered in the installer. This information is only presented if you want to

        manually modify the configuration.

        Use notepad to edit the httpd.conf file inside the httpd\conf directory of your

        CollabNet Subversion Server installation.

        Tip: By default, httpd.conf is in the following directory:

             C:\Program Files\CollabNet Subversion Server\httpd\conf\httpd.conf

        At the bottom of the httpd.conf file, you see a location directive that looks

        something like this:

          <Location /svn>

            DAV svn

            SVNParentPath C:\repositories

          </Location>

        Change the above section to look like the following:

          <Location /svn>

            DAV svn

            SVNParentPath C:\repositories

            SVNListParentPath On

            Require valid-user

            AuthType Basic

            AuthName “Subversion repository”

            AuthUserFile C:\repositories\password-file

          </Location>

     2. Open a new terminal (command prompt).

        NOTE: If you have an old command prompt open (prior to the Subversion

              installation), remember to open a new command prompt.

     3. Create Subversion users.

        Now create usernames with passwords that can be used to authenticate with

        Apache. Use the htpasswd command to create usernames and passwords for the

        Apache server.

        Type the following at the command prompt:

          htpasswd -cm <password-file> <username>

        This command prompts you for a password for the user. Enter the

        password and retype the password when prompted.

        For example: If you want to create a user ‘joe’, and the file at

        “C:\repositories\password-file”, type the following at the

         command prompt:

               htpasswd -cm C:\repositories\password-file joe

        Enter the desired password for the user and retype the password

        when prompted.

        For additional users, use the following command at the command prompt:

        htpasswd -m C:\repositories\password-file joe

     4. Create a Subversion repository.

        svnadmin create <Repository_Path>\<Repository_Name>

        For example: svnadmin create C:\repositories\my-first-repos

     5. Open Port on Windows firewall.

        Before starting the server, the firewall must be notified that

        this particular port is going to be used. To enable this port in the

        Windows firewall, follow the instructions found here:

    http://www.microsoft.com/windowsxp/using/security/internet/sp2_wfexceptions.mspx

        Note: apache.exe is the program name which you need add to the

        exceptions list. Alternatively, you can also use the port where

        you decide to run the server. By default, apache is run on 80.

     6. Start Apache.

        If you elected to have the installer set up Apache as a service, then open

        the Services application, find the entry for Apache/2, and take

        the Start option. The service was configured to start automatically

        on reboot. You can also run this command from the command line:

        net start apache2

        To start the server manually, run the following at the command prompt:

        apache

     7. Checkout the repository.

        svn co http://localhost/svn/<Repository_Name>

        For example: svn co http://localhost/svn/my-first-repos

        Tip: If you check out your Subversion repository from a different

        computer, replace ‘localhost’ with the IP address or hostname

        of the machine which hosts the Subversion repository.

7. Known issues

   When trying to access a repository via ViewVC, you might see an error

   trace that ends with this message:

      ImportError: DLL load failed with error code 182

   This error occurs when you have an older version of the OpenSSL DLLs in your

   PATH ahead of the CollabNet Subversion bin folder. Many Windows applications

   ship the OpenSSL DLLs and many of them also use older versions. To fix this

   problem:

      1. Edit your PATH so that the CollabNet Subversion bin folder is at or

         near the beginning of your PATH.

      2. Reboot so that your Apache service can pick up the change.

8. Back-end support

  If you try to access an existing BDB (Berkeley DB) based repository through

  CollabNet Subversion, then you might receive an alert “Failed to load module

  for FS type ‘bdb’.” This is because CollabNet Subversion does not support BDB.

  CollabNet recommends FSFS over BDB for ease of maintenance and supportability.

9. Support for CollabNet Subversion

   Find out about CollabNet Technical Support at

   http://www.collab.net/services/subversion/

   Information about CollabNet Training, Consulting, and Migration

   services is at http://www.collab.net/services/subversion/training.html

   Join openCollabNet for community support: http://open.collab.net

10 About Subversion and CollabNet

   CollabNet launched the Subversion project in 2000 in response to the demand

   for an open standard for Web-based software configuration management that

   could support distributed development. CollabNet continues to be strongly

   involved with the Subversion project and offers CollabNet Subversion Support,

   Training, and Consulting services.

   CollabNet also provides the most widely used collaborative development

   environment in the world. More than 1,400,000 developers and IT projects

   managers collaborate online through CollabNet. The company is transforming

   the way software is developed by enabling organizations to leverage global

   development talents to deliver better products and innovate faster.

   Visit CollabNet at http://www.collab.net for more information.

Tagged : / / / / / / / / / / / / / / / / / / /

How to Install CollabNet SVN Command Line Client in Solaris?

by scmgalaxy KApp / Web ServersLeave a Comment on How to Install CollabNet SVN Command Line Client in Solaris?

collabnet-svn-command-line

Link: http://www.collab.net/downloads/subversion/solaris.html

1. Platform and configuration

Product: CollabNet Subversion client

Platforms: Solaris 10 SPARC

Prerequisite: You must be a superuser (root) to install and uninstall

CollabNet Subversion.

2. Import/Update CollabNet certificate

CollabNet Subversion Solaris packages are signed. As a one-time task,

import the CollabNet certificate using the command:

    sudo pkgadm addcert -ty certificate.pem

The CollabNet certificate is available for download at:

http://www.collab.net/nonav/downloads/subversion/certificate/certificate.pem

NOTE: the certificate has changed between 1.5.0 and 1.5.1 release.  The

certificate used for 1.5.0 had a short expiration date so we have created

a new certificate.  If you have previously installed the 1.5.0 certificate,

you must remove it before installing the new one:

    sudo pkgadm removecert “Alexander Thomas(AT)”

Once it is removed you can install the new certificate.

3. First installation

The command to install the CollabNet Subversion client, if a previous version

has not already been installed, is:

    sudo pkgadd -d /path/to/client-sparc-local

4. Updating an existing installation

The proper way to update a Solaris package is to remove the current version

and then install the new version.  If you have the CollabNet Subversion server

installed, you will need to remove it first.  Again, refer to the readme for

that package before proceeding.

    sudo pkgrm CSVNclnt

    sudo pkgadd -d /path/to/client-sparc-local

5. Post-installation instructions

A. CollabNet Subversion installs into /opt/CollabNet_Subversion, which is

   probably not on the executable search path for your system. Add the directory

   /opt/CollabNet_Subversion/bin to your $PATH environment variable. In order to

   make this change affect all users of your system and persists across reboots,

   add the following line to /etc/profile:

    PATH=/opt/CollabNet_Subversion/bin:$PATH

B. CollabNet Subversion provides man pages and localizations for several

   languages. To take advantage of these features, update your MANPATH and/or

   LOCPATH environment variables to include the CollabNet Subversion directories.

   For example:

    export MANPATH=/opt/CollabNet_Subversion/share/man:$MANPATH

    export LOCPATH=/opt/CollabNet_Subversion/share/locale:$LOCPATH

6. Support for CollabNet Subversion

Find out about CollabNet Technical Support at

http://www.collab.net/services/subversion/

Information about CollabNet Training, Consulting, and Migration

services is at http://www.collab.net/services/subversion/training.html

Join openCollabNet for community support: http://open.collab.net

7. About Subversion and CollabNet

CollabNet launched the Subversion project in 2000 in response to the demand

for an open standard for Web-based software configuration management that

could support distributed development. CollabNet continues to be strongly

involved with the Subversion project and offers CollabNet Subversion Support,

Training, and Consulting services.

CollabNet also provides the most widely used collaborative development

environment in the world. More than 1,400,000 developers and IT projects

managers collaborate online through CollabNet. The company is transforming

the way software is developed by enabling organizations to leverage global

development talents to deliver better products and innovate faster.

Visit CollabNet at http://www.collab.net for more information

Tagged : / / / / / / / / / / / / / / / / / / / / /

How to Access SVN when client is under proxy ?

by scmgalaxy KApp / Web ServersLeave a Comment on How to Access SVN when client is under proxy ?

access-svn-when-client-is-under-proxy

The Subversion client can go through a proxy, if you configure it to do so.

 

First, edit your “servers” configuration file to indicate which proxy to use. The files location depends on your operating system.

 

On Linux or Unix it is located in the directory “~/.subversion”.

 

On Windows it is in “%APPDATA%\Subversion”. (Try “echo %APPDATA%”, note this is a hidden directory.)

Tagged : / / / / / / / / / / /