The Linux advice crew at LinuxQuestions.org is here to help you with your real-world Linux questions.
In cooperation with the helpful folks at LinuxQuestions.org, we’re bringing you a new feature: “Infrequently Asked Questions From LinuxQuestions.org.” Every week, we’ll run some of the best advice from the site here, to give you something to play with over the weekend. —Ed.
Can’t see the tracks on an audio CD
One of the “less frequently” asked questions on LQ is in regards to audio CDs.
A few samples:
Some people who come from a Windows background tend to think, once they have grasped the concept of mounting filesystems under Linux, that audio CDs also need to be mounted. After all, Windows’ Explorer displays audio tracks when you insert a CD, doesn’t it? However, audio CDs don’t have a standard filesystem, and therefore can’t be mounted by default by most Linux distributions.
However, Linux wouldn’t be Linux if there wasn’t someone out there who’s come up with a way to do the unexpected. Cdfs, available from https://trappist.elis.ugent.be/~ronsse/cdfs/ is a good example. Much like Windows, CDfs will let you treat audio and video-CD data-streams as if they were files. cdfs also lets you recover information from faulty multi-session disks.
–Tinkster
Restricting commands that can run in an SSH session
Many people know about ssh. Some know that ssh allows for public-key authentication. VERY few, however, are aware of the fact that one can not only have ssh execute remote commands, but also that one can tie that public-key exchange down to ONE specific command that a user is allowed to execute (without involvement of root-jails, sudoers and the like).
You may ask yourself: what’s the point of that?
Well, one of the very valid reasons is security; if the machine that you invoke your remote commands from was compromised, the public-key communication could allow a remote attacker who gained access to this machine to also compromise the “slave machine” as well.
Now, if all you ever do is run a single specific command against that other box, maybe from cron or during machine-startup, it may well make sense to have a non-privileged local account with a passwordless public-key (LQ has a very nice tutorial on that from david_ross, Public key authentication with ssh). And now comes the clever bit: the ssh authorized_keys files allow you to have ONE command that the user matching the key AUTOMATICALLY executes on login. In other words, they don’t get shell access at all. They can’t override the command defined in the authorized_keys file from remote, either. And they can’t scp or sftp. Tight, eh?
Another reason would be that you don’t have the chore of a long command-line in a script if you happen to be running the same command against more than one server.
We’ve all seen ~/.ssh/authorized_keys with content like
ssh-dss AAAAB3NzaC1kc3MAAAEBANvK1TIJa9TMmNRXGetPWlongscrambledstringGfzjI94IYMYvNf9FBlEJzwGvO6aS1j0= tink@diggn
which will allow us to do the connection; all we need to do to get the benefit of some extra protection in this situation is the following little change:
command="/home/tink/special_script" ssh-dss AAAAB3NzaC1kc3MAAAEBANvK1TIJa9TMmNRXGetPWlongscrambledstringGfzjI94IYMYvNf9FBlEJzwGvO6aS1j0= tink@diggn
–Tinkster
Hard Drive S.M.A.R.T Failure Imminent
ihatethedekoys reported that every time his computer booted, it gave him a warning that his main drive (hda) reported a S.M.A.R.T. Status indicating an imminent failure and wanted to know what he could do and how he could find out more about the problems with his hard drive.
S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) allows users to both check their drives’ performance and to compare this performance to values specified by the hard drive vendor. In addition to the BIOS warning, S.M.A.R.T. values can be accessed through a Linux package known as ‘smartmontools’, which should be in most distributions. The command smartctl -a /dev/hda shows all metrics reportable by S.M.A.R.T. for that drive. The most important line should read “SMART overall-health self-assessment test result: PASSED”. If it shows anything but passed, the built-in monitoring of the drive is telling you that something is wrong. Looking further down in the report, you can see exactly why the drive thinks it’s on its last leg. In many cases, the warning signs include too many bad sectors, high temperatures, high spin-up times, and high seek error counts.
The original S.M.A.R.T. design generally indicated that a failure would occur in 48 hours of continued use, but this cannot be depended upon. In the event of a S.M.A.R.T. error or warning, it’s a good idea to immediately back up the data from that drive and, if it’s your system drive, to transfer your whole system to a new drive. One part that ihatethedekoys asked about was transferring his bootloader. The easiest way to go about this is simply to copy the bootloader configuration over with all the other files and then point it to the new drive’s MBR. For LILO, this can be done with ‘lilo -b /dev/hdb’. Grub users should use ‘grub-install /dev/hdb’ to reinstall the Grub Stage 1.
As it turns out, ihatethedekoys’ drive had actually failed before his post, but he had fortunately managed to have Grub installed on both drives, so his system booted nicely with only one minor change, and files he had thought he had copied to hda were still safe. The full thread is available.
–Matir
Many of us use a Linux computer as a firewall/router, but would still like to maintain the ability to connect to network services on the LAN side of the network. The most common approach to this is iptables port forwarding. hazmatt20 wanted to know why he couldn’t connect to his FTP server behind his Linux firewall despite having set up iptables port forwarding.
The first answers were checking for the obvious errors in setting up port forwarding. /proc/sys/net/ipv4/ip_forward was set to 1, and both ip_conntrack_ftp and ip_nat_ftp kernel modules were loaded. He was using the following rules for the forwarding:
iptables -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 20:21 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 20:21 -j DNAT --to-destination 192.168.0.2
Masquerade was being used for outbound packets and for LAN Internet connectivity through: iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
At first, we suggested removing references to port 20: the kernel modules should automatically handle connections for FTP data, and since he couldn’t even connect, the problem should concentrate on port 21. Even then, the connection was still closed as soon as he attempted to connect. It was also confirmed that his FTP server was running on 192.168.0.2, that he could connect locally, and that he had no firewall rules set up.
It later occurred to check how he was testing the port forwarding. He said he was testing it from another computer on the LAN, by connecting to his external IP Address. Then it became apparent: testing port forwarding from within the same LAN causes problems.
The SYN packet coming from the client goes to the router where the destination address is changed and it is resent. The source address remains the same.
The FTP server sends an SYN-ACK packet back, but because the source address is on its own LAN, it needs no translation and goes directly. The client is confused, expecting the SYN-ACK packet to come from the router, not the FTP server, and closes the connection.
The port forwarding was indeed working and was verified by connecting from outside hazmatt20’s LAN. The eventual solution was simply to double check port forwarding by using another computer across the Internet. An SSH account on a public system can be very useful in such a case.
–Matir
