This week, “Infrequently Asked Questions” takes on procmail, permissions, and troubleshooting sound.
Testing Procmail filtering rules
Procmail can be used to deliver email locally and is often tasked with automatically filtering and sorting email. It works really well, but creating the right rules can be a small challenge even for the professionals. You could test your newly made rules on live incoming email, but you may end up trashing something that you really need by accident. It’s better to work on some messages you already have stored as copies. Here’s a way to test procmail filters without loosing email. We’ll work with mbox-format mail. Procmail also supports the Maildir format, but old-style mbox files keep multiple messages per file.
Select one message you want to test and save it to an empty mailbox. Just saving an email to a text file will not preserve headers, so use your mailer to duplicate the message to a new mailbox. Then open the new mailbox with a text editor and, if there’s a first message with the subject “DON’T DELETE THIS MESSAGE”, added by the mailer, remove that.
Now, create your procmail recipes and save them in one file, procmailtest.rc. Here’s an example that tries to filter all incoming email from the domain “bad.host” to a mailbox called “thrashcan”:
# $HOME/procmailtest.rc VERBOSE=on LOGFILE=$HOME/procmailtest.log DEFAULT=$HOME/procmailtest.mbox THRASHCAN=$HOME/procmailtest.thrash :0 * ^From:.*@bad.host $THRASHCAN :0 $DEFAULT
Now run:
cat that_mailbox | formail -s | procmail -m ~/procmailtest.rc
Look at your ~/procmailtest.log logfile for all the information to determine if your new recipe is working or not.
–unSpawn
Restoring permissions
This is proving to be a long day. I was installing a new package and screwed up. The install process went through / and changed the owner and group of ALL files to root/root….Any help?
Someone keeps yelling in your ear, your baby Anaconda settles for your right leg instead of her own food or you were just thinking of something else. In any case, a typo can ruin your filesystem’s permissions. If your favorite distribution comes with good package management tools you can restore them easily.
Here’s one way for restoring permissions of all files using the RPM package manager. If you only need to restore permissions for one package (say it’s Aide) you replace “rpm -qa –dump” with “rpm -q –dump aide” and if you would need to restore all permissions in say “/etc” you would use “rpm -qa –dump|grep ^/etc”:
rpm -qa --dump|while read line; do t=( ${line} ); for n in 3 4; do case "${#t[$n]}" in 7) chmod ${t[$i]:3:4} ${t[0]}; chown ${t[5]}.${t[6]} ${t[0]};; esac; done; done
Of course there are distro-agnostic ways of restoring permissions. For this I’d like to introduce Aide, the file integrity checker. It’s one tool you could use to monitor changes and I’d like to recommend running it (or Samhain) to any security-conscious GNU/Linux user. Here’s a way to extract information from it’s database to restore permissions:
zcat aide.db|egrep -ve "^(#|@)"|while read l; do l=( ${l} ) [ "${l[1]:0:1}" = "/" ] && chmod ${l[3]:2} ${l[0]}; chown ${l[5]}:${l[6]} ${l[0]} done
As is usually the case, there are caveats. Package managers only know about files that are packaged, and file integrity checkers need to be configured and run before you can use them. See the link to Aide for more information.
–unSpawn
Troubleshooting sound
I can’t get sound working – how can I fix this?
Nvidia onboard sound not working thread
While in many cases sound will work right out of the box, sometimes a bit of manual tweaking may be necessary, and getting an uncooperative audio device to work under Linux usually comes down to one of three issues: the hardware itself, a missing kernel module, or a configuration issue.
First, verify that everything is connected properly: Are the speakers turned on and is the volume knob turned up? Is the speaker cable plugged into the appropriate jack on the soundcard? Is the small cable running between the CD drive and the sound card present and connected correctly? Is the volume muted in the audio app itself? If you have a mixer or volume control in your desktop panel, turn that up, too. If you don’t have or don’t choose to use a GUI mixer, run “alsamixer” from the shell, and use the cursor keys to turn everything up. All of these things may seem obvious, but it’s worth taking a few minutes to verify that a simple problem isn’t the source of the trouble.
Next, verify that the appropriate module has been loaded. If you’re unsure of exactly which soundcard you have (which often can be the case if you are using the onboard sound) run “lspci” and look for the Multimedia Audio Controller. To determine the appropriate driver for that device, check out the very thorough list of popular soundcards and their associated drivers that the ALSA Project maintains.
Once you’ve determined your soundcard and driver, run lsmod | grep , substituting the particular driver name in place of “
Editor’s note: If the driver is installed on your system but not showing up in lsmod, check to see that you have the correct packages installed, and to see if your distribution has issued an update to the kernel or to the ALSA utilities since you installed Linux. Except for very uncooperative hardware vendors and very new sound cards, the driver you need should already be part of the kernel and already packaged in your distribution. Run your distribution’s package management tool, and check that you have a current kernel, and that the ALSA packages are installed. (on this Ubuntu system, the packages are: alsa-base, alsa-utils, alsa-oss, and alsa-tools). There should be an init script for ALSA in /etc/init.d, so run it with the “restart” argument to stop and restart ALSA. You may need to turn sound back up in your mixer of choice after doing this.
If there are no results, then you will need to manually download the driver and install it. Check the manufacturer’s website (note that different vendors have different levels of Linux support), and if you’re using onboard sound, you may need to go to the chipset manufacturers’ website to locate the driver. For example, if you happen to have an nVidia chipset, you can get the latest nForce drivers here. Once the driver has been installed, you may need to run “insmod” or “modprobe” to load it.
Lastly, run “alsaconf” which will attempt to configure your soundcard. If all goes well, you will hear a short “ta-da!” fanfare indicating success. If you still have silence, run “alsamixer” which controls the various sound levels for the different inputs and outputs. By default the settings are muted, so use the arrow keys to raise the volume, and be sure to use the right arrow key to navigate through all the different settings. Raising the levels to about 50% should be adequate; you can always come back and adjust them later if necessary. Once your volume settings are to your preferences, you can save them by running “alsactl store” as root.
If you still encounter silence and you’ve got a soundcard installed as well as onboard sound, get into BIOS to verify that the onboard sound is disabled. If they are both enabled, that sometimes can cause a conflict. Finally, if none of the above has resolved the issue, then my last suggestion would be to check the permissions of /dev/dsp and /dev/mixer. The should both be set to rw-rw-rw- and if they are not, you can fix that by running “chmod 666 /dev/dsp” and “chmod 666 /dev/mixer”.
— J.W.
