Frequently Asked Questions in #redhat

Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version
1.1 or any later version published by the Free Software Foundation; with
no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
Texts. A copy of the license is included in the section entitled "GNU Free
Documentation License".

This Documentation is not endorsed by or affiliated with Red Hat, Inc. in
any form or fashion. All trademarks and copyrights belong to their
respective owners.

People are often anxious to know "when is the next release of Red Hat
Linux going to be out." Well, the truth is, that Red Hat does not release this
information outside the company. There is no fixed release date written in stone.
We often say "when it is done(tm)", or some other similar answer. The reason for
that answer, is because truthfully, there *IS* no specific release date. When all
major outstanding bugs are fixed, and our Quality Assurance (QA) team gives a thumbs
up, then we whip up the final release and it is made publicly available at some
point after that. Anyone outside Red Hat, or even *inside* Red Hat, who gives a
date, is thus sadly mistaken.

However, when the next release of Red Hat Linux becomes
stable, rest assured that the announcement will make it to #redhat's
topic before it ever reaches a web site. When the
new directory on the main Red Hat ftp site has appeared
but is locked, it is a good indication that the next release is on the verge of coming out, so stay tuned for
further information!

This is one of the more common questions we hear from new users. For
detailed information pertaining to problems with the Red Hat gcc 2.96 compiler, please
read the following document which explains
it.

There are couple ways to capture an image of your desktop. The two most common
ways are gimp and import. To take a screenshot in gimp its File > Acquire
> Screenshot > Whole Screen. To take a screenshot using the command-line utility
import, open a terminal and type: import -window root screenshot.png

MD5 Sums are 32 bit string representing a 128 bit checksum, that are the result of running the MD5 sum program
against a particular file. Since any difference between two files results in two different
strings, MD5's can be used to determine that the file or iso you downloaded is a bit-for-bit
copy of the remote file or iso. In the directory of the ftp/http site that you downloaded
the ISO you will find a plain text ASCII file called MD5SUM which has the proper values.

If you are running one of the GNU/Linux distributions, you should already have the MD5
program installed. If you run Windows and don't have the program, you can download it
here. After running your preferred
anti-virus software on this downloaded file, copy or move it to your c:\windows\command
directory. Then, open up an MS-DOS window, and go to the directory of the downloaded iso
file that you wish to check. Once you are in that directory, type: md5sum xxxxxxxx.iso

Since this is being done in dos, the eight character file name limit applies. To get around
this, rename the .iso file to an eight character name similar to the original file name.
Once the program has run, and it will take a few minutes to run on a 640 megabyte file, a
32 digit md5sum will be generated. This sum should be exactly the same as the listed md5
sum for the specific downloaded iso. If the sums are different, your downloaded iso is not
an exact copy, and should be downloaded again. Click
here for more information
about md5.

There is no easy way to recover your root password. However, not all is lost.
You can change your root password by rebooting to the boot prompt, and booting into single user mode.
This will drop you into what is known as a root shell. From there you issue
the command passwd and will be prompted to enter a new root password.

LILO:
At the boot screen, press the following keystrokes to drop to the boot prompt:Ctrl-X

Once at the boot prompt, type the following string to boot into single user mode:linux single

GRUB:
At the boot screen, do the following:
Press e to edit the boot entry.
Select the line that starts with: kernel /vmlinuz....
On that line, press e again.
Grub will then give you a prompt with the string already entered. Add a space, then the following text
to the end of that line:single
When you're done, you should have a line that looks very similar to this:grub edit> kernel /vmlinuz-2.4.18-3 ro root=/dev/hda3 single
Hit enter, then b to boot the modified command line.

When you run your irc client as user root then your irc client runs with root
permissions (or privileges depending on how you look at it) which in itself is not an
immediate threat. Theoretically if someone were to exploit your irc client, by tricking it
into running malicious code or shell commands, it would be allowed to without restriction.

That is not the main reason people advise you to irc on a non-root account. Its assumed
that if you are doing a common everyday task such as IRC, from root, then you are most likely
doing everything as user root which is not a good thing since you can mess up your
system easily that way. Linux is great at giving you a rope to hang yourself with. If
people seem hostile about your ircing as root, consider it tough love. :)

No. When up2date came out during Red Hat Linux 6.2, it was free for a month
and then subscription-based fee was applied. That has since changed. Subscribing to RHN
(Red Hat Network) and using up2date is absolutely free of charge for 1 system profile.
Even if you downloaded it free of charge. It only costs $$$ if you want to register
multiple Red Hat Linux systems.

We hear this a lot and this is where the power of up2date comes into play.
Assuming you have a connection to the internet all you need to do is issue the command:
up2date --whatprovides "filename" and it will query the red hat rpm database to
find out which package is associated with that file. Then you can download the additional
package and install it at the same time as the first one.

Not at all. Kernel 2.4.x contains compatibility modules that allow you to configure
filtering and NAT just as you did with Kernel 2.2.x. You don't need to change anything
unless you want to. Of course, there is a catch. The old masquerading modules for some protocols
(such as Quake, CuSeeMe, and others) are not supported. If you need them, you will either have
to migrate to iptables or continue using an older kernel until you're ready to upgrade. To stick
with ipchains type: /usr/sbin/setup then under "System Services" uncheck iptables and checkmark
ipchains. Remember, ipchains and iptables modules are mutually exclusive so you cannot have both
modules loaded at the same time!

If the concern is simply converting your existing firewall to
iptables, the ipchains2iptables tool at
http://www.stearns.org/i2i/ipchains2iptables.v0.6.0
might be worth looking into. This tool does not give a
complete iptables firewall, but does give a starting point. Its README can
also be found here.

By default, sendmail does not accept network connections from any host
other than the local computer. If you want to configure sendmail as a server for
other clients, please edit /etc/mail/sendmail.mc and change DAEMON_OPTIONS to also
listen on network devices or comment out this option all together by adding dnl to the
beginning of the line (dnl is the comment tag for sendmail.mc). When finished, you will
need to regenerate /etc/sendmail.cf by running: m4 /etc/mail/sendmail.mc > /etc/sendmail.cf
(Note: You will need sendmail-cf package installed for this to work). Then restart sendmail using
the command: /sbin/service sendmail restart

Most every linux application is neatly indexed at either freshmeat.net or SourceForge.
Putting the program name in the search box will give you information about the program
including its homepage and direct downloads. Another site which is mentioned frequently
when people are looking for rpm packages of certain programs is rpmfind.net which is a handy database of rpms.

Yes. If someone does not answer your question immediately it could be for any
number of reasons. Some users idle in #redhat during certain times of the day because they
often connect to irc from work, where their attention is not always focused in the channel.

Other users may not answer you because they simply do not know the answer -- to paraphrase an
old saw "its better to be silent and thought a fool than to speak and remove all doubt." Personally
some of the more experienced members of the channel tend to simply ignore someone's question, rather
than flaming the user with "rtfm!", if they feel the person has not made any effort to figure it out
on his own. These are easy to spot since they generally tend to be very broad and loaded questions.

The combined Unix/Linux experience in #redhat is enormous. The people range from those who are
professionals in the Industry to home hobbyists. Everyone who participates in this channel, do so on
their own free will, without financial compensation. If you seek Linux solutions in a prompt and orderly
manner, please consider commercial avenues of support like those provided by Red Hat Support Service or 3rd party consulting firms.

Locating information about generic hardware components can be a little tricky,
but with a bit of strategic searching you can usually find whatever it is that you need.
The first step is to look at the hardware itself and see if there is a vendor name and
some sort of version or serial number. If for some reason there is no identifying information,
install the card and look at the BIOS messages that the computer spits out while booting.
If your computer recognizes the new hardware, it will print a message telling you what it is.
Then it's time to hit the Net and start searching

The first place to search is always Deja
which allows you to search through newsgroup archives, which contain tons of information about
topics like this. By using the advance search option you can limit your search to specific archives,
languages, subjects, authors, forums, and dates. You will probably get back a lot of matches if you
only search for a model number, so limit your search by date so you can view the most recent posts.

Even if Deja ends up being a dead end, try the Linux Hardware
Database and Linux Hardware Net sites which contain
an extensive database of Linux hardware and driver information. If at this point you still haven't
found any useful information and you still have no idea what's going on with your card, its time to
do some troubleshooting from the command prompt. Open a command prompt and su to root. Now cd to
/lib/modules/version/kernel/net. This directory contains a bunch of kernel modules that you can try
to load and see if any of them communicate with the unknown hardware. You can use the modprobe command
to see if any of these drivers will work with your card. The most common NIC card generic modules
you should try first are lance.o ne.o ne2k-pci.o tulip.o tlan.o. You can use the modprobe
command to see if any of these drivers will work with your card. From the command prompt, type:
modprobe -v lance.o to try the Lance driver. If it's not the right driver, it should tell
you right away. You can use the same command to go through the list and see if you get lucky.

If you do and the card ends up working, make sure you post the card name or serial number along with the
driver that worked for you in the newsgroups. This would ensure that the next person who runs into the
same hardware will be able to get the information much more easily. You can think of it as your
contribution to the Linux community.

Not much to be honest. Its a pretty open-minded channel.
Discussions revolve around Red Hat Linux but are not strictly
limited to it. Most hurdles that new users face are independent of
a particular distribution. However, if you are having problems with
a system component or web of scripts that are not related to Red Hat,
then consider other irc channels devoted to that distribution.

#redhat is full of well known project developers and established
hackers. Many people have joined in order to gather support/interest
with their own pet projects. Its not just a support channel for new
users. You are welcome to come and promote something you are working
on or that you thought was interesting. Collaboration is the key to
Linux's success.

What is not permitted

Bots of any nature: questions pertaining to setting up an irc bot are permitted, just don't run or test them in this channel

Multi-colored text: While it does look nice in a GUI(Graphical User Interface) IRC client, it carries the opposite effect on console-based IRC clients. As the colors do not always escape properly, they create a screen full of garbage on console-based IRC clients. We ask that the GUI users in channel respect their console-brothers and disable color text highlighting while in #redhat

flooding/spamming: While most people consider this a type of DoS (Denial of Service) on a channel, a lot of people inadvertently flood a channel in situations where they need to copy and paste a large body of text (usually error logs and what-not) without realizing its effects on other users who may be carrying their own conversation in channel. We ask that if you need to paste something that occupies more than a couple lines, please do so in private message and/or create a temporary channel so the user(s) can join.

Warez: While most everything for Linux is freely available off the 'net, there do exist certain commercial programs such as VMware, BRU, MpegTv, etc that require the user pay $$$ to use. Asking for serial numbers or registered copies of these programs is not only disrespectful to those who have purchased them but its also illegal. Do not attempt it here.

Negative Packet Activity: While portscanning someone in itself is not illegal, it is at the very least; rude. Trying to otherwise disrupt service or connectivity from any user who chooses to participate in this channel will carry swift repercussions.

Granted that what Red Hat Linux advertises on the side of the box
as minimum requirements tends to be a larger average than what people have
been able to pull off. Users in this channel have reported installing Red
Hat 7.1 on systems as low as 386 /w 32mb of RAM and a 200mb hard drive. If
your system is less than this, consider going with an older version of Red
Hat Linux like 6.1/6.2. The base install for 6.1 is 16mb of ram and 129mb
of hard drive space. A tip if your installing 7.1 on one of these systems
is to type: linux mem=exactmap mem=32M@0 at the syslinux screen prior
to install.

When something goes wrong first you must remain calm and then start
backtracking to the last few things you were doing before the problem occurred.
Process of elimination. Once you have determined the cause, then its pretty
easy to get back into your system to fix it.

Boot with the Red Hat Linux 7.1 disc1. At the syslinux screen issue the command:
linux rescue this will drop you into a shell. Your root (/) partition will
already be mounted for you in read-write mode in the directory /mnt/sysimage
which you had to do yourself in older versions of Red Hat. Now issue the command
chroot /mnt/sysimage and your system will act like it does when you boot into
it normally. Become root by typing su - and edit /etc/lilo.conf by
removing whatever you have done to it. When you are finished, save it and type
/sbin/lilo -v to write the changes back to the MBR. Now you can exit
and reboot, your system should be back to normal.

