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, email@example.com
Compiler/linker options are different between Solaris and Linux, even if you are using GCC on both.
—Usman S. Ansari, firstname.lastname@example.org
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, email@example.com
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, firstname.lastname@example.org
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, email@example.com
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é, firstname.lastname@example.org
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, email@example.com
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, firstname.lastname@example.org
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, email@example.com
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide