SUSE Conversations


How to clean SMT completely out of Apache DocumentRoot

ataschner

By: ataschner

September 5, 2008 5:47 pm

Reads:647

Comments:0

Rating:0

In some scenarios it is not feasible to place the Subscription Management Tool (SMT) certificate and repository directories inside the apache2 DocumentRoot structure. It can for instance be security policies that prohibit even creating symbolic links to the SMT data within the DocumentRoot.

Disclaimer:
Before reading on, you must be aware that this is not an officially Novell supported solution. In case you run into problems and need assistance from a Novell support provider, you may expect to roll back to at least a symlinked scenario, like what is described in section 3.3 “The /srv/www/htdocs Structure” of the SMT Guide for the duration of the troubleshooting process.

Setting up and maintaining such a “separated” SMT structure outside the default apache2 DocumentRoot involves the following:

Install Subscription Management Tool

First complete the installation of SMT including the configuration wizard as per the documentation in order to get the basic directory structure set up.
This creates the following file and directories in /srv/www/htdocs/

repo/       Update repositories
testing/    Test environment
smt.crt     Server certificate used by clients for registration

Set up the directory structure

First stop the SMT service:

# rcsmt stop

Create the directory to hold the SMT repositories – in the remainder of this document we refer to it as $MY_SMT_DIR.

# mkdir $MY_SMT_DIR

Move the repo and testing directories over to $MY_SMT_DIR and change the ownership. The ownership should only be changed on SMT 11 (running on SLES 11).

# mv /srv/www/htdocs/repo $MY_SMT_DIR
# mv /srv/www/htdocs/testing $MY_SMT_DIR
# chown -R smt.www $MY_SMT_DIR (SMT 11 only)

Modify SMT configuration files

/etc/smt.conf

Update the MirrorTo parameter from

MirrorTo = /srv/www/htdocs

to

MirrorTo = $MY_SMT_DIR  (e.g. /space/smt)

/etc/smt.d/nu_server.conf

Change all four occurrences of /srv/www/htdocs to $MY_SMT_DIR.

Also the alias names repo and testing/repo must be prepended with a forward slash now that they are moved out of the DocumentRoot.
After these changes the modified lines should look similar to these:

    Alias /repo "/space/smt/repo"
    <Directory "/space/smt/repo">
    Alias /testing/repo "/space/smt/testing/repo"
    <Directory "/space/smt/testing/repo">

Certificate location considerations/actions

At this point the only SMT related file left in the default DocumentRoot of apache2 is the server certificate file named smt.crt.

The most safe option here is to leave it like this for the following reasons:

First of all the /etc/init.d/smt init script verifies the certificate file /srv/www/htdocs/smt.crt on every start of the SMT services. In case it does not exist, it is copied over from /etc/ssl/certs/YaST-CA.pem. If this is not acceptable, you will either have to modify the init script (make sure you know what you are doing) or create your own post-smt init script which forcefully moves the /srv/www/htdocs/smt.crt file to $MY_SMT_DIR/repo/smt.crt. It is not sufficient to just delete the /srv/www/htdocs/smt.crt file, since it might have been updated by the smt init script in case of certificate change.

Secondly because configuring the clients against your SMT server will become more difficult.
The clientSetup4SMT.sh script does not support an alternative regcert location in its current state without being modified. So the only options to set up the clients are either to use the regcert kernel parameters during manual installation or the reg_server_cert property in the customer_center section of an AutoYaST profile as described in section 7 of the documentation.

For those scenarios, where it is not an option at all to have the file /srv/www/htdocs/smt.crt exist at any point after the initial installation of SMT, the following modifications are needed.

  1. Move the /srv/www/htdocs/smt.crt file to $MY_SMT_DIR/repo/smt.crt (to keep it simple)
  2. Replace the two occurrences of /srv/www/htdocs/smt.crt in the /etc/init.d/smt init script with $MY_SMT_DIR/repo/smt.crt (e.g. /space/smt/repo/smt.crt)
  3. If the clientSetup4SMT.sh script is being used to register already installed client with SMT, then it must be modified by replacing “/smt.crt” with “/repo/smt.crt” in the line:
    CERTURL=`echo "$REGURL" | awk -F/ '{print "https://" $3 "/smt.crt"}'`

    so that it looks like this :

    CERTURL=`echo "$REGURL" | awk -F/ '{print "https://" $3 "/repo/smt.crt"}'`

Now the configuration is complete and the SMT services can be restarted with

# rcsmt start

Things to keep in mind when implementing this solution

  • The support statement at the top of this document
  • Verify the configuration files in /etc/smt.d/ after applying updates to the smt package. These files are marked as “config” and as long as Novell does not change them with an update, custom changes will be preserved. However if a patch needs to change any of these files, they will be replaced with new ones and the “old”/customized files with your own changes will be saved as *.rpmsave files during application of the update.

Hopefully this article has clarified questions and important aspects around implementing a setup, where there are no Subscription Management Tool related files and directories within the default DocumentRoot of apache2 on SUSE Linux Enterprise Server 10.

The Novell AppNote Keep your SUSE Linux Desktops, Servers and OES Servers Updated with Subscription Management Tool for SUSE Linux Enterprise is a good starting point for getting familiar with SMT.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: , ,
Categories: SUSE Linux Enterprise, SUSE Linux Enterprise Server

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

Comment

RSS