PCI Symphony Network Cards
Establish the IP address for the eth1 interface by typing
ifconfig eth1 192.168.4.1 broadcast 192.168.4.255\ netmask 255.255.255.0
Set the Secid for the Symphony wireless segment with the following command:
rl2cfg dev eth1 secidUse the same Secid you used when setting up the notebook above, making sure you type it the same, including upper/lowercase. The Secid needs to be set only once; it is stored on the card in nvram. The rlmod driver versions after 1.5.1 use proxcfg instead of rl2cfg to set parameters for the Symphony card. Check the man page and READMEs.
Now, establish the route for the eth1 interface by typing
route add -net 192.168.4.0 dev eth1
You can check your results by typing ifconfig eth1 and netstat -r. You should be able to see that the eth1 interface is fully configured with its IP address and that there is a route using eth1 to the 192.168.4.0 network.
There is one more configuration command that sets the Symphony card mode to “master” and sets its name. Type the following, using an appropriate name for your server:
rl2cfg dev eth1 msta
If you don't have a firewall running on your Linux system, you should be able to ping the notebook from Linux and ping Linux from the notebook using the IP addresses. You should also be able to telnet to the Linux system from the notebook, again using the Linux server's IP address. If this works, you're just about there; if not, check your log files for errors.
Add a line to the /etc/hosts table on the Linux server, giving the IP address of the notebook when on the wireless subnet, using your domain as appropriate.
If you don't already have a c:\windows\hosts file with an entry for the Linux server on your notebook from a wired Ethernet configuration, create one now. The pertinent line entry in my c:\windows\hosts is:
192.168.1.254 server1 server1.If you have a firewall running on the Linux server, you will need to add input and output rules for the eth1 interface to allow the packets to be passed. I added lines to these two sections of /etc/rc.boot/masq as shown:
# local interface, local machines, going anywhere # is valid ipfwadm -I -a accept -W eth1 -S 192.168.4.0/24\ -D 0.0.0.0/0 # local interface, any source going to local net # is valid ipfwadm -O -a accept -W eth1 -S 0.0.0.0/0 \ -D 192.168.4.0/24Depending on your Linux distribution and version and whether you are using ipfwadm or ipchains, the location and name of the rules file will vary. Refer to the documentation for your firewall package. At this point, you should be able to ping and use telnet by host name between the notebook and all systems on your original network.
To allow packets to be forwarded to the Internet through the firewall from the wireless segment, you will need to add rules similar to the following:
# Masquerade from local net on local interface to # anywhere ipfwadm -F -a masquerade -W eth0 -S 192.168.4.0/24\ -D 0.0.0.0/0 ipfwadm -F -a masquerade -W ppp0 -S 192.168.4.0/24\ -D 0.0.0.0/0 ipfwadm -F -a masquerade -W sl0 -S 192.168.4.0/24\ -D 0.0.0.0/0
Due to the way diald works, there are rules for both ppp0 and sl0. Remember to restart your firewall rule set after making changes.
Once I had the firewall rules in place, I had full connectivity from the notebook to all local hosts and the Internet. The last service to get working was the Samba sharing from the Linux server. It took a little head scratching, but finally I realized I had a line in /etc/smb.conf that limited which networks had access to the Samba server. Since the wireless segment was new, it needed to be added to the config file, and then Samba needed to be restarted. The revised line in /etc/smb.conf is shown below.
hosts allow = localhost, 192.168.1., 192.168.4.
Once everything is working, you need to add the commands to initialize the wireless eth1 interface on system boot. Debian Linux uses SysV init, so I added the following lines to the /etc/init.d/network file after the eth0 interface section and before the line setting the default route:
insmod rlmod ifconfig eth1 192.168.4.1 netmask 255.255.255.0\ broadcast 192.168.4.255 route add -net 192.168.4.0 dev eth1 \ /usr/local/bin/rl2cfg dev eth1 msta name server1
These lines load the module, configure the eth1 interface, add the route and set the mode to master. Make sure it all comes up on reboot.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- SourceClear Open
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
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