• You know we love the watches from Tokyoflash. The new rogue design keeps us drooling.
• That’s not a walking spider… it’s a baby AT-AT!
• Gizmodo has an interesting piece on the birth of the OLPC
• I remember getting one of the space ice cream packets to sample in grade school. I might wonder if they’ve made improvements, but then I read this article on space cuisine from Discover magazine. So that’s a ‘no,’ then?
• In more little green laptop news, Amazon will soon be selling the OLPC.

oVirt allows administrators to visualize what’s going on with their servers–whether they’re down the hall or entirely virtual. In addition to status checks, the tool allows easy management of virtualized space and computing resources. Listen as Hugh Brock and Perry Myers–both members of the engineering team that developed oVirt–discuss how it can help simplify IT organizations and reduce cost. Follow along as they demonstrate deploying and assigning hardware through oVirt’s graphical interface.

More information

• The official welcome announcement from Red Hat Press.
• The oVirt project home page.

# chkconfig --add rhnsd
# chkconfig rhnsd on
# service rhnsd start

Red Hat has been working on the technologies behind MRG for quite some time–each of the components in MRG has had years of development. For example, Red Hat has been working on realtime technologies in the upstream kernel community for over seven years. Messaging has had a
similarly lengthy development history. Condor, the technology behind our grid scheduler, started development in the 1980’s!

We started work on these technologies because we saw the need for these capabilities, even if we didn’t know when or how we were going to bring
these technologies to market yet. For example, messaging is at the heart of enterprise computing. We had needs for messaging infrastructure at Red Hat–for building out our own capabilities around things like virtualization management. Many of Red Hat’s customers were asking us to provide an open source messaging offering. So, we started working on the AMQP specification and our messaging implementation, even though we didn’t know it was going to end up in something called “Red Hat Enterprise MRG”.

As we started working with customers and the community around the various technologies in MRG, it became apparent to us that the technologies had reached a point of maturity where we could support our most demanding customers with them. Also, we saw significant opportunities for building out fundamentally new capabilities by integrating messaging, realtime, and grid into one platform. And so, MRG was born.

We released MRG v1 at the Red Hat Summit on June 19, 2008. MRG v1 offers support for messaging and realtime, and grid is in Technology Preview. We’ll release a 1.1 update to MRG that will bring grid into full support as well.

JP Morgan Chase, like other investment banks, uses messaging for everything from executing stock trades to providing feeds of market data
to internal data distribution.

Realtime provides deterministic performance. The US Navy is deploying realtime in its DDG 1000 naval destroyers. Realtime is critical in this
environment, because the ships’ computers have to respond precisely without ever pausing, freezing, or getting out of sync with other
events. Otherwise, the results could be disastrous.

One of our large manufacturing customers has been working with Red Hat to build an on-demand grid in Amazon’s EC2 cloud environment for the times it needs access to a grid for calculations. Because this customer isn’t able to utilize fully a dedicated grid, having the option to deploy a grid in the cloud provides them significant cost savings and flexibility.

There isn’t an ideal customer–ultimately, we think that almost any customer will benefit from MRG. MRG provides a new platform and solution for many of the most pressing problems that enterprises face today. We have significant customer interest from many industries.

Having said that, many of our largest customers are MRG early adopters, such as investment banks like JP Morgan Chase, telco companies like
Alcatel Lucent, and multiple agencies in the US Government. We are also working across oil&gas, animation studios, Internet, shipping, stock exchanges, defense, travel, and so on.

MRG takes special advantage of and is highly optimized for Linux to deliver its performance. Additionally, at Red Hat, we have been driving
changes into Linux itself in order to benefit things like messaging performance. So, the fact that we are focusing on just one platform and optimizing both that platform and our implementation on that platform gives us tremendous gains (Note: everything we do is open source and contributed back to the community).

For example, we have written a new high performance journal for durable or persistent messaging that is highly tailored to Linux’s I/O model.
By using this journal, MRG Messaging can achieve throughputs up to about 500,000 durable messages/second/LUN. This rate is about 100 times
faster than other messaging solutions. For more details, you can read Carl Trieloff’s entry in the Red Hat Press blog.

Yes. For example, we support messaging clients across a wide variety of platforms and languages, from Linux to Solaris to Windows, and from C++ to Java/JMS to scription languages like Python. On the grid side, we’ll support scheduling to both Linux and Windows. And, of course, since we integrate with virtualization, this gives us a lot of flexibility in running on other operating systems.

We definitely see a lot of interest in cloud computing from customers. MRG integrates with cloud providers like Amazon EC2 so that you can dynamically provision and add capacity in the cloud from your grid scheduler. This means, for example, that you could have a scenario where you fully utilize your local data center but have additional work you want to compute.

MRG can automatically provision, say, 1000 extra servers for you at EC2, send your work over, get your results back, and tear down the servers when you’re done–all automatically. Some of our other customers are looking at provisioning most or all of their capacity in the cloud because they won’t utilize a data center fully and want to save on capital expenses.

In either case, one of the powerful features of MRG is that it can blend local capacity with cloud capacity. This means you don’t get locked into one cloud provider, and you can grow your infrastructure dynamically in the cloud or in your local data center.

One of the significant things about AMQP is that it is the first protocol standard for business messaging. All other standards, like JMS, aren’t comprehensive enough and don’t specify down to the wire level to provide true interoperability and an open ecosystem. So, I’m not concerned about competing standards–there aren’t really any right now. That’s why there is so much interest in AMQP.

I think that most big businesses will understand and appreciate what AMQP has to offer. Notably, many of the big businesses driving AMQP are not vendors but users. Eventually, if you want to work with these users, you’re going to have to adopt AMQP.

MRG is important to all of our offerings–it’s pretty strategic and central to many of the things that Red Hat is doing. MRG adds realtime capabilities to Red Hat Enterprise Linux and enables you to provide flexible scalability and performance for applications running on Red Hat Enterprise Linux. We’re working with Red Hat Network so that you can provision and manage MRG with our standard management tools. MRG Realtime and a realtime JVM from IBM or Sun can provide deterministic performance for JBoss Java applications. We’re working with the JBoss team to support MRG Messaging as a messaging transport for the JBoss ESB. And, many of our core products and technologies are using MRG technology. IPA and oVirt, for example, are both leveraging our messaging capabilities for distributing data.

More information

• Read more about MRG at the Red Hat Press blog.
• See the official MRG announcement.
• The official MRG pages on redhat.com.

The title alone is a mouthful, but you have to love a book that knows what it’s about.

‘Unix and Linux Systems Administration’. We all know what that is. Balding, bearded, bespectacled wizards wearing t-shirts, nestled deep in a corporate office, on a floor the CEO and VP’s never visit, tapping out incantations day and night, feeding the temperamental beasts caged in the data center.

No? What about a growing group of dedicated, professional, hard-working experts who keep servers–and consequently the rest of the business–running smoothly? Sure, some of them may have less than a full head of hair, or wear the occasional t-shirt to work, but if your job (which you only call ‘System Administrator’ on your resume) involves monitoring and maintaining expensive hardware that performs critical business functions, and if the CEO only notices you or your group when things have going horribly, horribly wrong… then this is the book for you.

Back up a bit. How did ‘Python’ sneak into the title? This is a book for System Administrators–I mean, sysadmins. These guys write bash scripts to do their laundry. Sure, some of them may have joined the cult of Perl, and what proper Linux shop doesn’t have a zsh fanatic locked in the supply closet (in case of emergency)?

Unless you’ve been asleep at the keyboard for a few years, it’s hard to miss the rise of Python as a language of choice among web developers–along with old favorites Perl, PHP, and Java, and the new kid on the block, Ruby.

Perl is an old standby for many sysadmins, especially in those moments when you realize there’s a CPAN module that does 90% of what you need, or you’re tired of guessing whether brackets should go around the test condition in an ‘if’ statement. Is Python ready to take it’s place alongside Perl in a sysadmin’s toolbox? The authors of this book make an excellent case that yes, it is.

The first chapter starts with some exposition and justification, then segues into a comparison of simple code examples using bash, Perl, and Python. A tour of python using the IPython interactive shell fills out the rest of the chapter. This section, which is skippable for those with python experience and not systematic or detailed enough to count as a true tutorial, gives the reader a taste of the example-based approach of the rest of the book and a gentle introduction to Python syntax and the Python shell.

The second chapter, the longest in the book, dives into the Ipython shell in detail, including more detailed instructions for installation. These might have been better placed before the interactive examples in the previous chapter.

Chapter two then proceeds to describe IPython and many of its features in detail, and will probably teach even experienced IPython users some new tricks. While the authors are correct to tout the impressive power of IPython, I question the wisdom of including such a detailed tutorial this early in the book. As useful as IPython is, there is a lot of material for readers to work through here that distracts from the book’s true focus. Much of this material may have been better introduced later on, or relegated to a final chapter or appendix. Strangely, there is no corresponding material introducing the Python language itself. There are, however, plenty of resources available online and in book form for those looking for a more thorough introduction to Python.

The third chapter gives some concrete examples of data gathering and reporting. It covers subjects as diverse as processing log files, sending and receiving email, and generating charts and reports, providing an excellent overview of some useful Python modules.

However, the need for a more in-depth tutorial to Python becomes apparent in this and future chapters. Previous chapters emphasize the usefulness of creating and using custom modules, and this chapter offers some building blocks from which readers could begin to create such a library. However, not enough information is provided about module creation; most readers would not yet be comfortable creating and using their own modules.

Chapter eight discusses creating python eggs, and chapter one describes how modules are imported, but nothing between the two (such as how Python treats a directory containing an __init__.py file when loading modules) is covered. Similarly, concepts such as regular expressions, list comprehensions, and exception handling are presented in example code throughout the book with little or no comment or explanation.

The fourth chapter reviews most of the primary networking modules in the python core library, starting with the low level socket module and proceeding up the stack through
urllib and urllib2. It then documents the usage of more specialized modules, such as Pyro as an XMLRPC replacement, paramiko for SSH support, Twisted for event-driven networking code, and Scapy for interactive and scripted packet-level network introspection.

The next two chapters follow the same pattern established in chapter four. Chapter five, rather ambitiously named ‘Data,’ is really about file and directory manipulation, and gives a good introduction to the same. Chapter six covers SNMP programming in similar detail.

Chapter seven returns to the formula of chapter three, and starts with the broad goal of cross-platform management, and guides the user through the implementation of a multi-threaded ssh-based command dispatch tool. It then describes using the PyInotify module to monitor filesystem changes.

Chapter seven then switches gears , discussing several techniques for use with OS X systems, then lightly touching on Red Hat-based technologies, Ubuntu, and Solaris. Next, it covers virtualization, followed by cloud computing with Amazon and Google. Finally, it describes using Zenoss to manage Windows systems.

Chapter eight covers installing Python packages using setuptools and Easy Install, and then moves on to creating and distributing Python packages with setuptools and distutils.

Chapter nine discusses process management and threading, including recipes for proper threading and daemonizing processes. Chapter ten covers the basics of creating simple GUIs, for both traditional and web-based applications. Chapter eleven covers data persistence in similar detail, starting with the pickle, shelve, and yaml modules, and moving quickly into sqlite and ORM with storm and sqlalchemy.
Chapter twelve provides an equally thorough introduction to making python scripts run well on the command line.

Chapter thirteen seems a bit out of place, as it is a discussion of callbacks, a fairly esoteric (though useful) feature of Python. If the authors are going to devote a chapter to this feature, why is there barely any mention of most of the other Python features used throughout the book?

Chapter fourteen is back on track, however, with simple but useful examples for managing DNS, using LDAP, another try at Apache log parsing, and a simple FTP mirror program.

Summary

Overall, this book provides a grand tour of core and optional Python modules that are likely to be useful for a sysadmin, along with a bevy of practical examples.

However, this book does not–by itself–serve as an introduction to Python for sysadmins. It skims over many important basics of the language.

Those already familiar with Python will get the most out of this book. If not, I’d recommend purchasing a beginner’s Python book as a companion, or you can rely on the many online Python tutorials and extensive documentation.

Similarly, while the book mentions writing and importing your own modules, and even using Python eggs and distutils to package and distribute them, a true stones-to-soup guide for creating and maintaining a library of useful modules is missing.

These caveats aside, if the reader has already acquired the basics of Python from another source, then Python For Unix and Linux System Administrators is likely to provide plenty of inspiration and guidance.

Note: One of the book’s authors, Noah Gift, is a frequent contributor to Red Hat Magazine.

Answer:

First, make sure that you have downloaded the correct files. For each distribution there are binary files and source files. To complete an installation the four binary files for a particular distribution are required.

Simply burning these files to CD as files will result in a single file being burnt to CD with a .iso extension. If this occurs your disks will not be bootable. The files available from Red Hat Network (RHN) are disk images and need to be burned to CD as an image.

Your burning software will extract the files from the .iso and burn them to CD. See your specific burning software documentation for more information on how to burn images to CD.

To check if you have burned each image correctly, simply examine the contents of the CD. Instead of a single .iso file the disk should contain multiple files and directories.

Red Hat’s customer service and support teams receive technical support questions from users all over the world. Red Hat technicians add the questions and answers to Red Hat Knowledgebase on a daily basis. Access to Red Hat Knowledgebase is free. Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries. The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.

Brian Crabtree and Kelli Cain are the artists and creators behind Monome. At first glance, this cool device is simply a white square with a grid of buttons. It produces music and the buttons light up. It seems random, but the lights and music are synchronized.

Monome is a musical interface that connects to a computer–and is controlled by the applications the computer runs. It respond to the keys being pressed, and the LEDs light up–it is, at its simplest, a programmable controller for music, video, games, or art.

The beauty of an open process allows people to build on the idea, creating more than anyone could originally imagine (just like Fedora). People have manipulated Monome to do a number of things.

Max/msp is the programming environment for most of the Monome applications. This environment gave Crabtree and Cain the flexibility they needed to compose live art and video performances. Open source technology was better than the conventional methods they tried previously, because they could use and manipulate technology the way they wanted.

Monome was born to help express music and art. But instead of hiding the idea, Crabtree and Cain decided to share with the world. So far, the work has been incredibly successful and a large community has formed, building upon the Monome idea. So far they’ve constructed 3 models:16 x 16 inches, 16 x 8 inches, and 8 x 8 inches. Each time they have sold out quickly.

I love this line from their blog:

“We believe that open source is commercially viable and mutually beneficial for our collective and the consumer. In opening our software we eliminate wasteful, redundant coding for ourselves by incorporating proven libraries and frameworks.”

The Monome duo believe in sharing and sustainable practices. Even the name, Monome, is derived from their belief in minimalism. They make everything from the musical interfaces to the screenprinted shipping boxes in their loft in Philadelphia. They follow sustainable practices that use local sources for raw materials and services. They sell kits so people can build their own. Their business is based on the open source model.

Like the Fedora Project, Monome also has a growing community of artists and programmers that actively contribute—whether it’s writing software or finding new ways to use the interface. This community has released a wide range of videos, showing everything from creating the actual machine to playing live performances.

Perhaps their blog says it best:

“We seek to actively facilitate community participation and encourage sharing.”

At Red Hat, we do the same.

More information

• Monome’s Wikipedia entry
• Official Monome website
• A Video and Text Interview with Monome from Cycling ‘74
• YouTube videos of mono in action can be found here and here.

Answer: The module mod_jk is currently included as part of the Application Stack channel and is not available in the base channel. However in Red Hat Enterprise Linux 5, the package httpd does provide a module by the name mod_proxy_ajp which helps connect between the two. The configuration file is located at /etc/httpd/conf.d/proxy_ajp.conf. Edit this configuration file according to the needs of the enviroment. At the very least, add i the webapps directory used by tomcat:

     ProxyPass /tomcat/ ajp://localhost:8009/
     ProxyPass /examples/ ajp://localhost:8009/jsp-examples/

Red Hat’s customer service and support teams receive technical support questions from users all over the world. Red Hat technicians add the questions and answers to Red Hat Knowledgebase on a daily basis. Access to Red Hat Knowledgebase is free. Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries. The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.

• Google wants to free the airwaves. The FCC is about to decide what to do with all the leftover radio white space, and this petition/drive could influence the decision. Check it out.
• And speaking of radio, it looks like some of the predicted results of the copyright fees levied on internet radio stations are about to come to pass. Wired is reporting that Pandora is near-failing, with almost 70% of their profits going to pay the fees. Sad news.
• We would be remiss without at least one Olympics-related item. So, here’s your obligitory gold-medal geek moment: the Wall Street Journal investigates how the DiveCam follows the athletes from platform take-off to splash-down. How does it work? The simple answer… is gravity. Mmmmm, physics.
• Last week brought news of a a legal win for open source licenses. See what the Red Hat legal team had to say about the ruling as well.

In Red Hat Enterprise Linux 4, The kernel-devel package includes the kernel headers files and you no longer require the kernel source package to build a third party kernel module. To install the kernel-devel package run the following command as root user in a terminal:

#up2date kernel-devel

A full source tree is not required in order to build modules against the current kernel you are using. You can simply point your Makefile to /lib/modules/`uname -r`/build. A more detailed explanation can also be found in the Release Notes.

If you require the kernel source package for reasons other than building a kernel module, you can obtain it in Red Hat Enterprise Linux 4 by typing the following as root user in a terminal:

# up2date redhat-rpm-config rpm-build

# up2date --get-source kernel

# rpm -ivh /var/spool/up2date/kernel*.src.rpm

# cd /usr/src/redhat/SPECS

# rpmbuild -bp --target=i686 kernel-2.6.spec

# cp -a /usr/src/redhat/BUILD/kernel-2.6.9/linux-2.6.9 /usr/src

# ln -s /usr/src/linux-2.6.9 /usr/src/linux

Note: This will build the source tree for a x86 based architecture. For different architectures, (i.e. x86_64) pass the appropriate target variable (i.e. rpmbuild -bp –target=x86_64 kernel-2.6.spec )

Once completed, a symlinked directory pointing to the latest Linux 2.6 kernel source should be available:

# ls -lt /usr/src
total 28
lrwxrwxrwx   1 root root   12 Mar  2 16:36 linux -> linux-2.6.9/
drwxr-xr-x  20 root root 4096 Mar  2 16:21 linux-2.6.9

Note:The steps are also provided in the Red Hat Enterprise Linux 4 Release Notes: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release-notes/as-x86/

This information has been provided by Red Hat, but is outside the scope of our posted Service Level Agreements (https://www.redhat.com/support/service/sla/) and support procedures. The information is provided as-is and any configuration settings or installed applications made from the information in this article could make your operating system unsupported by Red Hat Support Services. The intent of this article is to provide you with information to accomplish your system needs. Use the information in this article at your own risk.

Red Hat’s customer service and support teams receive technical support questions from users all over the world. Red Hat technicians add the questions and answers to Red Hat Knowledgebase on a daily basis. Access to Red Hat Knowledgebase is free. Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries. The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.