Xinetd is based on the concept of inetd but improves on
configurability, security, performance, .. well. It is a big improvement
overall. First thing you should do is take a look at man xinetd
and man xinetd.conf. You'll realize a lot of the TCP wrappers
functions are integrated and the config files aren't all that dissimilar.
Instead of all the services being set in one file /etc/inetd.conf
they are separated into their own config files labeled by service in the
directory /etc/xinetd.d/. Open the file belonging to the service
you want to edit and you will notice a line like disable = yes which
will, obviously, keep the service off. Change "yes" to "no", save and type:
/sbin/service xinetd reload which reloads the xinetd configuration
files (similar to running killall -HUP inetd back in Red Hat 6.x). Now
your service will be enabled.

Ximian is made up by the core GNOME developers so it makes
sense they will release a newer GNOME before Red Hat does. This tempts
people into wanting to upgrade to it immediately. Ximian GNOME is nice
from a usability standpoint but from a technical standpoint of rpm
packaging/upgrading/etc it is problematic. Its likely that one will
have to --force or --nodeps Ximian packages in order for
it to work which is bad. It breaks dependencies and conflicts with Red
Hat RPM packages & updates, making it impossible to upgrade cleanly.
Red Hat Linux 7.2 will not permit an upgrade installation on an older
version with Ximian packages installed. So unless you intend to uninstall
Ximian before a Red Hat Linux upgrade or you don't mind "starting over" it
may be best to not use the Ximian packages at this point in time.

In the OSS realm you can find packages like OpenOffice (StarOffice),
AbiWord, Lyx, and Koffice. Applix offers a commercial office suite as does
Corel. Remember to use freshmeat.net to find the current homepages for the
projects.

Depends. There are OSS options like Amanda, TAR, Dump, DD,
etc. Mondo is
an excellent OSS backup application (no bias here! ;). You can search freshmeat.net for other options. RH has packages
for the previously listed. Commercial solutions exist for linux from
Legato, Veritas, BRU and Arkeia among others. Investigate each, its
always good for the soul to at least ~try~ to learn about all your
options.

Red Hat Linux currently supports and has tested (extensively)
Ext3. Other members of the group have had both good and bad experiences
with the other options.
Ext3 is an "evolutionary" step and is easily the most obvious/stable for
the group. If you are looking for features in addition to journaling as well
as a history of reliability, XFS
and JFS are worth a look.
Reiser is maturing quickly and has many
new (and good) ideas. It would seem, from anecdotal evidence, the people in
#redhat lean towards Ext3 and XFS. That doesn't mean the others don't work well
though. All are maturing at this time and each have their pros and cons. More
importantly, do you have a ~compelling~ reason for the scalability of XFS? The
versatility of Reiser? Chances are for most ppl in #redhat, no. An interesting
piece about the benefits of ext3 can be found here. Also remember that with any filesystem in its
development stage, you run the risk of data loss and file corruption.

The author's sites for each of those provide pretty reasonable
instructions. We all know the above tools are probably better audited and
architected (with respect to _security_) than BIND and Sendmail. BIND and
Sendmail are still the big players and most used daemons in regards to DNS
and SMTP. There are reasons for their longevity. One reason is just the fact
they are entrenched and lots of configs already exist. Another reason though
is the fact that these tools are designed to be quite scalable and configurable
and have served their admins well over the years.

Remember that changing a major service "just because" isn't the best solution
always. Remember you may have to spend extra time administering the services
and other people may not be as familiar with these alternative packages. Fewer
resources for support (online or offline), etc. Just make sure you consider a
few extra perspectives before you jump into a new package for such a core service.
(This expands to other services like X11 vs. Berlin, etc.) I assure you that your
security policy and your update habits will be more of a concern before another
major remote Sendmail exploit.

First off, its "Red Hat" not "roothat". Calling it anything else will
just create unecessary noise. To understand why so much FUD (Fear, Uncertainty,
and Doubt) is spread about Red Hat Linux, one must take into account a few things.
Red Hat Linux receives the larger percentage of new system administrators to Linux.
Naturally a significantly increased number of server misconfigurations and plain old
user-error result in systems being vulnerable to an attack. When a system becomes
compromised, the immediate question becomes "What distribution were you running?"
and this is where the FUD starts.

To paraphrase an old saw about horses and water: The Red Hat people can lead a person
to documentation. But they cannot force the person to read it. ALL of their documentation
is well worth reading at least once. Linux is not DOS. Linux is not Windows. Linux is not
MacOS of any flavor. (And some argue Linux is not UNIX, with some good justification.)
Linux is very powerful, much the same way a .44 magnum is very powerful. Used the wrong
way both can hurt your foot, one literally and the other metaphorically.

Whether you like it or not, the moment you place your new system on an open network
(and whats more open than the internet?) you are a system administrator. This carries
a big set of responsibilities. Expecting that a system will be safe out-of-the-box is
naive and more importantly; dangerous. Anyone who claims their distribution is, should
be looked at with contempt.

We get this question a lot and it brings up a valid point. What is the point of a
powerful program if one cannot configure it properly? A big margin of hosts who have been
compromised, were as a result of user-error and/or misconfigurations on part of the system
administrator instead of a security hole created by a bug in the software. So until man files
and documentation provide more useful examples to supplement their explanations, one must look
for alternatives. Without covering the topics in depth, lets send you off to some sites that
have been referred to in regards to iptables configuration in #redhat:

LUG is an abbreviation, it stands for "Linux User Group."
Computer user groups, at least in the United States, are not a new
phenomenon; in fact, they played an important role in the history of
the personal computer. With the advent of the Internet, however, many
of the services that user groups once provided were transferred to
things like CompuServe, AOL, and the Web. The rise of Linux, however,
coincided with and was intensified by general public's "discovery" of
the Internet. So just when traditional PC user groups were declining
because of the Internet's popularity, this popularity propelled Linux
forward, creating new demand for new user groups dedicated exclusively
to Linux.

Linux User Groups meet on average once or twice a month at some public
location. Depending on the size of the LUG. There is no standard meeting
format for LUGs. Meetings range from well-organized, professionally
catered events, to informal get-togethers at the local pub where people
talk about beer almost as much as they discuss Linux. A large amount of
meetings involve socializing, pure and simple, like finding out what
distribution others are using that month or explaining how to get Linux
to do something new and exciting. LUGers are into Linux, and if
you go to a meeting, that is what you can expect.

A number of LUGs have monthly installfests in addition to, or in
conjunction with, their regular meetings. This proves invaluable
to your typical Linux newbie. One simple reason that many users
have never been to a LUG meeting is that LUGs tend to attract a
special breed: "the epitome of geekhood." Linux user groups members
are the first line of people who will try the new kernels, the
new window manager, whatever's on the cutting edge. They are like
test pilots. For a newbie, the reason to join a LUG is simple:
Spend more time around the people who know Linux best and it will
eventually rub off on you.

One thing you can say about LUG attendees: They're mostly guys.
Old guys, young guys, four-year-olds..doesn't matter. There has been
a conspicuous absence of women. These days, more women than ever before
are showing up at LUG meetings, and groups like LinuxChix are making the LUG scene more diverse, but still,
men invariably outnumber the women.

Not surprisingly, the majority of LUG members are computer professionals.
Many of them are also lucky enough to be Linux professionals, but a good
percentage of LUG members are actually Unix or NT sysadmins. It would
probably terrify Microsoft to know the number of MCSEs (Microsoft Certified System
Engineers) who are enthusiastic Linux users and who delight in every opportunity
to replace NT boxes with Linux boxes running Samba.But if it sounds like
you need to be a Linux guru to attend a LUG meeting, relax. Most knowledgeable
LUGites take a great deal of pleasure in helping newbies. It lets them share what
they've learned.

All you really need to get something out of a LUG meeting is a healthy interest in
Linux. Depending on where you live, there's probably a LUG near you. There are more
than 305 Linux User Groups in 52 countries registered with the Linux User Groups World
Wide Web site; 130 of those are in the United States with at least one LUG in every
state.

Red Hat provides a central authority for its
packages and does extensive quality assurance testing on packages released in their
distributions/updates. Red Hat provides an application that offers functionality that is
similar to apt-get, but safer, called up2date. up2date utilizes the Red Hat Network (RHN)
to gather updates for your system from Red Hat, and apply them and their dependencies
(with prompting). Future revisions of RHN will add functionality to install new packages
from Red Hat, not just upgrade existing ones. At this time, it is not safe (while possible)
to upgrade an entire Red Hat Linux installation to a later revision via RHN, and to do so
requires some hacks. up2date (and its registration component, rhn_register) are actively
developed and supported by Red Hat.

Bugzilla is a system/database for tracking bugs and RFEs (Request For
Enhancement). Go here for
the Red Hat Bugzilla page and to open your account. The process is quite simple:
Create an account (if you don't already have one). Search for existing bugs a few
times. Choose the product, component, and versioning/platform information. Enter
a detailed description. As detailed as possible to make it easy to reproduce for
Red Hat.

RFE submissions should be well thought out and have a clear justification why
they should be in the base distribution. Red Hat can't well QA and bundle anything
and everything, serious thought has to be made on each component of the distribution.

The short answer: They can't, legal issues. Remember that a lot of
technology that may be used is cross-licensed from other companies. So in
order to release OSS drivers and such each company would have to agree to
licensing, versions, etc. Its not a trivial thing especially considering
the issue of IP (Intellectual Property) and trade-secrets.

The longer answer includes the fact these companies don't feel there is a
market for such work. They also feel their competition would gain by their
work, which is a backwards way of thinking about it. All in all we
encourage you to contact these vendors and suggestion fully OSS drivers
using standard interfaces (ie. drivers and not complete kernel and GLX
packages).

In the UN*X world there are alot of "flavors" and methodologies. The two
largest are BSD and System V. Each UN*X implementation adopts tools and structures
for both traditional BSD and SysV but they eventually "lean" one way or another.
The core differences between BSD and SysV are beyond the scope of this FAQ but we
heavily encourage you to read up on each flavor. Read closely, objectively, take
other Point Of Views into consideration, etc. Draw your own conclusions for your
application. In the past there were clear advantages to BSD from a networking
and memory management standpoint. With the Linux 2.4 series of kernels that is
not the case anymore. Now its more about application support, scalability,
personal loyalties, etc.

Anytime somebody pipes (insert person/company) as a source or reason to use
something, be wary. Chances are he/she doesn't have all the details to go
blindly with that choice. After all, these aren't sneakers where celebrity
endorsements can define your options!

Remember to use man, info, google.com, and deja.com. Although,
before you look ~off~ the system, check the /usr/share/doc directories
for additional documentation as well. For any major package (Apache,
Mozilla, etc.) their own sites probably have a FAQ as well. Etc. Asking
blindly in IRC will never allow you to fully grow and learn to your
potential. So give it your best effort on-your-own and up-front.

When your Linux box boots, the first process that shows up is init. Init performs tasks that are outlined in /etc/inittab. If you look in /etc/inittab you'll see
runlevels defined from 0 to 6. For each runlevel, there is a corresponding directory in /etc/rc.d/. Depending on the runlevel you use, it'll go into the directory under /etc/rc.d/ that
is designated for that runlevel, and execute all the scripts beginning with the letter K (meaning "kill" the process or service) with an argument of "stop". Next, it runs all the
scripts that begin with the letter S ith an argument of "start" to start
the process or service. Order of K and S script execution is based on sort order; the script named S90mysql
would execute before the script named S95httpd. All the scripts in these directories are actually symbolic links to scripts residing in /etc/rc.d/init.d/. It doesn't take long to figure
out the creation and maintenance of these scripts and symbolic links could be quite the chore.

Thats where chkconfig steps in! chkconfig is a command-line tool used to enable/disable and maintain services for each runlevel (man runlevel) including those run from xinetd.
man chkconfig is a good place to start but you'll notice it doesn't provide any examples so lets go through a couple common tasks with chkconfig. Then hopefully it'll be easier
to pick up. Modifying a chkconfig entry is almost as easy as listing the existing configuration.
The form is:

chkconfig [--level <levels>] <name> <on|off|reset>

chkconfig --list Shows you all services (including those run from xinetd) for all runlevels and whether they are enabled or disabled.chkconfig --list | grep sendmail Since --list by itself results in everything being displayed, to narrow it down, you pipe (|) it through to grep.chkconfig --level 3 sendmail off This would turn off sendmail for the runlevel of 3. Re-running chkconfig --list |grep sendmail will confirm this. So next time you boot into
runlevel 3, sendmail will not launch.chkconfig --level 35 sendmail off This does the same as above except here we specified multiple runlevels (3 and 5).chkconfig --level 2345 sendmail on This enables sendmail to be started whenever you boot into runlevel 2, 3, 4, or 5.chkconfig --del sendmail At times, removing a service altogether may be in order. sendmail for example, on client machines where incoming mail for local accounts is not
required, running sendmail as a daemon may not be necessary. The following command will may be desirable since it reduces potential security risks. It removes all sendmail scripts from
/etc/rc.d/rc#.d/ where # is the runlevel number, but leaves the main sendmail script located in /etc/rc.d/init.d/ intact, just in case you want to re-establish sendmail as a service for
runlevels again.chkconfig --add sendmail Here chkconfig will read the configuration settings in /etc/rc.d/init.d/sendmail and establish which runlevels and priority sendmail will be run at.

Now that takes care of most service administration, lets move onto a cool feature of Red Hat's chkconfig, primarily its dealings with xinetd (the secure superdaemon). As
you know, inetd was replaced by xinetd in Red Hat 7.x. In addition, chkconfig functionality has been extended to manage some of the functionality of xinetd's Internet services. If you
run chkconfig --list, at the bottom you'll see "xinetd based services:" and a list of services along with their state (on|off). If you wanted to quickly disable a service, say
finger, you type: chkconfig finger off. Pretty neat, huh? However, there is one "gotcha." When the configuration is changed, the xinetd is signaled automatically to reload
the new configuration with the command /etc/rc.d/init.d/xinetd reload,
that is executed by chkconfig. This script performs a kill with the SIGUSR2 signal which instructs xinetd to
perform a hard reconfiguration. What does that mean? Well, active sessions of services offered through xinetd (ie., Telnet, FTP, etc) are immediately terminated. So unless you want to
modify the xinetd script so that the reload option sends a SIGUSER1 signal (soft reconfiguration), just plan your chkconfig use when the service isn't being used by someone.

Rawhide is Red Hat's public archive of development snap-shots. These are bleeding edge, may be unstable, could be ugly, and might make your system smell funny. They are
UNSUPPORTED but feedback is appreciated via BugZilla the almighty (and hungry). Rawhide is available at:

First off, you should really use SSH and SFTP where possible.
If thats not an option you want to make sure the packages for XINETD are
installed and each server you want (ie. telnet-server) is also installed.
Then take a gander at "man xinetd", "man xinetd.conf".. Under Red Hat
Linux 7.x you'll find the separate config files, labeled by service, in
"/etc/xinetd.d". By default each service will have a line like
"disable = yes" which will, obviously, keep the service off. So you'll want
to comment out that line. Next you'll want to make sure XINET is running/enabled
in your "runlevel". Type "runlevel" to determine your runlevel and use "chkconfig"
to enable Xinetd for that runlevel. For example "chkconfig --level 5 xinetd on"
would enable xinetd in runlevel 5. "man chkconfig" for other options. Then you'll
want to start (if needed) or reload the Xinet config files. To start
xinet "service xinetd start", to just reload the config files "service xinetd
reload"..

When someone comes into #redhat and has troubles, often users give that person specific commands to run, to help diagnose
the problem. Often users run those programs but get "Command not found" messages so they assume they do not have said program installed.
Most times however, that is not the case. The program is just not in the user's $PATH. For example, fuser or modprobe are
located in "/sbin" directory. Traditionally /sbin is not in a user's PATH because they contain system binaries which users should not
have to use. In order to run these programs, you have to do one of two things. 1) add "/sbin" to your path (not recommended) or 2) add the
path to the command (commonly referred to as "absolute paths"). So instead of typing: fuser, type: /sbin/fuser.

Now the problem is solved by this raises another question, how did you know fuser was in /sbin? You may have heard of a
command called which that will show you the full path of shell commands. But a more useful command to learn is called
whereis. "whereis" will not only locate the binary, but it'll find its man pages and even source code. "whereis fuser" will return
/sbin/fuser & fuser's man page location.

There are two answers, depending on which side of the network you
want to monitor.

The command ( netstat -a ) will list all of the ports
that are currently listening or established on the local machine.
These ports may not be able to establish connections to other
machines due to firewalling or other routing issues, but they are
listed anyway.

The programs nmap and ghostscan are useful
for scanning for open ports on a remote machine. These will
generally detect a subset of the ports that netstat
would display, depending on firewalling and other routing issues.
As there are many features to these programs, check their own
documentation.

The command ( lsof -nPsli TCP ) will list all open files
that correspond to TCP internet connections. On Linux and many
Unix-like systems, an open TCP/IP port connection is also tracked
as if it were a file.

If you just want to access your files, this is easy. Make
a mount point for the partition ( mkdir /mnt/windows ),
and mount the partition as type vfat ( mount -t vfat
/dev/hdXX /mnt/windows ) where hdXX is your windows partition.
This is fine for read and write, but it is a limited
filesystem. This means that there are no permissions, or ownership of
files or devices on that mounted partition.

