Posted by Tom Moertel
Fri, 13 Aug 2010 04:38:00 GMT
For those of you who use Emacs, Git, and Fedora Linux, I have just pushed emacs-magit-0.8.2 to updates-testing. (This package brings the wonderful Magit mode for Emacs to Fedora). For now, you can install it with yum by enabling the updates-testing repo:
sudo yum install emacs-magit --enablerepo=updates-testing
Posted in programming
Tags emacs, fedora, git, magit
no comments
no trackbacks
Posted by Tom Moertel
Sun, 05 Jul 2009 16:42:00 GMT
It seems that every time I upgrade Fedora on one of my workstations,
anaconda somehow manages to screw up the bootloader configuration,
and when the upgrade is “complete” and the system reboots, I’m
left starting at a GRUB prompt. So this is a little note to myself
for how to fix the broken configuration. (If you find my note helpful, great, but if you try anything in it, you do so at your own risk.)
First, find out where GRUB thinks the /boot partition is:
grub> find /grub/grub.conf
find /grub/grub.conf
(hd0,0)
(hd1,0)
Here, GRUB found two potential /boot partitions, which is actually
correct because I keep /boot on a RAID-1 md device and GRUB is
finding the device’s underlying partitions.
Next, tell GRUB to use the desired /boot partition as its root device:
grub> root (hd0,0)
root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd
Finally, tell GRUB to set itself up on the hard drive that contains the partition (which, for my workstations, is the correct place):
grub> setup (hd0)
That’s it, all done.
At this point, you can tell GRUB to “boot” using the configuration or “reboot” from scratch to test the configuration from a system restart.
Posted in linux
Tags fedora, grub, linux, note, self, sysadmin, to
1 comment
no trackbacks
Posted by Tom Moertel
Wed, 04 Feb 2009 04:45:00 GMT
After reading about the ordeal a paying customer went through attempting to
get Adobe to fix a simple
mistake, I
was reminded of why I lost my faith in proprietary software. After a
bad experience reinstalling
Win2k, it
dawned upon me that software vendors could waste my time, make me jump
through hoops, and sell me barely functional crap, and all I could do,
as a paying customer with a valid license, was take it.
This poor guy, for example, ordered a Mac OS X version of Flash CS3
and got sent a Windows version by mistake. Not his fault. But he’s
the guy who ended up wasting weeks fighting Adobe’s ineffective
customer support trying to get what he paid for in the first place.
This guy is a paying customer. He paid for that treatment.
Look, folks, the world of open source isn’t perfect, but it’s better
than that. Since dumping Windows for Linux, here’s how much
time I’ve wasted on stupid vendor hoop-jumping: None. Nada. Zero.
In the world of open source, you never have to worry about getting
stuck with the wrong version of software. That’s because you are
always free to download the right version. No need to ask for vendor
approval, fax in your “Letter of Destruction”, or wait for an
activation code. You just type in “yum install whatever”, the software installs, and you go back to work. That’s it.
Until I switched to the open-source lifestyle, I never realized how
much time (and blood and sweat) I had wasted on the side effects of
proprietary software. If you’re still in the proprietary world, take
a moment to consider how much time you have wasted and how much time
you will waste in the next few years on stupid vendor crap. Maybe
it’s time to stop jumping through hoops. Maybe it’s worth your while
to give open source a shot.
Go ahead, grab a Fedora Live
CD and test drive it for a few
days. What have you got to lose but a world of hurt?
Posted in rants
Tags adobe, fedora, freedom, linux, proprietary
22 comments
no trackbacks
Posted by Tom Moertel
Mon, 02 Feb 2009 17:22:00 GMT
Do you use Emacs? Do you use Git? If so, check out Magit, a delightful Emacs
mode that provides a convenient interface to working with Git. Unlike
many VCS modes, Magit is fully Git-centric: It understands the Git
way of branching, staging, committing, history-rewriting, tagging,
merging, pushing and pulling. It even knows about the reflog and has
some git-svn support.
If you’re a Fedora user,
just install the emacs-magit package. The package is currently in
testing, so install it with the following command:
$ sudo yum --enablereo=updates-testing install emacs-magit
One more thing, Fedora users: please don’t forget to provide
feedback on the package. It’s easy:
- Just visit the emacs-magit page in Bodhi
- Click on the package you installed (e.g., the Fedora 9 or 10 flavor)
- Add a comment, selecting “Works for me” or “Does not work” as appropriate
Hack on!
Posted in programming
Tags emacs, fedora, git, magit
1 comment
no trackbacks
Posted by Tom Moertel
Wed, 31 Oct 2007 04:35:00 GMT
I just got a Palm Centro smartphone, and I love it. Getting it to sync
with my Linux workstation, however, was tricky, so I’m posting this
recipe in hopes that it might save you some time.
The “visor” kernel driver is supposed to make compatible Palm
handhelds look like serial devices when attached via a USB cable. For
me, it didn’t work. Instead, I had to blacklist the driver and
then use libusb to talk to the Centro. Here’s the recipe:
First, blacklist the “visor” kernel driver:
# echo blacklist visor >> /etc/modprobe.conf
# modprobe -qr visor
Second, make sure libusb is installed:
# yum install libusb
Third, edit the system’s udev rules to make sure your user account can
access the device files used to talk to the Centro. On my Fedora 7
setup, I found the right rule in /etc/udev/rules.d/50-udev.rules:
ACTION=="add", SUBSYSTEM=="usb_endpoint", \
ATTR{bEndpointAddress}=="?*", ATTRS{devnum}=="?*", ATTRS{busnum}=="?*", \
NAME="bus/usb/$attr{busnum}/$attr{devnum}_ep/$attr{bEndpointAddress}", \
MODE="0644", SYMLINK+="%k"
I edited the last line of the rule, changing the mode to 0664 and adding
a GROUP key to assign the Centro devices to my exclusive user group:
MODE="0664", SYMLINK+="%k", GROUP="thor"
This change lets my account talk to the Centro without having to
take on root privileges. (For bonus points you could set up a more-specific rule to match just your Centro. The rule above, as is, will actually match other devices, too.)
Fourth, tell udev to reload the rules:
# udevcontrol reload_rules
Finally, set up a Palm-device connection via gnome-pilot. Be sure to
select USB for the Type and “usb:” from the Device drop-down list.
That’s it. If you’re lucky like me, you should now be ready to
hotsync your Palm Centro!
Update: Even better, this handy HOWTO shows you to
sync via Bluetooth, which is more convenient than hooking up a USB
cable. I’m now using this method.
Update 2: If you want to use USB to hotsync your Centro, there is a
method that’s more convenient than setting up udev rules. Just create a perms file for
pam_console_apply that tells it to give the console user permission to
access your Centro. To do so, create a file
/etc/security/console.perms.d/60-libpisock.perms and put the following in it:
<libpisock>=/dev/usbdev* /dev/bus/usb/[0-9]*/[0-9]*
<console> 0644 <libpisock> 0644 root
That’s it. (You’ll still need to use libusb.)
Posted in linux
Tags centro, fedora, hotsync, linux, palm, usb
6 comments
no trackbacks
Posted by Tom Moertel
Wed, 25 Apr 2007 18:07:00 GMT
Just a quick note for folks using the R statistics
system on Fedora
Linux. I have packaged for Fedora a
bunch of R packages from the CRAN. (R
packages have to be packaged again, as RPM packages, to integrate with
Fedora Linux.)
My initial goal was to package
arm,
which contains tools for working with various regression models.
(This package accompanies Andrew Gelman and Jennifer Hill’s wonderful
book Data Analysis Using Regression and Multilevel/Hierarchical Models.)
Packaging “arm,” however, quickly snowballed into packaging a bunch of
prerequisites. Thankfully, I have now completed that task and can
share the fruits of my labor with you.
All in all, to install “arm,” you will need the following RPMs:
- R-arm-1.0-2
- R-car-1.2-1
- R-lme4-0.9975-1
- R-Matrix-0.9975-1
- R-R2WinBUGS-2.0-1
The following RPMs are optional (but you will need them if you
want to rebuild the RPMs):
- R-coda-0.10-1
- R-leaps-2.7-1
- R-mlmRev-0.995-1
You can download the packages from the RPMs
section of the Community
Projects site. Better yet, you can use Yum to
download them for you. Just add the moertel-community
Yum repository to your /etc/yum.repos.d directory (see RPMs for the recipe) and then use the
following command:
$ sudo yum install R-arm
Yum will automatically resolve dependencies and install the required
packages. If you want any of the optional packages, add them after
“R-arm” on the command line.
I have built the packages for Fedora Core 6 on the x86_64 architecture, but the
RPM specs are available
if you want to rebuild the packages for other architectures. (See
the instructions for rebuilding RPMs for help.)
Caveat:
I’m not sure that the R-R2WinBUGS package is fully functional. It
depends on BRugs, which doesn’t yet build on the Linux platform. To
get around this problem, I made R-R2WinBUGS’s dependency on BRugs
weak; the first package no longer requires the second to install.
Posted in statistics, linux
Tags fedora, R, rpms, statistics
no comments
no trackbacks
Posted by Tom Moertel
Tue, 17 Apr 2007 07:45:00 GMT
Today I wanted to extract the data that were visualized in a
chart I saw on Seth Roberts’s blog. That is, I had a picture of a data set, and I wanted the numbers behind the picture.
This task turned out to be surprisingly easy – once I found Engauge Digitizer, an open-source (GPL) tool made for this very task. After I launched Engauge, the digitization process was straightforward:
- I established the chart’s coordinate system by clicking in the corners and entering the associated coordinates.
- Then I had Engauge identify data points. With the mouse, I selected a data point by hand, teaching Engauge what a point looks like. Then Engauge identified spots on chart that looked like data points and locked on to them. I was able to step through the points to tell Engauge to skip the few it misidentified.
- I manually selected a few more data points that were scrunched into blobs and had eluded Engauge’s point-detection heuristics.
- Finally, I exported the data set in CSV format.
If you ever need to extract the data behind a chart, do check out
Engauge Digitizer. (If you use Fedora Linux,
you’ll be happy to know that I have packaged Engauge for you.
Get it at the RPMs section
of the community site.)
Posted in statistics
Tags charts, data, fedora, plots, rpms, statistics, tools
no comments
no trackbacks
Posted by Tom Moertel
Wed, 09 Aug 2006 04:35:00 GMT
If an extended power outage drains your UPS, and your servers are
forced to shut down, will they automatically start up again when the
power is eventually restored? It’s a good question, especially
if your servers are in some distant, unattended server room.
Unless you’ve tested your servers, don’t assume that the answer
is Yes.
Many servers offer a BIOS configuration option that forces them to
automatically power on when they receive line voltage. If your
servers have this option, just set it and you’re done.
Unfortunately, some servers, including a Dell PowerEdge 1600SC
that I’m using, lack this configuration option. When these servers
turn themselves off as the final step of a UPS-controlled
shutdown, they don’t start up again when the power is restored.
Because they were shut down before the power was cut off, they think
they are supposed to remain off when the power is restored. That is,
they remember their on/off status across power outages.
Fortunately, there is a way to make sure these servers automatically
power on: shut them down without powering them off; halt them
instead. That way, when the UPS finally cuts off the supply voltage,
the servers will still be in their “on” state, and they will remember
this state across the outage. Later, when the power is restored, the servers
will automatically restore their pre-outage state and power up.
With Fedora Core Linux and Network UPS
Tools, it’s not difficult to make
sure the servers are halted instead of powered off, but the implementation
isn’t obvious. To spare you the digging, here are the
important bits.
- When the power fails and the UPS-monitoring software decides that
the batteries are almost depleted, it will initiate a server shutdown
using the command defined in the
/etc/ups/upsmon.conf
file. The default command is this:
SHUTDOWNCMD "/sbin/shutdown -h +0"
- The shutdown command will tell the
init process
to enter runlevel 0, which is the prepare-to-halt-the-system runlevel.
- The
init process will stop all of the running
services in an orderly fashion, and then, as the last step, invoke the
final script in the shutdown process:
/etc/rc.d/rc0.d/S01halt.
- The final lines of the
S01halt script will
power off the server. Unless, that is, the file /halt is
present, in which case the script will halt the server instead.
Thus the trick is to make sure that the /halt
file does exist. The trick turns out to be easy to pull off;
just redefine the shutdown command in /etc/ups/upsmon.conf:
SHUTDOWNCMD "/bin/touch /halt; /sbin/shutdown -h +0"
And that’s all there is to it!
Posted in linux, hardware, sysadmin
Tags fedora, halt, hardware, linux, nut, power, shutdown, ups
2 comments
no trackbacks
