Friday, February 20, 2009
Tuesday, February 03, 2009
Adding a Slave Zone
To add a slave zone (also known as a secondary master), click the New button and select Slave Zone. Enter the domain name for the slave zone in the Domain name text area.
A new window will appear, as shown in Figure 21-4, with the following options:
Name — The domain name that was entered in the previous window.
Masters List — The nameservers from which the slave zone retrieves its data. Each value must be a valid IP address. You can only enter numbers and periods (.) in the text area.
File Name — File name of the DNS database file in /var/named.
After configuring the slave zone, click OK to return to the main window as shown in Figure 21-1. Click Save to write the /etc/named.conf configuration file and have the daemon reload the configuration files.
The configuration creates an entry similar to the following in /etc/named.conf:
zone "slave.example.com" { |
The configuration file /var/named/slave.example.com.zone is created by the named service when it downloads the zone data from the master server(s).
Adding a Reverse Master Zone
To add a reverse master zone, click the New button and select Reverse Master Zone. Enter the first three octets of the IP address range that you want to configure. For example, if you are configuring the IP address range 192.168.10.0/255.255.255.0, enter 192.168.10 in the IP Address (first 3 Octets) text area.
A new window will appear, as shown in Figure 21-3, with the following options:
IP Address — The first three octets that you just entered in the previous window.
Reverse IP Address — Non-editable. Pre-populated based on the IP Address entered.
Contact —Email address of the main contact for the master zone.
File Name — File name of DNS database file in the /var/named directory.
Primary Nameserver (SOA) — State of authority (SOA) record. This specifies the nameserver that is the best resource of information for this domain.
Serial Number — The serial number of the DNS database file. This number must be incremented each time the file is changed, so that the slave nameservers for the zone will retrieve the latest data. The Bind Configuration Tool increments this number each time the configuration changes. It can also be incremented manually by clicking the Set button next to the Serial Number value.
Time Settings — The Refresh, Retry, Expire, and Minimum TTL (Time to Live) values that are stored in the DNS database file.
Nameservers — Add, edit, and delete name servers for the reverse master zone. At least one nameserver is required.
Reverse Address Table — List of IP addresses within the reverse master zone and their hostnames. For example, for the reverse master zone 192.168.10, you can add 192.168.10.1 in the Reverse Address Table with the hostname one.example.com. The hostname must end with a period (.) to specify that it is a full hostname.
A Primary Nameserver (SOA) must be specified, and at least one nameserver record must be specified by clicking the Add button in the Nameservers section.
After configuring the Reverse Master Zone, click OK to return to the main window as shown in Figure 21-1. From the pulldown menu, click Save to write the /etc/named.conf configuration file, write all the individual zone files in the /var/named directory, and have the daemon reload the configuration files.
The configuration creates an entry similar to the following in /etc/named.conf:
zone "10.168.192.in-addr.arpa" { |
It also creates the file /var/named/10.168.192.in-addr.arpa.zone with the following information:
$TTL 86400 |
BIND Configuration
This chapter assumes that you have a basic understanding of BIND and DNS; it does not attempt to explain the concepts of BIND and DNS. This chapter does explain how to use the Bind Configuration Tool (redhat-config-bind) to configure basic BIND server zones. The Bind Configuration Tool creates the /etc/named.conf configuration file and the zone configuration files in the /var/named directory each time you apply your changes.
 | Important |
|---|---|
Do not edit the /etc/named.conf configuration file. Bind Configuration Tool generates this file after you apply your changes. If you want to configure settings that are not configurable using Bind Configuration Tool, add them to /etc/named.custom. |
The Bind Configuration Tool requires the X Window System and root access. To start the Bind Configuration Tool, go to the Main Menu Button (on the Panel) => System Settings => Server Settings => Domain Name Service or type the command redhat-config-bind at a shell prompt (for example, in an XTerm or GNOME-terminal).
The Bind Configuration Tool configures the default zone directory to be /var/named. All zone files specified are relative to this directory. The Bind Configuration Tool also includes basic syntax checking when values are entered. For example, if a valid entry is an IP address, you are only allowed to type numbers and periods (.) into the text area.
The Bind Configuration Tool allows you to add a forward master zone, a reverse master zone, and a slave zone. After adding the zones, you can edit or delete them from the main window as shown in Figure 21-1.
After adding, editing, or deleting a zone, you must choose click the Save button or select File => Save to write the /etc/named.conf configuration file and all the individual zone files in the /var/named directory. Saving changes also causes the named service to reload the configuration files. Selecting File => Quit saves the changes before quitting the application.
21.1. Adding a Forward Master Zone
To add a forward master zone (also known as a primary master), click the New button, select Forward Master Zone, and enter the domain name for the master zone in the Domain name text area.
A new window as shown in Figure 21-2 will appear with the following options:
Name — Domain name that was just entered in the previous window.
File Name — File name of the DNS database file, relative to /var/named. It is preset to the domain name with .zone appended to it.
Contact — Email address of the main contact for the master zone.
Primary Nameserver (SOA) — State of authority (SOA) record. This specifies the nameserver that is the best resource of information for this domain.
Serial Number — The serial number of the DNS database file. This number must be incremented each time the file is changed, so that the slave nameservers for the zone will retrieve the latest data. The Bind Configuration Tool increments this number each time the configuration changes. It can also be incremented manually by clicking the Set button next to the Serial Number value.
Time Settings — The Refresh, Retry, Expire, and Minimum TTL (Time to Live) values that are stored in the DNS database file. All values are in seconds.
Records — Add, edit, and delete record resources of type Host, Alias, and Name server.
A Primary Nameserver (SOA) must be specified, and at least one nameserver record must be specified by clicking the Add button in the Records section.
After configuring the Forward Master Zone, click OK to return to the main window as shown in Figure 21-1. From the pulldown menu, click Save to write the /etc/named.conf configuration file, write all the individual zone files in the /var/named directory, and have the daemon reload the configuration files.
The configuration creates an entry similar to the following in /etc/named.conf:
zone "forward.example.com" { |
It also creates the file /var/named/forward.example.com.zone with the following information:
$TTL 86400 |
Configuring a DHCP Server
You can configure a DHCP server using the configuration file /etc/dhcpd.conf.
DHCP also uses the file /var/lib/dhcp/dhcpd.leases to store the client lease database. Refer to Section 18.2.2 Lease Database for more information.
Configuration File
The first step in configuring a DHCP server is to create the configuration file that stores the network information for the clients. Global options can be declared for all clients, or options can be declared for each client system.
The configuration file can contain any extra tabs or blank lines for easier formatting. The keywords are case-insensitive, and lines beginning with a hash mark (#) are considered comments.
Two DNS update schemes are currently implemented — the ad-hoc DNS update mode and the interim DHCP-DNS interaction draft update mode. If and when these two are accepted as part of the IETF standards process, there will be a third mode — the standard DNS update method. The DHCP server must be configured to use one of the two current schemes. Version 3.0b2pl11 and previous version used the ad-hoc mode; however, it has been depreciated. If you want to keep the same behavior, add the following line to the top of the configuration file:
ddns-update-style ad-hoc; |
To use the recommended mode, add the following line to the top of the configuration file:
ddns-update-style interim; |
Read the dhcpd.conf man page for details about the different modes.
There are two types of statements in the configuration file:
Parameters — state how to perform a task, whether to perform a task, or what network configuration options to send to the client.
Declarations — describe the topology of the network, describe the clients, provide addresses for the clients, or apply a group of parameters to a group of declarations.
Some parameters must start with the option keyword and are referred to as options. Options configure DHCP options; whereas, parameters configure values that are not optional or control how the DHCP server behaves.
Parameters (including options) declared before a section enclosed in curly brackets ({ }) are considered global parameters. Global parameters apply to all the sections below it.
| Important |
|---|---|
If you change the configuration file, the changes will not take effect until you restart the DHCP daemon with the command service dhcpd restart. |
In Example 18-1, the routers, subnet-mask, domain-name, domain-name-servers, and time-offset options are used for any host statements declared below it.
As shown in Example 18-1, you can declare a subnet. You must include a subnet declaration for every subnet in your network. If you do not, the DHCP server will fail to start.
In this example, there are global options for every DHCP client in the subnet and a range declared. Clients are assigned an IP address within the range.
subnet 192.168.1.0 netmask 255.255.255.0 { |
Example 18-1. Subnet Declaration
All subnets that share the same physical network should be declared within a shared-network declaration as shown in Example 18-2. Parameters within the shared-network but outside the enclosed subnet declarations are considered global parameters. The name of the shared-network should be a descriptive title for the network such as test-lab to describe all the subnets in a test lab environment.
shared-network name { |
Example 18-2. Shared-network Declaration
As demonstrated in Example 18-3, the group declaration can be used to apply global parameters to a group of declarations. You can group shared networks, subnets, hosts, or other groups.
group { |
Example 18-3. Group Declaration
To configure a DHCP server that leases a dynamic IP address to a system within a subnet, modify Example 18-4 with your values. It declares a default lease time, maximum lease time, and network configuration values for the clients. This example assigns IP addresses in the range 192.168.1.10 and 192.168.1.100 to client systems.
default-lease-time 600; |
Example 18-4. Range Parameter
To assign an IP address to a client based on the MAC address of the network interface card, use the hardware ethernet parameter within a host declaration. As demonstrated in Example 18-5, the host apex declaration specifies that the network interface card with the MAC address 00:A0:78:8E:9E:AA always receives the IP address 192.168.1.4.
Notice that you can also use the optional parameter host-name to assign a host name to the client.
host apex { |
Example 18-5. Static IP Address using DHCP
 | Tip | |
|---|---|---|
You can use the sample configuration file in Red Hat Linux 9 as a starting point and then add your own custom configuration options to it. Copy it to its proper location with the command
|
For a complete list of option statements and what they do, refer to the dhcp-options man page.
Lease Database
On the DHCP server, the file /var/lib/dhcp/dhcpd.leases stores the DHCP client lease database. This file should not be modified by hand. DHCP lease information for each recently assigned IP address is automatically stored in the lease database. The information includes the length of the lease, to whom the IP address has been assigned, the start and end dates for the lease, and the MAC address of the network interface card that was used to retrieve the lease.
All times in the lease database are in Greenwich Mean Time (GMT), not local time.
The lease database is recreated from time to time so that it is not too large. First, all known leases are saved in a temporary lease database. The dhcpd.leases file is renamed dhcpd.leases~, and the temporary lease database is written to dhcpd.leases.
The DHCP daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written. If this happens, there is no dhcpd.leases file that is required to start the service. Do not create a new lease file if this occurs. If you do, all the old leases will be lost and cause many problems. The correct solution is to rename the dhcpd.leases~ backup file to dhcpd.leases and then start the daemon.
Starting and Stopping the Server
| Important |
|---|---|
Before you start the DHCP server for the first time, it will fail unless there is an existing dhcpd.leases file. Use the command touch /var/lib/dhcp/dhcpd.leases to create the file if it does not exist. |
To start the DHCP service, use the command /sbin/service dhcpd start. To stop the DHCP server, use the command /sbin/service dhcpd stop. If you want the daemon to start automatically at boot time, see Chapter 14 Controlling Access to Services for information on how to manage services.
If you have more than one network interface attached to the system, but you only want the DHCP server to start on one of the interface, you can configure the DHCP server to start only on that device. In /etc/sysconfig/dhcpd, add the name of the interface to the list of DHCPDARGS:
# Command line options here |
This is useful if you have a firewall machine with two network cards. One network card can be configured as a DHCP client to retrieve an IP address to the Internet. The other network card can be used as a DHCP server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users can not connect to the daemon via the Internet.
Other command line options that can be specified in /etc/sysconfig/dhcpd include:
-p
— Specify the udp port number on which dhcpd should listen. The default is port 67. The DHCP server transmits responses to the DHCP clients at a port number one greater than the udp port specified. For example, if you accept the default of port 67, the server listens on port 67 for requests and responses to the client on port 68. If you specify a port here and use the DHCP relay agent, you must specify the same port on which the DHCP relay agent should listen. See Section 18.2.4 DHCP Relay Agent for details. -f — Run the daemon as a foreground process. This is mostly used for debugging.
-d — Log the DHCP server daemon to the standard error descriptor. This is mostly used for debugging. If this is not specified, the log is written to /var/log/messages.
-cf filename — Specify the location of the configuration file. The default location is /etc/dhcpd.conf.
-lf filename — Specify the location of the lease database file. If a lease database file already exists, it is very important that the same file be used every time the DHCP server is started. It is strongly recommended that this option only be used for debugging purposes on non-production machines. The default location is /var/lib/dhcp/dhcpd.leases.
-q — Do not print the entire copyright message when starting the daemon.
DHCP Relay Agent
The DHCP Relay Agent (dhcrelay) allows you to relay DHCP and BOOTP requests from a subnet with no DHCP server on it to one or more DHCP servers on other subnets.
When a DHCP client requests information, the DHCP Relay Agent forwards the request to the list of DHCP servers specified when the DHCP Relay Agent is started. When a DHCP server returns a reply, the reply is broadcast or unicast on the network that sent the original request.
The DHCP Relay Agent listens for DHCP requests on all interfaces unless the interfaces are specified in /etc/sysconfig/dhcrelay with the INTERFACES directive.
To start the DHCP Relay Agent, use the command service dhcrelay start.
Configuring an OpenSSH Client
To connect to an OpenSSH server from a client machine, you must have the openssh-clients and openssh packages installed on the client machine.
Using the ssh Command
The ssh command is a secure replacement for the rlogin, rsh, and telnet commands. It allows you to log in to a remote machine as well as execute commands on a remote machine.
Logging in to a remote machine with ssh is similar to using telnet. To log in to a remote machine named penguin.example.net, type the following command at a shell prompt:
ssh penguin.example.net |
The first time you ssh to a remote machine, you will see a message similar to the following:
The authenticity of host 'penguin.example.net' can't be established. |
Type yes to continue. This will add the server to your list of known hosts as seen in the following message:
Warning: Permanently added 'penguin.example.net' (RSA) to the list of known hosts. |
Next, you will see a prompt asking for your password for the remote machine. After entering your password, you will be at a shell prompt for the remote machine. If you do not specify a username the username that you are logged in as on the local client machine is passed to the remote machine. If you want to specify a different username, use the following command:
ssh username@penguin.example.net |
You can also use the syntax ssh -l username penguin.example.net.
The ssh command can be used to execute a command on the remote machine without logging in to a shell prompt. The syntax is ssh hostname command. For example, if you want to execute the command ls /usr/share/doc on the remote machine penguin.example.net, type the following command at a shell prompt:
ssh penguin.example.net ls /usr/share/doc |
After you enter the correct password, the contents of the remote directory /usr/share/doc will be displayed, and you will return to your local shell prompt.
Using the scp Command
The scp command can be used to transfer files between machines over a secure, encrypted connection. It is similar to rcp.
The general syntax to transfer a local file to a remote system is as follows:
scp localfile username@tohostname:/newfilename |
The localfile specifies the source, and username@tohostname:/newfilename specifies the destination.
To transfer the local file shadowman to your account on penguin.example.net, type the following at a shell prompt (replace username with your username):
scp shadowman username@penguin.example.net:/home/username |
This will transfer the local file shadowman to /home/username/shadowman on penguin.example.net.
The general syntax to transfer a remote file to the local system is as follows:
scp username@tohostname:/remotefile /newlocalfile |
The remotefile specifies the source, and newlocalfile specifies the destination.
Multiple files can be specified as the source files. For example, to transfer the contents of the directory /downloads to an existing directory called uploads on the remote machine penguin.example.net, type the following at a shell prompt:
scp /downloads/* username@penguin.example.net:/uploads/ |
Using the sftp Command
The sftp utility can be used to open a secure, interactive FTP session. It is similar to ftp except that it uses a secure, encrypted connection. The general syntax is sftp username@hostname.com. Once authenticated, you can use a set of commands similar to those used by FTP. Refer to the sftp man page for a list of these commands. To read the man page, execute the command man sftp at a shell prompt. The sftp utility is only available in OpenSSH version 2.5.0p1 and higher.
Generating Key Pairs
If you do not want to enter your password every time you use ssh, scp, or sftp to connect to a remote machine, you can generate an authorization key pair.
Keys must be generated for each user. To generate keys for a user, use the following steps as the user who wants to connect to remote machines. If you complete the steps as root, only root will be able to use the keys.
Starting with OpenSSH version 3.0, ~/.ssh/authorized_keys2, ~/.ssh/known_hosts2, and /etc/ssh_known_hosts2 are obsolete. SSH Protocol 1 and 2 share the ~/.ssh/authorized_keys, ~/.ssh/known_hosts, and /etc/ssh/ssh_known_hosts files.
Red Hat Linux 9 uses SSH Protocol 2 and RSA keys by default.
| Tip |
|---|---|
If you reinstall Red Hat Linux and want to save your generated key pair, backup the .ssh directory in your home directory. After reinstalling, copy this directory back to your home directory. This process can be done for all users on your system, including root. |
Generating an RSA Key Pair for Version 2
Use the following steps to generate an RSA key pair for version 2 of the SSH protocol. This is the default starting with OpenSSH 2.9.
To generate an RSA key pair to work with version 2 of the protocol, type the following command at a shell prompt:
ssh-keygen -t rsa
Accept the default file location of ~/.ssh/id_rsa. Enter a passphrase different from your account password and confirm it by entering it again.
The public key is written to ~/.ssh/id_rsa.pub. The private key is written to ~/.ssh/id_rsa. Never distribute your private key to anyone.
Change the permissions of your .ssh directory using the command chmod 755 ~/.ssh.
Copy the contents of ~/.ssh/id_rsa.pub to ~/.ssh/authorized_keys on the machine to which you want to connect. If the file ~/.ssh/authorized_keys does not exist, you can copy the file ~/.ssh/id_rsa.pub to the file ~/.ssh/authorized_keys on the other machine.
If you are running GNOME, skip to Section 15.3.4.4 Configuring ssh-agent with GNOME. If you are not running the X Window System, skip to Section 15.3.4.5 Configuring ssh-agent.
Generating a DSA Key Pair for Version 2
Use the following steps to generate a DSA key pair for version 2 of the SSH Protocol.
To generate a DSA key pair to work with version 2 of the protocol, type the following command at a shell prompt:
ssh-keygen -t dsa
Accept the default file location of ~/.ssh/id_dsa. Enter a passphrase different from your account password and confirm it by entering it again.
Tip A passphrase is a string of words and characters used to authenticate a user. Passphrases differ from passwords in that you can use spaces or tabs in the passphrase. Passphrases are generally longer than passwords because they are usually phrases instead of a single word.
The public key is written to ~/.ssh/id_dsa.pub. The private key is written to ~/.ssh/id_dsa. It is important never to give anyone the private key.
Change the permissions of your .ssh directory using the command chmod 755 ~/.ssh.
Copy the contents of ~/.ssh/id_dsa.pub to ~/.ssh/authorized_keys on the machine to which you want to connect. If the file ~/.ssh/authorized_keys does not exist, you can copy the file ~/.ssh/id_dsa.pub to the file ~/.ssh/authorized_keys on the other machine.
If you are running GNOME, skip to Section 15.3.4.4 Configuring ssh-agent with GNOME. If you are not running the X Window System, skip to Section 15.3.4.5 Configuring ssh-agent.
Generating an RSA Key Pair for Version 1.3 and 1.5
Use the following steps to generate an RSA key pair, which is used by version 1 of the SSH Protocol. If you are only connecting between systems that use DSA, you do not need an RSA version 1.3 or RSA version 1.5 key pair.
To generate an RSA (for version 1.3 and 1.5 protocol) key pair, type the following command at a shell prompt:
ssh-keygen -t rsa1
Accept the default file location (~/.ssh/identity). Enter a passphrase different from your account password. Confirm the passphrase by entering it again.
The public key is written to ~/.ssh/identity.pub. The private key is written to ~/.ssh/identity. Do not give anyone the private key.
Change the permissions of your .ssh directory and your key with the commands chmod 755 ~/.ssh and chmod 644 ~/.ssh/identity.pub.
Copy the contents of ~/.ssh/identity.pub to the file ~/.ssh/authorized_keys on the machine to which you wish to connect. If the file ~/.ssh/authorized_keys does not exist, you can copy the file ~/.ssh/identity.pub to the file ~/.ssh/authorized_keys on the remote machine.
If you are running GNOME, skip to Section 15.3.4.4 Configuring ssh-agent with GNOME. If you are not running GNOME, skip to Section 15.3.4.5 Configuring ssh-agent.
Configuring ssh-agent with GNOME
The ssh-agent utility can be used to save your passphrase so that you do not have to enter it each time you initiate an ssh or scp connection. If you are using GNOME, the openssh-askpass-gnome utility can be used to prompt you for your passphrase when you log in to GNOME and save it until you log out of GNOME. You will not have to enter your password or passphrase for any ssh or scp connection made during that GNOME session. If you are not using GNOME, refer to Section 15.3.4.5 Configuring ssh-agent.
To save your passphrase during your GNOME session, follow the following steps:
You will need to have the package openssh-askpass-gnome installed; you can use the command rpm -q openssh-askpass-gnome to determine if it is installed or not. If it is not installed, install it from your Red Hat Linux CD-ROM set, from a Red Hat FTP mirror site, or using Red Hat Network.
Select Main Menu Button (on the Panel) => Preferences => More Preferences => Sessions, and click on the Startup Programs tab. Click Add and enter /usr/bin/ssh-add in the Startup Command text area. Set it a priority to a number higher than any existing commands to ensure that it is executed last. A good priority number for ssh-add is 70 or higher. The higher the priority number, the lower the priority. If you have other programs listed, this one should have the lowest priority. Click Close to exit the program.
Log out and then log back into GNOME; in other words, restart X. After GNOME is started, a dialog box will appear prompting you for your passphrase(s). Enter the passphrase requested. If you have both DSA and RSA key pairs configured, you will be prompted for both. From this point on, you should not be prompted for a password by ssh, scp, or sftp.
Configuring ssh-agent
The ssh-agent can be used to store your passphrase so that you do not have to enter it each time you make a ssh or scp connection. If you are not running the X Window System, follow these steps from a shell prompt. If you are running GNOME but you do not want to configure it to prompt you for your passphrase when you log in (see Section 15.3.4.4 Configuring ssh-agent with GNOME), this procedure will work in a terminal window, such as an XTerm. If you are running X but not GNOME, this procedure will work in a terminal window. However, your passphrase will only be remembered for that terminal window; it is not a global setting.
At a shell prompt, type the following command:
exec /usr/bin/ssh-agent $SHELL
Then type the command:
ssh-add
and enter your passphrase(s). If you have more than one key pair configured, you will be prompted for each one.
When you log out, your passphrase(s) will be forgotten. You must execute these two commands each time you log in to a virtual console or open a terminal window.
Configuring an OpenSSH Server
To run an OpenSSH server, you must first make sure that you have the proper RPM packages installed. The openssh-server package is required and depends on the openssh package.
The OpenSSH daemon uses the configuration file /etc/ssh/sshd_config. The default configuration file installed with Red Hat Linux should be sufficient for most purposes. If you want to configure the daemon in ways not provided by the default sshd_config, read the sshd man page for a list of the keywords that can be defined in the configuration file.
To start the OpenSSH service, use the command /sbin/service sshd start. To stop the OpenSSH server, use the command /sbin/service sshd stop. If you want the daemon to start automatically at boot time, refer to Chapter 14 Controlling Access to Services for information on how to manage services.
If you reinstall a Red Hat Linux system, and clients connected to it before the reinstall with any of the OpenSSH tools, after the reinstall, the client users will see the following message:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ |
The reinstalled system creates a new set of identification keys for the system; hence, the warning about the RSA host key changing. If you want to keep the host keys generated for the system, backup the /etc/ssh/ssh_host*key* files and restore them after the reinstall. This process retains the system's identity, and when clients try to connect to the system after the reinstall, they will not receive the warning message.
Managing DNS Settings
The DNS tab allows you to configure the system's hostname, domain, name servers, and search domain. Name servers are used to look up other hosts on the network.
If the DNS server names are retrieved from DHCP or PPPoE (or retrieved from the ISP), do not add primary, secondary, or tertiary DNS servers.
If the hostname is retrieved dynamically from DHCP or PPPoE (or retrieved from the ISP), do not change it.
Sunday, February 01, 2009
add a new user in Redhat 9.0
To add a user and set up the directories you want that user to have, use the useradd command. By default, this will add a user and create a home dircetory for that user, which will be located in /home.
EXAMPLE: /usr/sbin/useradd yourname will create the user yourname, and make the directory /home/yourname
Set the password for the new user by running passwd. This will give the user a password and activate the account.
EXAMPLE: /usr/bin/passwd yourname. You will be prompted twice for a password.
NOTE: If you want useradd to create more default directories than just /home/newuser, you can add them to /etc/skel. Anything you add to this directory will be created when you add a new user.
EXAMPLE: mkdir /etc/skel/www will add a directory called www to the skel dir. Now whenever you run useradd to create a new user, it will also create a www directory in the new users home directory.
There are also some options for useradd you can add if you wish, such as changing where the users home directory will be, or which skeleton directory to use. For more information on useradd options go to www.linuxdocs.org
browse using ~user in Redhat 9.0
In order to be able to browse a user's www folder (or public_html) by using ~user you must do two things:
- Configure apache to allow userdir to do this
- Reset permissions of the users home dir and public_html dir
1) To configure apache to allow ~userdir
First you have find the following part in the Apache config file, /etc/httpd/conf/httpd.conf. (It will be around line 350 to 380)
TIP: If you are editing with vi, hold down
# UserDir is disabled by default since it can confirm the presence
# of a username on the system (depending on home directory # permissions).
#
UserDir disable
#
# To enable requests to /~user/ to serve the user's public_html
# directory, remove the "UserDir disable" line above, and uncomment
# the following line instead:
#
#UserDir public_html
# of a username on the system (depending on home directory # permissions).
#
UserDir disable
#
# To enable requests to /~user/ to serve the user's public_html
# directory, remove the "UserDir disable" line above, and uncomment
# the following line instead:
#
#UserDir public_html
You need to edit two of the lines.
- Comment out the line UserDir disable (put a # at the beginning). This enables userdir.
- Uncomment the line UserDir public_html (remove the #). This sets the users dir to /home/~user/public_html
2) Reset permissions of home and public_html directories
You must also chmod /home/~user/public_html to 755.
Type /etc/init.d/httpd restart.
Apache Web Server in Redhat 9.0
Redhat 9 comes with Apache webserver. This is installed by default, but does not run at boot up.
To run Apache type the following at the command prompt:
/etc/init.d/httpd start
To test it type:
/etc/init.d/httpd status
If apache is running you should see something like the following:
httpd (pid 1844 1843 1842 1841 1840 1839 1838 1837 1828) is running...
There are several ways to run Apache at bootup, and here is one of the simple ones.
To run Apache at bootup type:
vi /etc/rc.local
This will open rc.local in the text editor "vi". Arrow down to the bottom of the text (there may not be any yet, in which case it will be the first line) and add:
/etc/init.d/httpd start
Then type :w and enter it (writes the file, i.e. saves it)
Followed by :q and enter it (quits the vi text editor)
start FTP in Redhat 9.0
Redhat 9 comes with the ftp server vsftpd. This is installed by default, but does not run at boot up.
To run vsftpd type: /etc/init.d/vsftpd start
Login to test it by typing ftp localhost at the prompt, and if you get the following, vsftpd is running.
Connected to localhost (127.0.0.1)
220 (vsFTP 1.1.3)
Name:
220 (vsFTP 1.1.3)
Name:
If you get "connection refused", and the prompt ftp>, then
Note: you cannot log into ftp as root, you must have a user set up.
There are several ways to run vsftpd at bootup, and here is one of the simple ones.
To run vsftpd at bootup type:
vi /etc/rc.local (this will open rc.local in the text editor "vi")
Arrow down to the bottom of the text (there may not be any yet, in which case it will be the first line)
type i to enter 'insert' mode, and add....
/etc/init.d/vsftpd start
Press the 'escape' key to exit 'insert' mode.
Then type :w and enter it (writes the file, i.e. saves it)
Followed by :q and enter it (quits the vi text editor)
configuration ip ( redhat 9 )
At the command prompt type /sbin/ifconfig to see what the IP address is, and other information on your network card.
There are two sections - eth0 and lo.
- Eth0 is information about your network card. The 2nd line in the eth0 section shows you the IP address assigned to that network card (in this case it's 192.168.1.2).
- lo is information about the loopback device (we won't go into this here).
Use /usr/sbin/netconfig to configure your network card.
You should get a GUI like this....
If you wish to continue, press ENTER.
You will get a window where you can enter the address you want....
Check Use dynamic if you want your IP address assigned automatically. I recommend leaving it unchecked at this stage.
Type in an IP address
The netmask of 255.255.255.0 should work
Enter the IP address of the gateway you use, if you use one.
Enter the IP address of the DNS nameserver you wish to use.
Subscribe to:
Posts (Atom)
