Best of Technical Support
I am porting my project from Solaris to Linux and am faced with a few linking problems. The linker reports some multiple definition errors on functions. The function is defined in one .C and one .CXX file. On linking the object files created from the compilation of these objects, a multiple definition error is being issued. However, the linking step goes fine on Solaris. Is this a problem with some linker options? I am using the C++ linker on both platforms with the same flags/options.
—Mohit Kumar Singhal, firstname.lastname@example.org
Compiler/linker options are different between Solaris and Linux, even if you are using GCC on both.
—Usman S. Ansari, email@example.com
I'm attempting to install the Promise SuperTrack SX6000 RAID driver module into Red Hat 7.3 and maybe into Red Hat 8.X some day. After I compile a driver, I know there is more to it than simply running insmod to have the driver module automatically load at boot time. Is there an example or procedure that walks one through what an install shell does? What config files are tweaked and where does the driver go?
—Steven Brown, firstname.lastname@example.org
Driver information goes in the /etc/modules.conf file. For example, the line alias eth0 eepro100 specifies that the eepro100 driver should be loaded for use by Ethernet interface eth0. If the module is for your boot device, you need to use an initial ramdisk. See the mkinitrd man page.
—Robert Connoy, email@example.com
Red Hat has assembled a guide to their boot script layout at www.redhat.com/support/resources/tips/Boot-Process-Tips/Boot-Process-Tips-3.html. You can insert your own commands into this file for execution at boot time.
—Chad Robinson, firstname.lastname@example.org
This page, www.linux.org/docs/ldp/howto/mini/Modules, gives you some insight on the working of loadable modules. It has the basics. Another interesting page about Linux kernel modules is at www.luv.asn.au/overheads/kernelmodules.
—Felipe Barousse Boué, email@example.com
I believe Mr Marti has been tempted into a somewhat facile response to the question regarding telnet [see Best of Technical Support, LJ, April 2003]. OpenSSH is indeed an excellent choice over rlogin and telnet outside a trusted environment. But inside such a network, rlogin, telnet and the other r* commands give excellent and much more convenient service within their respective realms of use. I would not be happy to retire rlogin and telnet especially where I have to deal with older systems other than Linux. As ever with security issues, the cost of protection (embodied, in this case, in the greater complexity and inconvenience of setting up the secure tool) must be weighed against the benefits accrued. Simply replacing rlogin and telnet with SSH is useless unless the network is comprehensively bolted down and firewalled. Again, if appropriate protection is to be obtained, a full analysis must be done.
—Bob Hepple, firstname.lastname@example.org
You have the option of inserting public keys, for user authentication, on the servers to which you connect. Or, you simply can use password authentication. Even if you use password authentication, the password is protected by symmetric encryption with SSH. Today's hardware adds an additional wrinkle to security. Are you sure your broadband router doesn't have a trojan installed to sniff telnet packets and pass them over the network? Are you sure your 802.11 wireless bridge isn't passing your telnet packet over the air? A lot of hardware you have no control over has access to your data. Mr Hepple's assertion that “replacing rlogin and telnet with SSH is useless unless the network is comprehensively bolted down” is wrong. We always speak in terms of “raising the bar” of security and adding “layers of an onion”. You are correct, that if a security solution has high cost, one should perform a threat analysis, but SSH is so easy it is a no-brainer.
—Christopher Wingert, email@example.com
Modern distributions include OpenSSH by default, and make you go through extra effort to run a telnet server. Thankfully, the convenient choice and the secure choice are the same. SSH with password authentication is as easy as telnet. With properly configured keys, it's easier. Check next month's Linux Journal for some productivity-boosting OpenSSH tips. If you need to log in to your Linux system from another OS, check Rick Moen's list at linuxmafia.com/pub/linux/security/ssh-clients for compatible software.
—Don Marti, firstname.lastname@example.org