LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Linux Answers > Networking
User Name
Password

Notices

By ajeetraina at 2007-09-21 06:39

THE FEDORA DIRECTORY SERVER


- Implementation and Configurations

Followed List of Tasks:


1. Pre-requisite Software(s)
2. Configuring the NIS Server
3. Adding New NIS Users
4. Configuring the NIS Client
5. Installing the Fedora Directory Server
6. Migrating the NIS Database into LDIF file format
7. Importing the LDIF files into the Fedora Directory Structure



1. Pre-requisite Software(s)

This section contains information on operating system versions and further software needed for the complete installation and configurations.

These operations has been performed on Red Hat Enterprise Linux 2.6.9-55.ELxenU VMWare machine and should work on Fedora/CentOS and other Linux Distribution too.

If Fedora DS is being installed for production purpose, then the following pre-requisite settings has to be performed :
1. Verifying Disk Space Requirements
2. Verifying Required System Modules
3. Verifying the System Patches
4. Tuning the System


1. Verifying Disk Space Requirement
Ensure that you have sufficient disk space before downloading the software:
• Download drive: 120 MB
• Installation drive: 2 GB
2. Verifying Required System Modules
Directory Server is certified to work on:
• The Intel Pentium series processors [i686].
• The default kernel/glibc revisions that comes along with Red Hat Enterprise Linux and the other kernel revisions with their corresponding glibc revisions as mentioned below.
Red Hat Enterprise Linux 4:
o Default kernel: kernel-2.6.9-5_EL
o Kernel used for certification: kernel-2.6.9-5.0.5.EL
o Default glibc: glibc-2.3-4.2
o glibc used for certification: glibc-2.3.2-95.30
o Required Filesytem: ext3 (LARGEFILES support enabled) filesystem has been used for the certification process.
• With certain installed RPM packages on Red Hat Enterprise Linux, the server does not start.
3. Installing System Patches
Directory Server has been certified on Red Hat Enterprise Linux with the following kernel and glibc versions:
• Red Hat Enterprise Linux 4: default kernel kernel-2.6.9-5_EL (with certification on kernel-2.6.9-5.0.5.EL) and glibc version glibc-2.3-4.2 (with certification on glibc-2.3.2-95.30).
It is recommended that you use these kernel and glibc versions. If the machine is a single CPU machine, the corresponding kernel would be of the form kernel-x.x.x.x. If the machine is a multi-CPU machine, the corresponding kernel would be of the form kernel-smp-x.x.x.x.
4. Tuning the System
This section contains some basic system tuning information. Changing any of the following kernel-tuning parameters requires a system reboot.
• NFS Tuning: This tuning is recommended if you are using Directory Server to write to NFS mounted drives. On Linux, NFS is typically recommended to be done over TCP and not over UDP. Make the following change to the /etc/rc.d/init.d/autofs file:
+ localoptions='rsize=8192,wsize=8192,vers=3,tcp'
• TCP Tuning: You can increase the number of available local system ports available by running this command:
echo "1024 65000" > /proc/sys/net/ipv4/ip_local_port_range
• Make this change permanent by adding this line to the /etc/sysctl.conf file:
net.ipv4.ip_local_port_range = 1024 65000
• File Tuning: Check the current maximum number of files that can be stored on your system:
cat /proc/sys/fs/file-max
• If this number is less than 64000, increase it with this command:
echo 64000 > /proc/sys/fs/file-max
• Make the change permanent by adding this line to the /etc/sysctl.conf file:
fs.file-max = 64000
• Then, you need to increase the maximum number of open files. Add the following line to the /etc/security/limits.conf file:
* - nofile 8192
• Lastly, edit the file /etc/pam.d/system-auth to include this line if it does not already exist:
session required /lib/security/$ISA/pam_limits.so
You must log out and then log back in for changes in the limits.conf file to take effect.
[Note: If you are using older Red hat versions, JRE is required in order to use the Console]
2. Configuring the NIS Server
Network Information Services (NIS) enables you to create user accounts that can be shared across all systems on your network. The user account is created only on the NIS server. NIS clients download the necessary username and password data from the NIS server to verify each user login.
Before configuring the NIS we need to configure few NFS Server settings.The steps followed for this configurations are as follows:
Configuring The NFS Server
Here are the steps to configure the NFS server in this scenario:
1. Edit the /etc/exports file to allow NFS mounts of the /home directory with read/write access.
/home *(rw,sync)
2. Let NFS read the /etc/exports file for the new entry, and make /home available to the network with the exportfs command.
[root@test01 tmp]# exportfs -a
[root@test01 tmp]#
3. Make sure the required nfs, nfslock, and portmap daemons are both running and configured to start after the next reboot.
[root@test01 tmp]# chkconfig nfslock on
[root@test01 tmp]# chkconfig nfs on
[root@test01 tmp]# chkconfig portmap on
[root@test01 tmp]# service portmap start
Starting portmapper: [ OK ]
[root@test01 tmp]# service nfslock start
Starting NFS statd: [ OK ]
[root@test01 tmp]# service nfs start
Starting NFS services: [ OK ]
Starting NFS quotas: [ OK ]
Starting NFS daemon: [ OK ]
Starting NFS mountd: [ OK ]
[root@test01 tmp]#
After configuring the NFS server, we have to configure its clients, This will be covered next.
Configuring The NFS Client
You also need to configure the NFS clients to mount their /home directories on the NFS server.
These steps archive the /home directory. In a production environment in which the /home directory would be actively used, you'd have to force the users to log off, backup the data, restore it to the NFS server, and then follow the steps below. As this is a lab environment, these prerequisites aren't necessary.
1. Make sure the required netfs, nfslock, and portmap daemons are running and configured to start after the next reboot.
[root@client tmp]# chkconfig nfslock on
[root@client tmp]# chkconfig netfs on
[root@client tmp]# chkconfig portmap on
[root@client tmp]# service portmap start
Starting portmapper: [ OK ]
[root@client tmp]# service netfs start
Mounting other filesystems: [ OK ]
[root@client tmp]# service nfslock start
Starting NFS statd: [ OK ]
[root@client tmp]#
2. Keep a copy of the old /home directory, and create a new directory /home on which you'll mount the NFS server's directory.
[root@client tmp]# mv /home /home.save
[root@client tmp]# mkdir /home
[root@client tmp]# ll /
...
...
drwxr-xr-x 1 root root 11 Nov 16 20:22 home
drwxr-xr-x 2 root root 4096 Jan 24 2003 home.save
...
...
[root@client tmp]#
3. Make sure you can mount test01's /home directory on the new /home directory you just created. Unmount it once everything looks correct.
[root@client tmp]# mount 192.168.1.100:/home /home/
[root@client tmp]# ls /home
ftpinstall nisuser quotauser client www
[root@client tmp]# umount /home
[root@client tmp]#
4. Start configuring autofs automounting. Edit your /etc/auto.master file to refer to file /etc/auto.home for mounting information whenever the /home directory is accessed. After five minutes, autofs unmounts the directory.
#/etc/auto.master
/home /etc/auto.home --timeout 600
5. Edit file /etc/auto.home to do the NFS mount whenever the /home directory is accessed. If the line is too long to view on your screen, you can add a \ character at the end to continue on the next line.
#/etc/auto.home
* -fstype=nfs,soft,intr,rsize=8192,wsize=8192,nosuid,tcp \
192.168.1.100:/home:&
6. Start autofs and make sure it starts after the next reboot with the chkconfig command.
[root@client tmp]# chkconfig autofs on
[root@client tmp]# service autofs restart
Stopping automount:[ OK ]
Starting automount:[ OK ]
[root@client tmp]#
After doing this, you won't be able to see the contents of the /home directory on test01 as user root. This is because by default NFS activates the root squash feature, which disables this user from having privileged access to directories on remote NFS servers. You'll be able to test this later after NIS is configured.
All newly added Linux users will now be assigned a home directory under the new remote /home directory. This scheme will make the users feel their home directories are local, when in reality they are automatically mounted and accessed over your network.

