Novell

All posts tagged Novell

Not sure exactly why you need to manually modify Apache configs if you install using the Novell RPMs, but guess you do cuz the php shit just don’t work until you do the following.

zypper in apache2 apache2-mod_php53 php53   (and whatever else php53 mods you need)

copy in the php.ini, my install got this installed , but I’ve seen where there isn’t one.

cp /etc/php5/apache2/php.ini.template (or .example or .rpmnew) /etc/php5/apache2/php.ini

vi /etc/sysconfig/apache2

look for APACHE_MODULES= and add php5 rewrite.   Save. Exit.

APACHE_MODULES=”actions alias auth_basic authn_file authz_host authz_groupfile authz_default authz_user authn_dbm autoindex cgi dir env expires include log_config mime negotiation setenvif ssl php5 suexec userdir  reqtimeout rewrite”

 

I’ve never even knew this “SuSEconfig” command even existed but apparently it does, anyhow you need to run it..heh.

# SuSEconfig && rcapache2 restart

 

You should see your Apache modules using, look for php5 and rewrite

# apache2ctl -M

Now list your php modules with

# php -m

If you missing anything, you add use zypper to install em.

 

drop a phpinfo test file on apache root.

vi testme.php

<?php
phpinfo();
?>

should work.

Grabbed from Novells site

 

Disaster recovery of SMT

This document (7004986) is provided subject to the disclaimer at the end of this document.

Environment

Novell Subscription Management Tool 1.0
Novell Subscription Management Tool 1.1
SUSE Linux Enterprise Server 10 Service Pack 2
SUSE Linux Enterprise Server 10 Service Pack 3
SUSE Linux Enterprise Server 11

Situation

The first section of this document explains what data to proactively back up in order to provide for  a smooth recovery of an SMT server in case it for some reason should become unusable.
The second section describes how to recover by utilizing the information gathered in the first section.

Resolution

