For awhile now I've noticed that things in my home dir aren't setup optimally for my work flow. I've been trying to run with SELinux enabled and I run into development problems when I try to run web applications out of my home directory. Various parts of my home directory are version controlled separately due to the software projects they're part of, but not as a whole.

What I'd like is to setup some other place for "projects" (Mozdev code and docs, other software projects, RPM building, etc) and then version control my home dir.

The problem is I'm not sure how much this helps me. Things like IM clients still are going to want to log things to ~/.somedir/log which is evil. SELinux contexts for files in /home/myprojects is still going to be wrong; I'm not going to be able to run webapps out of there, either. Moving my docs out of my home dir might be a pain due to xdg-user-dirs needing to be setup correctly to point at the document dir

I'd really love to have a lean, mean homedir that is version controlled that I can port around between boxes. Have people attempted this before? What about the above problems?

by Wellington Grey

Jocelyn's definitely going to be a vi user; when she's done typing she immediately hits 'escape' and will pound 'escape' repeatedly when things aren't acting the way she thinks they should.

I finally have all my boxes upgraded to F8 (via yum; viva la Live Upgrage SIG!). It really wasn't as bad as I anticipated, and in fact, probably much better than my anaconda-based upgrade for F7 since I had all my third-party repos enabled for the upgrade and didn't have many stragglers after it was all done.

Two of my home servers were still running FC-6 (!!). These boxes presented some problems getting upgraded since they were running some more esoteric package sets. My one server gave me fits of problems with getting unmet dependencies for packages that clearly existed. This one was an x86_64 box and was giving me a "missing dependency" for glibc.i686. /me shrugs. "yum upgrade" rather than "yum upgrade yum* rpm*" seemed to get it fixed. I did have to remove a number of packages beforehand, but that didn't bother me much.

Overall I am very impressed with the F8 release. My statements earlier about Fedora not having enough direction were apparently completely without merit, or were just the result of not having enough first-hand experience with what had been going on. Hopefully I'll be able to give a bigger hand to development for F9 and keep the great work going.

echo setterm -powersave off -powerdown 0 -blank 0 >> /etc/rc.local

Yesterday Kevin and I swapped in some 250G hard drives for our old 80G drives. The 80G drives were setup in a RAID-1 configuration. With our recent upgrade to CentOS 5 we gained the ability to do online growing of RAID-1 arrays, so it was a good time to upgrade (actually, it was planned that way ;-P).

So the first step was swapping the new drives in and letting the array resync each time. When replacing the drives, we also modified the partition so it utilized the entire disk.

Old disk:
/dev/sdb3 : start= 2313360, size=158513355, Id=fd

New disk:
/dev/sdb3 : start= 2313360, size=486078705, Id=fd

Then, all was required was to re-add the disk to the array to get it syncing:
$ mdadm --manage --add /dev/md1 /dev/sdb3

After each drive was finished syncing, we needed to get grub setup on the device again to use its own copy of /boot (props to the Dell Software Raid and Grub HOW-TO).
$ grub
> device (hd0) /dev/sdb
> root (hd0,0)
> setup (hd0)

These steps were performed again for the other drive.

After both new drives were in, it was time to grow the RAID-1 array:
$ mdadm --grow /dev/md1 --size=max

After the array finished syncing, it was time to resize the filesystem:
$ resize2fs

And that leaves us with a much larger root partition! Where it was 90% full before, it's now 30% full:

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md1              229G   64G  154G  30% /

My recent blog post about direction and online updates sparked some interest - and some interesting discussion. Through that discussion, I wanted to post some clarifications and concessions about the original article.

