Setting Up a SPARCstation
The “images” directory on the CD-ROM and the ftp server contain both the floppy files (boot-v0.img and boot-v2.img) and a separate tftpboot.img file. As with the floppy images, the latest tftboot.img file can downloaded from one of the Red Hat mirror sites.
It is this latter file that is required for a network boot. The method used to configure the boot server is almost identical for Linux, SunOS and Solaris systems. We'll use an example configuration, where our boot server is a machine called tyne.gaijin.co.jp and the SPARCstation client is coquet.gaijin.co.jp. The server IP address is 172.17.172.50.
Assign an IP address for your new machine on the same sub-net as the boot server. In our example, the next available IP address for the client “coquet” is 172.17.172.52. It's hardware Ethernet address (MAC) is 8:0:20:3:9:96.
Create a directory for the tftp boot files on the server. SunOS and Solaris machines use /tftpboot by default, and we can use this directory on a Linux system, too.
Copy the tftpboot.img file to the newly created directory.
Create a symbolic link from the tftpboot.img file to a unique file name which the SPARCstation boot PROM requests across the net. The format of the symbolic link is <CLIENT_HEX_IP_ADDRESS>.<ARCHITECTURE>. Take the IP address which you assigned in the first step and convert it, section by section, to hex and then add the architecture of your system. In our example, we need to convert 172.17.172.52 into hex words and, since we aren't exactly sure what architecture our new system is, we'll create links for both 4c and 4m machines.
172 = AC 17 = 11 172 = AC 52 = 34 ln -s ./tftpboot.img AC11AC34.SUN4C ln -s ./tftpboot.img AC11AC34.SUN4M
Note that unlike SunOS and Solaris, the same boot image can be used for both 4c and 4m architectures.
Enable the tftp daemon in /etc/inetd.conf. The syntax for this entry is slightly different between Linux and SunOS/Solaris systems. On the Sun systems there's a -s option which enables the daemon in “secure” mode. The Linux tftp daemon does not use this option and, if it is present in the config file, it treats it as a directory name and all tftpd accesses fail. The other difference between Linux and SunOS/Solaris is that most recent versions of Linux come with the inetd.conf file configured with the tcpd logging daemon configured as default.
tftpd dgram udp wait nobody /usr/sbin/tcpd\ in.tftpd /tftpboot
tftpd dgram udp wait root /usr/etc/in.tftpd\ in.tftpd -s /tftpbootSolaris:
tftpd dgram udp wait root /usr/sbin/in.tftpd\ in.tftpd -s /tftpboot
Reinitialize inetd using a kill -HUP <inetd PID> or by rebooting the server.
Ensure that the the client's Ethernet address is in the arp cache, and the rarp cache for Linux systems, on the server.
arp -s 172.17.172.52 08:00:20:03:09:96 rarp -s 172.17.172.52 08:00:20:03:09:96Note the leading zero padding added to the Ethernet address in both cases.
The rarp command might produce this error:
cat: /proc/net/rarp: No such file or directory
It indicates that rarp isn't compiled into the kernel, and that the rarp module hasn't been loaded. Use insmod to load it and rerun the rarp command.
server# insmod /lib/modules/2.*.*/ipv4/rarp.oIf the module isn't present, you'll have to rebuild the kernel with rarp enabled.
The client system usually takes about three minutes to boot into the installation program. The screen changes from the default black-on-white to white-on-black with a much smaller font once the kernel loads. You'll start to see the normal Linux boot messages as devices are probed and identified. At the end of the boot sequence the system drops straight into the install program, and from that point onwards the prompts are pretty much self explanatory. There are still a few things to watch out for, though.
Red Hat install makes virtual consoles available to the user during the whole of the installation process. <ALT>F1 gets you to the main installation screen, <ALT>F2 is a shell, <ALT>F3 displays informational messages from the installation program, <ALT>F4 displays console messages and <ALT>F5 displays messages from the individual package installation programs as they run.
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
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
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