Preparation / backup of relevant information.
A normal rule is to ensure to have a usable backup of the complete system.
Besides that it is recommended to create easily-accessible copies of the data mentioned in the following steps, which should all be performed while being authenticated as the root user.

  • To back up the server certificate and be able to create a new server certificate when it expires, the easiest way is to create a copy of /var/lib/CAM/*
  • Record the IP address, DNS and routing configuration of the server in a file.
  • Create a copy of the following :
    • If special configuration of apache2 has been done, then make a copy of the modified files (e.g./etc/apache2/default-server.conf)
    • /etc/smt.conf
    • /etc/smt.d/*
    • /etc/zypp/credentials.d/NCCcredentials
  • Regularly create a backup of the SMT database.
    Since the database is constantly updated with changes it is recommended to create a script that backs up the database. In the examples below the file is named smt-db-backup.sh

    • Create a script  in /usr/sbin/ that includes the following commands  :
    • Set the appropriate permissions to the script – also to prevent normal users from being able to read it, since it contains the password of the MySQL root user :
    • Include the job in the SMT framework by appending a line like the following to the cron table in /etc/smt.d/novell.com-smt:
      22 2 * * * root /usr/sbin/smt-db-backup.sh
    • This will execute the script daily at 02:22
    • Restart the cron daemon to pick up the new job :
  • Depending on factors like :
    • the amount of repository data mirrored
    • backup capacity and costs
    • internet bandwidth constraints
    • requirements for SMT service restoration

    it might or might not be feasible to back up the repository structure (repo/), which is located in the directory specified in the MirrorTo parameter in /etc/smt.conf.

  • By default this means /srv/www/htdocs/repo/ and everything below

Disaster recovery :

In case the SMT server needs to be reinstalled from scratch, the information saved during the preparation can be used to get the server back to operational state as quickly as possible.
Always recover to the same version of SMT that the backups were created on !
The execution order of the individual steps is key and should be performed in the sequentially as listed below.

  • Install SLES 10 (for SMT 1.0) or SLES 11  (SMT 1.1) and configure the same hostname IP address etc. as the server had before.
  • Restore the backup copy of the /etc/zypp/credentials.d/NCCcredentials file.
  • Register it against an update source and apply the current updates (reboot).
  • Restore the Certificate Authority and server certificate from the removable device :
    • Overwrite /var/lib/CAM/ directory structure with the backup copy of the same directory – e.g. :
    • Verify the server certificate has been restored correctly and export the server certificate :
      • Start YaST and open CA Management under Security and Users
      • Enter the CA
      • Verify that the correct server certificate is present and valid
      • Select it, and click on Export | Export as common server certificate
        Enter the certificate password, click OK and a confirmation that “Certificate has been written as common server certificate” should appear.
      • Exit the YaST module.
      • With the next restart of SMT the Certificate Authority is copied to the apache document root directory
  • Restore the repository structure
  • Since the uid of the smt user might be different, the permissions to
    /etc/zypp/credentials.d/NCCcredentials must be set with
  • Verify that the owner/group of /srv/www/htdocs/repo/ is smt.www
    If not then set it recursively with
  • Install SMT as per the documentation :

    and complete the setup wizard.

  • Apply the current updates for SMT
  • Stop the SMT services :

  • Restore and verify the backup of the SMT database :
    • After entering the password it will silently load the backup file and return to the prompt.

    • Enter the MySQL monitor and verify that the tables in the smt database are present :

      Enter the password and when the monitor is loaded execute the command :

      It should return the following output :

+————————–+
| Tables_in_smt            |
+————————–+
| Catalogs                 |
| ClientSubscriptions      |
| Clients                  |
| MachineData              |
| ProductCatalogs          |
| Products                 |
| Registration             |
| Subscriptions            |
| Targets                  |
| migration_schema_log     |
| migration_schema_version |
+————————–+
11 rows in set (0.00 sec)
The above output is from SMT 1.0.
On SMT 1.1, the following four additional tables should exist :
Filters, JobQueue, Patchstatus and RepositoryContentData
    • Exit the monitor :

  • Adapt the configuration files to the customizations in the backed up ones and start SMT with

  • Syncronize data between local database and the Novell Customer Center with

  • Verify the catalogs/repositories enabled for mirroring with

  • List the registered clients with

  • SMT 1.1 only : View the job queue with

  • Kick off a mirror job to fix up the database :
    • SMT 1.0 :

    • SMT 1.1 :

Once the mirror job has completed the SMT server should be fully operational.
To verify client functionality perform a service refresh on a client and check that the “Last Contact” time-stamp for its entry of registered clients on the server gets updated

How to recreate SMT 11 CA and server certificate

This document (7006024) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Subscription Management tool or SUSE Linux Enterprise Server 11 and SUSE Linux Enterprise Server 10

Situation

It is usually unnecessary to recreate the CA and server certificate. If you think your CA or server certificate are not functioning as expected, you may need to recreate them. This TID explains how.

Resolution

Delete the old CA

  1. Since YaST does not allow to delete the existing CA as long it has not expired, we have to delete the related files manually.
  2. Open up a shell and change to the /var/lib/CAM and move the directory of the existing CA to /tmp/, e.g. by executing “mv YaST_Default_CA /tmp/”. Attention: Do not move or delete the “.cas” directory.

Create root CA

  1. From the root shell start ‘yast2 ca_mgm’.
  2. Select ‘Create Root CA’.
  3. For “CA Name” and “Common Name” enter “YaST_Default_CA”. Please note not to use the server name or server FQDN in here, since this would complicate later error analysis!
  4. Enter the email address of the issuer (and select “add”) and enter optional information such as organization, unit, locality, state and country.
  5. Select “Next”.
  6. Choose the password, length of the key and its validity.
  7. Select “Next” to see an overview about the CA.
  8. Select “Create” to create the CA.

Create server certificate

  1. Select the newly created CA in the YaST2 CA management module.
  2. Press “Enter CA”.
  3. Enter the CA password.
  4. Select the Certificates tab.
  5. Click on “Add” and choose Server Certificate.
  6. Provide the requested data:
  7. For Common Name put in the fully qualified domain name of the server (FQDN) of the server, for example “smt-server.example.net”. This is mandatory!
  8. Add an valid email address of the server administrator and press “Add”.
  9. Press “Next”.
  10. Here it is possible to either use the CA password for the server certificate or a different one. Also key lengt and validity may be changed.
  11. Optional: Enter the IP Adress of the server as Subject Alternative Name. This ensures that clients can connect to the server via IP address.
    • Select ‘Advanced Options’.
    • Select ‘Subject Alt Name’ (not to be confused with Issuer Alt Name!!).
    • Select ‘Add’.
    • Choose ‘IP’ and put in the IP address of the server.
    • Select ‘Ok’.
  12. Select ‘Next’ to get to an overview over the certificate.
  13. Select ‘Create’ to create the server certificate.

Export the certificate as common server certificate, so that the http server apache uses it

  1. On the certificates tab locate the “Export” button.
  2. Select “Export as common server certificate”.
  3. Enter the password that was chosen for the server certificate.
  4. A message “Certificate has been written as common server certificate” will be displayed.

Export the CA certificate to the smt.crt file

  1. In the YaST2 CA management module change to the “Description” tab and select “Advanced / Export to File”.
  2. Select “Only the Certificate in PEM Format” and enter “/srv/www/htdocs/smt.crt” as the filename.
  3. Select “Ok” to export the file.
  4. Leave YaST.

Restart SMT

  1. Restart the smt server by entering “rcsmt restart” into the root shell. This will also restart the http server apache, so that apache uses the new certificate.

Import the newly created CA to the SMT clients

  1. Execute “clientSetup4SMT.sh –host smt-server.example.net” (adjust the FQDN to your SMT server) to import the new CA to the SMT clients and to make the clients to trust the new CA. On SLE 11 clients you can alternatively use the “yast2 inst_suse_register” module (select “Advanced” and follow the instructions).
  2. Execute “suse_register -L /root/.suse_register.log” to register the client against the SMT server.

software.opensuse.org.

Search for your software, make sure you choose the packages geared for your distro SLES11SP1 or 2.  Open the repository in your browswer, look for the .repo file.  For example, here’s the ImageMagick for SLES11SP2

http://download.opensuse.org/repositories/home:/cabelo:/ImageMagick/SLE_11_SP2/

Click the home:cabelo:ImageMagick.repo file

Select all, copy/paste into /etc/zypp/repos.d/Image.repo

zypper ref -s