• Fedora project’s Package_update_HOWTO
• Fedora project’s Using_Fedora_GIT
• For know that I need a new version of fedora-packager
• and this for let git push to the branch you are tracking

Unfortunately, there still seems to be some issues:

Cloning into bare repository /cvs-scratch/fedora/opensc/fedpkg.git...
open log failed: Permission denied
fatal: The remote end hung up unexpectedly
Could not clone: Command '['git', 'clone', '--bare', 'ssh://me@pkgs.fedoraproject.org/opensc', '/cvs-scratch/fedora/opensc/fedpkg.git']' returned non-zero exit status 128

I’m not sure what this means. But the old CVS repository doesn’t seem to be usable either, which kinda stinks. I’m sure it’s just a minor buglet or two and will get worked out eventually. Very very happy that we’re no longer using CVS for this… I’d prefer SVN myself, but git is ok too.

Dear lazyweb, how can I make this system as quite on Fedora as it is on Windows? It’s absolutely silent when Win7 is running, but when Fedora is running the fans are quite noisy. Most of the time the system has a load average of 0.00 so it isn’t CPU spiking causing the fans to go full-bore. For temperatures I have Core0 at about 51C and Core1 at 44C and the other two cores at 48C, but the fans are running at 1583 and 1160 rpm. I can’t get the sensors to pick up temps or fan speeds on Win7 for some reason so don’t have a basis for comparison (tried a few of those “gadgets” and none show me temperatures).

There has to be a way to lower the fan speed on Fedora but I can’t find it. I tried fancontrol from lm_sensors but it complains about not being able to manually set the fans and there’s nothing I can see in the BIOS that’s even remotely relevant.

Am I doomed to a noisy Fedora box? Or is there a way I can make this thing quieter short of buying new fans? (The latter is an option I suppose, but if Win7 can run perfectly silent, then I’m of the frame of mind that Fedora should too). Running an up to date F13 (wheeee!!). Thanks for any suggestions.

Anyways, one of my favourite features in Annvix was being able to run the entire system out of runit (Annvix used runit in place of SysVinit). This gave us nicely supervised services using runit (much like DJB’s daemontools). Feeling crappy with the first day of a head cold, I spent some time today over lunch to get runit working with RHEL5. I had to re-tool the package since I don’t want it to replace SysVinit, but run under init and just supervise services (like sshd, exim, etc. — call me weird, but runit/daemontools makes a fantastic watchdog and with sshd running from tcpsvd, I get some nice ACLs to use as well).

At any rate, runit now installs and works properly. Sorry to anyone who wanted to use it (I’ve been meaning to do this for the last year, ever since I switched all of my servers over to CentOS). The runit package also comes with a bunch of run scripts; I’ve not tested them all yet so if you do end up using it and have issues, let me know. I did have to fix a few minor things in a few of them.

At any rate, I’ve chkconfig’d off a few services and have them running supervised now:

# srv --list|grep -v '-'

service                   status   pid      started
crond                     up       2737     04/07/2010 02:16:32 PM
crond/log                 up       2735     04/07/2010 02:16:32 PM
exim                      up       2747     04/07/2010 02:16:32 PM
exim/log                  up       2746     04/07/2010 02:16:32 PM
mdadm                     up       2738     04/07/2010 02:16:32 PM
mdadm/log                 up       2736     04/07/2010 02:16:32 PM
ntpd                      up       2733     04/07/2010 02:16:32 PM
ntpd/log                  up       2731     04/07/2010 02:16:32 PM
smartd                    up       2739     04/07/2010 02:16:32 PM
smartd/log                up       2734     04/07/2010 02:16:32 PM
sshd                      up       2732     04/07/2010 02:16:32 PM
sshd/log                  up       2730     04/07/2010 02:16:32 PM

One thing knocked off my TODO list. Replaced it with going to bed early tonight.

Currently Fedora is third at 8% with Ubuntu leading at 35%, and Debian in second at 10%.

Show these people some Fedora pride!

Congrats Fedora developers, users, testers, QA guys, and the many many many other people I’m forgetting. I don’t mind saying that I used to hate Fedora, but I think I was biased with years of Mandriva and just plain old not being used to it. Now that I’ve used Fedora 10, 11, and now 12, I can honestly say that I’m a great big Fedora fan now (and, seriously, if you’re still reading my gushing and haven’t started downloading, get cracking because it’s worth it!)

So I think this might be a good move. rsec is essentially a complete tool, but if we can swap in msec’s plugin functionality for the reports and make it so that is can be a standalone component separate from msec (be it that msec drops the reporting capabilities and adopts a refreshed rsec as a dependency, or whether msec permits building just the reporting capabilities separate from the msec stuff), then I’m definitely game. What might be interesting, however, is to see how msec and rsec can be merged with sectool in some way. To be honest, I’d never heard of sectool until Eugeni mentioned it… it’s a Fedora project so it might have a lot of Red Hat/Fedora-specific stuff in there, but if it is or could be more generalized to do what msec does as well as what rsec does, then maybe there’s a place for one tool to take the place of three tools and have a broader usage base and become a better tool.

The opportunity here to build a better tool out of two, or maybe even three, tools is quite interesting and one of the things I love about open source. Merging msec and rsec should be quite easy I think. Merging with sectool might be more difficult, but I see a lot of crossover in what msec and sectool both do already — there really is no reason to have a Mandriva-specific tool and a Fedora-specific tool that do the same thing. I suspect sectool might be good at creating decent reports which may even obsolete the need for rsec. Taking a closer look at sectool will help me determine if that is the case (and then it remains to be seen if there is a sectool build for EPEL or if it can be done since I’m currently using rsec on some Red Hat Enterprise Linux 5 and CentOS 5 systems).

Either way, I smell some possibilities here.