Answers 99

From LXF Wiki

Answers 99

<title>Gentoo renamed my PC</title>

<question>I am using Fedora Core 7; after trying out the Live CD of Gentoo from LXF96, I notice that when in a terminal the name is now root@livecd. How can I change this back to my original name? Why did it happen? </question>

<answer> It sounds like you're using DHCP to configure your network (possibly built into your Internet router). I suspect that when you booted the live CD, it said "my name is livecd, give me an IP address" Then, your router remembered this hostname and reissued it the next time it got a request from the same MAC address. If so, the answer is to have your computer send its hostname with the DHCP request, by setting its hostname in the network config. Go into System > Administration > Network, select your interface and click on Edit. Type the hostname you want to use in the Hostname (optional) box. Now Fedora will tell the DHCP server that it wants to use this hostname instead of leaving it up to the DHCP server to decide on a hostname. There may be an alternative method, depending on your router/DHCP server. Some allow you to specify the hostname or IP address given out to specific MAC addresses (a MAC address is the hardware identification for an individual network interface). If your router supports this, you can set the hostname in here ­ it should show you a list of connected MAC addresses, or you can find it by running ifconfig on the computer: the MAC address is on the first line of an interface's output, labelled HWaddr and looks like 00:50:56:C0:00:08. This method means that you will always have the same hostname or IP address whichever OS you boot on this computer, which can be either a good thing or a bad thing depending on your preferences. </answer>

<title>CD silence</title>

<question>I can't play audio CDs in either my user account or my partner's. My audio is working ­ I'm having no problems with digital tracks ripped onto my system. KsCD shows that an audio CD seems to be playing but there's no audio output. The CD is turned up to about 90 per cent in a mixer. The master is at 100 per cent and nothing obvious is muted. I did have to change the /etc/fstab so that /dev/cdrom had user, users, noauto listed. </question>

<answer>To take your last comment first, audio CDs are not mounted so /etc/fstab has no bearing on this. Most distros use automounting via HAL nowadays, so data CDs don't usually want an entry in /etc/fstab either. To your audio problem: there are two ways of getting the audio data from the drive to your sound card. The first is the traditional method of using an audio cable. This plugs into the small, flat four-pin connector on the back of the drive, and the matching connector on the sound card (or motherboard, if you have on-board sound). This is the most efficient method because all the computer needs to do is send the start/stop/etc commands to the drive; the audio simply runs down the cable where it is mixed by the sound card. The second method uses digital extraction, where the computer pulls the CDDA (Compact Disc Digital Audio) data from the drive via its ATA/SATA cable, performs any audio conversion needed and passes the result to the sound card. This is more processor-intensive, but the load is insignificant with modern hardware, and tends to be the default setup because it saves the manufacturer a few pennies per machine on cables. There is an easy way to tell if a CD drive is sending audio directly: if it has a headphone socket, plug some headphones into it. If you can hear the music, you are trying to play via a direct audio connection. KsCD does not use digital extraction by default, this has to be turned on explicitly by enabling the Use Direct Digital Playback checkbox in the configuration window. You may prefer a different media player: KsCD is OK as a basic CD player, but if you also listen to MP3 or Ogg Vorbis audio files or Internet radio, KDE's all-encompassing audio player, Amarok, may be more suitable. </answer>

<title>Console colours</title>

<question>How can I change the colour of the text and background on the Linux console in run level 3? I would like to change the colour to black text on a white background. If possible, I would like this change to be evident as soon as the kernel begins to load so all the boot messages are black text on a white background. I have a suspicion that I may need to do some kernel hacking for this and if so which part of the kernel source code would need to be changed? </question>

<answer>Changing the colours of a console can be done in two ways, once it is started. You can echo ANSI codes, provided you can remember what they are, or you can use the setterm command to make the changes. To set black on white, you would use

setterm -background white -foreground white -
store

The setterm man page contains full details of the various options and the valid colour values. You can run this command from a startup script, the details are distro-dependent but /etc/rc.local is often a good starting point. If you want to change the colours right from the start, you'll need to edit the kernel source to change the default colours and recompile your kernel. The file to edit is drivers/char/vt.c (it was drivers/char/console.c with older kernels); find the lines starting with

vc->vc_def_color         = 0x07; /* white */

This is at line 2739 in the 2.6.22 sources. The two hex digits represent the background and foreground, so 0x07 is the default white on black, whereas 0x70 would be the reverse setting that you want. Change the values to your preferred defaults and recompile your kernel in the usual way. The numbers for the various colours are

0 ................black 1 ................blue 2 ...............green 3 ...............cyan 4 ...............red 5 ...............purple 6 ...............brown/yellow 7 ...............white

Add 8 to these numbers to get the `bright' versions, but rendering of bright colours is hardware-dependent and may blink on some systems. </answer>

<title>iWireless</title>

<question>I'm trying to install OpenSUSE 10.2 on an iMac for my granddaughter. The install went well until I tried to add a PluscomWU-ZD1211B USB wireless stick, neither the drivers that came with the stick nor from the net seem to install. When running make as root, I get lots of warnings: make [6] Error1, make [5] Error 2, leaving dir etc. In YaST hardware the stick is shown as USB2.0 Wireless/drivers: active/ modules: yes/ modprobe: zd1211rw? I've copied the firmware as the readme, and setup ssid etc in YaST advises. There are no zd1211rw drivers or ndiswrapper on SUSE 10.2 sources or spike, so I can't install with YaST! As a newbie still fighting the command line I hope you can help this is driving me mad! </question>

<answer>I can confirm that the zd1211 drivers work with a PPC kernel, I used them with my iBook before there were drivers for the internal wireless card. However, you do not need to install any drivers for a zd1211-based adaptor, they are included with the standard SUSE 10.2 kernel. The following two commands, run as root, should confirm the presence of the zd1211rw module.

modprobe -l | grep zd1211
modinfo zd1211rw

You can also see the files in YaST. Go into the Software Management section, find the kernel- default package and click on the Files tab. Scroll down to see the relevant modules in drivers/net/wireless. Did modprobe run with no errors? If not, you may need to ensure the firmware is installed in the correct place. Most drivers expect to find the firmware files directly in /lib/firmware, but this one expects them to be in /lib/firmware/zd1211. You can get the latest firmware from http://sourceforge.net/projects/zd1211. If the module is loading, and the network device shows up in the output from

ifconfig -a

then your problem is most likely with the wireless settings. The first thing to do is turn off encryption. Normally, you shouldn't run an unencrypted wireless connection, but encryption only gets in the way when settings things up, and until you get things working you have no connection to protect anyway. When using YaST to set up your network, try with and without Network Manager. Some setups work with Network Manager whereas others are better off with the standard configuration method. Incidentally, should you run into similar problems when compiling from source in future, the error numbers are not useful on their own, it is the accompanying text that shows the reason for the error. </answer>

<title>Batch photo conversion</title>

<question>I'd like to have a simple command to

          convert all the RAW images in a folder,
          let's say /home/andy/photographs/

new, into TIFF with LZW compression. I don't know if it's relevant, but the extension for the RAW files is .PEF ­ (the Pentax RAW format). </question>

<answer>The program for converting digital camera RAW files is dcraw (www.cybercom.net/~dcoffin/dcraw). This converts from most digital camera raw formats to the NetPBM PPM (Portable PixMap) format. You then need another program to convert the PPM data to TIFF. ImageMagick's convert command and the pnmtotiff program from the NetPBM suite are both capable of doing this. The easiest answer to the question of which to use is "which one is already installed?" Dcraw should be in your distro's repository, otherwise download the source and compile/install in the usual way. There's no need to fill your hard disk up with PPM files when converting (PPM is a big, uncompressed format using three bytes per pixel), you can pipe the output of dcraw directly to the conversion program. To convert a directory of files using ppm2tiff, run this in a terminal.

for f in ~/photographs/new/*.PEF
do
  dcraw -c "$f" | pnmtotiff -lzw >"${f/.PEF/.tif}"
done

The -c argument tells dcraw to send the data to standard output, which is piped to pnmtotiff's standard input. The ${f/.PEF/.tiff} part provides the name of the original file with the PEF extension replaced with tif. To use ImageMagick instead, replace the third line with

 dcraw -c "$f" | convert -compress lzw - "${f/.PEF/.
 tif}"

In this case, convert uses the standard notation of "-" for standard input. The imagemagick, dcraw, netpbm, and convert man pages detail various extra options you can add to fine-tune the process. This assumes all the PEF files are in the same directory. If your camera stores them in sub-directories, use the find command to generate a list of the names. It is also possible to store the converted images in a different directory, thus:

 find /mount/pointof/camera -name `*.PEF' | while
 read f
 do
   dcraw -c "$f" | convert -compress lzw - "~/
 photographs/tiff/$(basename "$f" .PEF).tif"
 done

This time we use the basename command to extract the base filename from the full path and remove the extension. The quotes around the various filenames are there in case any file or directory names contain spaces. </answer>

<title>Grumpy about GnuCash...</title>

<question>I have used various versions of GnuCash for years with no problem. However, using 2.0.2 on either the latest versions of Ubuntu or SUSE, on two occasions the Current Account folder has disappeared between saving the account and restarting it. On the first occasion, I went back to an earlier saved account and retyped my bank statements. This time I have lost 6/52 worth of data and will not retype the lost data. Is there any way of recovering the data and/or how can this be avoided in future? Clearly the program is unusable in its current state. </question>

<answer>My first response would be that I have been using GnuCash for years, and am currently using version 2.2.1, without seeing what you describe, which makes me think it is a problem specific to your setup, but that's not great consolation to you. Are you sure that your home filesystem has no errors? Running fsck on /home would be a prudent move. As far as recovering goes, GnuCash stores backups of the data and log files in its data directory; the data files are named AccountName. datestring.xac. Find the most recent undamaged one and copy it to AccountName. Do not rename it, you want the backup to still be there if the account file is lost or corrupted again. These backup files are created each time you run GnuCash and could fill up your hard drive if you left them all there, so GnuCash will remove the oldest files after a configurable period. Set this in the General section of the Preferences window, a value of 0 means your backup files will never be deleted automatically. If there are no problems with your filesystem, it would be good to get to the bottom of this error (restoring from backups is not a real solution), so run GnuCash from a terminal and the next time it does this you should see some errors in the terminal output or the logfile. Search the GnuCash mailing lists and bugzilla (both available via www.gnucash.org) for a similar problem, and file a bug report if you find none. The developers cannot fix this unless they know about it. It would be wise to try a newer version first: get GnuCash 2.2.x RPMs for SUSE from http://rpm.pbone.net. </answer>

<title>Konquering USB</title>

<question>There seems to be a wide discrepancy in how various distros handle scripts on USB memory sticks. Using Konqueror's execute command under the tools menu: Ubuntu runs them without fuss (initially my Feisty upgrade broke this by mounting the stick non-exec). SUSE 10.2 and Startcom consider the stick as remote and won't execute anything from it. Fedora 7 live raises a prompt for confirmation but it tries to run them from the wrong directory if Konqueror is used to open the USB device icon. The automounter mounts the /dev/sdb1 on /media/disk and Konqueror sees the URL as /media/sdb1. On execution, Konqueror tries to cd to /media/sdb1 and can't find the executable. If I navigate to /media/disk the scripts can be executed normally. Though SUSE 10.2 won't execute via Konqueror if there's an autostart.sh on the stick, KDE offers to execute this as soon as the stick is plugged in. Presumably all this stuff is configurable (surely it's not compiled in), but as HAL, udev and KDE are all involved with a multiplicity of configuration files, where does one start looking? </question>

<answer>There are a number of reasons for this, partly to do with the way KDE works and partly because of the lack of real file permissions on FAT filesystems. You have already discovered that the path KDE uses to a file on a removable device is not a real path. Konqueror displays media:/media/devname but actually mounts the device on /media/volumename (or /media/disk if the disk does not have a volume name). This causes no problems with most KDE applications as they understand media:/ and system:/media URLs, but non-KDE programs ­like bash ­ fall over here. It works with Ubuntu because they have patched things so that Konqueror goes directly to the mount point, although there has been some debate over whether the drawbacks of this outweigh the advantages. There is an easy way to fix this for all distros, right-click on a script and open the Properties window. Click on the icon to the right of where it says Type: Shell Script to open the filetype editor and use the Add button to add bash to the list of programs. Don't look in the application list for bash, just type it into the box above the list. OK this window and the properties and right-clicking on a script will now show bash in the Open With sub-menu. If you put bash at the top of the application list, you will also be able to run scripts by clicking the icon. Either of these is more convenient than selecting the icon and then moving to the top of the window to find the menu. The automatic running of authstart.sh is governed by a setting in the Peripherals/Storage Media section of the KDE Control Center. The other possibility that you refer to is editing the HAL configuration to have the volume mounted with the device name instead of the volume name. This can be done, but makes the system less intuitive, especially when using FAT filesystems created by other devices that give them a meaningful name: my camera's memory cards are always identifiable as such, as is my audio player, there's no danger of copying files to the wrong device when both are mounted, which could easily happen if they were mounted at /media/sde1 and /media/sdf1. </answer>

<title>Installation confusion</title>

<question>My laptop to dual-boots to PCLinuxOS. One thing that trips me up every time I try to install apps from an LXF DVD is when I follow the general instructions in the mag, there is no hyphen shown in the command to decompress the tar. The magazine shows tar xzvf /mnt, but one must actually type in tar - xzvf /mnt. Installing software is a complete boondoggle with Linux, and any explanation or justification of this situation is pointless. What would be good is if specific instructions for installing each of the cover disc programs were supplied. It would be interesting to see installation for 30 different programs shown in one document. I bet all 30 will be slightly different. For example, I am currently trying to install DEFCON from the LXF96 disc. Where is it made obvious what I'm supposed to do when I type in ./configure and my terminal kicks back:

bash: ./configure: No such file or directory

</question>

<answer>Installing software from outside of your distro's package manager can be confusing, because there are several different ways of supplying it. The generic instructions in the magazine apply to some per cent of software, programs supplied as source code using the autotools suite. In many cases there are installation instructions on the disc, in the form of a README or INSTALL file provided with the software, and these often contain identical instructions. This should be considered gospel when installing, as these are the instructions from the programmers. The leading argument hyphen is unnecessary unless you use a VERY old version of tar. In fact, the z option has been redundant for quite a while as tar is able to detect common forms of compression. I normally use tar xf filename. The "." is shell notation for the current directory, so ./configure tells the shell to run a program or script called configure in the current directory. Once you understand that, the reason for the error is obvious, there is no configure script with this program. That is because DEFCON is not supplied as source code: this is a binary package that does not require any installation to run. Instead of a configure script you will see a defcon script; run that with ./defcon to start the program. I agree that this is not obvious, the only documentation supplied refers to using Mac OS, but this is a failing of the individual program, although we could have perhaps pointed this out in the magazine. This is the type of program that would benefit from the Autopackage system (www.autopackage.org) that Mike, Linux Format's website and disc editor, champions. Autopackage bundles the software into a single file that you `run' to install the software. </answer>

<title>VMware incommunicado</title>

<question>I use VMware Workstation to run various virtual machines, both Windows and Linux ­ for web development and also to try out different distros. Recently I've lost the ability to SSH between the host (Ubuntu) and guest OSes. The ssh commands just hang until I hit Ctrl+C. I can SSH into the host or the guest from my laptop on the same network, and I can connect to the laptop from the host or any of the virtual machines, it seems to be only connecting between the host and guest on the same machine that is problematic. I can ping a guest from a host and vice versa, it onlyappears to be SSH that is affected, but I haven't changed any of my SSH settings on the host, and as it affects all guests, I don't see how it can be a settings problem there. I am using bridged networking, as I have always done and this worked previously. </question>

<answer>I was hit with exactly the same problem. At first, I suspected an issue with SSH, but then I found that other protocols failed too. It turned out that anything using TCP was broken, and the problems were brought about by a kernel update. The change was in the support for the TCP Offload engine in some network cards (in my case an Attansic L1 Gigabit controller). The offload engine passes some of the load for TCP processing from the kernel to the network card's controller, which causes a problem when the network traffic isn't going through the network controller, even though it is on the same network, a situation unique to virtual machines. Bridged networking gives the virtual machine an IP address on the same subnet as your LAN, but the traffic doesn't go through the card. The solution is as simple as turning off some of the offload engine's features with ethtool. To turn off everything that is likely to cause a problem, run

sudo ethtool --offload eth0 rx off tx
off sg off tso off

If this works, you can narrow down the options you disable; on my system I only needed

sudo ethtool --offload eth0 tx off

Once you have identified the correct parameters to disable, you can then add the command to /etc/rc.local (without the sudo part) to have it executed automatically when you boot. </answer>

<title>Walkman standstill</title>

<question>I have a Sony NW-E507 Walkman and I use Ubuntu 7.04. This Walkman uses Sonic Stage for installing and removing music files and podcasts, which is what I mostly use it for. I have tried Mbnet without success. Is there anyway to use this Walkman with my OS? </question>

<answer>This Walkman device is heavily tied into Sony's DRM technology and Sonic Stage is required. You can mount the player as a USB mass-storage device to upload files, but those files will not be playable. This device is Windows-only, and even there it is locked into Sony's software; Mac users are also out of luck too. Standard MP3 players are cheap nowadays, so the best option is usually to replace such locked hardware with something that lets you do what you want with the music you have bought. </answer>

<title>Bridging alone</title>

<question>Do you know if there is a game of Bridge for Linux? All I can find is versions of Bridge to play over the Internet with other players. </question>

<answer>After some searching we found one bridge game where you can play against the computer, but it is not open source. Does this mean that open source programmers do not play bridge, or that they prefer to play real opponents? I'm sure it would make a good topic for an apparently pointless sociological study, but that doesn't help you. The game we could find is Xcontractbridge, a commercial game supplied on CD for $29. You can find more information at www.xcontractbridge.com/xbridge.htm along with a demo version for download. This is a pre-compiled static binary that should work on most i386+ or x86_64 systems, it certainly ran without problems on my Core2Duo machine, though my bridge skills are limited to distinguishing between red and black cards (so much for heredity, my Dad was a Bridge master). </answer>

<title>Linux as mail proxy</title>

<question>I want to download my emails from my ISP account automatically and use my Windows laptop to retrieve them from the Linux box, thus not having to download them on one machine and then also the next and also leave them on my host's server. I would just alter the MX records to point to my own box, but my IPS doesn't offer a static IP service (ruling out dyndns). </question>

<answer> Running a local MTA (Mail Transport Agent) without a static IP address is risky: changes in dynamic addressing could cause your mail to be delivered elsewhere. Some ISPs block port 25: it's a potential point of entry for would-be attackers. But, you don't need to run your own MTA to achieve what you want. You can use fetchmail to pull mail from your ISP's mail server, store it locally, then run a POP3 or IMAP server to serve that mail to your local PCs. With a text editor, create .fetchmailrc in your home directory with these contents

set daemon 300
poll mail.myisp.com with proto POP3
     user `myispuser' there with password
`mypass' is `myuser' here options keep
mda `/usr/bin/procmail -d %T'

and set it to be readable by only your user with

chmod 600 ~/.fetchmailrc

The first part tells fetchmail to run in daemon mode and poll your ISP's mailserver every 300 seconds, the second gets the mailserver to contact and username and password to use, and the local username to save the mail for. The keep option leaves mail on the server (remove once you're sure everything works). The last line tells fetchmail to use procmail to deliver mail instead of running it through sendmail. Tell procmail to deliver the mail by putting this in ~/.procmailrc

MAILDIR=/var/spool/mail
DEFAULT=$MAILDIR/$LOGNAME/

The trailing / is important, it tells procmail to use maildir storage, which is needed by the IMAP server later. Create the mail directory with

mkdir -p /var/spool/mail/myuser
chown myuser:mail /var/spool/mail/myuser
chmod 770 /var/spool/mail/myuser

Test it with fetchmail --daemon 0 -v. This turns off the background mode and shows all that is happening. If it works, set fetchmail to auto-run by selecting System > Preferences > Personal > Session, pressing New in the Startup Programs tab and typing fetchmail in both boxes. Fetchmail will now run each time Gnome starts. Now the mail is on your system, you need an IMAP server to be able to access it from your LAN. Once Dovecot is installed from the Fedora repositories, make changes to /etc/dovecot.conf. Find lines

#listen= [::]
#mail_location =

and change them to

listen = *
mail_location = /var/spool/mail/%u

You also need to allow ports 110 (POP3) and 143 (IMAP) through your firewall. For outgoing email, each computer can be left set to communicate directly with your ISP's SMTP server. </answer>