Ever find yourself with your iPod and no way to actually hear it? Have a laptop with a linux distro on it? All you need it a standard 1/8′ mini stereo cable (on both ends) and you can have your laptop act as a play-through device under Linux.
Having recently received an iPod, I cruised in to work enjoying my music collection with the iPod connected to the AUX port on my car via a standard 1/8″ mini stereo cable (like the headphone connection, but on both ends of the cable).
I walked in to work, powered on my laptop, only to realize I left the USB cable at home. Ugh. And no external speakers. Ugh. And I didn’t have the ear buds. Ugh. There was no available way to actually listen to what was on the iPod. I did have the pass-through cable from the car, and this laptop has a microphone jack, so I knew this could somehow be done. I tried a couple of player applications, but those were more complex than what I needed and they were unable to set up the microphone jack as a pass-through device to the speakers. After a little digging, the solution presented itself in the most simplistic manner: I realize that I could use ‘rec’ to record the input from the microphone to standard output and pipe it to ‘play’ to simply output it to the speakers. Viola! It works.
rec -r 44100 -t wav -q – | play -t wav -q –
The one thing to be aware of is that you will need to unmute your microphone input. By default, most Linux distributions have it muted by default.
Even if you have more than one system, the benefits of having your own local mirror of RPMs are substantial: faster updates, better synchronization of system packages, etc. It’s also pretty easy to do.
Install createrepo via yum: yum -y install createrepo
You might as well install “repoview”, too:
yum -y install repoview
Install rsync via yum if you don’t have it installed already: yum -y install rsync
Pick a file system and directory to contain your copy of the repository. Remember, this repository will only grow over time, so take that in to consideration. You don’t want to pick a volume that will cripple your entire system if it fills up. In this example, let’s use /export/repos, and create the following directories:
/export/repos/6/x86_64
/export/repos/6/i386
Edit /etc/exports to contain:
/export/repos *(ro,sync)
Start the NFS server process:
/etc/init.d/nfs start
chkconfig –level 345 nfs on
Mount the file system on all of your hosts. I personally use automounter, but it is not required:
mount myserver:/export/repos /home/repos
Put together a small script (I have a sample one attached to this post) which will rsync the repository from a known good mirror source to the directory you created in step 3. (rsync_repos.pl)
if [ “$2” = “32bit” ] || [ “$2” = “all” ]; then
##
# Sync up the ‘updates’ tree for the 32bit distribution.
##
/bin/nice /usr/bin/rsync $RSYNC_OPTIONS \
$RSYNC_HOST/i386/ $MIRROR1 \
>> $OUTFILE
##
# Build the repo data
##
if [ “$CREATEREPO” = “1” ]; then
/usr/bin/createrepo -q $MIRROR1
cd $MIRROR1
/usr/bin/repoview -q .
cd /
fi
fi
if [ “$2” = “64bit” ] || [ “$2” = “all” ]; then
##
# Sync up the ‘updates’ tree for the 64 bit distribution
##
/bin/nice /usr/bin/rsync $RSYNC_OPTIONS \
$RSYNC_HOST/x86_64/ $MIRROR2 \
>> $OUTFILE
##
# Build the repo data
##
if [ “$CREATEREPO” = “1” ]; then
/usr/bin/createrepo -q $MIRROR2
cd $MIRROR2
/usr/bin/repoview -q .
cd /
fi
fi
Update your yum repo files to point to your local copy of the repository and disable the external ones:
Disable the Fedora “updates” repo /etc/yum.repos.d/fedora-updates.repo:
Change all of the entries to contain “enabled=0”
Create a cronjob to sync your repo and the known-good repo mirror nightly:
crontab -e
00 04 * * * /home/root/bin/rsync_repos.pl -d all -r
In my case, I figured the one to keep sync’ed was the one that changed the most: the updates repository. However, your mileage may vary, and you can apply the above to sync’ing just about any repository. I also chose one that used ‘rsync’ versus having to script a bit “wget” or another web mirroring tool.
You get the general feeling that the force is against you. You’re running EXT3, an extension to the old and stable ext2, for that extra buffer: journaling. In the simplest of terms, ext3 prevents those enormous boot-up delays when the volume needs checking due to a crash or other circumstances. EXT3 has the ability to recover the state of the volume from the journal, and, viola! Your boot up is very quick.
However, you’ve now found you’ve been running that server of yours for half a year (180 days) or more and you are happy. You now have the itch to change something which requires a reboot. It pains you to lose that uptime, but the gains are better than holding out for greater up time. You do the necessary work, boot up the machine, and are greeted with a message stating that the volume has gone unchecked for greater than 180 days followed by the dreaded words check forced. This now makes you sit there as it falls back to using the old ext2 file system check that takes forever on large drives.
Unless you formatted these drives by hand, you would never have seen the warning message:
This filesystem will be automatically checked every 24 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Most GUI’s and OS installers hide this information.
So, the trick is to nip this one in the bud by disabling the check. You don’t need it anyhow. Really.
tune2fs -i 0 /dev/hdb1
And your system will never force a check of the volume unless you tell it to.