Michele is not a chick, he's a man, baby! Yeah! He was once a Red Hat employee, in Italy.
For those of you still confused, here is a graphical explanation:
Michele is a man, like Bruce Willis and Mr. T.
He is not a girl, like Katie Holmes and Wonder Woman.

Assuming your graphics adapter supports framebuffer, use
the vga= parameter on your lilo or grub kernel line. The
Framebuffer-HOWTO
5.3 contains a hex table of possible modes. Convert the hex mode to a
decimal mode, and append the result to vga= on the kernel line. e.g.,
0x314 is a 16bit 800x600 mode that produces 100 cols by 37 rows. It
converts to decimal 788. So if you want 100x37, add 'vga=788' to your
kernel line. In order to try to pick a mode, add 'vga=ask' to your
kernel line, and you will be prompted to pick from a list of possible
modes.

If you already have an ext2 partition, you can enable ext3
journaling by unmounting it, running tune2fs -j /dev/hda3
(where /dev/hda3 is the ext2 partition you're converting), then
remounting it as ext3.
If you're converting your / partition to ext3, you will
also need to create/update your initrd.img with mkinitrd.
All this information and more is covered at http://www.uow.edu.au/~andrewm/linux/ext3/ext3-usage.html.

Due to patent licensing, and conflicts between such patent licenses
and the licenses of application source code, MPEG-1/2 audio layer 3
(mp3) support has been removed from applications in Red Hat Linux such
as XMMS and noatun. Red Hat suggests the use of Ogg Vorbis(TM), an
open, non-proprietary, patent-and-royalty-free compressed audio
format. Summary: Because of the restrictions on mp3 licenses, no GPL license
can be applied to mp3 technology.Read the official Red Hat statement here.Guru Labs xmms MP3 plugin for RHL 8.0

1. run gnome-session-properties
2. click the "current session" tab
3. select your currently running window manager from the list
(metacity in this case)
4. click the "remove" button
WARNING! Don't click the "apply" button yet or you will
lose your currently running window manager,
crash Gnome panel, and/or lose input focus to _all_ open
windows.
5. open an xterm and run:sleep 10; nohup /usr/bin/sawfish 1>dev/null &
You now have 10 seconds to click the "apply"
button in gnome-session-properties. If you're lucky your
currently running window manager will die, Gnome panel
will crash, and your new window manager will start up in
10 seconds.
6. run gnome-session-save.

If you wish to add information or correct information
contained in this FAQ, please email the current maintainer.
Many thanks go to all the people who have already
contributed from #redhat, in no particular order: