Issue #7 May 2005

Tips & Tricks

Red Hat's customer service team receives technical support questions from users all over the world. As they are received, Red Hat technicians add the questions and answers to the Red Hat Knowledgebase on a daily basis. Individuals with a login are granted access. Every month, Red Hat Magazine offers a preview into the Red Hat Knowledgebase by highlighting some of the most recent entries.

This month's Tips & Tricks include topics related to this month's feature section Open source: Know your rights as well as some frequently asked, good old-fashioned tips for system administrators.

Tips from RHCEs

Are there ways to provide a kickstart file other than from a floppy disk or over the network?

Most Red Hat administrators are familiar with the kickstart feature of the Anaconda installation program, which allows install options to be specified using a simple text file instead of interactively through the graphical interface. When used to automate the installation of large numbers of machines, kickstart can save enormous amounts of time and effort.

Most will also know that kickstart files can be provided on floppy disks or over the network via FTP or HTTP (including via CGI), and although these are both useful in their own rights, there are a couple of other options which can be really handy in the right situation.

A kickstart is triggered by specifying linux ks at the boot: prompt. This starts a default kickstart, configuring the network interfaces via DHCP and retrieving the kickstart file from NFS. The option can also take an argument specifying exactly where the file comes from.

The available options are:

  • ks
  • ks=nfs:<server>:/<path>
  • ks=http://<server>/<path>
  • ks=floppy
  • ks=floppy:/<path>
  • ks=hd:<device>:/<file>
  • ks=file:/<file>
  • ks=cdrom:/<path>

Most of these options are pretty self-explanatory. For the full details, refer to the Kickstart Installations chapter of the Red Hat Enterprise Linux System Administration Guide.

The options really come into their own when used imaginatively to give different behaviours. Try the following for example:

  • Create a 5GB ext2 partition and populate it with the installation ISOs. Copy your kickstart file to the same partition. If you created the partition hda2, for example, use the following line in your kickstart file:
harddrive --partition=hda2 --dir=/path/to/isos
  • To install from the partition, which can be an external media source such as a USB pen drive, use the following command at the boot: prompt:
linux ks=hd:hda2:/mykickstart.cfg

Does Red Hat distribute software under a license other than the GPL?

The large majority of software distributed by Red Hat is licensed under the GNU General Public License (GPL). However, Red Hat does include other open source software available under various licenses. For example, the GNU Lesser General Public License (LGPL) (a variation of the GPL license), the revised BSD license, and the MIT license among others.

What is the difference between the GPL and the public domain?

It is a common mistake in perception that free software licenses such as the GPL are the same as any entity in the public domain. However, there are key differences between free software licenses and public domain software.

Public domain software is one in which all the developers of the software have agreed explicitly to disclaim all their rights granted to them otherwise by copyright laws. This means that any individual or team cannot assert any rights over the software and everyone is allowed to do whatever they want with it

For example, sqllite, an embedded database software, is under public domain.

The GPL license, on the other hand, is a copyright license which can be only used under the terms of its license. GPL is, however, unique in the fact that terms of the license are designed to protect the freedom of the end users rather than restrict them from doing things.

Examples of software under the GPL license is the Linux kernel, the core of any Linux based systems such as Red Hat Enterprise Linux and Fedora Core.

Can I modify GPL software and include it in a proprietary software application?

You can modify GPL'd software and include it within a proprietary software program, you just can not distribute it. That is, a non-distributing end-user can do whatever they want with GPL'd software. The GPL does not require that all derivative works be under the GPL, only derivative GPL works that are distributed to others.

You can make private modifications to software licensed under the GPL and retain exclusively rights over your modifications as long as you do not distribute the software in source or binary form to a third party.

How can I limit what users can log onto a system via SSH?

Sometimes allowing all users the ability to remotely log onto a system can be a security risk. There are many ways to limit who can remotely access a system. You can use PAM, IPwrappers, or IPtables to name a few. However, one of the easiest ways to limit who can access a system via SSH is to configure the SSH daemon.

To limit who can log into a system via SSH, edit the /etc/ssh/sshd_config file and add a line at the bottom of the file similar to:

AllowUsers [username]

Where [username] is the username you want to allow. For example:

AllowUsers joe

This will only allow the users that you specify the ability to log via SSH. In the above example, user joe has already been created on the system. Multiple users can be specified, separated by spaces.

For additional information and options, see the sshd_config and sshd man pages by typing man sshd_config and man sshd, respectively, at a command prompt.

What ports are used by Samba?

The following is a list of ports and protocols used by Samba:

  • Port 137 (UDP)—NetBIOS name service and nmbd
  • Port 138 (UDP)—NetBIOS datagram service
  • Port 139 (TCP)—File and printer sharing and smbd
  • Port 445 (TCP)—NetBIOS was moved to 445 after 2000 and beyond, (CIFS)
  • Port 901 (TCP)—for SWAT

Warning: Running Samba over the Internet could pose a security risk. The system administrator should not open these ports (externally) without a full understanding of the possible security risks.

What is the difference and purpose of pci.ids and pcitable?

Both pci.ids and pcitable reside in /usr/share/hwdata/.

  • pci.ids maps PCI vendor, device, subvendor, subdevice, and class identifiers to human readable names. It's a SourceForge project that gets used in utilities like lspci which reads /proc/pci and tell you what each device is.
  • pcitable is a file that is used almost exclusively by Kudzu (and Anaconda). It maps the same PCI identifiers above to kernel module names. Kudzu (and Anaconda) use this file to write the appropriate entries into /etc/modules.conf or /etc/modprobe.conf so that the appropriate driver(s) will be installed for the hardware detected on the PCI bus.

This article is protected by the Open Publication License, V1.0 or later. Copyright © 2005 by Red Hat, Inc.