Gadget Wisdom

It is time to talk about our Fedora 11 server migration. Why, do you ask, are we discussing this three months after Fedora 11 was released, halfway to the release of Fedora 12?

We finally upgraded our server to Fedora 11 this morning, after a weekend of work. In previous generations, we’d offloaded all of the data, formatted all the drives, and installed the new OS. And we, to keep up, would have to do this every 6-9 months, every time a new Fedora release came out. And our data kept growing. When you are storing many gigabytes of information, trying to slowly offload to a 4.3GB DVD is a slow process.

This weekend, we threw in the metaphorical towel, and got a 1.5TB drive and installed it in the computer. This allowed us to empty our older drives one by one and reformat them to EXT4 format. We had previously been using the more established XFS format. EXT4 is an update of the established EXT3 with improved handling for large files, among other things.

Improved large file handling is very important to us, because we use our server as a storage base for our MythTV DVR. Large file handling is required when an hour of over-the-air broadcast HD can be more than 8GB.

After reformatting all the drive to EXT4, we discovered another feature we’d never noticed before. The Reserved Block Percentage for the Superuser. A default setting, it holds back 5% of the reported available drive space for superuser privileged processes, ensuring that even if the hard drive fills up, the running processes can still do their work. Which is all well and good on an OS partition. But on a data partition, 5% of  a TB drive is almost 50GB being held in reserve. Ultimately, now that we know it is there, we left it turned it. You can override it as needed.

While we kept all the data on the data drives, although we did move around what was stored where, we did wipe and redo the OS partition completely. This is always a learning experience because as we rebuild parts of it, we add and fiddle with features, some of which are new to the upgraded OS. For example, we added an hourly run of status information which is ported to Linux’s MOTD(Message of the Day) feature so that anyone logging in receives a notification of them.

We also tried running tuned. Tuned isn’t enabled by default under Fedora 11, and it is merely an early version of a project that should be fully realized in Fedora 12. For several versions, Fedora has been auditing programs to look for redundancy or inefficiency. One of the most solid examples of that was a goal of a 20-second boot time.  There is an apparent lack of good discourse on tuned that we found, but the service will allow cpu, disk, and net devices to adapt dynamically to usage, reducing power, according to profiles set.

Tuned, unfortunately, kept bringing down our network link, causing hiccups. For now, we’ve turned it off. Power Management is a goal we aspire to. We want constant availability with low power usage, which means a service that turns things off when not in use. We look forward to the next generation of this program, when it may be enabled by default.

Since our server does not run a graphical environment by default, nor does it have a monitor attached normally, the experience of using it is different than most using a Linux machine. We’re always looking for things to cut from it to improve its efficiency. During this latest iteration, we cut a partition, no longer creating a separate home partition for the system. We never store anything in the home directories anyway.

You will be hearing more about our server. Our systems are the testbed for practical experiments in spinning down hard drives and other techniques to try and reduce waste. The drives are even 5400rpm ‘green’ drives, as the data doesn’t require anything faster. If you are interested in more specific details about the system, comment. We’d love to hear your feedback.

• Choosing the right Linux File System Layout using a Top-Bottom Process (slumpedoverkeyboarddead.com)
• Is There a Perfect Linux Filesystem? (daniweb.com)
• Fedora 11 – Palimpsest Saves the Day (gadgetwisdom.com)

Yesterday, those of you following our tweets know that we continued our Fedora migration plan. The plan was sidetracked when the new Fedora 11 monitoring advised us of a hard drive problem.

SMART, System Monitoring and Reporting Tool, is built into every hard drive, and does not seem to be utilized under Windows(feel free to correct us on this. It might be hiding there somewhere). Linux has always offered a monitoring daemon, but now that is coupled with Palimpsest Disk Utility, a frontend to the disk functions of DeviceKit, so alerts come to the desktop. DeviceKit is a replacement for the older HAL system, and creates a uniform interface.  “This is a simple system service that a) can enumerate devices; b) emits signals when devices are added removed; c) provides a way to merge device information / quirks onto devices.”

So, after letting it do a check to confirm, we swapped out the drive, and used it as an excuse to clean the interior of the computer and add extra ventilation, and resumed installation.

The two machines done are part of our MythTV system, where simple computers take the place of cable boxes, so nothing is stored on the drive except the software. All the video comes over the network from the backend(the last machine to get Fedora 11). But had the hard drive contained critical data, this feature would have prevented a major disaster.

In a disappointment, both machines, which run Nvidia video, did not work with Plymouth by default, but the boot on them is so fast you hardly see the splash screen anyway.

As a final measure, the remaining Fedora 10 machine will now download its updates directly from the internet, allowing us to delete our 30GB Fedora 10 Repository. The Fedora 11 machine will continue to use the assembled Fedora 11 repository.

The remaining machine is the hardest because it is where all the data is stored. Fedora Upgrade Time is a time to think about new hardware. Perhaps a hard drive might need to be replaced, etc. Migration of large amounts of data is difficult. The system must be slowly backed up and emptied, using a combination of optical burns, backup hard drives, etc. It will take a bit more work.

We continue to find new things to love about Fedora 11. The continual improvement to hardware handling is one of them. More to come.

Related articles by Zemanta

• A Peek at DeviceKit in Fedora 11 and Beyond (ostatic.com)

To our disappointment, the Fedora 11(Leonidas) launch date has pushed back by one week. As noted on their announcement mailing list….

In a meeting today between Release Engineering, QA, and various team
leads, we decided to enact a 7 day slip of the Fedora 11 release date.
The primary reason behind this slip is the state of our blocker bug:
https://bugzilla.redhat.com/showdependencytree.cgi?id=F11Blocker&hide_resolved=1 We cannot begin Release Candidate phase until the blocker bugs are closed or at least in MODIFIED state. We are not there today, which would be our last day to enter RC phase and still have enough time to release on the 26th. We hope to enter RC phase in the next couple days, and hit our new target, June 2nd.

Freeze breaks for critical bugs will still be accepted, however trivial
bug fixes should be pushed as updates via bodhi. Thanks!

Better to have a stable system than an unstable one. Here’s hoping for June release.

Related articles by Zemanta

• Whats New in Fedora 11 (slumpedoverkeyboarddead.com)
• History (and Releases) Are Cyclical: This is Fedora 11! (ostatic.com)

We continue to want to write about Fedora, especially in light of our recent inspiration. We were reading this post on a blog about the fact that Fedora 11 will have roughly 60 new features, some of which we previously summarized. The last few releases have had less than half that. Today is the feature freeze for Fedora 11.

The author predicts these features will have other distributions rushing to catch up.  The beta freeze of F11 is in a week, with the Beta release on the 24th. The final release is set for the end of May.

Every time there is a new release of Fedora coming, we wipe and reinstall every system from scratch. Our preparations begin a month in advance, when we start mirroring the complete Fedora repository and the update repository for the release, as well as our favorite 3rd-party repositories. Every night, a cron job updates any changes made.

Jigdo allows us to use those files to assemble an install image. And we maintain the repository and keep it updated to keep our systems updated. As we mentioned previously, the new DeltaRPM system will save download bandwidth.

Creating a local repository is easy. You start with your installation DVD, if you have one, and copy the packages to a directory. Then, run the createrepo command on the directory(you may have to install it). The directory should be accessible on a local web server…we use lighttpd over apache for memory reasons(but more on that another time). Then, you can edit your yum configuration files in one of two ways…adding a local only repository file, or editing the existing files to redirect to the local server instead of one of the Fedora mirrors.

To sync a remote update use a command like this…

rsync -avrt rsync://mirrorsite/fedora/linux/releases/10/updates/x86_64/ /var/www/html/yum/updates/10/x86_64

Go to the Fedora Mirror List to find mirrors that work for you.

As a final step, the Fedora Unity project releases re-spins of the Fedora releases with updated packages, as well as the Fedora Everything spin, which is a multiple DVD release of the entire Fedora repository.

With hard drive space so cheap lately, and metered internet coming into vogue, this is a decent solution. Once one has the latest distribution, one has to figure out how to distribute it to multiple systems. We start by loading it onto one system, and breaking it in before distributing it elsewhere.

More to come…

We’re devotees of Fedora Linux, despite alternatives, and the incredible popularity of Ubuntu, which we have spent some time with. But we started with Red Hat 7, and with Fedora as its successor, we know more of the ins and outs of this distribution.

Tonight, we’re using to Jigdo to assemble new DVD images, as the Fedora Unity project has released a Fedora 10 re-spin. For those of you not familiar with these things, some background.

Jigdo is a wonderful thing, and has been used by various Linux distributions for some time, and only recently as a method for Fedora distribution. The idea is this…a CD or DVD for a Linux OS is merely a compilation of various software packages and configuration files. Instead of downloading an entire image, Jigdo assembles it from its components. This has several advantages…for one it doesn’t tax any one site. Jigdo, given a mirror list, can download files from multiple sites to assemble its image.

The Fedora Unity Re-Spin is a Jigdo image of the standard Fedora installation media, using any updates that have been released since the original release. Thus, if you install Fedora 10 on a new system, you don’t then have to download a few hundred megabytes of updated files to each system. We maintain a local mirror we use to update multiple systems at one time, and using it and Jigdo, can assemble a new installation DVD in less than 5 minutes.

The glaring gap in the Fedora Jigdo release is that specialty Fedora spins are not released as Jigdo templates. Fedora offers LiveCDs and custom distributions of various types, and these are distributed only as ISOs.

Either way, the Re-Spin system is a good one, and Fedora Unity provides a service. For those of you still on Windows, check out this Lifehacker article on their equivalent, known as slipstreaming.