Concession: I wasn't correct about my statement that Fedora has a "lack of direction" - it's direction is exactly that its maintainers can try to do what they want to improve the distribution.
Clarification: Fedora is not an easy place to get along at - Just read fedora-devel list and you will find that most people post messages that are incredibly selfish and full of negativity - this doesn't feel like "community" to me. Even in my discussion on the #fedora-devel channel, my previous post was immediate construed as "OMG apt-get rulz FTW" fanboy love instead of the actual criticism that online updates should be supported. It still took an hour of discussion to get it understood what I was desiring and for some agreement and constructive ideas to come around
Concession: apt-get upgrade might not rock - I don't have strong experiences here and shouldn't have stated that it was great.
Clarification: Fedora should support online upgrades - "Online upgrades" means you can upgrade from release X to release Y without needing to reboot into some installer (rebooting for a new kernel or FS changes are fine). Fedora does have the YumUpgradeFaq wiki page, but the very first bullet point is Don't. This mentality needs to change in order for online upgrades to succeed.
Concession: someone needs take charge to make online updates happen - As gregdek pointed out, things don't change if someone doesn't champion it. At the same time, OSS is not only about "scratching your own itch", it's about community. Just because a user requests a feature doesn't mean we should expect the user to implement it every time.
Clarification: I'm excited about Fedora, and I'd love to help make it be better - I've been a Red Hat user for 8-9 years; and I've tried other distributions in the past. The issues I've pointed out are the ones that have been bugging me for awhile now, and the ones I'd like to see changed. I wasn't really prepared for the first reply to my blog to be "well do something about it", but they're right.

I had a good discussion with skvidal, wwoods, f13, gregdek, and others in #fedora-devel about how upgrades currently work, the progress being made towards media-less upgrades, and the problems faced by online upgrades. I hope to have the ideas and concepts laid out into a wiki page soon where everyone can contribute their ideas on how to improve things.

I'm also a little disappointed that no one made it to my last point - or perhaps they were so enraged by my first two points that they just stopped reading - about packages with optional features. I know it's been discussed a little bit on the fedora-devel list, but I have no idea what it would take or what maintenance would be like. That's probably something else I should work on writing ideas down about.

Some of the biggest problems I see in Fedora these days are the following:

1. Lack of direction

   Since Fedora is a distribution for developers by developers in order to test out new technology, the main tree ends up being a hodge-podge of whatever each individual maintainer feels like working on. Unless there is an individual or small group of individuals that desires things to be a certain way, then you have to abide by those rules (take for example, no kmods in Fedora).

   If Fedora had a better sense of what it should be doing it would polarize developers along the same path rather than everyone working for their own goals.

   For example, I haven't seen any real ground-startling features for Fedora 7 or 8. Sure, Fedora 7 had "the merge", but that mostly was for maintainers benefit (arguably) and again was driven by very few people. For Fedora 8 one of the "big features" was supposed to be a rework of the init system, but that's again been pushed off. Instead we get features like "online desktop" and "NetworkManager". While these do improve user experience, they are very small nitches that don't involve developers for all of Fedora - just tiny groups of people. Everyone else is left to do whatever they want, so long as they don't piss off one of the groups that are in control.

2. Upgrades aren't supported - All hail Anaconda - the great upgraderinstaller!

   Fedora (and RHEL/CentOS) needs to be able to upgrade online, using a tool like yum (or smart, or apt - I don't really care which tool it is - right now it seems smart could handle it better than yum). Most of the other distros can do this without problems (Gentoo, Ubuntu, Debian).

3. No optional featuresets for packages - You have packages that either include the feature or do not.

I'm not sure how to fix the problems, but I do know that Fedora needs to make the following happen:

1. Make upgrades work - Even with Anaconda it wasn't possible to upgrade from FC-6 to F-7 without broken packages - an online upgrade would have arguable gone better, but it "wasn't supported". "yum upgrade" should work like "apt-get upgrade" between versions.

   With the rolling release like we've been having the past couple versions, it's very easy for someone with an up-to-date release have newer packages than are available with the release of the next version.

   Case in point: FC-6 had KDE 3.5.7, but F-7 shipped with KDE 3.5.6. Immediately after release 3.5.7 was available as an update for F-7, but an upgrade from FC-6 to F-7 wasn't supported due to libata changes (hda->sda). This stuff needs worked out so that you can update from one version to the next easily.

2. Optional package features - Offer packages that can somehow enable/disable features based on what other packages are installed. Be able to install package foo that has either mysql or postgresql support, or both - even if they're compile flags. That is to say, if I have mysql currently installed, and I install foo, I get foo w/ mysql. Or if I try to install foo without mysql or postgresql, provide some way of saying that they can be supported if you install them.

Both of these problems are hard. They require coordination across all of the package maintainers. Perhaps they're features that could polarize the maintainers to a common goal and make Fedora better.

I've had this little script laying around for awhile that I use as a wrapper for RCS to check out a group of files in one batch, edit them all, and commit them. So I setup repository for rcsedit in case others want to try it out.

It should be pretty easy to try out, just:

wget http://svn.silfreed.net/rcsedit/trunk/rcsedit

Should get you the script to use. I typically install it to /usr/local/bin. It will use your default $EDITOR if you have one defined, otherwise it will use vim. If the files exist it will check them all out (or only the ones that exist), edit them, and commit them as one batch (allows you to enter a log message once for all changes).

Let me know if you can think of any improvements.

For some years now I've relied on a script written by Lindsay Snider while at PA.net for all my backup needs. A year or so ago a presentation was done at CPLug that described the tool, and it was agreed that the script should become public somewhere so people can use it.

It wasn't really clear whose job it was going to be to setup the project publically, so it kinda just was forgotten. I was recently looking into backup tools again and decided it was time to get the tool out there and integrate my local changes into a canonical copy.

So now we have the remotebackup project with a public SVN tree.

Feel free to send any questions/comments/ideas my way for now while we work out the structure of who will be working on the project.

So, I'm still running Tripwire 2.3.1.2 (hmm.. isn't 2.4.1.2 out now?) on Argo. You know what? Maintaining it sucks.

I hear samhain is the uber-cool IDS of the day (that actually has database signing using gpg, unlike aide), but then I need to learn another IDS.

I have this RPM database; isn't there some script that can use that to verify things aren't evil? Something that checks binaries and stuff using the database, and then looks for directories and files that shouldn't exist at certain places?

What else do people use for an IDS? Or IDS' just a tool of days-gone-by and I should just learn to live in the days where no one uses an IDS to make sure their box is 0wnz3d?

My suspicions about RoR appear to be vindicated; at least by one person anyway.

I've tried to read some examples and howtos about Ruby and Ruby-on-Rails. The language seems very elegant, but I always heard that it's slow and suspected that it's ability to do lots of different things was limited. I've picked up some python recently and found that using objects for everything (mostly) works out very well. In PHP 5, OOP is very well supported (with some caveats) and if you have a firm grasp on OOP, PHP can even begin to look like Ruby (see: fluent interface).

When I rebooted my firewall the other day I ended up not being able to route via IPv6. This seemed very odd since route -n --inet6 seemed very clear that I had a default route.

I eventually found that this is a kernel bug through a message on Sixxs' forums.

So the solution for me was:
ip -6 route add 2000::/3 via 2001:4830:1600:bc::1 dev sixxs

and then add a static route at boot time:
# cat /etc/sysconfig/static-routes-ipv6
sixxs 2000::/3 2001:4830:1600:bc::1

Tonight I was able to get ejabberd up and running on Argo. I had to use the Fedora 7 package for now until I work out co-maintainership on the ejabberd package in EPEL, but it seems to be running fine.

I imported all the "major" domains - nivek.ws, pyxos.net, silfreed.net, and thtech.net. What I didn't import were some "legacy" jabberd.blah.net domains. I'm not sure if anyone was using these, but my guess is that they weren't. If you were or knew someone that was, please let me know and we'll figure something out.

At any rate, ejabberd seems to be working fine. We'll really get a test next week when people on other servers log in and I can see if s2s works properly.

Argo is now upgraded to CentOS 5.0. There was the usual amount of pain for a server that runs all possible services, but for the most part the upgrade went very well.

So far the only remaining problem is jabberd. I don't have new packages available and the old ones don't start. I guess this is a good time to upgrade to ejabberd.

Feel free to comment if you have problems with the server; or catch me on AIM.