Configuring the NIS Server
NFS only covers file sharing over the network. You now have to configure NIS login authentication for the lab students before the job is done. The configuration of the NIS server is not difficult, but requires many steps that you may overlook. Don't worry, we'll review each one in detail.
Install the NIS Server Packages
All the packages required for NIS clients are a standard part of most Fedora installations. The ypserv package for servers is needed to be installed through the http://www.fedora.org website.
Edit Your /etc/sysconfig/network File
You need to add the NIS domain you wish to use in the /etc/sysconfig/network file. For the school, call the domain NIS-SCHOOL-NETWORK.
#/etc/sysconfig/network
NISDOMAIN="NIS-LOGICA-NETWORK"
Edit Your /etc/yp.conf File
NIS servers also have to be NIS clients themselves, so you'll have to edit the NIS client configuration file /etc/yp.conf to list the domain's NIS server as being the server itself or localhost.
# /etc/yp.conf - ypbind configuration file
ypserver 127.0.0.1
Start The Key NIS Server Related Daemons
Start the necessary NIS daemons in the /etc/init.d directory and use the chkconfig command to ensure they start after the next reboot.
[root@test01 tmp]# service portmap start
Starting portmapper: [ OK ]
[root@test01 tmp]# service yppasswdd start
Starting YP passwd service: [ OK ]
[root@test01 tmp]# service ypserv start
Setting NIS domain name NIS-SCHOOL-NETWORK: [ OK ]
Starting YP server services: [ OK ]
[root@test01 tmp]#

[root@test01 tmp]# chkconfig portmap on
[root@test01 tmp]# chkconfig yppasswdd on
[root@test01 tmp]# chkconfig ypserv on
Table 30.1 lists a summary of the daemon's functions.
Required NIS Server Daemons
Daemon Name Purpose
portmap The foundation RPC daemon upon which NIS runs.
yppasswdd Lets users change their passwords on the NIS server from NIS clients
ypserv Main NIS server daemon
ypbind Main NIS client daemon
ypxfrd Used to speed up the transfer of very large NIS maps
Make sure they are all running before continuing to the next step. You can use the rpcinfo command to do this.
[root@test01 tmp]# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100009 1 udp 681 yppasswdd
100004 2 udp 698 ypserv
100004 1 udp 698 ypserv
100004 2 tcp 701 ypserv
100004 1 tcp 701 ypserv
[root@test01 tmp]#
The ypbind and ypxfrd daemons won't start properly until after you initialize the NIS domain. You'll start these daemons after initialization is completed.
Initialize Your NIS Domain
Now that you have decided on the name of the NIS domain, you'll have to use the ypinit command to create the associated authentication files for the domain. You will be prompted for the name of the NIS server, which in this case is test01.
With this procedure, all nonprivileged accounts are automatically accessible via NIS.
[root@test01 tmp]# /usr/lib/yp/ypinit -m
At this point, we have to construct a list of the hosts which will run NIS
servers. test01 is in the list of NIS server hosts. Please continue to add
the names for the other hosts, one per line. When you are done with the
list, type a <control D>.
next host to add: test01.logicacmg.com
next host to add:
The current list of NIS servers looks like this:

test01

Is this correct? [y/n: y] y
We need a few minutes to build the databases...
Building /var/yp/NIS-LOGICA-NETWORK/ypservers...
Running /var/yp/Makefile...
gmake[1]: Entering directory `/var/yp/NIS-LOGICA-NETWORK'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
Updating hosts.byname...
Updating hosts.byaddr...
Updating rpc.byname...
Updating rpc.bynumber...
Updating services.byname...
Updating services.byservicename...
Updating netid.byname...
Updating protocols.bynumber...
Updating protocols.byname...
Updating mail.aliases...
gmake[1]: Leaving directory `/var/yp/NIS-LOGICA-NETWORK'

test01 has been set up as a NIS master server.

Now you can run ypinit -s test01 on all slave server.
[root@test01 tmp]#
Note: Make sure portmap is running before trying this step or you'll get errors, such as:
failed to send 'clear' to local ypserv: RPC: Port mapper failureUpdating group.bygid...
You will have to delete the /var/yp/NIS-LOGICA-NETWORK directory and restart portmap, yppasswd, and ypserv before you'll be able to do this again successfully.
Start The ypbind and ypxfrd Daemons
You can now start the ypbind and the ypxfrd daemons because the NIS domain files have been created.
[root@test01 tmp]# service ypbind start
Binding to the NIS domain: [ OK ]
Listening for an NIS domain server.
[root@test01 tmp]# service ypxfrd start
Starting YP map server: [ OK ]
[root@test01 tmp]# chkconfig ypbind on
[root@test01 tmp]# chkconfig ypxfrd on




Make Sure The Daemons Are Running
All the NIS daemons use RPC port mapping and, therefore, are listed using the rpcinfo command when they are running correctly.
[root@test01 tmp]# rpcinfo -p localhost
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100021 1 udp 1024 nlockmgr
100021 3 udp 1024 nlockmgr
100021 4 udp 1024 nlockmgr
100004 2 udp 784 ypserv
100004 1 udp 784 ypserv
100004 2 tcp 787 ypserv
100004 1 tcp 787 ypserv
100009 1 udp 798 yppasswdd
600100069 1 udp 850 fypxfrd
600100069 1 tcp 852 fypxfrd
100007 2 udp 924 ypbind
100007 1 udp 924 ypbind
100007 2 tcp 927 ypbind
100007 1 tcp 927 ypbind
[root@test01 tmp]#
2. Adding New NIS Users
New NIS users can be created by logging into the NIS server and creating the new user account. In this case, you'll create a user account called nisuser and give it a new password.
Once this is complete, you then have to update the NIS domain's authentication files by executing the make command in the /var/yp directory.
This procedure makes all NIS-enabled, nonprivileged accounts become automatically accessible via NIS, not just newly created ones. It also exports all the user's characteristics stored in the /etc/passwd and /etc/group files, such as the login shell, the user's group, and home directory.
[root@test01 tmp]# useradd -g users nisuser
[root@test01 tmp]# passwd nisuser
Changing password for user nisuser.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[root@test01 tmp]# cd /var/yp
[root@test01 yp]# make
gmake[1]: Entering directory `/var/yp/NIS-LOGICA-NETWORK'
Updating passwd.byname...
Updating passwd.byuid...
Updating netid.byname...
gmake[1]: Leaving directory `/var/yp/NIS-LOGICA-NETWORK'
[root@test01 yp]#
You can check to see if the user's authentication information has been updated by using the ypmatch command, which should return the user's encrypted password string.
[root@test01 yp]# ypmatch nisuser passwd
nisuser:$1$d6E2i79Q$wp3Eo0Qw9nFD/::504:100::/home/nisuser:/bin/bash
[root@test01 yp]
You can also use the getent command, which has similar syntax. Unlike ypmatch, getent doesn't provide an encrypted password when run on an NIS server, it just provides the user's entry in the /etc/passwd file. On a NIS client, the results are identical with both showing the encrypted password.
[root@test01 yp]# getent passwd nisuser
nisuser:x:504:100::/home/nisuser:/bin/bash
[root@test01 yp]#

ADDING 10 NIS USERS
For Example, the following termianl shows the 10 NIS Users being added :
[root@test01 ~]# ypcat passwd
jupiter:$1$iNSHQcdZ$PdeDu2f.JEsf4eDyb2.bp/:508:100::/home/jupiter:/bin/bash
sijo:$1$SwLGgPWW$kH6cD1qjyNVqkOwmxGhQ90:511:100::/home/sijo:/bin/bash
earth:$1$s2wsRN8t$Q9O.3J6Cj/0794t7NcFz.0:509:100::/home/earth:/bin/bash
pluto:$1$zFQYZ7ok$a97j1kP/nt5xU.l12pSup.:507:100::/home/pluto:/bin/bash
nisuser:$1$tXXrsS7A$2Xm1bzs32hT44iAXlZuQ51:503:100::/home/nisuser:/bin/bash
purushottam:$1$t4E8AB7E$JXe.1xL/9frA91hyMhmDK1:510:100::/home/purushottam:/bin/bash
jack:$1$l4bfO/cT$u.X5Fd07Yw1aNe/EHDVKs0:500:500::/home/jack:/bin/bash
madan:$1$RWc0rRSJ$bDHOqcdyhnEQdfDDtRKBe/:505:100::/home/madan:/bin/bash
mark:$1$C.1hCRxK$riPSY1P/cRqKYq/Ya7/mk/:502:502::/home/mark:/bin/bash
test1:$1$h/t4wHF5$y/DxUwAeQAZM.tEPO8I630:512:512::/home/test1:/bin/bash
peter:$1$cQQOR3OI$/0pTgMuXo.IBLWrGpMflV0:501:501::/home/peter:/bin/bash
saturn:$1$FKqc6DD1$tYoSXcfwqEfnjSpA92O5Y.:506:100::/home/saturn:/bin/bash
tintin:$1$SXutfhdz$aqsLvHp8aRnhmU8EJfi3/1:504:100::/home/tintin:/bin/bash
[root@test01 ~]#



3. Configuring The NIS Client
Now that the NIS server is configured, it's time to configure the NIS clients. There are a number of related configuration files that you need to edit to get it to work. Take a look at the procedure.
Run authconfig
The authconfig or the authconfig-tui program automatically configures your NIS files after prompting you for the IP address and domain of the NIS server.
[root@client tmp]# authconfig-tui
Once finished, it should create an /etc/yp.conf file that defines, amongst other things, the IP address of the NIS server for a particular domain. It also edits the /etc/sysconfig/network file to define the NIS domain to which the NIS client belongs.
# /etc/yp.conf - ypbind configuration file
domain NIS-LOGICA-NETWORK server 192.168.1.100

#/etc/sysconfig/network
NISDOMAIN=NIS-SCHOOL-NETWORK
In addition, the authconfig program updates the /etc/nsswitch.conf file that lists the order in which certain data sources should be searched for name lookups, such as those in DNS, LDAP, and NIS. Here you can see where NIS entries were added for the important login files.
#/etc/nsswitch.conf
passwd: files nis
shadow: files nis
group: files nis
Note: You can also locate a sample NIS nsswitch.conf file in the /usr/share/doc/yp-tools* directory.
Start The NIS Client Related Daemons
Start the ypbind NIS client, and portmap daemons in the /etc/init.d directory and use the chkconfig command to ensure they start after the next reboot. Remember to use the rpcinfo command to ensure they are running correctly.
[root@client tmp]# service portmap start
Starting portmapper: [ OK ]
[root@client tmp]# service ypbind start
Binding to the NIS domain:
Listening for an NIS domain server.
[root@client tmp]#

[root@client tmp]# chkconfig ypbind on
[root@client tmp]# chkconfig portmap on
Note: Remember to use the rpcinfo -p localhost command to make sure they all started correctly.

4. Installing the Fedora Directory Server


Directory services play a vital part in today's networks by helping administrators manage network users and resources. Until recently, the only choice for deploying a secure and easy-to-use open source directory server was OpenLDAP. While it gets the job done, it lacks the polish of commercial alternatives. Now Fedora Directory Server (FDS), Red Hat's open source LDAP server, makes setting up an enterprise directory server on Linux simple.
FDS started its life in 1999 as the Netscape Directory Server. In 2004, Red Hat purchased Netscape Directory Server with a promise to make it open source. FDS is the fruit of that labor. Red Hat also sells a supported version, called Red Hat Directory Server, whose business model is to that of FDS as Red Hat Enterprise Linux is to Fedora Core. FDS does not come with any support options.
To install Fedora Directory Server on RHEL 4.0 AS we need to perform the following steps:
1. Download the latest Fedora DS RPM from the following link:
http://directory.fedoraproject.org/wiki/Download
2. Use the rpm tool to install the server components as follows:
# rpm -ivh fedora-ds-1.0.4-1.RHEL4.i386.opt.rpm

The server components are then installed in the default location: /opt/fedora-ds/.


3. Next, we need to create an instance of the Directory Server by running the setup program:

# cd /opt/redhat-ds/
# ./setup/setup
4. The Command line console will be displayed. Follow up the following steps :

[06/11/07:20:38:28] - [Setup] Info Start...
[06/11/07:20:38:28] - [Setup] Info Start binary installation...
[06/11/07:20:38:29] - [Setup] Info PreInstall phrase...
[06/11/07:20:38:29] - [Setup] Info Unzip component binaries...
[06/11/07:20:38:29] - [Setup] Info Extracting Fedora core components ...

[06/11/07:20:38:31] - [Setup] Info PostInstall phrase...
[06/11/07:20:38:31] - [Setup] Info DONE
INFO Begin Setup . . .



LICENSE AGREEMENT AND LIMITED PRODUCT WARRANTY
FEDORA(TM) DIRECTORY SERVER

This agreement governs the use of Fedora Directory Server,
Administration Server and Management Console (collectively, the
"SOFTWARE") and any updates to the Software, regardless of the
delivery mechanism.

1. FEDORA DIRECTORY SERVER

1.1 LICENSE GRANT. Fedora Directory Server ("FDS") is a modular
application consisting of hundreds of software components and is a
collective work under U.S. Copyright Law. Subject to the following
terms, Red Hat, Inc. ("RED HAT") grants to the user ("LICENSEE") a
license to this collective work pursuant to the GNU General Public
License. Please note that Administration Server and Management
Console, which are binary-only code used to configure and administer
FDS, are subject to the license terms in Section 2. The end user
license agreement for each component of FDS is located in the
component's source code. The license terms for the components
permit LICENSEE to copy, modify, and redistribute the component, in
both source code and binary code forms. This agreement does not limit
LICENSEE's rights under, or grant LICENSEE rights that supersede, the
license terms of any particular component.

1.2 LICENSE EXCEPTION. In addition, as a special exception, Red Hat
gives LICENSEE the additional right to link the code of FDS with code
not covered under the GNU General Public License ("NON-GPL CODE") and
to distribute linked combinations including the two, subject to the
limitations in this paragraph. Non-GPL Code permitted under this
exception must only link to the code of FDS through those well defined
interfaces identified in that file named EXCEPTION in the source code
files for FDS (the "APPROVED INTERFACES"). The files of Non-GPL Code
may instantiate templates or use macros or inline functions from the
Approved Interfaces without causing the resulting work to be covered
by the GNU General Public License. Only Red Hat may make changes or
additions to the list of Approved Interfaces. LICENSEE must comply
with the GNU General Public License in all respects for all of the FDS
code and other code used in conjunction with FDS except the Non-GPL
Code covered by this exception. If LICENSEE modifies FDS, LICENSEE may
extend this exception to its version of FDS, but LICENSEE is not
obligated to do so. If LICENSEE does not wish to provide this
exception without modification, LICENSEE must delete this exception
statement from LICENSEE's version of FDS and license FDS solely under
the GPL without exception.

1.3 INTELLECTUAL PROPERTY RIGHTS. FDS and each of its components,
including the source code, documentation, appearance, structure and
organization are owned by Red Hat and others and are protected under
copyright and other laws. Title to FDS and any component, or to any
copy, modification, or merged portion shall remain with the
aforementioned, subject to the applicable license.

2. ADMINISTRATION SERVER, AND MANAGEMENT CONSOLE

2.1 LICENSE GRANT. Subject to the provisions of this Section 2.1, Red
Hat hereby grants LICENSEE a non-exclusive, non-transferable,
worldwide, perpetual, fully paid right (without the right to
sublicense) to use, reproduce and distribute Administration Server
("ADMIN SERVER"), and Management Console ("CONSOLE") in executable,
machine-readable form. LICENSEE must reproduce all copyright and
other proprietary notices on such copies. LICENSEE may only reproduce
and distribute Admin Server or Console to another party if the other
party agrees in writing to be obligated by the terms and conditions of
this Section 2.1. Except as provided in this Section 2.1, LICENSEE
may not modify, copy, transfer or otherwise use Admin Server, or
Console, and all licenses granted in this Section 2 are automatically
terminated if LICENSEE does so.

2.2 CHANGE IN LICENSING. It is Red Hat's intent to change the terms
of the license granted in this Section 2 to that of an open source
license. If such change is generally announced to the public,
LICENSEE will have the option to elect to have Admin Server and
Console governed by the terms of such open source license. If
LICENSEE does not make such election, the terms of this Agreement will
continue to govern LICENSEE's use of Admin Server and Console.

3. LIMITED WARRANTY. Except as specifically stated in this Section 3
or a license for a particular component, TO THE MAXIMUM EXTENT
PERMITTED UNDER APPLICABLE LAW, THE SOFTWARE AND THE COMPONENTS ARE
PROVIDED AND LICENSED "AS IS" WITHOUT WARRANTY OF ANY KIND, EXPRESSED
OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY,
NON-INFRINGEMENT OR FITNESS FOR A PARTICULAR PURPOSE. Red Hat does
not warrant that the functions contained in the Software will meet
LICENSEE's requirements or that the operation of the Software will be
entirely error free or appear precisely as described in the
accompanying documentation.

4. LIMITATION OF REMEDIES AND LIABILITY. TO THE MAXIMUM EXTENT
PERMITTED BY APPLICABLE LAW, RED HAT WILL NOT BE LIABLE TO LICENSEE
FOR ANY INCIDENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR
LOST SAVINGS ARISING OUT OF THE USE OR INABILITY TO USE THE SOFTWARE,
EVEN IF RED HAT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

5. EXPORT CONTROL. As required by U.S. law, LICENSEE represents and
warrants that it: (a) understands that the Software is subject to
export controls under the U.S. Commerce Department's Export
Administration Regulations ("EAR"); (b) is not located in a prohibited
destination country under the EAR or U.S. sanctions regulations
(currently Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria); (c)
will not export, re-export, or transfer the Software to any prohibited
destination, entity, or individual without the necessary export
license(s) or authorizations(s) from the U.S. Government; (d) will
not use or transfer the Software for use in any sensitive nuclear,
chemical or biological weapons, or missile technology end-uses unless
authorized by the U.S. Government by regulation or specific license;
(e) understands and agrees that if it is in the United States and
exports or transfers the Software to eligible end users, it will, as
required by EAR Section 740.17(e), submit semi-annual reports to the
Commerce Department's Bureau of Industry & Security (BIS), which
include the name and address (including country) of each transferee;
and (f) understands that countries other than the United States may
restrict the import, use, or export of encryption products and that it
shall be solely responsible for compliance with any such import, use,
or export restrictions.

6. THIRD PARTY PROGRAMS. Red Hat may distribute third party software
programs with the Software that are not part of the Software. These
third party programs are subject to their own license terms. The
license terms either accompany the programs or can be viewed at
http://www.redhat.com/licenses/. If LICENSEE does not agree to abide
by the applicable license terms for such programs, then LICENSEE may
not install them. If LICENSEE wishes to install the programs on more
than one system or transfer the programs to another party, then
LICENSEE must contact the licensor of the programs.

7. GENERAL. If any provision of this agreement is held to be
unenforceable, that shall not affect the enforceability of the
remaining provisions. This agreement shall be governed by the laws of
the State of North Carolina and of the United States, without regard
to any conflict of laws provisions, except that the United Nations
Convention on the International Sale of Goods shall not apply.
Do you accept the license terms? (yes/no) yes
=======================================================================
Fedora Directory Server 1.0.4
=======================================================================

The Fedora Directory Server is subject to the terms detailed in the
license agreement file called LICENSE.txt.

Late-breaking news and information on the Fedora Directory Server is
available at the following location:

http://directory.fedora.redhat.com
Continue? (yes/no) yes
Fedora Directory Server system tuning analysis version 04-APRIL-2005.

NOTICE : System is i686-unknown-linux2.6.9-55.ELxenU (1 processor).

WARNING: 256MB of physical memory is available on the system. 1024MB is recommended for best performance on large production system.

NOTICE : The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
(120 minutes). This may cause temporary server congestion from lost
client connections.

WARNING: There are only 1024 file descriptors (hard limit) available, which
limit the number of simultaneous connections.

WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.

Continue? (yes/no) yes
Please select 1, 2, or 3 (default: 2) 2
getFQDN: hostname = test01
getFQDN: host test01 = ;;
getFQDN: host test01 has length 7
getFQDN: new max host test01 has length 7
getFQDN: host ;; has length 3
getFQDN: host test01.logicacmg.com has length 21
getFQDN: new max host test01.logicacmg.com has length 21
getFQDN: host test01 has length 7

Hostname to use (default: test01.logicacmg.com)
Server user ID to use (default: nobody) test1
Server group ID to use (default: nobody) test1

5. The hostname must be a fully qualified host and domain name. If the default hostname is not a fully qualified host and domain name, installation fails.
6. The setup program then asks you for the System User and the System Group names. Enter the identity under which you want the servers to run.
7. For the configuration directory, select the default if this directory will host your o=NetscapeRoot tree. Otherwise, enter yes. You will then be asked for the contact information for the configuration directory.
8. The setup program then asks if you want to use a different installation for your user directory. The default is no (this installation will be the user directory). However, if you intend this server instance to be used as a configuration directory only, then you should enter yes
9. For the Directory Server port, select the default; this will be 389 or a randomly-generated port number if you already have another application using that port or you are not installing as root.
10. For the Directory Server Identifier, enter a unique value (normally the default is sufficient). This value is used as part of the name of the directory in which the Directory Server instance is installed. For example, if your machine's host name is phonebook, then this name is the default, and selecting it will cause the Directory Server instance to be installed into a directory labeled slapd-phonebook.
11. For the configuration directory administrator ID and password, enter the name and password as whom you will log in when you want to authenticate to the Console with full privileges. For the Directory Manager DN, enter the DN that you will use when managing the contents of your directory with unlimited privileges. In former releases of Directory Server, the Directory Manager was known as the root DN. This is the entry that you use to bind to the directory when you want access control to be ignored. This DN can be short and does not have to conform to any suffix configured for your directory. However, it should not correspond to an actual entry stored in your directory.
For the Directory Manager password, enter a value that is at least 8 characters long.
12. For a directory suffix, enter a distinguished name (DN) meaningful to your enterprise.This string is used to form the name of all your organization's directory entries. Therefore, pick a name that is representative of your organization. It is recommended that you pick a suffix that corresponds to your Internet DNS name. Avoid space characters in the suffix.For example, if your organization uses the DNS name example.com, then enter dc=example,dc=com here
13. For the Directory Manager DN, enter the DN that you will use when managing the contents of your directory with unlimited privileges.
14. For Administration Domain, enter the domain to which you want this server to belong. The name you enter should be a unique string that is descriptive of the organization responsible for administering the domain.
15. For the administration port number, enter a value that is not in use (an available port number will be randomly generated as the default). Be sure to record this value
16. For the user as whom you want to run Administration Server, enter root. This is the default. You have to run this as root if your port number is below 1024; otherwise, you can run this as a regular user. The server is then unpackaged, minimally configured, and started. You are told on what host and port number Administration Server is listening. The server is configured to use the following suffixes:
o The suffix that you configured.
o o=NetscapeRoot
Do not modify the contents of the directory under the o=NetscapeRoot suffix. Either create data under the first suffix or create a new suffix to be used for this purpose.
The Overall scenario will display the following output at the end:
[slapd-test01]: starting up server ...
[slapd-test01]: Fedora-Directory/1.0.4 B2006.312.435
[slapd-test01]: test01.logicacmg.com:1500 (/opt/fedora-ds/slapd-test01)
[slapd-test01]:
[slapd-test01]: [14/Sep/2007:14:33:15 +051800] - Fedora-Directory/1.0.4 B2006.312.435 starting up
[slapd-test01]: [14/Sep/2007:14:33:16 +051800] - slapd started. Listening on All Interfaces port 1500 for LDAP requests
Your new directory server has been started.
Created new Directory Server
Start Slapd Starting Slapd server configuration.
Success Slapd Added Directory Server information to Configuration Server.
Configuring Administration Server...
Setting up Administration Server Instance...
Configuring Administration Tasks in Directory Server...
Configuring Global Parameters in Directory Server...

You can now use the console. Here is the command to use to start the console:
cd /opt/fedora-ds
./startconsole -u admin -a http://test01.logicacmg.com:14000/

INFO Finished with setup, logfile is setup/setup.log

Ultimately ,fedora DS gets installed under the /opt/fedora-ds directory.
You can browse the Directory Administrative and Directory Server Configuration through http://test01.logicacmg.com:14000/




5. Migrating the NIS Database into LDIF file format


The MigrationTools are a set of Perl scripts for migrating users, groups, aliases, hosts, netgroups, networks, protocols, RPCs, and services from existing nameservices (flat files, NIS, and NetInfo) to Fedora DS database.
Scripts
• migrate_base.pl creates naming context entries, including subordinate contexts such as ou=people and ou=devices.
• migrate_aliases.pl migrates aliases in /etc/aliases to entries conforming to the rfc822MailGroup schema. Organizations who have deployed LDAP-based messaging solutions, such as Netscape's Messaging Server, may wish to use a different schema for representing mail aliases. Ypldapd does not use X.500 groups (such as groupOfUniqueNames) for mail alias expansion because flattening an arbitrarily nested group at runtime may be expensive. (It is possible to write a ypldapd plug-in to support such a schema, however.)
• migrate_group.pl migrates groups in /etc/group
• migrate_hosts.pl migrates hosts in /etc/hosts
• migrate_networks.pl migrates networks in /etc/networks
• migrate_passwd.pl migrates users in /etc/passwd. Note that if users are allowed read the userPassword attribute, and your LDAP server doesn't support authenticating against hashed passwords then anyone may read the userPassword attribute's value and authenticate as that user. Modern LDAP servers, such as Netscape Directory Server, support authenticating against hashed passwords, so this is not an issue. The OpenLDAP LDAP server also supports such authentication.
• migrate_protocols.pl migrates protocols in /etc/protocols
• migrate_services.pl migrates services in /etc/services
• migrate_netgroup.pl migrates netgroups in /etc/netgroup
• migrate_netgroup_byuser.pl migrates the netgroup.byuser map. It requires revnetgroup.
• migrate_netgroup_byhost.pl migrates the netgroup.byhost map. It requires revnetgroup.
• migrate_rpc.pl migrates RPCs in /etc/rpc

Let’s migrate the overall NIS Database files into the LDIF and in turn,import these LDIF into the fedora DS database.
First of all, we need to use the following commands to download and extract the zipped Migration Scripts into the local running the NIS Server:
1. Download the Migration Scripts from
http://www.padl.com/OSS/MigrationTools.html
2. Extract the Migration through the following command:
# tar xvzf MigrationTools-3.22
3. The command will extract the following files:
[root@test01 MigrationTools-3.22]# ls
drwxr-xr-x 2 root root 4096 Sep 20 15:45 .
drwxr-x--- 15 root root 4096 Sep 21 11:49 ..
-rw-r--r-- 1 root root 220 Sep 22 1999 CVSVersionInfo.txt
-rw-r--r-- 1 root root 607 May 20 1999 Make.rules
-rwxr-xr-x 1 root root 2573 Jul 29 1999 migrate_aliases.pl
-rwxr-xr-x 1 root root 2800 Jul 16 1998 migrate_all_netinfo_offline.sh
-rwxr-xr-x 1 root root 2796 Jul 16 1998 migrate_all_netinfo_online.sh
-rw-r--r-- 1 root root 2854 Jul 16 1998 migrate_all_nis_offline.sh
-rw-r--r-- 1 root root 2850 Jul 16 1998 migrate_all_nis_online.sh
-rw-r--r-- 1 root root 2661 May 19 1999 migrate_all_nisplus_offline.sh
-rw-r--r-- 1 root root 2657 May 19 1999 migrate_all_nisplus_online.sh
-rwxr-xr-x 1 root root 4557 Jun 29 1999 migrate_all_offline.sh
-rwxr-xr-x 1 root root 5771 Jun 29 1999 migrate_all_online.sh
-rwxr-xr-x 1 root root 3444 Oct 20 1998 migrate_base.pl
-rw-r--r-- 1 root root 5543 Jun 22 1999 migrate_common.ph
-rwxr-xr-x 1 root root 2919 Oct 1 1998 migrate_fstab.pl
-rwxr-xr-x 1 root root 2683 Oct 1 1998 migrate_group.pl
-rwxr-xr-x 1 root root 2720 Oct 1 1998 migrate_hosts.pl
-rwxr-xr-x 1 root root 2825 Oct 1 1998 migrate_netgroup_byhost.pl
-rwxr-xr-x 1 root root 2825 Oct 1 1998 migrate_netgroup_byuser.pl
-rwxr-xr-x 1 root root 2875 Oct 27 1998 migrate_netgroup.pl
-rwxr-xr-x 1 root root 2809 Oct 1 1998 migrate_networks.pl
-rwxr-xr-x 1 root root 5156 Sep 22 1999 migrate_passwd.pl
-rwxr-xr-x 1 root root 2604 Oct 1 1998 migrate_protocols.pl
-rwxr-xr-x 1 root root 2626 Oct 1 1998 migrate_rpc.pl
-rwxr-xr-x 1 root root 2805 Oct 1 1998 migrate_services.pl
-rw-r--r-- 1 root root 769 Jun 22 1999 MigrationTools.spec
-rw-r--r-- 1 root root 1855 Jun 18 1999 README

3. Run the following command to migrate all the NIS related database files into /tmp directory in ldif form.
[root@test01 MigrationTools-3.22]# ./migrate_group.pl /etc/group /tmp/group.ldi f
[root@test01 MigrationTools-3.22]# ./migrate_hosts.pl /etc/hosts /tmp/hosts.ldif
[root@test01 MigrationTools-3.22]# ./migrate_passwd.pl /etc/passwd /tmp/passwd.l dif
[root@test01 MigrationTools-3.22]# ./migrate_services.pl /etc/services /tmp/serv ices.1dif
[root@test01 MigrationTools-3.22]# cd /tmp
[root@test01 tmp]# ls
base.ldif hosts.11555.ldap protocols.11308.ldap
fstab.11271.ldap hosts.11597.ldap protocols.11330.ldap
fstab.11291.ldap hosts.11631.ldap protocols.11419.ldap
fstab.11308.ldap hosts.ldif protocols.11432.ldap
fstab.11330.ldap kde-root protocols.11449.ldap
fstab.11419.ldap ksocket-root protocols.11485.ldap
fstab.11432.ldap logC18418 protocols.11508.ldap
fstab.11449.ldap logN18341 protocols.11519.ldap
fstab.11485.ldap logT17894 protocols.11538.ldap
fstab.11508.ldap mcop-root protocols.11555.ldap
fstab.11519.ldap networks.11271.ldap protocols.11597.ldap
fstab.11538.ldap networks.11291.ldap protocols.11631.ldap
fstab.11555.ldap networks.11308.ldap rpc.11271.ldap
fstab.11597.ldap networks.11330.ldap rpc.11291.ldap
fstab.11631.ldap networks.11419.ldap rpc.11308.ldap
gconfd-root networks.11432.ldap rpc.11330.ldap
group.11271.ldap networks.11449.ldap rpc.11419.ldap
group.11291.ldap networks.11485.ldap rpc.11432.ldap
group.11308.ldap networks.11508.ldap rpc.11449.ldap
group.11330.ldap networks.11519.ldap rpc.11485.ldap
group.11419.ldap networks.11538.ldap rpc.11508.ldap
group.11432.ldap networks.11555.ldap rpc.11519.ldap
group.11449.ldap networks.11597.ldap rpc.11538.ldap
group.11485.ldap networks.11631.ldap rpc.11555.ldap
group.11508.ldap orbit-root rpc.11597.ldap
group.11519.ldap passwd.11271.ldap rpc.11631.ldap
group.11538.ldap passwd.11291.ldap services.11271.ldap
group.11555.ldap passwd.11308.ldap services.11291.ldap
group.11597.ldap passwd.11330.ldap services.11308.ldap
group.11631.ldap passwd.11419.ldap services.11330.ldap
group.ldif passwd.11432.ldap services.11419.ldap
hosts.11271.ldap passwd.11449.ldap services.11432.ldap
hosts.11291.ldap passwd.11485.ldap services.11449.ldap
hosts.11308.ldap passwd.11508.ldap services.11485.ldap
hosts.11330.ldap passwd.11519.ldap services.11508.ldap
hosts.11419.ldap passwd.11538.ldap services.11519.ldap
hosts.11432.ldap passwd.11555.ldap services.11538.ldap
hosts.11449.ldap passwd.11597.ldap services.11555.ldap
hosts.11485.ldap passwd.11631.ldap services.11597.ldap
hosts.11508.ldap passwd.ldif services.11631.ldap
hosts.11519.ldap protocols.11271.ldap services.1dif
hosts.11538.ldap protocols.11291.ldap setupE17927
[root@test01 tmp]#




The /tmp directory has all the files (LDIF) which is understood by the fedora DS.

8. Importing the LDIF files into the Fedora Directory Structure

It is important to tweak with LDIF file so that Fedora DS database can understand the file format. A particular LDIF file for 10 NIS users format looks like this :
dn: uid=vjs,ou=People,dc=padl,dc=com
uid: vjs
cn: vjs
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$jwNSJA89$ufH4yWwanaKW44nzK21vR1
shadowLastChange: 13689
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 500
gidNumber: 500
homeDirectory: /home/vjs

dn: uid=ajeet,ou=People,dc=padl,dc=com
uid: ajeet
cn: ajeet
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$Io5G0iTK$1ksWy5/Bttf.xeEw3YcT7.
shadowLastChange: 13775
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 501
gidNumber: 501
homeDirectory: /home/ajeet

dn: uid=peter,ou=People,dc=padl,dc=com
uid: peter
cn: peter
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$YEPNVp9E$yztvvYeH8VYMXN4YWKrLI.
shadowLastChange: 13775
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 502
gidNumber: 502
homeDirectory: /home/peter

dn: uid=nisuser,ou=People,dc=padl,dc=com
uid: nisuser
cn: nisuser
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$udwxj/nd$2V9qOzAm.9FZfZQmB0N3L/
shadowLastChange: 13775
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 503
gidNumber: 100
homeDirectory: /home/nisuser

dn: uid=saturn,ou=People,dc=padl,dc=com
uid: saturn
cn: saturn
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$0fSVPPNZ$vNfW9oXNJmZrngDWJ9b7D.
shadowLastChange: 13775
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 504
gidNumber: 100
homeDirectory: /home/saturn

dn: uid=sijo,ou=People,dc=padl,dc=com
uid: sijo
cn: sijo
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$n4bdi9vP$fTWlLOqsUvtXIc7JjB7sr0
shadowLastChange: 13775
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 505
gidNumber: 100
homeDirectory: /home/sijo

dn: uid=test1,ou=People,dc=padl,dc=com
uid: test1
cn: test1
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$THXT5kSc$KFIPQi/1CPK6JdX04uhu4/
shadowLastChange: 13775
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 506
gidNumber: 506
homeDirectory: /home/test1

dn: uid=ldap,ou=People,dc=padl,dc=com
uid: ldap
cn: LDAP User
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}!!
shadowLastChange: 13775
loginShell: /bin/false
uidNumber: 55
gidNumber: 55
homeDirectory: /var/lib/ldap
gecos: LDAP User


We need to make only one modification. Change dc-padl to dc=groupinfra, dc=com
[Quick Trick : Open the /tmp/passwd.ldif file through vi editor & provide the following command:
:%s/padl/groupinfra/g
This ex-mode command will change all the padl entry into groupinfra in a single shot.]

Next provide the following command to start the Directory Server console in order to configure the Importing into the Fedora DS.
Run the following command in GNOME to get the Fedora DS Console display:
# ./startconsole –u admin –a http://localhost:14000
Click on Task after providing the credentials and this will let you with the following options as you see below.we will first try to import the passwd.ldif file into Fedora DS.




This will lead to a successful import .We can easily check the various entry for the particular users called Sijo and Purushottam below. It shows that all the schema has been copied to the database






Thus, the various other NIS Users has been comfortably imported into the Fedora DS database Server.


  



All times are GMT -5. The time now is 05:38 AM.

Main Menu

My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration