Port 25: The Open Source Community at Microsoft : Server Center, Open Source

Virtualizing Free Linux Distributions in Windows Server 2008 R2

Peter Galli — Tue, 11 Aug 2009 00:00:00 GMT

Jason Perlow, a columnist over at ZDNet, has written a comprehensive review on virtualizing free Linux distributions in Windows Server 2008 R2.

In his Tech Broiler column, Perlow notes that the updated Hyper-V bare-metal hypervisor virtualization layer in Microsoft's upcoming Windows Server 2008 R2, which is due to be released August 14th to MSDN and Technet customers, now has support for SUSE Linux Enterprise Server 11 and Red Hat Enterprise Linux 5.3.

"Additionally, Linux support and performance has greatly improved over the initial Hyper-V release. Microsoft also recently released its Hyper-V Linux Integration Components (Linux ICs) under the GPLv2 Open Source License," Perlow says.

The Linux ICs for Hyper-V, which are in Release Candidate status, provide synthetic device drivers that enhance I/O and networking performance when Linux OSes are virtualized under Hyper-V.

"The source code for the Linux IC's were accepted into the Linux Driver Project and should become part of the Linux Kernel within two subsequent releases and code merges - 2.6.32 is expected to be when they will be integrated, and all Linux distributions using that kernel code base going forward should be Hyper-V enabled out of the box. Yes, you heard that correctly, Microsoft is now an official Linux Kernel contributor," Perlow says.

You can read the rest of Perlow's column here.

MindTouch: Open Source Collaboration Built on .NET

Aaron Fulkerson — Tue, 04 Aug 2009 18:05:00 GMT

It has been a while since I last guest wrote at Port25, which is always a pleasure.

Today, I am writing about the latest MindTouch software release, codename Minneopa, which introduces three new innovative capabilities: the ability to capture and collaboratively edit video, the easy packaging of applications built on MindTouch for distribution, and the new capability to stage content.

However, if you are new to MindTouch, allow me to introduce the product. The canned statement reads as follows:

MindTouch Inc. is changing the way businesses share information, consume content, and collaborate. The company's open source platform, MindTouch 2009, combines the ease of use of a wiki with the scalability, security and integration capabilities of an enterprise portal, connecting enterprise systems, databases, web services, and Web 2.0 apps to create collaborative networks.

The gist, however, is that MindTouch offers an easy to use platform that looks a lot like a wiki, but behaves more like a portal with rapid application development capabilities. The architecture is unique and quite innovative because MindTouch is implemented in C# on .NET (or Mono) and consists of the following components:

A decoupled PHP client that provides a wiki like interface for collaboration, document management, mashups, and for creating composite and situational applications
Composition of more than 120 ReSTful web services
A web service orchestration engine
An acess control layer
An extensible HTTP message bus

To really appreciate the capabilities of MindTouch it is best to watch a demo as we' are truly defining a new category in collaboration.

This new Minneopa release of MindTouch buoy's our efforts to help those who are building collaborative networks on MindTouch. This is especially useful for developers, IT workers and business users to package their enterprise dashboards, composite applications and mashups for distribution.

For the collaborative video capabilities, we partnered with Kaltura, the developer of the world's first open source online video platform. The integration with Kaltura gives MindTouch users the built-in ability to collaborate, edit, publish and syndicate video directly within MindTouch. End users can record video and have multiple parties edit while retaining a complete version history -- all within a MindTouch page.

Download MindTouch Core, the free and open source edition that runs on Windows Server with IIS, Linux or even with a VMware virtual image, which should run in hypervisor without issue. Or download the native Windows Server version of MindTouch 2009, which is packaged in an easy to install Microsoft Installer (MSI) and supports Windows Server 2003/2008.

With the commercial edition, MindTouch 2009, users also benefit from a rich set of desktop tools, more features and a collection of adapters to popular enterprise systems and databases.

Mindtouch: Deki, OSS and Windows

jcannon — Wed, 16 Jul 2008 23:59:00 GMT

Our community knows that open source businesses are important to Microsoft. Nothing demonstrates this better than the fact that open source was a key theme in the recent Windows Server 2008 Launch. You can read more about that here.

One of the individuals we highlighted was Steve Bjorg, Founder and CTO at Mindtouch. Mindtouch develops an open source collaboration platform. Today, I'm excited to have Robert Mason, Mindtouch Platform Engineer, update us on the progress Mindtouch has made in delivering a first class open source experience on Windows. Take it away Bob....

Short Demo Video: MindTouch Deki 8.05.2

This demo video goes through a lot of information quickly. It shows the basics of collaboration in MindTouch Deki and then demonstrates a mashup with a Microsoft Silverlight charting package. NOTE: With MindTouch Deki creating mashups, dynamic reports and dashboards does not require programming ability.

Hello! It’s great to be asked to guest blog here at Port 25. Last you had heard from us, we had written about MindTouch Deki from the start being written in C#, but running solely on Mono inside of a Linux environment. Well, that’s all about to change… I’m happy announce that for the first time, MindTouch is releasing an official Windows-based beta version of MindTouch Deki. Specifically, you may now install using a MindTouch-created Microsoft Windows MSI!

MindTouch Deki is an open source collective intelligence platform. In other words, it is an enterprise wiki that sits atop a web-services framework and enables mashups, dashboards, and dynamic reporting from disparate systems and databases. MindTouch Deki provides a unique collaboration tool for enterprises and workgroups. Rather than taking the less useful approach of other collaborative and Enterprise 2.0 applications by providing a simple walled-garden / point application, MindTouch has developed Deki with the collaborative intuition of a highly polished and robust enterprise wiki, but is also able to federate and mashup application and data silos. It was developed on Microsoft .NET using C#, and, until today, has only officially supported installations on Linux using Mono.

Although this is a beta release, the MindTouch team has worked hard to include all major features and functionality currently available to Deki users on Linux-based operating systems. Please report any problems or issues that you may discover either at our forums or by filing a bug. This new MindTouch Deki MSI beta supports IIS 7 on Microsoft Windows Server 2008 and Microsoft Vista only. However, the final release of the MSI will also support IIS 6 on Microsoft Windows Server 2003. Download the MindTouch Deki MSI today. We're very excited to at last be offering support for Microsoft IIS 6 and 7 on Vista, Windows Server 2003, and 2008. MindTouch Deki has enjoyed a groundswell of adoption with daily downloads in the thousands; by (finally) introducing an easy and officially supported means of installing on Windows Server and Windows Vista we are expecting great things! Now, Systems Integrators and .NET developers can return to their existing customer base (and find new customers) to deliver more value by "adding the 2.0" to the enterprise infrastructure in the form of a collaborative surface atop the existing infrastructure that they've already deployed.

Write MindTouch for more information about our web-oriented architecture or for a high level explanation read about our technologies at the website. Finally, expect to see more Microsoft-related updates from MindTouch in the coming months… Subscribe to our monthly eNewsletter at www.MindTouch.com to stay up to date on new Microsoft related products and offerings.

Thanks,
Bob Mason

Is High Performance Computing naturally Open Source (ie. for tinkerers)?

anandeep — Wed, 18 Jun 2008 13:17:00 GMT

I have always been fascinated by clusters. Some people envision working with desktops or workstations when they think of “working with computers”. For me working with computers was always with a large collection of computers in a back room somewhere. And how cool if you could make all those computers collaborate with each other working to solve cool things like genome mapping, movie special effects, simulations of car crashes or simulations of molecules being formed!

So you can imagine I jumped at the chance to work with the Windows High Performance Computing team. This is the same team that builds Windows HPC Server 2008.

I think most of the people working in the team are from the “large collection of computers in back room somewhere” school. Would be really different in the Mac software division I assume!

I work with the Open Source Software Lab and we are all things “Open Source” to the rest of the company. The HPC Server team wanted us to make sure that their product played nice with Linux infrastructure and vice-versa. The usual suspects like AD, Samba, LDAP. CIFS etc were involved. We had to make sure that these recurrent interoperability themes were addressed in the HPC environment. I also got a chance to dig into ROCKS, OSCAR, MPI stacks and job schedulers etc etc.

This was a very rewarding experience not only for the technology exposure that I got but the pervasiveness of knowledge of Open Source within the team. They were far ahead of the other product groups in this regard and “got” the Open Source ethos. In fact, prior to my interactions with them they had released an open source MPI stack based on Argonne National Lab’s MPI implementation.

The other reason was that a lot of their customers were relentlessly open source! The conventional wisdom is that HPC applications and infrastructure require a lot of tinkering. Of course, there are some applications like FEM and CFD and that are well understood, but the general feeling was that complete control and access to the underlying infrastructure is a must for getting the most performance out of a cluster. And performance is the main thing in “High Performance Computing”.

Linux is seen providing that access by HPC customers and there is a large base of Linux for HPC in academia, the national labs and other institutions that use large clusters for doing their thing.

But is this really true?

I think that HPC has gone through a typical evolution – it starts with a few people who have a pressing need. There is a cross disciplinary team formed that builds software to do their job and a community grows around it. The community reaches critical mass and people start making building tools to make it more convenient. ROCKS is an example of this. Great skill, knowledge and ability is needed to get the job done.

However, these skilled people now become overloaded. The tools and the infrastructure that they created become so popular that everyone, including people who do not have background that was assumed before, wants to use it for their ends. So the community responds and builds standardized, easy-to-use infrastructure pieces that start to fit seamlessly together. Some control is lost, but ease-to-use is the primary focus.

The infrastructure for HPC has reached that stage (ROLLS with ROCKS). Windows HPC Server 2008 is built for this ease-of-use too.

However, the applications have not reached the stage of ease-of-use. They have to be coded with a lot of domain knowledge and have to built from scratch to truly scale while running on clusters. That means that the application writers demand more control of the underlying infrastructure and want more access to it than the users and maintainers want.

I am going out on a limb and making a prediction here – soon end users will be able to specify instead of coding applications, be it genome comparison or physics simulation. This is similar to accountants finding spreadsheets. There will probably be a few different models for different types of applications but that stage will come pretty quickly.

The infrastructure that runs these user-specified applications will be adaptive and will take these specifications and automatically tune them for high performance on the clusters.

This is where the perception of needing control to the lowest levels will be moot. The best adaptive infrastructure will be the one adopted.

Bold enough for you?

Technical Analysis: OpenSSH on Linux using Windows/Kerberos for Authentication

jcannon — Fri, 06 Jun 2008 14:35:00 GMT

Abstract: Secure remote access to UNIX and Linux systems is generally accomplished through SSH. The most frequent implementation of that protocol is OpenSSH, originally written for the OpenBSD project but now ported to a wide variety of platforms. This paper will show how to use OpenSSH with the Kerberos portion of Active Directory to automate authentication.

Download OpenSSH on Linux using Windows/Kerberos for Authentication

Note: This paper represents testing and documentation in a lab environment. User Account Control (UAC) is an essential security component to Windows and Microsoft does not recommend turning off UAC in production environments.

Technical Analysis: VIM, PowerShell and Signed Code

jcannon — Thu, 29 May 2008 15:59:00 GMT

Abstract: In the UNIX and Linux world, vi and EMACS have long held positions as the best-developed editors for handling large amounts of code or other text. More recently, an improved vi clone has emerged named VIM (Short for Vi, IMproved). VIM features syntax highlighting, a vi-like command-line interface, and many powerful features for editing large text projects. It has quickly become one of the favorite text editors outside the Windows world. This analysis looks at using VIM with Windows PowerShell, with considerations for code signing.

Download VIM, Powershell & Signed Code.

Managing Towards Open

Sam Ramji — Tue, 29 Apr 2008 19:59:00 GMT

I have the privilege of interacting almost every day with technical and business experts who are creating the future of software—including both core engineering teams at Microsoft and thought leaders across a broad spectrum of open source communities. Especially in the last few months, I’ve been able to take more time to articulate where I think this is going – such as writing how open source has influenced Windows Server 2008 and participating in Infoworld’s roundtable on the state of open source.

I think that many people are seeing that the interrelationship between Microsoft and open source is being changed fundamentally (and for mutual benefit).

Today, Bob Muglia and Brad Anderson announced that System Center will have the ability to deliver automated management across heterogeneous IT environments, such as UNIX and Linux. What I see as a best practice for commercial and community engagement with open source technology plays a big part in this.

Specifically, Microsoft will deliver an agent infrastructure and management packs (MPs) for monitoring Linux and UNIX platforms for System Center Operations Manager 2007. Early partners like Xandros and Quest are delivering cross-platform MPs for MySQL and Apache, and Oracle, respectively. Microsoft and Novell are collaborating on the SUSE Linux Enterprise MP.

The agent infrastructure Microsoft is building to interoperate with UNIX and Linux is built leveraging industry standards and open source such as WS-Management and OpenPegasus. Pegasus is an open-source implementation of the DMTF CIM and WBEM standards coded in C++, designed to be portable, and licensed under an MIT license, and work is underway to integrate with the newly DMTF ratified WS-Management standard. Pegasus already ships as part of major Linux and UNIX distros.

It simply makes great technical and business sense to cooperate with the OpenPegasus community to build upon an industry-standards based, cross-platform technology. Just as important, however, is preserving the virtuous cycle of contribution, benefit, and subsequent contribution: Microsoft is joining the OpenPegasus Steering Committee. The agent technology—being built will be contributed back to the community under the Microsoft Public License (MS-PL), an OSI approved open source license.

I greatly appreciate Allen Brown's positive comments (Allen is the President and CEO for The Open Group) and the support and education we’ve received from the sponsors and maintainers of Pegasus. He said:

“We are pleased to have Microsoft join the OpenPegasus Steering Committee and welcome their commitment as a positive step for the global open source development community. Since The Open Group initiated the OpenPegasus project seven years ago, it has been deployed across a wide range of IT platforms worldwide. We look forward to Microsoft’s active participation in the continuing development of the project.”

Today’s announcement and the business and technical decisions made by the System Center team are a great example of the fact that commercial innovation, industry partnerships, and open source participation can all work together to make the whole greater than the sum of its parts. My enthusiasm and excitement—and my applause for the System Center team, partners like Xandros, Quest, and Novell, and the OpenPegasus community—is tempered solely by my conviction this is not the only or last example of the best of Microsoft, partners, and open source growing together. This is a great day – and there are more great days to come.

PHP on Windows

hjanssen — Tue, 04 Mar 2008 13:50:00 GMT

I have this really odd feeling of Dejavu. The last blog I wrote (here), I started by saying that I have been very delinquent with writing blogs. So what do I do? I continue to be very delinquent with my blogs!

If anything, I am consistent! :)

So, why this sudden re-emergence of myself on port25? (Besides the fact that I just realized that it has been months since I last blogged, that is) Well we have been keeping ourselves very busy in the last few months. A lot of that work relates directly to PHP, so I wanted to talk about some of these efforts.

We have significantly increased our work in this area. And my group continues to find itself at the middle of pretty much all of these efforts. The SQL Server driver for PHP is now in its second release (Get the latest bits here). And we continue to make improvements and enhancements going forward to this driver.

We have also been working very closely with the PHP community on improving PHP performance on Windows. This is an effort that will be ongoing and probably accelerating in the months to come.

With the release of Windows Server 2008, I wanted to take a moment and highlight some of the things that have been done to make Windows an excellent PHP Deployment platform.

First of all, Microsoft late last year released FastCGI for IIS6 and IIS7. IIS7 is integrated with Windows Server. IIS7 has as part of its deployment FastCGI included (not an optional download as is the case with IIS6) this in effect means that with IIS7, Microsoft has added out of the box Microsoft-supported software designed to run PHP on IIS.

Equally as interesting, we have been working with Zend to help them certify Zend Core for Windows Server 2008. I think this makes it one of the first PHP products to be certified for WS2008. Which makes Windows PHP ready :). Imagine that, PHP running on Windows Server, fully certified!

To this end we will continue to work with Zend very closely to continue to improve PHP on Windows.

Secondarily (although not directly related to Windows Server) we have also been working with Zend to provide Cardspace functionality in the Zend Framework. You can get it here, and read more about how to use it at the Zend website here. Which is another way in which Microsoft has added support to PHP for Microsoft technologies.

This continues the close relationship with Zend into the future, and I am expecting to work with them on a whole host of other PHP related efforts going forward.

As you could read in earlier blogs by Garrett Serrack we hosted the Apache Software Foundation guys here in Redmond last week. So look for a blog from me later this week on the wrap-up of that visit.

Dominic Sartorio on SpikeSource and Open Source Interoperability

Community Contributor — Wed, 27 Feb 2008 23:33:00 GMT

First, many thanks to Microsoft’s Port 25 Team for the opportunity to post today!

Today SpikeSource announced the availability of five additional PHP-based applications on the Windows Server 2008 platform. Gallery, Mantis, Moodle, PhpBB and WebCalendar are available for free download from www.spikesource.com. We welcome you to take a look and to offer your feedback!

Similar to the previous applications we released on Windows Server (Drupal, Alfresco), SpikeSource delivered these as turnkey “SpikeIgnited” applications, with all components needed to run the application available in a single one-click-install distribution. We have also included a variant of our SpikeNet update service optimized for Windows Server 2008.

“That’s great”, you might say, “SpikeSource has ‘Ignited’ a few more apps, so what’s the big deal?” We believe the big deal is that these applications also run on a stack of other Microsoft products in addition to Windows, namely, IIS/Fast-CGI and SQL Server Express, with which many open source products have historically not interoperated well. Quite a bit of engineering went into assembling this “WISP” stack and building/testing these PHP applications, and this know-how is an important step towards improving the interoperability between the worlds of Microsoft and open source.

Why do this? Because customers want it. Throughout SpikeSource’s history, nearly 50% of our customer’s request Windows versions of our open source applications, and most of them also care about interoperating with IIS, SQLServer, Sharepoint, ActiveDirectory and so forth. Our experience is representative of the industry. Ask any commercial OSS ISV with a server-side application, and they’ll tell you the same thing, with similar numbers.

Also, last December, the Open Solutions Alliance (www.opensolutionsalliance.org) published a report (pdf) summarizing the results of its customer outreach efforts. One of the key findings was that customers want better open source and Microsoft interoperability, and moreover, they felt this was the issue that the industry has collectively done the least to address. While there has been a lot of unfortunate history that has gotten in the way of this, ultimately customers don’t care as much about grudges as they care about everything simply working. Together, SpikeSource and Microsoft’s open source lab are doing something about it.

The release of these five PHP applications is just a first step. By taking five commonly used PHP applications and making them run better on a Windows stack, we took a step towards better interoperability, and we also built some technical expertise that we intend to leverage more broadly and share with the community in the future.

So, stay tuned, and we welcome your input. What other types of open source applications are important to run well on Windows? What specific technical issues do you have that you would like to see us solve? What more can we do? Please send us your feedback!

Dominic Sartorio
Sr Director, Product Management, SpikeSource
President, Open Solutions Alliance

How open source has influenced Windows Server 2008

Sam Ramji — Wed, 27 Feb 2008 12:00:00 GMT

When I think about what works really well in open source development and technology, the following things stand out:

Modular architectures
You can find these wherever you see participation at scale – and often a rearchitecture to a more modular system precedes expanded participation. Great examples of this are Firefox, OpenOffice, and X11 – from both the historical rearchitecture and the increased participation that resulted. The Apache HTTP server and APR are good examples that have been modular for as long as I can recall.
Programming language agnostic
A given project uses a consistent language, but there are no rules on what languages are in scope or out of scope. Being open to more languages means opportunity to attract more developers – the diversity of PHP/Perl/Python/Java has been a core driver in the success of a number of projects including Linux.
Feedback-driven development
The “power user” as product manager is a powerful shift in how to build and tune software – and this class of users includes developers who are not committing code back, but instead submitting CRs and defects – resulting in a product that better fits its end users.
Built-for-purpose systems
Most frequently seen in applications of Linux, the ability to build a system that has just what is needed to fulfill its role and nothing else (think of highly customizable distributions like Gentoo or BusyBox, as well as fully custom deployments).
Sysadmins who write code
The ability of a skilled system administrator to write the “last mile” code means that they can make a technology work in their particular environment efficiently and often provide good feedback to developers. This is so fundamental to Unix and Linux environments that most sysadmins are competent programmers.
Standards-based communication
Whether the standard is something from the IETF or W3C, or simply the implementation code itself, where these are used projects are more successful (think of Asterisk and IAX2) and attract a larger ecosystem of software around them.

So where did we apply these ideas to the development of Windows Server 2008?

Modular architectures was applied in multiple areas, but the one that stands out most to me is Internet Information Server 7 (IIS7). IIS7 has been rearchitected for flexibility as 40 individual modules, enable more to be written by community developers or delivered as out-of-band releases. This has already enabled performance improvements and independent evolution, and I expect to see further enhancements.
Programming language agnostic is something we’ve delivered on with support for PHP on IIS7 and the enhancements to FastCGI (which can be used by any of the P* languages). We set a goal of having PHP certified on Windows Server 2008, and we’ve achieved that. We’ll continue to improve runtime, security, and manageability support for non-.NET languages and the applications that are built on them, as well as testing the full stacks of PHP-based applications running on Windows Server, IIS, and SQL Server.
Feedback-driven development based on developer and customer trials (RDPs, TAPs, and Betas in our process) led to a range of “feature completion” developments that connected different components – like connecting Windows Firewall with Active Directory central policy, and the end-to-end improvements in SMB 2.0. Features like the RODC (Read-Only Domain Controller) have become more and more solid through experience with early alpha and beta customer deployments, and requests to enforce things like BitLocker encryption of user disks from a central authority have achieved full support.
Built-for-purpose systems such as DNS, DHCP, file and web serving can be created through wizard-driven configuration thanks to Windows Server Core. The goal of having a minimum attack surface and a small hardware footprint, inspired by the capabilities mentioned above, yet achievable by a broad base of admins has been achieved. Additionally, this has created an opportunity for Windows admins to become much more knowledgeable about the low-level structure of the operating system.
Sysadmins who write code are first-class citizens in the PowerShell-driven infrastructure. We’ve increased Windows administrators’ opportunity to master the full surface area of WMI and demonstrate that mastery in reusable, low-level scripts. As we evolve this to support multiple language bindings and bash aliasing, this should become a comfortable home for highly skilled sysadmins.
Standards-based communication such as in CardSpace (with support for X.509, SAML, Kerberos tokens, and more) and the Web Services stack (not only are all 38 Web Services standard under the Open Specification promise, but our implementations have achieved a high level of interop with Apache’s Axis web services stack), and beta support for emerging standards like Xen virtualization represent a small subset of the standards built into Windows Server 2008.

Overall, we’ve learned and continue to learn from open source development principles. These are making their way into the mindset, development practices, and ultimately into the products we bring to market.

I’ve focused here on “what Microsoft has learned from Open Source” – and ironically, I’ve agreed to do a panel at OSBC on 3/25 with Jim Zemlin of the Linux Foundation on “what Open Source can learn from Microsoft”. As all of the different organizations in IT continue to evolve, we’ll learn from each others’ best practices and make increasingly better software. As in science, this incremental improvement will move all of us forward.

Technical Analysis: Installing Apache on Windows

jcannon — Tue, 12 Feb 2008 13:21:00 GMT

Abstract: By many estimates, Apache is the world's most popular web server software, hosting more than half of active domains according to Netcraft. Typically, Apache is run on Linux or UNIX, but it runs quite well on Windows. This paper provides an introduction to running this software on Windows and provides a framework for understanding how Apache on Windows is fundamentally different from Apache on Linux.

Download Installing Apache on Windows

Note:This paper represents testing and documentation in a lab environment. User Account Control (UAC) is an essential security component to Windows and Microsoft does not recommend turning off UAC in production environments.

Technical Analysis: Installing Apache with SSL on Windows

jcannon — Fri, 04 Jan 2008 17:02:00 GMT

Abstract:
Often SSL or TLS is required to secure data from web applications. Sometimes this is just prudent to prevent confidential or sensitive data from being confiscated. Sometimes this is required by regulations like HIPAA or industry bodies, such as the Payment Card Industry. This guide will show how to install Apache with SSL on Windows.

Download Report Installing Apache on Windows

Systems Manageability Part 6: Patch Management and Online Updates

kishi — Fri, 29 Jun 2007 17:44:00 GMT

Level-Set - Patch Management: Patch Management and Maintenance focuses on those solutions available to deploy and install software update on Linux systems, with a primary focus on Novell based Linux systems. This is going to be a very short blog because the only open source tool that I could find, which is used in a widespread manner, is YaST. I know there are tons of solutions out there, some proprietary like RHN and some custom built. YaST was the only common thread we could recognize. A deeper look at YaST and its online update abilities follows:

YAST Online Update Utility

Probably the most common and important modules in YaST are those related to software management (adding and removing software) and patch management. Software and updates for a typical SUSE system are obtained from software repositories, which can be local or remote software inventories from which new software or updates may be obtained. At a deeper level, the SLES9 package management system utilizes the common rpm utility to install, remove, and update packages and manage the package and dependency database. Although this subsystem is similar to RedHat’s, Novell has chosen a very different approach to distributing its patches, choosing to utilize what are called patch RPMs. With many RPM-based distributions, when a package needs to be updated for one reason or another the distributor will modify or patch the original source tree and recompile/repackage the software to produce a new RPM for that particular package. Therefore in these cases the new RPM will simply be an updated version of the original RPM.

Novell has taken a slightly different approach with patching via RPMs. Instead of updating and repacking the entire package, Novell updates the original source tree, recompiles, and then produces a delta (or a diff) between the original binaries in the package and the newly patched/recompiled binaries. The delta is a binary file that contains information about the differences between two binary files. The deltas will then be packaged within an RPM and distributed to clients. The patch RPM can then be manually or automatically installed in the same way a standard RPM would be installed. An advantage to this technique is that patches are often smaller in size – typically anywhere between 5KB and 8MB depending on the size of the package and the changes being applied. This often allows the update process to progress far faster than it would otherwise when using full RPMs – especially for large applications.

Major updates to the stable SLES9 branch are released as an installable “service pack”. Novell typically recommends installing the service pack files via YaST2, from either a CDROM or network location that contains the service pack files. One may also simply utilize the Online Update module of YaST2 to update the system manually or automatically. In this case, the service pack will be distributed as a large number of individual packages, similar to how RedHat distributes major updates (i.e. RHEL4 U4). Aside from a log file, SLES9 does not currently have an email mechanism to inform the administrator when a patch is automatically downloaded and installed (as RedHat does). However, a log file that contains information about each automatic update is maintained in /var/lib/YaST2/you/youlog. This log is generally very easy for an administrator to read and discover when, or if, a patch RPM was downloaded and installed.

There are other ways to find information about installed patches, however. By default, SLES9 archives each patch RPM that is downloaded and installed. Full RPMs will also be archived if they were installed via YaST2 after the original system installation. This functionality can be disabled with YaST2, of course, although it can sometimes be useful to maintain the archive if a patch ever needs to be reinstalled.

1. YaST Software/Update Repositories

Software repositories are typically added manually via the Installation Source module in YaST or can be scanned using SLP (Service Location Protocol). From this module, one may add references to locations from which to receive updates. These references typically take the form of a URI or a directory path. YaST supports the following software repository references:
FTPHTTP(S)
SMB/CIFS
NFS
CD or DVD
Local Directory
Using this methodology it is also quite common for an administrator to install a centralized repository for software and updates. Updates may then be obtained from Novell by a single server, and other servers on the LAN may then pull patches from the central patch server using one of the above protocols.

2. YaST Security

Although software repositories for SLES and SLED distributions are typically operated by Novell, it is quite possible to add third-party repositories to obtain software not offered by Novell, or even different versions of the same software packages. Novell warns against this, however, since adding repositories not controlled by Novell can result in the installation of untested or possibly malicious software, which ultimately could compromise security, but more likely may result in software instability and RPM package conflicts.
All official software and patches obtained by Novell are cryptographically signed, which can be verified with Novell’s public key. The public keys used to verify these signatures are typically obtained via the official SLES/SLED CDs or DVDs, but may also be obtained via Novell’s website. Once these public keys are accepted and imported, any software package or update obtained with an invalid signature will produce a warning and may not install without user intervention.

3. YaST Automatic Updates

Automatic updates can be configured via YaST’s Online Update Setup module, which allows a user to schedule updates to occur at a particular time either daily or weekly. On the backend, this module simply installs a new cron entry, a task scheduling application, which periodically runs another program to check for and install updates pushed out by Novell.
In earlier SUSE-based systems, YOU (YaST Online Update) had been used to automate the installation of updates packages. The cron utility would execute a shell script called /usr/bin/online_update which would automate the patch installation process. Newer versions of SUSE, including SLED10, utilize a similar process but instead of a shell script a utility called rug is used. The rug utility is the command-line interface to the ZENworks management agent that is present on new SUSE systems.

If you are running any open source based tools or applications in your environment to push patches and manage online update scenarios, we would REALLY like to hear what you have to say. As always THANK YOU for tuning into Port25

Systems Manageability Part Five: Monitoring

kishi — Thu, 21 Jun 2007 14:16:00 GMT

Background: This is Part 5, continuation of the series of 8 blogs I’m doing on Systems Manageability. In this specific blog, I will focus on and explain the third part of the “ontology” which is “Monitoring”

Level-Set – Monitoring: Monitoring and other data collection tools are an essential component of any management strategy. The proper collection and organization of host data allows for manual and sometimes automated reactive corrective measures. This section outlines many of the open source and free software monitoring tools available on the Linux platform. Much of the analysis in this section is focused on the inner workings of these tools as data collection systems, rather than feature comparisons between the various monitoring applications. The WBEM/CIM overview has been placed in this section due to its basis as a data collection and management system, even though its use is not limited the confines of this category.

I.WBEM/CIM: The following section includes an overview of the WBEM initiative and the open-source CIM implementations that exist today. The Distributed Management Task Force (DMTF) classifies WBEM (Web Based Enterprise Management) as the following:

“[WBEM is] a set of management and Internet standard technologies developed to unify the management of distributed computing environments. WBEM provides the ability for the industry to deliver a well-integrated set of standard-based management tools, facilitating the exchange of data across otherwise disparate technologies and platforms.”

Core components and industry standards used in WBEM include CIM, CIM-XML, CIM Query Language, SLP (Service LocationProtocol, for WBEM Discovery) and WBEM URI (Universal Resource Identifier) mapping. The DMTF has also developed a WBEM Management profile template for the purpose of systems manageability. WBEM has been designed to be compatible with all the major existing management protocols, including SNMP, DMI, and CMIP. There are several open source implementations of WBEM including OpenWBEM, WBEM Services, OpenPegasus and SBLIM. These are discussed in more detail below. Additionally, there are both client and server implementations available for the WBEM standard:

WBEM clients include PyWBEM, an open-source WBEM library written in Python, and the Purgos open-source management client for Windows written in C++.
WBEM server implementations include OpenPegasus and OpenWBEM, an open-source client and server written in C++ (Novell has adopted this and added it to SLES9/10).

The following is an explanation of CIM, or Common Information Model, from the DMTF documentation:

“provides a common definition of management information for systems, networks, applications and services, and allows for vendor extensions. CIM’s common definitions enable vendors to exchange semantically rich management information between systems throughout the network. It is a conceptual information model for describing management that is not bound to a particular implementation. This allows for the interchange of management information between management systems and applications. This can be either "agent to manager" or "manager to manager" communications that provides for Distributed System Management.”

CIM includes two components; a specification and a Schema.

CIM Specification: This describes the language, naming, Meta Schema and mapping techniques to other management models such as SNMP MIBs, and DMTF MIFs etc. The Meta Schema is a formal definition of the model. It defines the terms used to express the model and their usage and semantics. The elements of the Meta Schema are Classes, Properties, and Methods. The Meta Schema also supports Indications and Associations as types of Classes and References as types of Properties. Essentially, the CIM specification
CIM Schema: This provides the actual model descriptions. The CIM Schema supplies a set of classes with properties and associations that provide a well-understood conceptual framework within which it is possible to organize the available information about the managed environment. The CIM Schema itself is structured into three distinct layers:

The Core Schema is an information model that captures notions that are applicable to all areas of management.
Common Schemas are information models that capture notions that are common to particular management areas, but independent of a particular technology or implementation. The common areas are systems, devices, networks, applications, metrics, databases, the physical environment, event definition and handling, management of a CIM infrastructure (the Interoperability Model), users and security, policy and trouble ticketing/ knowledge exchange (the Support Model). These models define classes addressing each of the management areas in a vendor-neutral manner.
Extension Schemas represent organizational or vendor-specific extensions of the Common Schema. These schemas can be specific to environments, such as operating systems (for example, UNIX® or Microsoft Windows®). Extension Schema fall into two categories, Technology-Specific areas such UNIX98 or Product-Specific areas that are unique to a particular product such as Windows.

WBEM (CIM) Architecture Diagram

OpenPegasus:

OpenPegasus is an open-source implementation of the DMTF CIM and WBEM standards being driven under the auspices of The Open Group. OpenPegasus is open source and is licensed under the MIT open-source license. The distribution is available via CVS, and as snapshot images in tar, zip, and (self-extracting) exe file formats on the OpenPegasus web site. Based on documentation posted on the site, simply put, Pegasus is an open-source CIM Server for DMTF CIM objects. It is written in C++ and includes the Object manager (CIMOM), a set of defined interfaces, an implementation of the CIM Operations over HTTP operations and their cimxml HTTP encodings, and Interface libraries for both clients and providers. It is maintained to be compliant with the DMTF CIM and WBEM specifications with exceptions noted in the documentation. It is designed to be portable and modular. It is coded in C++ and translates the object concepts of the CIM objects into a programming model. Pegasus is designed to be inherently portable and builds and runs today on most versions of UNIX(R), Linux, and Windows. OpenPegasus includes the following components:

A DMTF compliant CIM Server that processes CIM operations, CIM Indications, and includes class and instance repositories and interfaces for creating CIM Providers and CIM Clients.
Provider interfaces so that providers may be build in multiple languages (i.e. C++, C, Java).
A number of CIM Providers.
A MOF compiler.
A number of CIM Clients to provide usage examples, CIM Server test functions, and administrative functions

OpenWBEM On SLES10:

OpenWBEM is included in SUSE Linux Enterprise Server 9 and 10, allowing any WBEM enabled management console to access configuration information on the system. A CIM schema and a MOF compiler are also included as packages in SLES9 and 10, which can be used to create and import the schema.

## Create the namespace called /root/cimv2

SLES10:/etc/openwbem # owcreatenamespace -n /root/cimv2
Creating namespace (/root/cimv2)
## Import the CIM schema.
SLES10:/etc/openwbem # owmofc /usr/share/mof/cimv2.12/cimv212.mof
[ ... Lots of Output ... ]
Compilation finished. 0 errors occurred.
Compiling and Importing the CIM Schema

## Start the OpenWBEM Daemon.
SLES10:~ # /etc/init.d/owcimomd start
Using common server certificate /etc/ssl/servercerts/servercert.pem
Starting the OpenWBEM CIMOM Daemon done
## Check the status of the OpenWBEM service.
SLES10:~ # /etc/init.d/owcimomd status
Checking for service OpenWBEM CIMOM Daemon running
Starting the OpenWBEM Service on SLES10

II. NAGIOS: Nagios is a system monitoring application designed to monitor remote hosts and applications over a network. The application provides a web-based graphical display that allows one to view the status of nodes and particular applications running on the nodes. The following is an excerpt from the Nagios documentation listing some of Nagios’ feature set: Some of the many features of Nagios include:

Monitoring of network services (SMTP, POP3, HTTP, NNTP, PING, etc.)
Monitoring of host resources (processor load, disk usage, etc.)
Simple plugin design that allows users to easily develop their own service checks
Parallelized service checks
Ability to define network host hierarchy using "parent" hosts, allowing detection of and distinction between hosts that are down and those that are unreachable
Contact notifications when service or host problems occur and get resolved (via email, pager, or user-defined method)
Ability to define event handlers to be run during service or host events for proactive problem resolution
Automatic log file rotation
Support for implementing redundant monitoring hosts
Optional web interface for viewing current network status, notification and problem history, log file, etc.

Nagios can poll servers and obtain data in a number of different ways. The most straight-forward method is to connect to a remote system directly and test to see if the host is available or if a particular service is running. Data internal to the host, such as free memory or processor usage, however, must be gathered using the Nagios agent, SNMP, another custom script or program or a Nagios plug-in called check_by_ssh - which is a standard plug-in designed to run a command on a remote machine and collect the output. The configuration of Nagios is done entirely via text-based configuration files. Hosts and other resources are defined inblocks, which can also inherit information from other pre-defined blocks, making complex configurations possible and more manageable. There are several third-party applications available that provide a web or other GUI interface to assist one with configuring Nagios, but these were not tested for this project. The following configuration block defines a generic host template called “linux-server”. Many of the configuration values such as “24x7” and “workhours” are actually defined in other configuration blocks within the Nagios configuration. This allows administrators to define custom names to a specific time period, such as “workhours”, and use that definition in other parts of the configuration.

define host {

   name                       linux-server
   use                        generic-host
   check_period               24x7
   max_check_attempts         10
   check_command              check-host-alive
   notification_period        workhours
   notification_interval      120
   notification_options       d,u,r
   contact_groups             admins
   register                   0
}
Nagios Host Definition Template

Individual hosts are defined in configuration blocks. Below is a sample configuration for an individual host called management. Notice the use statement is inheriting other definitions from the previously defined generic template mentioned above called “linux-server”.

define host {
   use            linux-server ;Name of host template to use.
   host_name      management
   alias          Management Server
   address        10.197.173.100
}

Finally, hosts may be organized into logical groups for easier management. The following is a hostgroup that defines a group that includes five hosts.

define hostgroup {
   hostgroup_name test
   alias          Test Servers
   members        localhost,management,www,rhel4-production2,network
}

Nagios is distributed with a wide assortment of plug-ins that can be used to obtain data or check a particular service. Plug-ins are distributed as a separate package which must be installed with both the server and the agent if an agent is to be used. The Nagios plug-ins are simply stand-alone executable programs, each of which can perform a particular task and return a result code for each service or subsystem being tested. Since plug-ins are individual scripts or binary programs, they often will accept different arguments to change their behavior and what information they return. The command usage of each plug-in must be defined individually within the configuration files using the define command syntax. Some plug-ins can accept multiple options which can be customized when writing the configuration for a particular system. The define command definition provides a sort of usage template so that Nagios will know how to run the command later. Luckily for new users, the default sample configuration files already provide accurate definitions for the default plug-ins. Once one is familiar with how commands are defined, however, new commands or custom scripts can also be defined here as well.

NRPE: is the Nagios Remote Plugin Executor that is installed on a remote host. It is designed simply to execute Nagios plugins on behalf of the Nagios server and return the results. The same plugins that are installed on the server must then be installed on the remote host for NRPE to utilize. A new plug-in called check_nrpe is also distributed with the NRPE agent and is used to query the NRPE daemon from the Nagios server. NRPE utilizes a rudimentary access control system to assure that only particular Nagios hosts will be allowed to contact the NRPE client. A configuration directive such as the following within NRPE’s configuration file will only allow communication with a particular host:

allows_hosts=10.197.173.100

It is possible to configure NRPE run nearly any command with any arguments, although one is warned against doing this in the documentation. By default, NRPE will only run specific commands and their arguments as specified in its own configuration file (located on the host itself). Meaning that the Nagios server can tell NRPE to execute only specific commands specified in the remote host’s /etc/nrpe.cfg file, but the server may not pass arbitrary commands or plug-in arguments for the agent to execute. Below is a sample NRPE configuration. The specific commands (plug-ins) and arguments must be specified here. The Nagios server can then request NRPE to execute one or more of these commands and return the results:

command[check_users]=/usr/local/nagios/libexec/check_users –w 5 –c 10
command[check_load]=/usr/local/nagios/libexec/check_load –w 15,10,5 –c 30,25,20
command[check_disk_root]=/usr/local/nagios/libexec/check_disk –w 20 –c 10 –p /dev/sda1
command[check_zombie_procs]=/usr/local/nagios/libexec/check_procs –w 5 –c 10 –s Z
command[check_total_procs]=/usr/local/nagios/libexec/check_procs –w 150 –c 200

By default NRPE utilizes SSL communications between itself and the Nagios server. The SSL parameters are generated at compile time and stored in the C header file called dh.h within the NRPE source tree. This header file is then used to compile the NRPE daemon and the check_nrpe plugin. This means that both the NRPE daemon and the check_nrpe plugin must be compiled using the same parameters (typically from the same source tree) if one wishes to utilize SSL communications.

III. Hyperic: Hyperic HQ is a Java-based monitoring application consisting of a central monitoring server and one or more remote agents to report node status information to the server. Hyperic HQ is supported on a wide array of platforms, including Linux, Solaris, Windows, HP-UX, AIX, Mac OS X and FreeBSD. Hyperic distributes two versions of its software;

An open source version licensed under the GNU GPL
and a commercial version called HQ Enterprise which includes additional components and functionality.

HQ Open Source and HQ Enterprise Feature Set Comparison
Note: As of HQ 3.0 thefeature-set distribution between the Open-Source and Enterprise versions has changed. Please see http://www.hyperic.com/products/hq_for_ent.html for more details.

Hyperic Installation and Configuration: Hyperic HQ aims to be quick to install and relatively easy to configure. The installation is performed via the command-line, and will prompt the administrator for all the information (administrator password, database information, etc) it will need to successfully run. Upgrading can also be done relatively easily by simply running the installer with the –upgrade option. Hyperic HQ provides a web interface to deliver monitoring alerts and status information to the end-user. However, unlike other monitoring applications the web-interface is also used as the primary configuration interface for the application. All node and agent details, metric options and alerts may be configured directly over the web interface. The monitoring agent is installed in a similar manner as the server. Because all agent configuration is done via the web interface on the server, the only information the agent installation script needs is login information for the server, the preferred path on the node to which it should install the agent files and various other pieces of information such as the port numbers on which the server and agent will be running. Once the agent successfully registers itself with the server, the administrator can then log in to the web interface and import the new system into its list of monitored hosts. The Hyperic HQ server utilizes the open-source PostgreSQL database application to store configuration and monitoring data. PostgreSQL comes prepackaged with the Hyperic HQ software, and can be installed and configured automatically by the installation system. One may also choose to use an existing PostgreSQL or Oracle database server if one exists. The installation system would then prompt the administrator for information about the database so that Hyperic HQ may log in and store its data. By default, Hyperic HQ stores its authentication information within this database as well, but may also be configured to utilize and external LDAP server if one is available.

Auto-Discovery: A unique feature of the Hyperic HQ monitoring solution is its ability to automatically locate and monitor services and daemons running on the remote node. Once the agent is installed on the remote node it can then scan for a variety of known services and add it to the hosts inventory. Once added to the inventory, metrics and alerts can be configured to monitor that particular service. Hyperic HQ supports two scanning options, auto-scan and file-scan. Agents run an auto-scan periodically by default which scans the process list for known server types. A more comprehensive scan called a file-scan can actually search through the file system on the remote node and locate known applications. Because it requires more time to run and is more resource intensive, this type of scan must be scheduled and configured manually by the administrator.

Alerts and Notifications: Hyperic HQ supports the configuration of alerts based on any metric for any particular resource (such as the host itself) or service running on the host. For example, an alert can be triggered when the Availability metric for a host falls changes at all, or falls below a predefined value. When an alert is triggered an email can be sent to a predefined email address. Depending on the priority of the alert, a message will also be posted to the Dashboard, the Hyperic HQ administration front page. The HQ Open Source version lacks many of the more advanced notification options that are available in the Enterprise version. HQ Enterprise also supports the concept of Recovery Alerts, which are alerts that can be configured to cancel and reset triggered alerts. When an alert is triggered in the Open Source version, the alert will continue to be triggered until the problem is fixed or the alert is disabled. Recovery Alerts allow an administrator to automate the process of disabling an active alert, and then re-enabling the alert when the problem is corrected. HQ Enterprise also supports the option of sending SNMP traps as a notification option.

Hyperic HQ Plugins: Hyperic HQ plugins are distributed as .jar or .xml files that are deployed on the server and the agent. Plugins can be developed to enhance the collection of metrics from certain applications or services, locate and inventory new services and control actions to control specific resources. The Hyperic website provides comprehensive documentation on plugin development. Developing and adding a new plugin tends to be a more complex process compared to Nagios or other monitoring applications. The framework provided by Hyperic HQ, however, provides advanced APIs from which the plugins can query information on multiple platforms. On Windows, for example, Hyperic HQ includes classes which a plugin may use to access Windows specific data and functions. These functions can provide access to performance information, registry data, event log information and the Service Control Manager (SCM). Hyperic HQ also provides support for simple script-based plugins to gather particular metrics. Even individual scripts or Nagios plugins may be imported and configured for use by the Hyperic HQ server and agents.

SIGAR – System Information Gatherer And Reporter: SIGAR is the primary data collection component of the Hyperic HQ agent. The software is designed to collect system and process information from a number of platforms - including Linux, Windows, Solaris, AIX, HP-UX, FreeBSD and Mac OSX. SIGAR is written in C, but Hyperic provides C, C#, Java and Perl APIs which one may use to to integrate SIGAR into their applications. The SIGAR component is licensed under the GNU GPL, and is distributed separately from the Hyperic monitoring agent for potential use in third-party applications. The Sigar API provides a portable interface for gathering system information such as:

System memory, swap, cpu, load average, uptime, logins
Per-process memory, cpu, credential info, state, arguments, environment, open files
File system detection and metrics
Network interface detection, configuration info and metrics
Network route and connection tables

user@linux:~/hyperic-sigar-1.3.0.0> java -jar sigar-bin/lib/sigar.jar
Loaded rc file: /home/user/hyperic-sigar-1.3.0.0/sigar-bin/lib/.sigar_shellrc
sigar> help
Available commands:
        alias          - Create alias command
        cpuinfo        - Display cpu information
        df             - Report filesystem disk space usage
        du             - Display usage for a directory recursively
        free           - Display information about free and used memory
        get            - Get system properties
        help           - Gives help on shell commands
        ifconfig       - Network interface information
        iostat         - Report filesystem disk i/o
        kill           - Send signal to a process
        mps            - Show multi process status
        netinfo        - Display network info
        netstat        - Display network connections
        pargs          - Show process command line arguments
        penv           - Show process environment
        pfile          - Display process file info
        pinfo          - Display all process info
        pmodules       - Display process module info
        ps             - Show process status
        ptql           - Run process table query
        quit           - Terminate the shell
        route          - Kernel IP routing table
        set            - Set system properties
        sleep          - Delay execution for the a number of seconds
        source         - Read a file, executing the contents
        sysinfo        - Display system information
        test           - Run sigar tests
        time           - Time command
        ulimit         - Display system resource limits
        uptime         - Display how long the system has been running
        version        - Display sigar and system version info
        who            - Show who is logged on
sigar>
Example SIGAR usage from the command-line.

And that does it for the “Monitoring” section. There are so many other tools we got a chance to play with like Monit, Argus, OProfile etc. but am running out of space …… As always, please let us know if you found the above mentioned useful and any comments/feedback you may have. Thank you for tuning into Port25.

PXE Dust: The magic of CD-less installs...

MichaelF — Fri, 01 Sep 2006 21:19:00 GMT

(Special thanks to Dan Simonton & Kyle Adams for the testing and writing of this tech tip)

Have you ever stood in front of a server you are building, feeding it install cds, and thought to yourself “it just doesn’t get any better than this…?”

Me neither.

But look at the bright side: That growing collection of CDRS that are now spilling over the top of the spindle will make an excellent conversation piece when you have guests in your facility. It also makes for an interesting makeshift “jenga” type game. Ok, maybe not. The point is, there are alternatives.

After a growing frustration with having to burn new install discs every time one got a scratch in the wrong place, misplaced, or needing them while they were currently in use, some of the other penguins and I said, “STOP THE INSANITY!!”, and then endeavored to build ourselves a PXE boot server for our lab so we could install our machines on the fly. We anticipate this being a major time saver in the future.

If you live in an IT cave or for some other reason are unfamiliar with PXE boot systems, the acronym itself stands for “Preboot Execution Environment”. It is a boot option that is built into the firmware of the bios on most modern network interface cards. Essentially it is a coupling of dhcp(bootp) and tftp. Basically, a dhcp request is sent out from the client machine, it receives an ip address and a file with instructions to complete the transaction. From here, the install process is initiated. That’s the short version. If you want the long version, look here: http://www.pix.net/software/pxeboot/archive/pxespec.pdf

We set ours up on a machine with a dhcp server, tftp server, and an apache web server. It is possible to setup the PXE system, adding it to the configuration of an existing, authoritative dhcp server, but for the sake of simplicity, we kept ours on a separate machine running RHEL4 AS. If an authoritative DHCP server already exists on the network, it is important that the following option be applied to it’s configuration under the subnet specification:

ignore bootp;

This ensures it will not attempt to answer requests by the PXE client. Otherwise, any PXE installation you attempt may not make it very far.

On the PXE dhcp server, you will want to setup with the following options

not authoritative;

allow bootp;

subnet 192.168.1.0 netmask 255.255.255.0 {

range dynamic-bootp 192.168.0.200 192.168.0.254;

max-lease-time 3600;

default-lease-time 3600;

option routers 192.168.1.1;

option subnetmask 255.255.255.0;

filename "pxelinux.0";

}

We kept the lease time at 1 hour. Once the install is complete (which should only take a third of that time), it won’t need it anymore, so we figured this was sufficient. It is important to note the “not authoritative” option at the top, as this will prevent unintended machines from leasing non-routable ip addresses from the machine.

We then mounted the FC5 iso images on a loopback and copied all of the files over to a directory we created called FC5, under /tftpboot.

mkdir /tmp/FC5

mount –o loop FC-5-i386-disc1.iso /tmp/FC5

cp –r /tmp/FC5/* /tftpboot/FC5

We repeated this process for disc 2-5.

In our /etc/httpd/conf/httpd.conf file, we’ve added the following directory options.

<Directory /tftpboot/FC5>

Options Indexes

AllowOverride None

</Directory>

Alias /linux /tftpboot/FC5

As the directory specification “FC5” might suggest, we’re using this to install Fedora Core 5 from the PXE server. This specification within the httpd.conf gives Anaconda access to the necessary files to install FC5 via http.

It’s worthy of mention that you can choose to do this for as many operating systems as you wish to install. We primarily run RHEL4 and Fedora Core 5 systems for the sake of uniformity, so we’ll use RHEL4 in this example. Next we copied initrd.img and vmlinuz files from both /tftpboot/FC5/isolinux and /tftpboot/RHEL4/isolinux into the upper /tftpboot directory and renamed them according to distribution (rhel4-initrd.img and rhel4-vmlinuz for example).

Next we have to setup the tftp server. If the file does not exist under /etc/xinetd.d, it will need to be created (but most likely, it’s already there). It should have the following options specified:

service tftp

{

socket_type = dgram

protocol = udp

wait = yes

user = root

server = /usr/sbin/in.tftpd

server_args = -s /tftpboot

disable = no

per_source = 11

cps = 100 2

flags = IPv4

}

Next, create the directory /tftpboot/pxelinux.cfg and make it world-readable. Inside this directory, we need to create eight zero-byte files which represent 192.168.0.254 (use the “touch” command).

touch C
touch C0
touch C0A
touch C0A8
touch C0A80
touch C0A800
touch C0A800F
touch C0A800FE

and lastly, a 9^th file for the MAC address, with 01 pre-pended to the beginning

touch 01-AA-BB-CC-DD-EE-FF

The AA-BB-CC-DD-EE-FF portion of course, replaced with the actual mac address of the interface you will be using. If you do not have this information, it can be obtained via:

$ ifconfig

eth0 Link encap:Ethernet HWaddr

00:C0:A8:8D:D0:D0 ß ß ß

inet addr:192.168.1.1 Bcast:157.55.215.255 Mask:255.255.248.0

Next we create a file called “default” with the following added to it:

prompt 1

default linux-fc5 ks=http://10.197.173.80/FC5/ks.cfg

timeout 100

label linux-fc5

kernel vmlinuz-fc5

append initrd=initrd-fc5.img ramdisk_size=9216 noapic acpi=off

label linux-rhel4

kernel vmlinuz-rhel4

append initrd=initrd-rhel4.img ramdisk_size=9216 noacpi acpi=off

The options are pretty much the same as you would see in a grub configuration. You can add kickstart file options here if you wish, as noted above. With this configuration, once we reach the PXE linux boot prompt, we can specify either the linux-fc5 or linux-rhel4 to begin the install. If you wish to use a kickstart file, simply specify the location next to the kernel option. As you can see, in our example, it is being taken from an http connection on a different machine. One final step, copy /usr/syslinux/pxelinux.0 into your /tftpboot directory and you should be ready to go.

The final step in the process would be to actually perform an install. On the machine intended for this, go into your bios and place PXE/Network boot in the order before harddrive (if there is an OS present on the machine already). Alternatively, if there is a key-press option (such as f12) on post, you could do that as well. You should see the dhcp client address request progress on screen. Once the address has been obtained, you will see the files specified under /tftpboot/pxelinux.cfg directory load and will get a “boot:” prompt. At this point, specify the label of the kernel you wish to boot (these were defined in your /tftpboot/pxelinux.cfg/default file). The install process should now begin.

That’s all there is to it.