SUSE Linux Enterprise Cool Solutions

Early Bird Discount: Save $300 on BrainShare

mattclayton — Fri, 06 Nov 2009 13:31:43 -0700

Novell has taken steps to make BrainShare more affordable by dropping the full price of the conference from US$1,895.00 to US$1,695.00. You can save an additional $300 with the "early bird" registration. The "early bird" rate of US$1,395.00 will be available until February 19, 2010. Learn more at http://www.novell.com/brainshare

Cool Solutions

Using the OpenSUSE Build Service to Create and Distribute Kernel Module Packages

andavis — Wed, 04 Nov 2009 11:21:02 -0700

Using the OpenSUSE Build Service to Create and Distribute Kernel Module Packages

1. Introduction
2. Scope
3. What is OBS?
4. Using OBS to Create KMPs
    4.1 Code Preparation
           4.1.1 Example
    4.2 Creating an OBS Project
           4.2.1 Example
    4.3 Defining Target Distributions
           4.3.1 Example
    4.4 Adding Packages to a Project
           4.4.1 Example
    4.5 Setting Target Distributions for a Package
           4.5.1 Example
    4.6 Building KMPs
           4.6.1 Example
    4.7 Publishing KMPs
           4.7.1 Example
5. Using OBS Repositories
    5.1 Example
6. Summary
Appendix A – Sample Files
Appendix B – Building for Red Hat Enterprise Linux (RHEL)
References

1. Introduction

As Linux gains market-share in the server, desktop, and laptop operating system space, demand for Linux drivers and kernel modules is increasing. Independent hardware and software vendors (IHVs and ISVs) can expand their customer bases significantly by providing proper kernel-space support for their products.

Novell promotes having all Linux drivers in the official kernel.org source tree. However, Novell also recognizes that sometimes IHV and ISV partners do need to provide drivers separate from the Linux kernel. Novell encourages partners who need to provide such external driver(s) to use specially-built rpms called Kernel Module Packages (KMPs). By using KMPs, partners can ensure that their modules will be installed appropriately and handled correctly during OS updates..

Novell's Partner Linux Driver Process web site¹ provides full instructions for building KMPs on one's local development systems. But Novell also provides another way to build packages: the openSUSE Build Service (OBS). OBS allows developers to build rpms (including KMPs) remotely on hardware maintained by Novell. By using OBS, partners can 1) build KMPs for multiple architectures and distributions, and 2) easily provide KMPs in repositories that customers can access and that interact well with the SUSE Linux installation and update utilities.

2. Scope

This document explains how to use OBS to build KMPs for the Code 11 SUSE Linux distributions. However, Appendix B includes information on how to use OBS to build KMPs (from the same source code and packaging files) for Red Hat Enterprise Linux (RHEL) as well.

With respect to the OBS web and command-line interfaces, this document only describes the specific steps and commands required to build a KMP. For complete information on the OBS web and command-line interfaces, see the full OBS user documentation².

This document does not provide information about developing or porting driver source code.

3. What is OBS?

The openSUSE Build Service is an open and complete distribution development platform which provides software developers with tools to compile, release and publish their software for different Linux distributions and hardware architectures2. Novell/SUSE's development teams use OBS to build packages for openSUSE, SLES, SLED, etc. For the purposes of this document, the term "OBS" refers to both the web interface as well as the systems used to perform actual builds.

There are a number of benefits to building packages using OBS rather than local development or build systems. Developers who build locally must install physical and/or virtual machines for each architecture and distribution they wish to support. Obtaining and maintaining such a large number of build systems can be expensive and cumbersome. By using OBS, developers can concentrate on developing code and offload much of their build work to the automated OBS processes.

Another benefit to using OBS is the ability to easily create repositories and publish packages. Traditionally, developers have had to build their packages then work with their distribution and/or IS&T departments to provide those packages to customers. But OBS takes care of the distribution work: after building, OBS places packages in automatically-created YUM repositories that SUSE Linux (and other Linux distributions) can use as installation and update sources.

Even given the above benefits, it is important to note that OBS is not suited to all development projects. Partners are encouraged to consider the following points before using OBS to build KMPs:

OBS is essentially public: Any source code uploaded to OBS is visible and available to all other persons with OBS logins.
Source code uploaded to build KMPs must be licensed under the GPL in order to comply with legal and policy requirements.^3,4 OBS must not be used to build non-GPL kernel modules.
Partners should not use OBS to mark their modules as "supported: external" without prior explicit approval from Novell. (The privilege of marking modules as "supported external" is reserved for partners with whom Novell has L3-level support agreements.)
Currently, OBS does not provide a means to build for specific SLE service pack versions or security/maintenance updates. OBS only supports building for the first customer ship version of each major SLE release.
Currently, OBS only supports building packages for ix86 and x86_64 architectures.

4. Using OBS to Create KMPs

The following sections detail the basic steps to follow when using OBS to build and publish a KMP. Each sub-section describes a particular step in the process, then provides a hands-on example. The example in each sub-section builds upon the example from the previous sub-section.

Note: Although the instructions in this section describe how to use OBS, they do not delve into the details of how to interact with the OBS web interface. It is assumed that the OBS web interface is intuitive and that partners will be able to determine how to use the interface to execute the steps listed.²

4.1 Code Preparation

OBS creates packages from source code and packaging files. Therefore, before using OBS to build a KMP, a partner needs to have source code that is ready to be packaged: development should be complete, the code should build as an external module in compliance with the information in /usr/src/linux/Documentation/kbuild/modules.txt, and the resulting module(s) should function as desired. As a simple test, if a partner's source code builds by simply issuing a "make -C <target-kernel-source-directory> M=`pwd`" command in the source code's top-level directory, then it should be very straightforward to package the code into a KMP.

Note 1: As the above paragraph implies, it is certainly possible to have code which builds but whose build structure does not work well with the standard process for building KMPs. Build structures that do not comply with /usr/src/linux/Documentation/kbuild/modules.txt, or build structures that perform steps in addition to basic module build and install, may require modification in order to "fit" with the steps outlined in the following sections. Working with such build structures is outside the scope of this document.

Note 2: Often, the impetus to create an external module is the need to make a module from one kernel (the source kernel) work on a different kernel (the target kernel). This is generically referred to as "backporting", since the most common scenario is for a developer to start with module source code from the upstream kernel and build it for an older kernel version. Depending on the complexity of the module source code and the differences between the source and target kernels, backporting can be difficult and is beyond the scope of this document.

4.1.1 Example

The example used in this and following sections is structured around the common use case of a system vendor needing to provide an external driver to support SLE 11 on a particular system. To work through the example, assume the following:

The system to be supported is "samplesystem".
The driver to be provided is "sampledriver".

To complete the "Code Preparation" portion of the example:

Create a "sampledriver" directory in a work location on your development system. E.g.:
```
mkdir -p /work/sampledriver
	
	
```
Create a "sampledriver-1.0" directory in the sampledriver directory:
```
mkdir /work/sampledriver/sampledriver-1.0
	
	
```
In the sampledriver directory, create a sampledriver.spec file by copying and pasting the text from the sampledriver.spec file in Appendix A.
In the sampledriver-1.0 directory, create a sampledriver.c file by copying and pasting the text from the sampledriver.c file in Appendix A.
In the sampledriver-1.0 directory, create a Kbuild file by copying and pasting the text from the Kbuild file in Appendix A.

Your directory structure should now look like:

work
    sampledriver
       sampledriver.spec
       sampledriver-1.0
             sampledriver.c
             Kbuild

From within the sampledriver-1.0 directory, test building this source code by issuing the command
```
make -C /usr/src/linux M=`pwd`
```
and verifying that it creates a sampledriver.ko file. Note: In order for this make command to succeed, /usr/src/linux should be the top-level directory of a SLE 11 kernel source tree which has been prepared for module build in accordance with the instructions in section 2.4 of /usr/src/linux/Documentation/kbuild/modules.txt.
From within the sampledriver directory, create a tarball of the sampledriver-1.0 directory:
```
tar cvjf sampledriver-1.0.tar.bz2 sampledriver-1.0
```

4.2 Creating an OBS Project

The next step in using OBS to build a KMP is to create an OBS project.

An OBS project is basically an abstract container for packages that are related in some way. OBS projects may contain sub-projects to further categorize packages. OBS projects and sub-projects correspond to how repositories are presented to users.

OBS projects can be created at the root level or in existing OBS project containers such as "home" or "isv". The root level is generally reserved for official community projects, the "home" container is intended for individual developers to use as a testing area, and the "isv" container is where Novell encourages partners to create their projects.

Note that any OBS project repository URL contains the name of its associated project. For this reason, Novell encourages partners to establish project names that reflect their organizations. E.g., a Novell partner with the name "AAA Computers" might wish to establish the project "aaa-computers" in the "isv" container. The URL for a SLE 11 repository associated with the "aaa-computer" project would be http://download.opensuse.org/repositories/isv://aaa-computers/SLE_11.

While no authorization is needed to create projects in the "home" container, projects in the "isv" container are more controlled. Partners who wish to create a project in the "isv" container should post a request to the opensuse-buildservice mail list2 or contact their Novell representative.

IHV/ISV partners can certainly use their main projects for all their KMPs. However, often partners have sets of packages that apply to different hardware and software configurations. For instance, a partner "AAA Computers" might wish to provide one set of drivers for "Peripheral-A" and another set of drivers for "Peripheral-B". The partner could use a main "isv:aaa-computers" project for both the Peripheral-A and Peripheral-B drivers... with the result that all the KMPs would be provided in a single repository (e.g., http://download.opensuse.org/repositories/isv://aaa-computers/SLE_11 ). A more useful approach might be for AAA Computers to create two sub-projects: "isv:aaa-computers:peripheral-a" and "isv:aaa-computers:peripheral-b", each containing its own drivers and each providing its own repository.

4.2.1 Example

Note: Because OBS users are automatically provided with a "home:<loginname>" project (no authorization needed), this example demonstrates how to create a sub-project in the user's "home:<loginname>" project rather than in the OBS "isv" container.

To create the samplesystem sub-project using the OBS web interface:

Login to http://build.opensuse.org using your Novell login. (The http://build.opensuse.org website also provides a link to obtain a Novell login if necessary.)
On the main OBS page, click the "Home Project" link to display your OBS home:<loginname>:samplesystem project page.
Click to create a subproject. Name the subproject "samplesystem". Enter and save the appropriate information, then OBS should display your samplesystem subproject page.

4.3 Defining Target Distributions

Once an OBS user has created a project, he/she can define the target distributions that apply to the project. A project should include a distribution as a target if any of the packages in the project will --- or even may --- need to be built for that distribution. Whether a particular package is to be built for a particular target distribution can be specified on a package level; the project should include all distributions that might be needed.

Note that OBS refers to a project's target distributions as "Build Repositories": collections of packages needed to build project components against a particular target. With respect to OBS projects, there are the Build Repositories that users select as target distributions (i.e., repositories used during build)... and there are the Build Repositories that OBS creates to provide the project's built packages. Any Build Repositories that OBS creates to provide a project's built packages can be selected as target distribution repositories for other projects.

4.3.1 Example

To set target distributions for your OBS samplesystem project:

On the OBS samplesystem subproject page, use the "Build Repositories" section to add SLE_11 and RHEL_5. (While the bulk of this document discusses building for SLE 11, Appendix B describes how to use the same build structure and source code to build for RHEL 5 as well.)

4.4 Adding Packages to a Project

OBS projects can contain one or more packages, but the name of each package must be explicitly specified on the OBS project page before uploading any source code. (Using the OBS project page to add a package name is analogous to adding a directory which will hold the package's source code and packaging files.) Once an OBS user adds a package name to his project, he can upload his source code (generally in the form of a tarball). As noted in section 4.1 above, partners who wish to build KMPs should ensure that their source code is structured in accordance with /usr/src/linux/Documentation/kbuild/modules.txt.

Uploading module source code (including Kbuild files and/or Makefiles) provides OBS with the information needed to create the pertinent kernel modules. But to create rpms, OBS also needs package meta-data provided via a *.spec file.

The basic spec file template for building SLE 11 KMPs is available in the Kernel Module Packages Manual – Code 115. By using this template as a basis to create his own spec file, an IHV/ISV can ensure that his modules will be installed and configured to interact correctly with SUSE Linux. The spec file in Appendix A is taken from the KMP spec file template and modified to apply to the "sampledriver" package.

4.4.1 Example

To add a sampledriver package to your samplesystem project:

On the OBS home:<loginname>:samplesystem project page, click the appropriate link to add a package. Name the package "sampledriver". Complete the required fields and save the data, then OBS will display the sampledriver package page.

Now that the sampledriver package exists, source code and build files can be uploaded to it. Uploading files to OBS can be done using either the OBS web-interface or command-line client. To upload the sampledriver files using the OBS web-interface:

In the "Files" section, click to add a file to the sampledriver package. Upload the sampledriver-1.0.bz2 tarball from the /work/sampledriver directory.
In the "Files" section, click to add a file to the sampledriver package. Upload the sampledriver.spec file from the /work/sampledriver directory.

To upload the sampledriver files using the OBS command-line client:

Install the "osc" package from the SLE 11 SDK ( http://developer.novell.com/wiki/index.php/SLES_SDK). The osc package provides the "osc" utility, which is used to interact with OBS. (Note: Readers familiar with the Subversion Version Control System may find it useful to analogize the "osc" command to the "svn" command. Use the "osc help" command to view options.)
From a staging area on your development system (e.g., /work), check out the sampledriver package from the home:<loginname>:samplesystem project:
```
co home:<loginname>:samplesystem sampledriver
```

The above command will create the following directory structure:

work
		home:<loginname>:samplesystem
			.osc
			sampledriver

(Note: The ".osc" file provides information that the osc tool uses to interact with OBS.)

Copy the sampledriver.spec and sampledriver-1.0.tgz files from /work/sampledriver into the empty /work/home:<loginname>:samplesystem/sampledriver directory:
```
	cd /work/home:<loginname>:samplesystem/sampledriver
	cp /work/sampledriver/* .
	
	
```
Upload (check in) the sampledriver source code and build files to OBS:
```
	osc add *
	osc ci
	
	
```

Note: The "osc ci" command will prompt for a check-in message.

4.5 Setting Target Distributions for a Package

By default, a package is "enabled" to build for all the target distributions associated with the package's parent project. However, OBS users can override this default and disable building a specific package for a particular target distribution.

4.5.1 Example

To set the target distributions for your sampledriver package:

On your OBS sampledriver package page, click the appropriate links in the "Package Flags" section to specify that the package should be built for SLE 11 only (i.e., disable building for RHEL 5).

4.6 Building KMPs

When an OBS package is enabled to build on a specific target distribution, the package will be built/rebuilt automatically whenever updates are made to the package or to the target distribution. However, OBS users can also manually trigger builds for each distribution by clicking on appropriate items in the "Build Status" section of the OBS package page or by using the OBS command-line client.

4.6.1 Example

To build your sampledriver package using the OBS web interface:

In the "Build Status" section of the OBS sampledriver page, click on the SLE_11 icon to trigger rebuilds for this target distribution.
Refresh the page (by using the "Build Status" refresh icon) until the status changes for the SLE_11 sampledriver builds.

To build your sampledriver package using the OBS command-line interface:

Change directory to the directory containing the home:<loginname>:samplesystem project (e.g., /work or other staging location created in section 4.1.1).
Tell OBS to rebuild the sampledriver package (for all enabled target distributions):
```
osc rebuildpac home:<loginname>:samplesystem sampledriver
```
After issuing the above command, view the status from your build request:
```
osc results home:<loginname>:samplesystem sampledriver
```

4.7 Publishing KMPs

One of the great benefits that partners gain by using the openSUSE Build System is the ability to provide not just packages (or in this case, KMPs), but also repositories that end-users can access to install the KMPs. OBS makes it very simple to provide a repository that is fully compatible and integrated with the SUSE Linux installation and update utilities.

By default, OBS creates and publishes a separate repository for each of a project's target distributions. The OBS project page "Goto Repository" link for each target distribution provides an easy way to view the actual repositories. Alternatively, users can access each repository directly by using the URL http://download.opensuse.org/repositories/home://l... . Note that while publishing is enabled by default, OBS users can enable or disable publishing for specific repositories as desired.

4.7.1 Example

Note: Completing this step may require waiting for OBS to finish any scheduled builds and create/populate appropriate repositories.

To view the repositories for the samplesystem subproject:

Access the OBS home:<loginname>:samplesystem project page. In the "Build Repositories" section, click the "Goto Repository" link for the SLE_11 target distribution. Navigate into the separate architecture directories to view the built sampledriver KMPs.

5. Using OBS Repositories

Once a partner makes KMPs available in an OBS repository, anyone (partners, customers, etc.) can add the repository URL as an installation/update source from which to install the KMPs. There are several common use cases in which OBS repositories might be used:

A system integrator might wish to sell pre-loaded systems that include the OBS repository as a pre-configured installation/update source. In this case, registering the repository (and installing appropriate initial KMP(s) from the repository) would be done by system integrator as part of the system installation process. After customers purchase the systems, they might access the repository to get updated KMPs.
An IHV might wish to provide a KMP to support a particular hardware product. In this case, the partner might provide customers with documentation that details the repository URL and explains how to register the repository and install KMPs from it.
A partner who creates a SLE-based appliance might wish to include an OBS repository as an installation/update source. In this case, the process of registering the repository (and installing appropriate initial KMP(s) from the repository) would be part of the appliance build process.

5.1 Example

To add the OBS samplesystem repository and install the sampledriver KMPs from it:

Install a system with SLES/SLED 11. Using YaST2->"Software Repositories" or YaST2->"Add-on Product", add the OBS SLE 11 samplesystem repository by specifying the URL http://download.opensuse.org/repositories/home://<... .
Using YaST2->"Software Management", click to show packages in the samplesystem repository, then install the desired KMP(s).

6. Summary

IHVs and ISVs who provide drivers and other kernel modules face some unique development challenges in ensuring that their products will interact correctly with the SUSE Linux operating environments. By using Novell's openSUSE Build Service, these partners can greatly simplify the process to build, package and distribute their kernel-space products.

Appendix A – Sample Files

The following sampledriver.c and Kbuild files may be used to build the sampledriver.ko module referenced in Section 4 above. The following sampledriver.spec file is based on the spec file template in the Kernel Module Packages Manual – Code 11⁵.

sampledriver.c

/* 
 * sampledriver.c - A sample driver which simply creates an entry in the proc filesystem.
 * 
 * Copyright (C) 2009
 * Ann Davis <andavis@novell.com>, Novell Inc. 
 * 
 * This program is free software; you can redistribute it and/or modify it under the terms of the
 * GNU General Public License as published by the Free Software Foundation.
 * 
 * A copy of the GNU General Public License can be obtained from http://www.gnu.org/.
 * /

#include <linux/module.h>
#include <linux/init.h>

MODULE_AUTHOR("Ann Davis <andavis@novell.com>");
MODULE_DESCRIPTION("Sample driver");
MODULE_LICENSE("GPL");

static struct proc_dir_entry *proc_entry;
static char *sampledriver_message = "Hello from sampledriver."

int sampledriver_read(char *page, char **start, off_t off, int count, int *eof, void *data);
{
	int retVal = 0;

	retVal = sprintf(page, "%s\n", sampledriver_message);

	return retVal;
}

int __init init_sampledriver(void)
{
	int retVal = 0;

	printk(KERN_INFO "In sampledriver init function...\n");

	proc_entry = create_proc_entry("sampledriver_info", 0644, NULL);
	if (proc_entry == NULL) {
		printk(KERN_INFO "sampledriver:  Unable to create proc entry.\n");
		retVal = -ENOMEM;
	}
	else {
		proc_entry->read_proc = sampledriver_read;
	}
	
	return retVal;
}

void __exit exit_sampledriver(void)
{
	printk(KERN_INFO "In sampledriver exit function...\n");
	remove_proc_entry("sampledriver", NULL);
}

module_init(init_sampledriver);
module_exit(exit_sampledriver);

Kbuild

obj-m += sampledriver.o

sampledriver.spec

#norootforbuild 

Name:			sampledriver 
BuildRequires:	%kernel_module_package_buildreqs 
License:		GPL 
Group:			System/Kernel 
Summary:		Sample Driver 
Version:		1.0 
Release:		0 
Source0:		%name-%version.tar.bz2 
BuildRoot:		%{_tmppath}/%{name}-%{version}-build

%kernel_module_package

%description 
This package contains the sampledriver.ko module. 

%prep 
%setup 
set -- * 
mkdir source 
mv "$@" source/ 
mkdir obj 

%build 
for flavor in %flavors_to_build; do 
        rm -rf obj/$flavor 
        cp -r source obj/$flavor 
        make -C %{kernel_source $flavor} modules M=$PWD/obj/$flavor 
done 

%install 
export INSTALL_MOD_PATH=$RPM_BUILD_ROOT 
export INSTALL_MOD_DIR=updates 
for flavor in %flavors_to_build; do 
        make -C %{kernel_source $flavor} modules_install M=$PWD/obj/$flavor 
done

%changelog
Mon Oct 19 2009 – andavis@novell.com
- Initial version.

Appendix B – Building for Red Hat Enterprise Linux (RHEL)

Red Hat and Novell have participated with other Linux community members in the Linux Foundation's efforts to establish cross-vendor standards for building, installing, and distributing drivers.⁶ While differences still exist between distributions, partners can now create SLES kernel-module-package build structures that need very few (or even no) modifications to build correctly for RHEL..

Because Red Hat's Driver Update Program⁷ spec file template is very similar to Novell's, the sampledriver code provided in Appendix A requires only a minor modification to build appropriately for RHEL 5: While the SLE install location for external modules is /lib/modules/<kernel-version>/updates, the RHEL 5 install location is /lib/modules/<kernel-version>/extra/%{name}. Fortunately, OBS has the ability to perform distro-specific functions (see http://en.opensuse.org/Build_Service/cross_distribution_package_how_to ), so there is no need to create a separate OBS sampledriver package (or even a separate sampledriver.spec file) for RHEL. All that is required to build for both RHEL and SLE is to modify the sampledriver.spec file as noted below, then enable both the RHEL and SLE target distributions for the OBS home:<loginname>:samplesystem project.

sampledriver.spec (modified to build for both SLE and RHEL)

#norootforbuild 

Name:			sampledriver 
BuildRequires:	%kernel_module_package_buildreqs 
License:		GPL 
Group:			System/Kernel 
Summary:		Sample Driver 
Version:		1.0 
Release:		0 
Source0:		%name-%version.tar.bz2 
BuildRoot:		%{_tmppath}/%{name}-%{version}-build

%kernel_module_package

%description 
This package contains the sampledriver.ko module. 

%prep 
%setup 
set -- * 
mkdir source 
mv "$@" source/ 
mkdir obj 

%build 
for flavor in %flavors_to_build; do 
        rm -rf obj/$flavor 
        cp -r source obj/$flavor 
        make -C %{kernel_source $flavor} modules M=$PWD/obj/$flavor 
done 

%install 
export INSTALL_MOD_PATH=$RPM_BUILD_ROOT 
%if 0%{?rhel_version} == 501
export INSTALL_MOD_DIR=extra/%{name}
%else
export INSTALL_MOD_DIR=updates
%endif
for flavor in %flavors_to_build; do 
        make -C %{kernel_source $flavor} modules_install M=$PWD/obj/$flavor 
done

%changelog
* Tue Oct 20 2009 – andavis@novell.com
- Add RHEL support.
* Mon Oct 19 2009 – andavis@novell.com
- Initial version.

References

[1] Novell, Inc. Partner Linux Driver Process (PLDP). Project website at http://developer.novell.com/wiki/index.php/Partner_Linux_Driver_Process .
[2] openSUSE Build Service (OBS). Documentation website at https://build.opensuse.org/documentation/obs . Forums website at http://forums.opensuse.org/opensuse-build-service-obs/ .
[3] Free Software Foundation. Licenses website at http://www.gnu.org/licenses .
[4] Linux Foundation. Kernel Driver Statement. Website at https://www.linuxfoundation.org/en/Kernel_Driver_Statement .
[5] Partner Linux Driver Process, Andreas Gruenbacher. Kernel Module Packages Manual for Code 11. http://developer.novell.com/wiki/index.php/Image:Kmpm-code11.pdf .
[6] Linux Foundation. Driver Backport Workgroup. Website at http://www.linuxfoundation.org/collaborate/workgroups/driver-backport .
[7] Red Hat, Inc. Driver Update Program. Website at http://dup.et.redhat.com/ .

Cool Solutions

Heads Up! Novell Pulse Coming Your Way

ssalgy — Wed, 04 Nov 2009 09:28:47 -0700

Novell just announced the first real-time collaboration platform for the enterprise, called Novell Pulse. Novell and Google jointly announced that they are working together to enable Novell Pulse users and Google Wave users to seamlessly work together across both systems. Novell is the first collaboration provider to integrate Google Wave.

What is Novell Pulse?

Novell Pulse is the first enterprise class, real-time collaboration platform that unites communication, authoring and social messaging tools. Novell Pulse helps drive enterprise productivity and innovation by making it easier to communicate digitally, generate ideas and share information. People continents apart can share and edit documents, jointly browse websites, and have a digital conversation, all in real-time. Individuals can also manage content overload by filtering for people and topics to follow as well as storing files—both native and office type—along with their related groups and conversations.

What can you do with Pulse?
Novell Pulse is an enterprise real-time collaboration solution. Real-time collaboration tools allows people to easily share and work together on documents, have real-time conversations, interact using social media tools, and much more.

Novell Pulse was designed specifically for the enterprise user, so it includes robust security and management capabilities. Novell Pulse will also interoperate with other real-time technologies like Google Wave, as well as existing collaboration solutions.

How would you use it in a business setting?

Communication. Say you have a project that requires input from 5 people. Before Novell Pulse, you would email those 5 people and receive separate responses—some of which would be responding to your email, while others would be responding to other emails from the distribution list, depending on when each was composed. Then you'd have to aggregate all the responses, synthesize them, and begin the cycle of emails all over again.

With Novell Pulse, you send one, synchronous message, and all 5 people can respond to you and each other in real-time. No aggregation, missed information or repetition of efforts—and if you make the conversation public, you may get valuable input from someone you weren't expecting.

Intra- and Inter-company Collaboration. For example, you plan to issue a product datasheet jointly with one of your partners. You work in different document publishing environments such as OpenOffice and MS Word. Before Novell Pulse, you would have written the press release and sent it as an OpenOffice attachment to everyone on your team within your company for input, then aggregated all the input, edited it down for redundancy, and then converted it to MS Word before sending as an attachment to your partner for input. Then you'd begin the cycle again for every round of edits.

With Novell Pulse, you and your partner could simply collaborate on the document in real-time and then both companies could export the document into their preferred format when it's final. This also works seamlessly if you are using Novell Pulse and your partner is using Google Wave.

Breaking Through the Clutter. Information overload is a serious concern for companies today. Users are hit with information from all directions—email, instant messenger, blogs, micro-blogs, social networks, calendars. By unifying all these information mediums into one, easy-to-use interface with folders, filtering and search, Novell Pulse enables users to make sense of it all and focus on what's really important.

Working With Google

This is a technical collaboration between Google and Novell to bring federation to both systems, using the Wave Federation Protocol. We're the first company to show federation using the WFP, and we're the first collaboration solution to integrate with Google Wave. Novell Pulse and Google Wave systems can operate in tandem so that users of the two platforms can work together in real time, each using their preferred tool.

What does federation with Google Wave involve?
Federation involves using a protocol call the Wave Federation Protocol to enable messages (or Waves) to be shared in real-time, character-for-character, as they are being created or edited between two or more separate systems.

The sharing is based on addressing. You place addresses ( which look just like e-mail addresses) from potentially different domains on a message or Wave, then the message is live and any edits made by anyone will be automatically shared in real-time.

How is Novell Pulse different from Google Wave?
The design point for Novell Pulse is the enterprise user, so we've placed a strong emphasis on features such as security and management controls. We've also drawn on our 20+ years experience in the enterprise collaboration space with products like GroupWise, and worked to address enterprise and business use-cases.

Novell Pulse is a key component in Novell’s collaboration strategy and open collaboration architecture, working standalone or in concert with Novell’s broader product portfolio. Novell Pulse is very complementary to Google Wave and to our existing collaboration products such as GroupWise. Key features, which draw on the best of e-mail, instant messaging, document sharing, social connections, real-time co-editing and enterprise controls, include:

Security
Provisioning, sign-on and permissions leverage enterprise identity and access management systems, directory servers and audit tools to integrate with established processes, keep data safe and support compliance requirements.
Real-time collaboration
Collaborative editing and document sharing enables users to get work done with other users in real-time, from co-editable online documents to the ability to share and comment on traditional office documents in real time.
Unified Inbox
A single interface allows users to see, sort and filter all their personal and professional content from various social messaging services, email, Wave, etc. all in one place.
Enterprise social messaging
Social Blog allows users to share, follow and comment on topics and ideas.
Real-time awareness and chat
Allows users to know exactly when their colleagues are available via people, group and message activity monitoring.

Novell Pulse will be available in both cloud and on-premise deployments.

Is Novell Pulse designed for the consumer or the enterprise customers?
Novell Pulse is focused on the enterprise customers. It addresses the needs of a global, knowledge-based workforce and gives enterprises the confidence to embrace real-time collaboration technologies. Novell Pulse leverages Novell's expertise and experience developing enterprise collaboration and communication tools, as well as industry leadership in creating strong identity and security management solutions.

Is Novell Pulse open source?
No.

When will Novell Pulse be available? What will it cost?
Novell Pulse will be generally available in the first half of 2010 in a cloud deployment, and with an on-premise deployment option in a subsequent release. Pricing will be announced at general availability.

How can I get access in when this goes to beta availability?
We'll be announcing that later this year.

Where can I see Novell Pulse in action?
Novell Pulse was demonstrated on Nov. 4, 2009 during the Integrating Google Wave into the Enterprise keynote at Enterprise 2.0 in San Francisco. We'll be giving previews of the technology over the coming weeks via Novell blogs and video. Stay tuned. A select beta is scheduled for early 2010.

Where can I get more information about Novell Pulse?
You can find more information at www.novell.com/pulse . We'll be previewing more of Novell Pulse over the coming weeks too.

End-User Computing

BrainShare Jacket Promotion

mattclayton — Tue, 03 Nov 2009 00:00:00 -0700

Get a free jacket by being one of the first 400 to register for BrainShare 2010 using this registration code: jacket. Sign up and share the news with your friends. The red and gray, athletic jacket is the perfect jacket for the spring weather in Utah. Jackets will be available for pick up at the registration booth on Monday, March 22, 2010.

ZENworks Cool Solutions

BrainShare - Flip the Switch

mattclayton — Tue, 27 Oct 2009 00:00:00 -0600

Here's a link to a great article about some of the changes and modifications we've made for BrainShare 2010. Check it out to see how we've incorporated your feedback to make this year's conference better than ever.

http://www.novell.com/connectionmagazine/2009/10/b...

ZENworks Cool Solutions

Performance Scripting for GNOME Desktop

susethailand — Wed, 14 Oct 2009 16:42:39 -0600

This shell script optimizes some of the Gnome configuration options for simplicity and performance. The last two steps also reapply these settings making them the defaults forced on every start of a Gnome session.

1. Create shell script

$ vi /etc/profile.d/gnome-perf.sh
#!/bin/sh 
# Gnome Performance of SUSE Linux
# By: Sontaya Photibut, , 2009
# Website: http://www.susethailand.com
# Path Schemas "/etc/gconf/schemas"

### gnome-session.schemas ##
# Don't show the Gnome splash page (Default=false)
gconftool-2 --type bool --set /apps/gnome-session/options/show_splash_screen false

##  apps_nautilus_preferences.schemas ##
# Don't count how many files and their sizes in the Nautilus windows (Default=local_only)
gconftool-2 --type string --set /apps/nautilus/preferences/show_directory_item_counts never
# Don't try to preview a sound (Default=local_only)
gconftool-2 --type string --set /apps/nautilus/preferences/preview_sound never

# Don't show the text below the icon that describes the file (Default=local_only)
gconftool-2 --type string --set /apps/nautilus/preferences/show_icon_text never

## desktop_gnome_background.schemas ##
# Don't use wallpaper (Default=zoom)
gconftool-2 --type string --set /desktop/gnome/background/picture_options none
# Don't use a gradient backdrop (Default=solid)
gconftool-2 --type string --set /desktop/gnome/background/color_shading_type solid
# Set the background color to blue - Really purple :) (Default=#66ba00)
gconftool-2 --type string --set /desktop/gnome/background/primary_color \#666699
# Disable desktop picture background
gconftool-2 --type bool --set /desktop/gnome/background/draw_background false

## desktop_gnome_interface.schemas ## 
# Set the Icon theme to gnome
gconftool-2 --type string --set /desktop/gnome/interface/icon_theme gnome
# Set the GTK them to Sample (Default=>Clearlooks)
gconftool-2 --type string --set /desktop/gnome/interface/gtk_theme Simple

## desktop_gnome_sound.schemas ##
# Don't start ESD (Default=false)
gconftool-2 --type bool --set /desktop/gnome/sound/event_sounds false
gconftool-2 --type bool --set /desktop/gnome/sound/enable_esd false

## apps_nautilus_preferences.schemas ##
# Don't show hidden files (Default=false)
gconftool-2 --type bool --set /desktop/gnome/file_views/show_hidden_files false
# Don't show backup files (those marked with a ~)
gconftool-2 --type bool --set /desktop/gnome/file_views/show_backup_files false

2. Setting permission

$ chmod 755 /etc/profile.d/gnome-perf.sh

3. Restart system

$ reboot

END.

Cool Solutions

When upgrading SLES and/or OES, be sure to backup & reimplement kernel parameters

preycor — Fri, 09 Oct 2009 08:44:10 -0600

When following this knowledgebase article to upgrade your SLES or OES server, be sure to bear in mind that the upgrade will overwrite any customisation that you've done in /boot.

While initially this may not seem like a problem, bear in mind that if you're running a VM then it's likely (one would hope) that you have the "clock=pit" kernel parameter implemented.

If this is not re-implemented after the upgrade your server's time will go wild and you'll kick yourself when you realise what happened!

Yes. It happened to me. ;)

Cool Solutions

Hot Linux tips and Hacks

ankursan — Fri, 09 Oct 2009 02:25:36 -0600

To mount ext2fs filesystems under FreeBSD, you first have to build a new kernel with ext2fs support. Put the line

options “EXT2FS”

in your kernel configuration file for the new kernel and compile.
Read the FreeBSD handbook to learn how to do that.

Do the following steps to enable ext2fs support in the kernel:

# cd /usr/src/sys/modules/ext2fs
# make
# make install

You can use ‘kldload‘ to load the ext2fs module in to the kernel.

# kldload ext2fs
Then you will be able to mount your linux partitions by giving a command like:

# mount -t ext2fs /dev/ad1s1 /mnt

to unload module use

# kldunload ext2fs

To load the module automatically on system startup

add the following line in to /boot/loader.conf

ext2fs_load=”YES”

Thanks
Law of Attraction

Life Coaching

SUSE Linux Enterprise Cool Solutions

Registering and updating a SLES server through an authenticated proxy

preycor — Fri, 09 Oct 2009 01:27:48 -0600

In most corporate environments web proxies are implemented as part of an overall security requirement. When implementing a SLES server it is just as important, from a security standpoint, to keep the server patched up to date. Being able to set the server to register and update from the command line did not seem possible until I discovered the following method.

The suse_register script, which is used to perform the server registration, uses curl in order to interact with the Novell website. The first step is therefore to tell curl to use the proxy, which is done by creating the file /root/.curlrc and adding the following content. Obviously the settings in the file must correspond to the settings required in your environment.
```
proxy = "https://10.10.2.10:8080"
proxy-user = "username:password"
```
Run suse_register as normal. The registration will appear to fail. What's happening in the background is that the server is being registered, but is not able to subscribe to the software update channels.
RCD (Red Carpet Daemon) is the background process which keeps track of available updates and listens for update commands from rug. Use the following commands after registering the server in order to set RCD to go through the proxy:
```
rug set proxy-url https://10.10.2.10:8080
rug set proxy-username username
rug set proxy-password password
```
Initiate a rug refresh so that the available channels can be picked up:
```
rug ref
```
Check which channels are available.
```
rug ca
```
Subscribe to the appropriate channels, for example:
```
rug sub SLES10-SP2-Updates
```
Retrieve the available updates.
```
rug up
```

One could suggest that step 3 gets done before step 2 in order to make the process more efficient. Unfortunately this doesn't work - suse_register appears to overwrite whatever settings are already in place for RCD. It'd be great if suse_register could take options which allow this all to be done in one shot. At the time of writing this, suse_register does allow a full registration process to be completed through an unauthanticated proxy (if you configure a proxy through YaST before doing the registration), but not an authenticated proxy.

SUSE Linux Enterprise Cool Solutions

Fix for Sleep and Hibernate on a Thinkpad T61p with an nVidia FX570 Video Card

tmstone835 — Thu, 08 Oct 2009 16:42:07 -0600

Sleep and Hibernate fix for Thinkpad T61p with an NVIDIA FX570 video card

When I ordered my Thinkpad laptop I specified the best video card that they had available thinking that it would be the best choice with SLED or OpenSuSE. That turned out to be a bad idea until now.

I found out after the fact that NVIDIA drivers can be a problem in certain situations. Especially when it comes to using your laptop's sleep and hibernate functions. They seem to go to sleep just fine. The problem occurs when you try to wake them up again. Everything seems to start up but then when the system tries to load the X11 driver and switch to the desktop, it goes to a black screen and then you are stuck. The only option you have is to power-off and reboot. That is not good for your filesystem integrity even with journaling filesystems such as EXT3 or ReiserFS.

I dug through many forums, discussion threads, and sites like thinkwiki.org for a solution and found nothing that worked for my laptop. However, I have to give them all credit for helping me discover the final solution. I can't guarantee that this will work for your computer but it could help.

It all seems to revolve around which driver is trying to control the AGP features on your computer. In case you are not familiar with the term. AGP is the power management capability that is built into any modern computer. It seems that all power management has been delegated to the video system driver in Linux and Windows.

Many system boards come with integrated video controllers but when you add a different video card it complicates things. It seems like the linux distributions have a problem configuring AGP settings when there are two video adapters on a system. Laptops and desktops might come with an enhanced video card using ATI or nVideo chipsets but the integrated video on the motherboard is still there lurking in the background.

I also think that you need to match the AGP capability of the computer to that in the driver. Read the information below and you will see what I mean by that.

Step 1

Check to see which AGP driver is enabled on your system by running:

lsmod | grep agp

Mine came back with intel_agp but yours might show sis_agp or via_agp depending on your motherboard. It will also show agppart but that is OK. Make note of which agp module is installed because you will need that information in the next step.

Step 2

Edit /etc/modprobe.conf.local and add the following line:

blacklist intel_agp

Yours should look like this:

#
# please add local extensions to this file
#
blacklist intel_agp

Step 3

Now you need to look in the driver registry to see which features are enabled. Run the following:

cat /proc/driver/nvidia/registry

Look for NvAGP: 3. This number is the supported AGP state.

Step 4

You need to modify the X system configuration so it knows about your video card's AGP feature. Edit /etc/X11/xorg.conf and look for the [Device] section. Mine originally looked like this:

Section "Device"
  BoardName    "Quadro FX 570M"
  Driver       "nvidia"
  Identifier   "Device[0]"
  VendorName   "NVidia"
EndSection

Add a new entry: Option "NvAGP" "3" into this section. After I made this change mine looks like this:

Section "Device"
  BoardName    "Quadro FX 570M"
  Driver       "nvidia"
  Identifier   "Device[0]"
  VendorName   "NVidia"
  Option        "NvAGP" "3"
EndSection

It seems as if the settings are working as soon as you save the file but you should probably reboot your system before trying your new settings. I noticed that if I now check the current agp driver by running lsmod | grep agp it comes back with:

agpgart                32308  1 nvidia

Conclusion

My system now goes to sleep and wakes up properly. The hibernate feature works but, when waking up, it sits for 2 minutes at a black screen with a blinking cursor in the upper left corner. It will beep once and then after another minute it will beep again. After another minute, it will resume the system and you should see a desktop. I rarely use hibernate so this doesn't bother me. At least I know it works if I need it.

Workgroup Cool Solutions