Radio E-mail in West Africa: The Complete Version

Remote networking with high-frequency (HF) radio and Dan Bernstein's qmail.
Operator Interface and qturn

Each of the radio e-mail servers in the field run headless, controlled from a simple command-line interface via Telnet session from the operator's desktop PC. The basic interface consists of four commands, usually run in the following sequence:

  ppp.start
  mail.get
  mail.send
  ppp.stop

Simple shell scripts perform their respective tasks, each providing the operator with a modest amount of feedback about what is happening at the time. The functions could be further collected into a single command, such as mail.run, but we want to enable the operator to maintain some discretion over radio access, depending on the demands for voice communication. For example, if getting the mail takes more than 15 minutes or so, the operator may stop the session, reestablish voice communications for a security check, then start a separate session a few minutes later to send outbound mail.

The command interface shows that we don't try to get and send mail simultaneously. Rather, first we do one, then the other. This is another accommodation for the anemic, half-duplex bandwidth of the HF radio link. As far as network traffic goes, this link is like a one-lane backroad. More than a little traffic creates a long skinny parking lot.

It should be pretty easy to figure out that the mail.send script is a simple wrapper around the maildirqmtp command described in the second example. What may be less obvious is how we get the mail. That is, how do operators in the field run the maildirqmtp command on the radiohub server in Conakry?

As with most things UNIX, TMTOWTDI. You may choose, for example, to set up ssh for remote execution of the maildirqmtp command shown in the example. Alternatively, you could just go ahead and set up a POP3 server on the radiohub and use fetchmail over the link (with the—qvirtual option to strip the prefix added to each envelope's address), though you would then lose the benefits of QMTP.

For the Radio E-mail project, we decided to take advantage of Dan Bernstein's daemontools and ucspi-tcpi packages, already installed as part of our standard Life with qmail installation. The tools in these packages make it ridiculously easy to set up special purpose servers. Ours is called qturn and is modeled on Bernstein's AutoTURN comments described in the documentation with his serialmail package. With qturn we keep the significant efficiencies of QMTP, while avoiding the time-consuming overhead involved in establishing and authenticating an ssh connection.

The components of the qturn server running on the radiohub are provided in Listings 9 - 11. The principle is simple. The qturn run script (Listing 9) is set up as a daemontools service listening on a specific port of your choosing (here we use 55210). Anytime a connection to the port is made, the qturnd.sh script (Listing 11) is executed. This script reads the $TCPREMOTE environmental variable passed to it by the tcpserver invocation and gets the static IP address we have assigned to the incoming connection. The script then matches this IP address to the Maildir directory used for that field office. The maildirqmtp command is then run, sending the collected mail in the Maildir to the QMTP server on the remote host, while directing status output to filehandles that can be read by the client process.

Listing 9. qturn.run

Listing 10. qturn_log.run

Listing 11. qturnd.sh

Now the mail.get script on the client is simple, as is shown in Listing 12. It calls tcpclient to connect to the qturn server created with tcpserver on the radiohub and redirects the stream returned from that process to standard output. That's it! Client/server programming just doesn't get any easier.

Listing 12. mail.get

An Algorithm for Africa

As we may have mentioned, the HF radio link is a tad on the slow side. Yet we do manage to move a decent amount of mail with it nonetheless. On an average day, over 300 messages travel the airwaves between Conakry and field offices, over two to three brief connections per office. And as is typical with all internet technologies, every taste stimulates even greater appetite.

Given the limitations inherent in radio e-mail, we try to maintain a usage policy that is as open as possible. For example, staff are free to use radio e-mail for personal correspondence with friends and family anywhere in the world, and there is no limit to the number of messages any user may send. Our only explicit policy restriction is the request that users not subscribe to mailing lists.

To prevent the radio links from getting choked-up for hours on huge attachments, such as large documents and graphic files, all qmail servers connected to radios (that is, the radiohub in Conakry and each of the field office servers) are run with a message size limit of 8,000 characters. This is sufficient for three to four pages of text and is configured with qmail's databytes control file. We advise users of this message size limitation, suggest they stick to plain text for their correspondence and configure their mail client software accordingly. But whatever can be squeezed into the 8,000 byte limit by way of attachment and file compression is free to go. (Users in Conakry, which has a full-time, broadband gateway to the internet, are not quite as restricted. Here the databytes control file is set to one megabyte.)

As one would expect with our software selection, the system has proven extremely reliable. Despite the intermittent power outages typical in Conakry, we do try to keep the mailhub server coyah running at all times through the use of generator and battery back-up. So far these measures have kept this machine serving flawlessly since it was first installed, with a continuous uptime at this writing of over three months, no reboots.

Yet this reliability would mean nothing if the system were not sustainable over the long term. Two months before we installed the first radio server in the field, we formed a Network Users/UNIX Group among interested and capable IRC staff. This group meets regularly and enthusiastically to learn Linux/UNIX and to develop network administration skills. UNIX is a linguistically rich operating environment, and I think it finds a natural affinity among Africans whose language abilities seem inherently prodigious. In any case, the group now has a number of functional production systems on which to work and play, using mostly recycled hardware. While this article has focused on qmail and serial communications, the Linux servers installed for this project also host a typical range of other servers and services, including DHCP, DNS, natd, Apache, FTP, Samba and PostgreSQL. The IRC-NU/UG provides a human network that will continue to sustain and grow the technical network over the years to come.

The successes of this project are readily duplicated anywhere in the world. Schools, government ministries and other NGOs can easily build remote networking solutions over HF radio where access is otherwise not available, and at minimal cost. Once installed, these systems are almost trivial to administer and may be quickly adapted to alternative TCP/IP carriers. Maintenance of the e-mail system itself involves only the routine adding/deleting of user accounts, while keeping the /etc/aliases files up to date.

The current result of our own Radio E-mail project is that we are now serving mail to over 50 desktops and 150 staff in four offices throughout Guinea. The entire wide area network is serviced behind a single public IP address, at a total ISP cost of $150(USD) per month. Based mostly on existing hardware, the Radio E-mail project has leaped boundaries and opened dialogs for its users that were previously not possible.

Best of all, the system has deployed standard network and internet technologies throughout the organization and throughout Guinea utilizing the freely available, best of breed, borderless open-source technologies that underlie all global connectivity. Not only does this plant grass-roots networking infrastructure where there is yet no Internet, it helps build the core competencies and capabilities essential for Africa's connected future.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

CRMF Papua New Guinea

Anonymous's picture

wow great.

did you know CRMF in Papua Neu Guinea is doing the same?
visit www.crmf.com

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

I worked as a Radio operator for NGOs in Guinea and experienced the "huddle" and difficulties involved in it, especially during the time of tight security. Can you imagine rebels (killers) just infront of your office and you are responsible to say inform the HQ office in some where around 600 Kms (NZerekore or Macenta)? I think Wayne can do something by creating a second type "Geekocop". This is amazing, the budget is less than nothing. I worked with IRC and know how strict and small is the operating budget for communication is. Now, as a Network & Systems Engineer myself, I greatly admire Wayne and Paula who took over from Mustafa Elkanzi (Former IRC Country Director & personal friend of mine). Paula you should have the praise for this hard job done by Wayne....

Wayne, I will always be your admirer and fan. Infact, you have inspired me to dig into the Unix /Linux world. I already carry Microsoft Certificates in my pocket and Cisco.

Bravo, bravo and thanks to OpenSource

M. Pathe Jalloh,

Former refugee and IRC staff

Now working with Ashanti Goldfields, Siguiri-Guinea

pathe.diallo@ashantigold.com

www.ashantigold.com

Mustafa Elkanzi

Khizr I. Tajammul's picture

You mentioned you are a good friends with Mr. Elkanzi. I was wondering if you could forward me his contact details. It has come to my knowledge that he has become the country director of IRC in Pakistan.

Bridges is a development consortium and we would like to meet him and possibly assist him in his projects in Pakistan.

Appreciate your time.

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

I think your right

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Anyone out there using KA9Q? Any comparisons to using a UNIX-based solution, or comparison to UUCP protocols?

Thanks,

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

When I picked a copy of Linux Journal up from the stands, I had no idea what a great article I was about to read.

The North-South digital divide is something I think a lot about, though I am just learning to appreciate the difficulties of connectivity in less-developed countries.

I'm involved with Indymedia.org (that is, a member of one of over 75 Independent Media Centres world-wide). Some of our American IMCs have been behind a push to send used technology to South American IMCs -- about 250 configured old PIIs are on a ship heading south as I write this.

Yes, those machines will all end up in urban settings. But we now have a real and tangible solution for reaching outside the cities, where the needs are arguably greater.

Those 250 PIIs are just the start of a long-term project. And now it seems there may be no end to it.

Thanks very much for a very inspiring read.

All the best,

David H.

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Ham Radio operators have been doing this for YEARS now. Nothing new.

From using simple type of 'modems' like http://www.baycom.org/bayweb/index.htm or using tcp/ip over the air using the baycom modem and software like http://www.fwarig.org/home_jnos.html

Or providing ham radio operators who are sailing around the world access to email as well via HF.

http://www.w2xo.pgh.pa.us/

http://www.hfradio.com/

Of course thats just the tip of it.

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Six years ago I set up a similar system for a christian missionary organisation "Operation Mobilisation". At that time you even got in Singapure Harbour a very bad telephone line that was only capable of 300-1200 baud (with a Trailblazer PEP modem). Not to speak for some locations more remote.

In the end we had an central e-mail hub that could do SMTP, UUCP over Modem und UUCP over TCP/IP. Some of the "clients" had DOS based UUCP systems with UUPC and Pegasus Mail for DOS, some had Windows based systems, and some had Linux servers with Pegasus-Mail for Windows. You see, many operation modes were possible and we were able to adjust to the different technology levels of the various countries. Some used SMTP with their local providers.

In not-so-advanced countries we used UUCP-over-TCPIP if we got a local ISP, sometimes we had to use UUCP-over-Modem. In this case we used the uucp-g protocol because of it's efficiency. To my knowledge, we did not use radio-transmitting, althought some people looked into packet-radio like technology.

However, the choice of transpartion was surprisingly often not a function of the available infrastructure. Instead it was quite often a result of the locally available expertise. A missionary organisation does not generate profits, it lives from donation. Therefore money is usually scarce. It was simply not possible to train all operators worldwide up to the same level of expertise, just the flight tickets would have cost us a fortune. And of course not every country had techy-aware people there. So it was good to have different options to choose the right one from.

By the way: the Linux-Server site was interesting, because a simple menu hacked together from "dialog", "bash" and "perl" allowed even novice operators to setup up and create users and an e-mail connection. The system was dubbed "OM Standard Linux Server" because it later also became file-server (samba), print-server (lpr) and so on.

However, we had a different problem domain (getting e-mail in countries without internet access, not getting e-mail to remote areas of countries with full area covering internet access). So we did, up to my best knowledge, not use radio based links.

HolgerSchurig has a mailbox at gee-emm-ex point dee-eeh :-)

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Hello Wayne,

I read your article with great interest, as I am writing a white paper on wireless use and options in our US schools for the Consortium of School Networking (CoSN). I would like permission to use excerpts of your piece and to provide a link to the the entire version. Making wireless work in such extreme conditions is an amazing accomplishment, and would give an interesting perspective.

This white paper is to be presented at the Nov. National School Board Administration conference, and will be featured in several ed-tech print and electronic magazines. If you agree to my request, please provide contact information for those who would like to connect with you directly.

I look forward to hearing from you!

Regards,

Kristen Hammond

Wallingford, CT USA

khammond@edupuppy.com

http://www.EduPuppy.com

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Check out the NATO Standard for HF Data Transmission (STANAG 5066) and the newer standards for HF data modems (MIL-STD-188-110B and STANAG 4539). I'd love to see low-cost (no-cost) implementations of these from the open-source community to complement the existing commercial implementations (which are kinda' pricey). But the data modems support rates up to 9600 bps in a standard 3 kHz bandwidth, and support adaptive data rate when the channel goes to crap. The data transmission standard (STANAG 5066) supports e-mail and IP-over-HF using ARQ or non-ARQ modes. All of the advantages cited by the article were identified by the military HF industry as good reasons to develop the standards and equipment. Think of it as long-haul wireless internet and ISP access from the days when 9600 bps telephone modems were hot stuff. With a minimum of costly infrastructure.

Re: Radio E-mail in West Africa: East Africa since late 90's

Anonymous's picture

In Uganda we have had access to email over HF since the late nineties using Codan HF radios and Windows based systems. I did an interesting version using SuSE Linux (6.4 at the time) and wrote a small paper and sent it to Codan (http://www.codan.com.au). I managed to send and receive files to units 500 Kms from the nearest ISP. My paper and corresponding files are available under http://kym.net/codan/ Read the codan.doc

Kiggs

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Interesting. Having used amatuer digital modes on HF, I find

the application of HF for email, etc, refreshing.

However, readers (at least here in the U.S.) should note...

HF is (afaik) totally "closed" to unlicensed experimentation.

No mention of licensing or legal use was mentioned in

the article (afaict). Here in the U.S., presumably you could

get an commercial HF license for a digital mode, but

experimentation is not allowed. Unlike 802.11 (2.4ghz)

there is no unlicensed band for digital use (note that the

old "unlicensed CB" 27 mhz band only allows for AM/SSB or

remote control applications.)

I'm not totally familiar with the geographic topology of

the africa-based sites mentioned in the article, but

bandwidth (and reliability!) could be greatly improved by

going with 2.4ghz (802.11), locating repeaters on

mountain tops, and using highly directional (hence high gain)

antennas. This depends alot of on the topology and

could very well not be feasible for those sites.

Otoh, possibly 2.4ghz is closed in that part of the world

requiring the fallback to international HF frequencies.

jeff

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Jeff I would love to discuss your concept. How much would it cost? Repeaters are the only solution for short distance 802.11 of course now there is WiMax 802.16 I believe. 802.11 goes how far, a kilometre or 5. If 5 is reliable it will take 20 repeaters for 100 kilometres!

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

I was reading this until I got to the description of the PPP link and remembered the days of UUCP over serial lines. Since the modem took care of the error correction they could send much more data more quickly by using straight serial UUCP instead of trying to get a PPP handshake to get TCP/IP working. A UUCP chat script was always faster than PPP in my experience.

Kris

Store and Forward web searches

Anonymous's picture

The author might want to check out TEK. TEK is a store and forward interface to the google API that is designed to work over slow and inconsistent network interfaces.

To quote from their homepage:

Welcome to the TEK Project. The goal of the TEK project is to build a low-connectivity search engine for use by people at the far side of a bad telephone connection.

In many places in the world, there are no books, there is no television, there is no access to information. And just a modem away there are gigabytes of information streaming by that noone can access -- because telephone charges are too high, because ISP fees are 10% of a local monthly wage, or because there are no computers. Even if there were computers and working phone lines, bandwidth is so narrow that searching the Web and downloading the discovered material will take so long as to be financially impossible.

TEK supports a different model of Web access. Think of inter-library loan. You need a book. Your library doesn't have it, and you can't afford to buy it. But you can get it on loan. You are willing to `pay' to access the infomation in that book with time: you will wait a week to see the book.

With the TEK search engine, the user submits a query which is emailed to Boston. The TEK Server, which is connected to the Internet backbone, searches the Web, locates some pages, selects which pages to send back, compresses them, and returns them back to the user. Because the search results are returned asynchronously, by email, the connectivity charges are lower. Post-processing the search results and selecting which pages to send back reduces the amount of information and addresses the bandwidth question.

http://www.cag.lcs.mit.edu/tek/

It may be greater than the bandwidth available but that may change - the on-off nature of connections in the bush won't for many years :)

Cheers

James

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

> Remote networking with high-frequency (HF) radio and

> Dan Bernstein's qmail.

>

>

They're using PPP to establish a TCP/IP connection over HF. While it's a solution, it's not the best solution - using UUCP and eliminating the overhead of PPP and TCP/IP is a much better, more robust, and higher throughput solution for store-and-forward applications. Been there, done that.

Also, it's not necessary to use such a complicated setup such as qmail if you're using UUCP. qmail isn't Open Source - the licensing is rather restrictive, a fact that leads the major distributions to not distribute qmail.

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Linux already supports courtesy of the ax25 kernel modules the ability to use amateur ax.25 protocols on HF. By using these with a NOS driver, tcp/ip connectivity is as easy as typing "insmod ax25".

I suspect that the commercially made modems were using sitor/amtor or pactor or variants thereof.

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

ax.25 is not particularly good at HF. The channel is too cruddy to support the quite low error rate that ax.25 requires to be successful. HF protocols such as amtor/sitor/pactor and clover are designed to deal with the vagaries of hf channels. clover being probably the fastest and most robust for large block half-duplex communication. But it works best for large blocks. I suggest that you read up on data-over-HF, you will find a lot of interesting and unexpected things drivin by the fading and noise that is unique to an HF channel. de N6NZ

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

I enjoyed the article and respect the ingenuity of what you have done.

But it's pretty ironic that you talk about how enabling "freely available, best of breed, borderless open-source technologies" are, having spent most of your article describing a network that uses the proprietary, limiting and non-free qmail mail transport agent.

I have no arguments against the use of proprietary software where it's necessary. But please, please don't misrepresent proprietary software as something it is not! Calling qmail "open source" is not only unfair to Dan Bernstein, it is also disrespectful to the authors of MTAs like exim, postfix and sendmail who have spent their lives developing software that's truly free to share, use and modify. qmail is a very powerful piece of software, but "open source" it is not.

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Interesting. But I didn't pay anything for qmail, so how can you call it non-free? And if qmail is proprietary, how can it be that I have access to the source? And I can distribute patches? Name another proprietary program for which anybody can download the source and distribute patches for it. I think you are stretching the meaning of "proprietary".

A little ironic

Anonymous's picture

I enjoyed the article and respect the ingenuity of what you have done.

But it's pretty ironic that you talk about how enabling "freely available, best of breed, borderless open-source technologies" are, having spent most of your article describing a network that uses the proprietary, limiting and non-free qmail mail transport agent.

I have no arguments against the use of proprietary software where it's necessary. But please, please don't misrepresent proprietary software as something it is not! Calling qmail "open source" is not only unfair to Dan Bernstein, it is also disrespectful to the authors of MTAs like exim, postfix and sendmail who have spent their lives developing software that's truly free to share, use and modify. qmail is a very powerful piece of software, but "open source" it is not.

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Wouldn't your solution create a lot of traffic overhead? (PPP, IP, TCP, SMTP and neither of these are efficient protocols.) My spontaneous idea would be to re-use some of that old FidoNet software and set up something similar: store and forward of compressed packets of e-mail directly over serial links.

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

UUCP could be an easier choice, and more Unix friendly.

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

The author responded to this with:

Although we might have implemented e-mail to the field using UUCP, our TCP/IP system is easier to configure and integrate with the existing network and e-mail system. This setup is also readily converted to use faster telecommunications linkups, such as through landlines or satellites. If and when these become available in the field (and as the budget may support them), the IRC network is ready to simply plug in.

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

HF and VHF packet radio have been going on for years in the Amateur Radio Service. It's good to see others not directly involved in radio finally recoginzing the benefits. Check out www.tapr.org.

73 de N8SQT

(Best regards from Bob)

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Greetings Wayne:

That was a super article! I have done similar with less as you are doing right now, so I think you are doing something quite special indeed.

I wonder if you ever considered Amtor or even Sitor as a way of linking over the HF ether? Amtor is a protocol adapted by amateur radio from Sitor, its commercial predecessor. Further, Pactor further enhances Amtor with better compression and frequency instabilities. I believe Pactor and Sitor are available in the public domain.

My thinking is to marry the best of Pactor with DAMA the add a layer of DHCP/CHAP/PPP so your hub could actually sustain more than just one link at a time. DAMA will ensure all new links are welcomed and added to the round table, the ppp(or whatever you use) would authenticate, and Pactor would ensure the best compression verses time verses link state. I don't think I have seen anything like this in production, but it would sure be fun to have a go with. Unlike tcp/ip packet, a broken packet can be repaired without a complete retransmission of the whole packet.

Pactor II is now available and actually does even more with compression and squeezes more data in even less bandwidth and can cope with signals that are almost inaudible. Unfortunately, it is very proprietary and the makers want a lot of money for each license. Yet it will move even more data over less channels than Pactor can.

One other nagging thought kept creeping into my mind: why don't you use either 2 meter or 6 meter single side band radios? This would effectively release the hf rigs for pure voice/emergency calls while moving the data load to that portion of the spectrum where it would be least likely to interfere with other systems. As you know, HF knows no boarders! The VHF spectrum in SSB mode has amazed and delighted many an operator over the years. The modems you now use on the HF radios would work exactly the same on the VHF rigs, and probably a little faster since transmitter to receiver turn around is likely faster on the VHF rigs. I realize this is probably not doable in tight budgets, but it sure would be fun!

Thank you for taking me on this splendid tour of your works. It seemed like you had a lot of fun making all of this system work.

Take care and happy hacking.

a_hippie@linuxfreemail.com

Re: VHF SSB

Anonymous's picture

Would VHF SSB give 375 mile/600 km coverage?

Excellent article, Wayne. I found every word

useful.

Everett

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

My sister works with Wycliffe in Mali. She's translating the Bible for the 60000 Tadaksahak people living in eastern Mali. She also uses a radio link powered by a car battery to send and get email from her place in Menaka to and from the capital city Bamako. The infrastructure is a ccMail system with an internet mail gateway provided by JAARS.

Beat Bolli

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Solomon Islands People First Network (PFnet), a UNDP-funded ICT in Development project, has been using community radio email since October 2001. We use Wavemail and Pactor 2/3 (level 3 is equivalent in throughput to the CODAN). It's also much cheaper and more user-freindly for less skilled operators. We find that a week's training is suficient even if they have no previous computer experience.

http://www.peoplefirst.net.sb/general/pfnet.htm

David Leeming

Technical Advisor

leeming@pipolfastaem.gov.sb

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

This is an interesting application - I'm just curious if the author was familiar with some of the amateur radio modem systems that have been in operation for around a decade now doing basically the same stuff?

HF is very much a different kind of fish compared to 802.11B, etc. Store and forward works pretty good in this application. There are even radio bbs systems that run under dos that automate this kind of thing too.

Nice article.

Re: Radio E-mail in West Africa: The Complete Version

Anonymous's picture

Ham Radio operators have been doing this for YEARS now. Nothing new.

From using simple type of 'modems' like http://www.baycom.org/bayweb/index.htm or using tcp/ip over the air using the baycom modem and software like http://www.fwarig.org/home_jnos.html

Or providing ham radio operators who are sailing around the world access to email as well via HF.

http://www.w2xo.pgh.pa.us/

http://www.hfradio.com/

Of course thats just the tip of it.

HF Automatic Link Establishment - HFLINK

ALE Automatic Link Establishment's picture

HF ALE Automatic Link Establishment is being used for this purpose now. The system enables the best frequency for ionospheric propagation. This maximises the throughput and baud rate.
See the website
http://hflink.com
for more information about ALE Automatic Link Establishment, Robust and High Speed HF Communications.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState