PHP/JavaScript hackers needed.

The Fedora Documentation team needs some short-term help from a few people who can help us resolve some licensing snafu’s. I’ve been working with Docs, Marketing, and several other teams to finally get a content management system lifted off for Fedora. This system would let us do a better job of putting news, documentation, PR materials, and other important content in front of the public beyond our community. Some time ago, we went through all the various options for a CMS, and after public comment and putting heads together with the fabulous Fedora Infrastructure team, we ultimately decided on Zikula (which some readers might know from its previous life as PostNuke).

As the various teams have been consulted for needs, we’ve started to develop a list of Zikula extension modules, and package them for Fedora and EPEL. During the package review, as Karsten Wade noted in a recent blog, we’ve discovered some licensing flaws that we’d like to help upstream resolve. One of the points of collaboration is to build on each other’s work and strengthen it, after all.

However, to accomplish this with less drag, we really need the help of someone who has experience in PHP and JavaScript, who can help us yank out a couple included scripts and substitute compatibly licensed material. Then we can send the patches upstream for the good of all. We believe the work itself is not particularly difficult or extensive.

If you have significant PHP and JavaScript experience and could spend a couple of days helping us resolve these issues, please get in touch with us via the fedora-docs-list, send email to pfrields or sparks (both at fedoraproject dot org), or leave me a comment here.

UPDATE: As J5 pointed out, bug numbers would be good. They’re listed in my comment on this post.

Fedora Talk activity day.

For a while now, I’ve been working on plans for a FAD to work on our Fedora Talk VoIP system. There are a couple gaps I’d really like to fill, such as the ability to record, publish, and/or stream calls. These features would make the system much more capable of high transparency. They’d also contribute to an archival history that might help future contributors in the same way as other types of conference and meeting proceedings.

For example, it would be really cool if we could use the Talk server to record our sessions at FUDCon, which could be streamed and/or downloaded later by any community member. The only thing we’d need to do is to run a microphone into any laptop running a VoIP softphone on Fedora Talk, set the record level, and voila.

The raison d’être for any Fedora Activity Day is to gather a small number of interested contributors to a central location to work on short-term, focused goals that advance some part of the Fedora Project. (These are very different from the Fedora Users and Developers Conferences (FUDCons), which are much larger gatherings that serve many needs.) I’ve been to a couple of FADs this year already, including one for Documentation in Clemson, SC, and another for the development cycle in Raleigh, NC. So, in keeping with the slow sojourn up the East Coast, I am working on one that will be held in my hometown of Fredericksburg, VA.

It might be nice to add one more person with some Python and Infrastructure skills to our merry band, especially if they know something about streaming media. If you’re interested, drop me a line and put your name on the wiki page.

Spare hours FAIL.

Today in a nutshell, since I’m running on empty and can’t be creative right now:

• 0700: Left house for Raleigh.
• 1030: Arrive Red Hat. Meet Max just as I’m about to enter the building, and almost fail to recognize him because his hair’s so short. Head upstairs, open laptop, sync mail, put out fires.
• 1145: Make it down to the POSSE 09 conference room and wave hi. Meet Mel Chua, intern extraordinaire, and also say hi to Ian, intern extraordinaire #2. Grab marginally nutritious snack and beverage, and run back upstairs for Board meeting.
• 1330: Back to POSSE room to see what’s actually happening there — Mozilla hacking, awesome! Talk to Chris Tyler and a couple other contributors.
• 1400: Meet with Max about some internal stuff, mostly budget and other administrivia, also FUDCon preliminaries.
• 1530: Meet with Legal.
• 1630: Back to POSSE, which is letting out for the day a few minutes after I arrive. (*Sigh.*) Send a couple emails, finally say more than five words in a row to Greg DeK, which I would have done sooner if not for the whirlwind of stuff to do.
• 1645: Back upstairs, sit next to Max. We barely talk to each other as we read and pound out other emails in a vain attempt to catch up.
• 1800: Head to cars to rendezvous with group for dinner, which is highly enjoyable, attended not only by the students and staff, but we’re also joined by Michael Cunningham, Red Hat EVP and general counsel and have a nice chat with him too.
• 2130: Arrive at hotel, unpack my tiny bit of stuff, and discover I have no broadband connection (broken modem). After the help line fails to restart or fix the modem properly, the clerk gives me a new room.
• 2230: Repack, move to new room, discover I have a barely functional A/C. Give up, do work, post this blog.
• 0030: Sleep.

Try installing F12 Alpha early.

According to this posting to the fedora-test-list by Liam, there’s going to be some installation testing for the Fedora 12 (Constantine) Alpha candidate next week, on Wednesday July 29. This is a chance to shake out some of the new features in the Anaconda installation application that have come in over the past couple of months. The more testing we can get on the installer early, the more bulletproof we can make it for our final release by the time code is frozen in the fall.

I find that the easiest way to do installation testing is to maintain a local Rawhide mirror — a copy of the Rawhide repository on a machine on my home network, shared out via the Web. But there are complete instructions on the wiki for the many ways you can test Rawhide, specifically a section on doing a direct daily installation. You don’t even have to have a local mirror. You can download a small-ish boot.iso image for either 32-bit or 64-bit architecture, and install directly from the Internet if you have a broadband connection.

It’s easy to get involved in testing, and there’s even a matrix of results that we’ll be filling out on July 29 to see what works, and what needs work. This is a great opportunity for anyone to become a contributor to Fedora by helping with Anaconda, which is used not just in Fedora and Red Hat Enterprise Linux, but also in CentOS, Scientific Linux, and many other derived distributions. See you on the 29th for an awesome installer validation day!

Best in show gets better.

Regarding an earlier post, I made some changes to my NetworkManager dispatcher script. The problem with the original was that it reset defer_transports when any interface went down, without regard for redundancy. Since I use my laptop in my home office, it’s often plugged into a wired network. When I disconnect to go somewhere else in the house (on the rare occasions I get the chance to wander), my wireless takes over courtesy of NetworkManager, of course. So there’s no need to change the Postfix server configuration if I still have a default route in place.

This script works better:

#!/bin/sh
 
if [ "$2" == "down" ]; then
    ( [ -z "`ip route show 0.0.0.0/0`" ] && \
	/usr/sbin/postconf -e 'defer_transports = smtp' && \
	&& /sbin/service postfix reload ) || :
elif [ "$2" == "up" ]; then
    ( /usr/sbin/postconf -e 'defer_transports =' && \
	/sbin/service postfix reload && \
	/sbin/service postfix flush ) || :
fi

Thus far, results have been outstanding. I made this change a few days back but hadn’t had the opportunity to blog about it until now.

Git User’s Survey 2009.

From the “likely playing catchup” files: The Git User’s Survey for 2009 is now available online. We have a lot of git gurus in Fedora, so if you do use it, go take the survey. It takes only 5 minutes and can help the git developers with future roadmapping.

I proudly note that Fedora Hosted is on their list of git hosting services!

That FUDCon poster is catching on.

There’s a nice entry on the Red Hat press blog about some of the interesting items that went on at FUDCon Berlin 2009.

FUDCon is a great place for us to renew social bonds with our fellow Fedora contributors. But it’s also a place where, first and foremost, we try to advance upstream collaboration, present and critique new ideas, and otherwise use the bandwidth that an in-person meeting affords to move Fedora forward through a combination of planning and action. The specific examples of the wireless maintainers who met at FUDCon, and the Red Hat Security Team’s work there, are great examples of what FUDCon can provide.

The Fedora Ambassadors from the EMEA region who met at FUDCon similarly achieved some worthwhile goals, including migrating their automated systems into Fedora. They were rightfully very proud of the work they completed there, and that migration will ultimately benefit the Ambassadors program itself, enhancing transparency and maintainability of those systems. Great work, guys!

I had a nice long phone call with Max earlier today and one of the things we talked about was an upcoming North American FUDCon. So far I have a couple things in mind, such as:

1. An early-December timeframe, either December 4-6 or 11-13.
2. A location off the Eastern Seaboard. Currently the front-runners are Austin, Toronto, and Portland. The decision will be made on the basis of overall travel cost, available venues, presence of a “ground force” to help with advance planning, and possibly the extent of existing open source community that might be interested in our conference.
3. We are also considering some content format changes to make FUDCon even more inclusive and appealing to even more people. For instance, we might have targeted talks for people who are new to specific community teams and looking for places they can help. Whether we make these content changes may largely depend on how many people of that type commit to attendance once the date and venue are set.

Numerous other people are sharing ideas for how we can continue to improve FUDCon and keep it fresh for the next waves of Fedora contributors who are already showing up and looking for ways to help free software. Late next week I will be at Red Hat in Raleigh for part of the POSSE 2009 conference, and I plan to take the input I continue to receive from community members, and collate and combine that with our resources available, along with the valuable wisdom of the Red Hat Community Architecture Team, to get some of the basics decided. Stay tuned!

Talk FAD?

I’ve been thinking of a FAD to upgrade Fedora Talk, our project voice-over-IP system. So I started by putting a skeleton of planning information on this wiki page. What I really need to do is gather a few people there with insight and skills in one or more of the following:

• Asterisk
• Python
• TurboGears
• GStreamer

These people would work on a couple basic application style upgrades, and associated backend support on our Asterisk server. We might need the services of a designer, but I’m not sure yet.

Additional thoughts appreciated — write them in the wiki page, or on its associated discussion page. This event is just a brainstorm right now, and I’m not even sure yet whether it will actually happen — but you have to start somewhere, so that wiki page is a scratchpad for now.

Best in show.

Update to my last post about email setup…

As a remote worker, I travel frequently, and often work away from my home office. My workhorse computer is my laptop, which has most of my important data. Unfortunately, I’m not always near a working open wifi, and that happens frequently in my hometown, which is not a super-wired community.

I do a lot of work via email — in fact, much of my job revolves around email, so I frequently need access to the email stored on the IMAP mail servers I use. I have a Gmail (Google Mail) account, and an account on the corporate email servers as well.

To make sure this mail is available when I don’t have a network connection, I use the offlineimap utility, which synchronizes the email stored on the servers periodically with the email stored on my laptop. This means that I have over 3 GB of email on my laptop, but hey, storage is cheap. It also means that when I read email with Mutt — an extremely functional and flexible text-mode email reader — I’m reading it off my hard disk, which is several orders of magnitude faster than reading over a network. Access to messages and sorting is practically instantaneous, as I’ve mentioned before.

The missing piece of the puzzle, though, is sending email. In the past, I’ve had Mutt set up to send through to the proper SMTP servers for each account. This isn’t hard, since Mutt lets you add hooks as you access an account, a folder, or even compose or reply to email on a per-message basis. But the problem is that network access is always slow, and the user interface blocks for many seconds while the email is sent — and I don’t really want to wait, I want to move on with my life and let the computer deal with that stuff, the way it’s supposed to.

There’s also another problem I need to solve — I want my email sending to also work when I’m on a plane. I don’t mean that I expect that email to actually go anywhere, but I want it to look that way to me and my Mutt reader. I don’t want to worry about whether I’m online or offline, I just want to write my email, and feel confident it will be sent when I’m next online.

Enter Postfix — the secure and highly configurable sendmail alternative, originally written by the inestimable Wietse Venema (of tcp_wrappers and other fame). By configuring a local Postfix mail server to handle the actual transfer of email, when I send email, Mutt pops right back instantaneously so I can continue doing my work. And if I’m not online, Postfix will hold that email and try again later when the network is up. And of course, I need this to work for multiple email accounts I use.

Once I started puttering around with Postfix’s many configuration options, I started to understand enough to be dangerous. I looked at the Postfix documentation online, and also a couple of HOWTOs to see how various subsystems work. Here’s how I did it:

1. Install Postfix, using PackageKit:

   pkcon install postfix

2. Set the system to use Postfix as the new MTA:

   su -c 'alternatives --config mta'

3. Configure Postfix with the following options in /etc/postfix/main.cf:

   smtp_sender_dependent_authentication = yes
   sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
   smtp_sasl_auth_enable = yes
   smtp_sasl_security_options = noanonymous
   smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
   smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
   smtp_use_tls = yes
   smtp_tls_note_starttls_offer = yes
   smtp_tls_CApath = /etc/pki/tls/certs

   This did take a little trial and error, I confess, but the results are clear. This set of options allows Postfix to relay email based on the sender address, based on a map file I’ll show you below; enables SASL authentication for Postfix as an SMTP client, using TLS based on a policy map; and allows it to check certificates for validity using the certificates already installed on the system as part of the ca-certificates package.
4. Make a new file /etc/postfix/sender_relay, with the following contents, making changes as needed to reflect your Gmail and corporate account:

   # per-sender provider; see also /etc/postfix/sasl_passwd
   your_gmail_address@gmail.com  [smtp.gmail.com]:587
   my_corp_address@corp.example  [127.0.0.1]:25025

   Note that my corporate email is being tunneled through SSH via a local forward, so my email server actually attaches to port 25025 on the localhost address to send email. If your corporate email server is available on the internet, you would probably just use [mail.corp.example], and make sure to include the appropriate TLS stuff later where needed.
5. Make a new file /etc/postfix/sasl_passwd, which will contain the authentication information for each of your accounts:

   your_gmail_address@gmail.com   username:password

   Add a line for each email address that needs to do SMTP authentication.
6. Make a new file /etc/postfix/tls_policy, which will include information on the way in which each account requires Postfix to use SMTP authentication as a client to the appropriate relay host:

   smtp.gmail.com:587         encrypt

   GMail requires the use of TLS, so the encrypt rule here ensures that Postfix will do TLS-based authentication when it connects.
7. Rebuild all of the affected map files:

   cd /etc/postfix
   postmap sender_relay
   postmap sasl_passwd
   postmap tls_policy

Now Postfix is configured. At this point, I needed to reconfigure Mutt, to remove all the smtp_url options I was setting before. By default, Mutt simply uses the system’s locally-installed sendmail to send email; and the Postfix package provides an equivalent sendmail.postfix binary, which the alternatives command above sets up with an appropriate link, so everything on the system continues running like a top without any further problems. Now Mutt will simply call sendmail blindly, and Postfix will handle all that mail as configured above.

Then I just had to turn off the running Sendmail process, and start up Postfix instead:

1. Turn off Sendmail:

   service sendmail stop

2. Start up Postfix:

   service postfix start

3. UPDATE: You’ll also probably want to have Postfix start by default at boot time:

   chkconfig postfix on

Then I sent a couple of messages to make sure everything was working properly, using tail -f /var/log/maillog to watch the results. Now, to get really cool, I decided to add a hook for NetworkManager to take care of reconfiguring Postfix on the fly to automatically defer SMTP activity when offline, and to turn off that deferment and flush the waiting queue when returning online. I simply installed a script into /etc/NetworkManager/dispatcher.d that looks like this:

#!/bin/sh
 
if [ "$2" == "down" ]; then
    ( /usr/sbin/postconf -e 'defer_transports = smtp' \
      && /sbin/service postfix reload ) || :
elif [ "$2" == "up" ]; then
    ( /usr/sbin/postconf -e 'defer_transports =' \
      && /sbin/service postfix reload \
      && /sbin/service postfix flush ) || :
fi

Enjoy!

Brings us the smiles.

There’s a great video on YouTube featuring a lovely bunch of Fedora contributors from Latin America showing their community spirit. “Eu sou Fedora!” Nice to be able to put a couple faces to names where I hadn’t seen them before, and it looks like the FUDCon in Latin America has invented a new cheer.