The Apache HTTP server is installed by default in all Linux distributions and it is configured to run as service. I usually prefer to install Apache from source instead of using the default one. After installing Apache I want to run that instance as service so that it can be restarted automatically whenever machine is rebooted. This can be achieved easily by modifying /etc/rc.d/init.d/httpd file, which is configured to run the Apache installed with OS.
Comment the following section, though it is not required but I prefer to keep all configuration at one place
if [ -f /etc/sysconfig/httpd ]; then
. /etc/sysconfig/httpd
fi
Modify the following lines-
apachectl=/usr/sbin/apachectl
httpd=${HTTPD-/usr/sbin/httpd}
prog=httpd
pidfile=${PIDFILE-/var/run/httpd/httpd.pid}
to point towards your Apache installation
apachectl=/opt/apps/httpd-2.2.14/bin/apachectl
httpd=${HTTPD-/opt/apps/httpd-2.2.14/bin/httpd}
prog=httpd
pidfile=${PIDFILE-/opt/apps/httpd-2.2.14/logs/httpd.pid}
Now your custom Apache instance will be started by OS instead of the default one.
Saturday, December 26, 2009
Wednesday, December 16, 2009
Cron: Understanding crontab deeply?
A crontab file contains instructions to the cron daemon of the general
form: `run this command at this time on this date'. Each user has
their own crontab, and commands in any given crontab will be executed as
the user who owns the crontab. Uucp and News will usually have their own
crontabs, eliminating the need for explicitly running su as part of a
cron command.
Blank lines and leading spaces and tabs are ignored. Lines whose first
non-space character is a pound-sign (#) are comments, and are ignored.
Note that comments are not allowed on the same line as cron commands,
since they will be taken to be part of the command. Similarly, comments
are not allowed on the same line as environment variable settings.
An active line in a crontab will be either an environment setting or a
cron command. An environment setting is of the form,
name = value
where the spaces around the equal-sign (=) are optional, and any subse-
quent non-leading spaces in value will be part of the value assigned to
name. The value string may be placed in quotes (single or double, but
matching) to preserve leading or trailing blanks. The name string may
also be placed in quote (single or double, but matching) to preserve
leading, traling or inner blanks.
Several environment variables are set up automatically by the cron
daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the
/etc/passwd line of the crontab's owner. HOME and SHELL may be overrid-
den by settings in the crontab; LOGNAME may not.
(Another note: the LOGNAME variable is sometimes called USER on BSD sys-
tems... on these systems, USER will be set also).
In addition to LOGNAME, HOME, and SHELL, cron will look at MAILTO if
it has any reason to send mail as a result of running commands in
`this' crontab. If MAILTO is defined (and non-empty), mail is sent to
the user so named. If MAILTO is defined but empty (MAILTO=""), no mail
will be sent. Otherwise mail is sent to the owner of the crontab. This
option is useful if you decide on /bin/mail instead of /usr/lib/sendmail
as your mailer when you install cron -- /bin/mail doesn't do aliasing,
and UUCP usually doesn't read its mail.
The format of a cron command is very much the V7 standard, with a number
of upward-compatible extensions. Each line has five time and date
fields, followed by a user name (with optional `:' and
`/' suffixes) if this is the system crontab file, followed
by a command. Commands are executed by cron when the minute, hour,
and month of year fields match the current time, and when at least one of
the two day fields (day of month, or day of week) match the current time
(see `Note' below). cron examines cron entries once every minute.
The time and date fields are:
field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)
A field may be an asterisk (*), which always stands for `first-last'.
Ranges of numbers are allowed. Ranges are two numbers separated with a
hyphen. The specified range is inclusive. For example, 8-11 for an
``hours'' entry specifies execution at hours 8, 9, 10 and 11.
Lists are allowed. A list is a set of numbers (or ranges) separated by
commas. Examples: `1,2,5,9', `0-4,8-12'.
Step values can be used in conjunction with ranges. Following a range
with `/' specifies skips of the number's value through the
range. For example, `0-23/2' can be used in the hours field to specify
command execution every other hour (the alternative in the V7 standard is
`0,2,4,6,8,10,12,14,16,18,20,22'). Steps are also permitted after an
asterisk, so if you want to say `every two hours', just use `*/2'.
Names can also be used for the `month' and `day of week' fields. Use
the first three letters of the particular day or month (case doesn't mat-
ter). Ranges or lists of names are not allowed.
The `sixth' field (the rest of the line) specifies the command to be
run. The entire command portion of the line, up to a newline or % char-
acter, will be executed by /bin/sh or by the shell specified in the SHELL
variable of the cronfile. Percent-signs (%) in the command, unless
escaped with backslash (\), will be changed into newline characters, and
all data after the first % will be sent to the command as standard input.
The command can optionally be prefixed by `@AppleNotOnBattery ' to tell
cron not to run the command when functioning on battery power. For exam-
ple, the `sixth' field when using this option would appear something
like `@AppleNotOnBattery /usr/bin/touch /tmp/foo'
Note: The day of a command's execution can be specified by two fields --
day of month, and day of week. If both fields are restricted (ie, aren't
*), the command will be run when either field matches the current time.
For example, `30 4 1,15 * 5' would cause a command to be run at 4:30 am
on the 1st and 15th of each month, plus every Friday.
Instead of the first five fields, one of eight special strings may
appear:
string meaning
------ -------
@reboot Run once, at startup.
@yearly Run once a year, "0 0 1 1 *".
@annually (sames as @yearly)
@monthly Run once a month, "0 0 1 * *".
@weekly Run once a week, "0 0 * * 0".
@daily Run once a day, "0 0 * * *".
@midnight (same as @daily)
@hourly Run once an hour, "0 * * * *".
EXAMPLE CRON FILE
# use /bin/sh to run commands, overriding the default set by cron
SHELL=/bin/sh
#
# mail any output to `paul', no matter whose crontab this is
MAILTO=paul
#
# run five minutes after midnight, every day
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
#
# run at 2:15pm on the first of every month -- output mailed to paul
15 14 1 * * $HOME/bin/monthly
#
# run at 10 pm on weekdays, annoy Joe
0 22 * * 1-5 mail -s "It's 10pm" joe%Joe,%%Where are your kids?%
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
5 4 * * sun echo "run at 5 after 4 every sunday"
Notes
When specifying day of week, both day 0 and day 7 will be considered Sunday. BSD and ATT seem to disagree about this.
Lists and ranges are allowed to co-exist in the same field. "1-3,7-9" would be rejected by ATT or BSD cron -- they want to see "1-3" or "7,8,9" ONLY.
Ranges can include "steps", so "1-9/2" is the same as "1,3,5,7,9".
Names of months or days of the week can be specified by name. Environment variables can be set in the crontab. In BSD or ATT, the environment handed to child processes is basically the one from /etc/rc.
Command output is mailed to the crontab owner (BSD can't do this), can be mailed to a person other than the crontab owner (SysV can't do this), or the feature can be turned off and no mail will be sent at all (SysV can't do this either).
All of the `@' commands that can appear in place of the first five fields are extensions.
If you're in one of the 70-odd countries that observe Daylight Savings Time, jobs scheduled during the rollback or advance will be affected. In general, it's not a good idea to schedule jobs during this period.
"Wisdom is the power to put our time and our knowledge to the proper use" - Thomas J. Watson
form: `run this command at this time on this date'. Each user has
their own crontab, and commands in any given crontab will be executed as
the user who owns the crontab. Uucp and News will usually have their own
crontabs, eliminating the need for explicitly running su as part of a
cron command.
Blank lines and leading spaces and tabs are ignored. Lines whose first
non-space character is a pound-sign (#) are comments, and are ignored.
Note that comments are not allowed on the same line as cron commands,
since they will be taken to be part of the command. Similarly, comments
are not allowed on the same line as environment variable settings.
An active line in a crontab will be either an environment setting or a
cron command. An environment setting is of the form,
name = value
where the spaces around the equal-sign (=) are optional, and any subse-
quent non-leading spaces in value will be part of the value assigned to
name. The value string may be placed in quotes (single or double, but
matching) to preserve leading or trailing blanks. The name string may
also be placed in quote (single or double, but matching) to preserve
leading, traling or inner blanks.
Several environment variables are set up automatically by the cron
daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the
/etc/passwd line of the crontab's owner. HOME and SHELL may be overrid-
den by settings in the crontab; LOGNAME may not.
(Another note: the LOGNAME variable is sometimes called USER on BSD sys-
tems... on these systems, USER will be set also).
In addition to LOGNAME, HOME, and SHELL, cron will look at MAILTO if
it has any reason to send mail as a result of running commands in
`this' crontab. If MAILTO is defined (and non-empty), mail is sent to
the user so named. If MAILTO is defined but empty (MAILTO=""), no mail
will be sent. Otherwise mail is sent to the owner of the crontab. This
option is useful if you decide on /bin/mail instead of /usr/lib/sendmail
as your mailer when you install cron -- /bin/mail doesn't do aliasing,
and UUCP usually doesn't read its mail.
The format of a cron command is very much the V7 standard, with a number
of upward-compatible extensions. Each line has five time and date
fields, followed by a user name (with optional `:' and
`/' suffixes) if this is the system crontab file, followed
by a command. Commands are executed by cron when the minute, hour,
and month of year fields match the current time, and when at least one of
the two day fields (day of month, or day of week) match the current time
(see `Note' below). cron examines cron entries once every minute.
The time and date fields are:
field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)
A field may be an asterisk (*), which always stands for `first-last'.
Ranges of numbers are allowed. Ranges are two numbers separated with a
hyphen. The specified range is inclusive. For example, 8-11 for an
``hours'' entry specifies execution at hours 8, 9, 10 and 11.
Lists are allowed. A list is a set of numbers (or ranges) separated by
commas. Examples: `1,2,5,9', `0-4,8-12'.
Step values can be used in conjunction with ranges. Following a range
with `/' specifies skips of the number's value through the
range. For example, `0-23/2' can be used in the hours field to specify
command execution every other hour (the alternative in the V7 standard is
`0,2,4,6,8,10,12,14,16,18,20,22'). Steps are also permitted after an
asterisk, so if you want to say `every two hours', just use `*/2'.
Names can also be used for the `month' and `day of week' fields. Use
the first three letters of the particular day or month (case doesn't mat-
ter). Ranges or lists of names are not allowed.
The `sixth' field (the rest of the line) specifies the command to be
run. The entire command portion of the line, up to a newline or % char-
acter, will be executed by /bin/sh or by the shell specified in the SHELL
variable of the cronfile. Percent-signs (%) in the command, unless
escaped with backslash (\), will be changed into newline characters, and
all data after the first % will be sent to the command as standard input.
The command can optionally be prefixed by `@AppleNotOnBattery ' to tell
cron not to run the command when functioning on battery power. For exam-
ple, the `sixth' field when using this option would appear something
like `@AppleNotOnBattery /usr/bin/touch /tmp/foo'
Note: The day of a command's execution can be specified by two fields --
day of month, and day of week. If both fields are restricted (ie, aren't
*), the command will be run when either field matches the current time.
For example, `30 4 1,15 * 5' would cause a command to be run at 4:30 am
on the 1st and 15th of each month, plus every Friday.
Instead of the first five fields, one of eight special strings may
appear:
string meaning
------ -------
@reboot Run once, at startup.
@yearly Run once a year, "0 0 1 1 *".
@annually (sames as @yearly)
@monthly Run once a month, "0 0 1 * *".
@weekly Run once a week, "0 0 * * 0".
@daily Run once a day, "0 0 * * *".
@midnight (same as @daily)
@hourly Run once an hour, "0 * * * *".
EXAMPLE CRON FILE
# use /bin/sh to run commands, overriding the default set by cron
SHELL=/bin/sh
#
# mail any output to `paul', no matter whose crontab this is
MAILTO=paul
#
# run five minutes after midnight, every day
5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
#
# run at 2:15pm on the first of every month -- output mailed to paul
15 14 1 * * $HOME/bin/monthly
#
# run at 10 pm on weekdays, annoy Joe
0 22 * * 1-5 mail -s "It's 10pm" joe%Joe,%%Where are your kids?%
23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
5 4 * * sun echo "run at 5 after 4 every sunday"
Notes
When specifying day of week, both day 0 and day 7 will be considered Sunday. BSD and ATT seem to disagree about this.
Lists and ranges are allowed to co-exist in the same field. "1-3,7-9" would be rejected by ATT or BSD cron -- they want to see "1-3" or "7,8,9" ONLY.
Ranges can include "steps", so "1-9/2" is the same as "1,3,5,7,9".
Names of months or days of the week can be specified by name. Environment variables can be set in the crontab. In BSD or ATT, the environment handed to child processes is basically the one from /etc/rc.
Command output is mailed to the crontab owner (BSD can't do this), can be mailed to a person other than the crontab owner (SysV can't do this), or the feature can be turned off and no mail will be sent at all (SysV can't do this either).
All of the `@' commands that can appear in place of the first five fields are extensions.
If you're in one of the 70-odd countries that observe Daylight Savings Time, jobs scheduled during the rollback or advance will be affected. In general, it's not a good idea to schedule jobs during this period.
"Wisdom is the power to put our time and our knowledge to the proper use" - Thomas J. Watson
Monday, December 14, 2009
Tomcat: Troubleshoot the Tomcat?
Installing JDK (Java Development Kit)
In order to run Tomcat, you will need to install JDK and set the JAVA_HOME environment variable to identify the location of the JDK environment on your system. I have chosen to use JDK 5.0.
1. You can download JDK 5.0 at http://java.sun.com/j2se/1.5.0/download.jsp.
2. Click on Download JDK 5.0 Update 6 to go to the download page.
3. Click Accept to accept the license agreement.
4. Next choose the Linux self-extracting file. This is the download for the self-extracting binary file rather than the rpm.
5. Download to your preferred download directory. Change to that directory and make it executable by executing the following command:
chmod +x jdk-1_5_0_06-linux-i586.bin
6. Now execute the file:
./jdk-1_5_0_06-linux-i586.bin
7. You should now have a new directory called j2sdk1.5-sun. Now move this directory to the location where it should be run. I chose /usr/lib/.
mv j2sdk1.5-sun /usr/lib
8. Now create a symbolic link called jdk to JAVA_HOME by the following command. This allows you to easily switch back and forth between different jvms should you ever need to
cd /usr/lib
ln -s j2sdk1.5-sun jdk
8. Now we need to set the JAVA_HOME environment variable. Add the following at the end of /etc/profile just after export PATH.
JAVA_HOME="/usr/lib/jdk"
export JAVA_HOME
/etc/profile is executed at startup and when a user logs into the system. In order to update the environment you will need to log out and log back in to the system.
10. Check to make sure JAVA_HOME is defined correctly by executing the command below. This should report the location of the Java SDK which should be /usr/lib/jdk.
echo $JAVA_HOME
11. Now test Java with the following command. You should be returned with /usr/bin/java. If so, you have successfully completed this section.
which java
export JAVA_HOME=/usr/java/jdk1.6.0_15
export PATH=$PATH:$HOME/bin:/bin:/usr/local/bin:/usr/bin:/usr/java/jdk1.6.0_15/bin/
Setting Tomcat
Download the binary version to your preferred download directory from here: http://tomcat.apache.org/download-55.cgi. Choose the tar.gz from the core section for 5.5.15.
Now change to that directory and extract the files using the following command:
cd /mydownloads (be sure to change to your download directory)
tar xvzf apache-tomcat-5.5.15.tar.gz
You should now have a new directory called apache-tomcat-5.5.15. Now move this directory to the location where it should be installed. Again, I chose /usr/lib/. Note that this location will be referred to as CATALINA_HOME in the Tomcat documentation.
mv apache-tomcat-5.5.15 /usr/lib
Next change to the /usr/lib/ directory.
cd /usr/lib
Now create a symbolic link called apache-tomcat to CATALINA_HOME by the following command.
ln -s apache-tomcat-5.5.15 apache-tomcat
[root@linuxguy bin]# echo $CATALINA_HOME
/usr/lib/apache-tomcat
[root@linuxguy bin]# pwd
/usr/lib/apache-tomcat/bin
[root@linuxguy bin]# ./startup.sh
The BASEDIR environment variable is not defined correctly
This environment variable is needed to run this program
How to troubleshoot?
[root@linuxguy bin]# chmod +x *.sh
[root@linuxguy bin]# ./startup.sh
Using CATALINA_BASE: /usr/lib/apache-tomcat
Using CATALINA_HOME: /usr/lib/apache-tomcat
Using CATALINA_TMPDIR: /usr/lib/apache-tomcat/temp
Using JRE_HOME: /usr/java/jdk1.6.0_15
Using CLASSPATH: /usr/lib/apache-tomcat/bin/bootstrap.jar
[root@linuxguy bin]#
[root@linuxguy bin]#
In order to run Tomcat, you will need to install JDK and set the JAVA_HOME environment variable to identify the location of the JDK environment on your system. I have chosen to use JDK 5.0.
1. You can download JDK 5.0 at http://java.sun.com/j2se/1.5.0/download.jsp.
2. Click on Download JDK 5.0 Update 6 to go to the download page.
3. Click Accept to accept the license agreement.
4. Next choose the Linux self-extracting file. This is the download for the self-extracting binary file rather than the rpm.
5. Download to your preferred download directory. Change to that directory and make it executable by executing the following command:
chmod +x jdk-1_5_0_06-linux-i586.bin
6. Now execute the file:
./jdk-1_5_0_06-linux-i586.bin
7. You should now have a new directory called j2sdk1.5-sun. Now move this directory to the location where it should be run. I chose /usr/lib/.
mv j2sdk1.5-sun /usr/lib
8. Now create a symbolic link called jdk to JAVA_HOME by the following command. This allows you to easily switch back and forth between different jvms should you ever need to
cd /usr/lib
ln -s j2sdk1.5-sun jdk
8. Now we need to set the JAVA_HOME environment variable. Add the following at the end of /etc/profile just after export PATH.
JAVA_HOME="/usr/lib/jdk"
export JAVA_HOME
/etc/profile is executed at startup and when a user logs into the system. In order to update the environment you will need to log out and log back in to the system.
10. Check to make sure JAVA_HOME is defined correctly by executing the command below. This should report the location of the Java SDK which should be /usr/lib/jdk.
echo $JAVA_HOME
11. Now test Java with the following command. You should be returned with /usr/bin/java. If so, you have successfully completed this section.
which java
export JAVA_HOME=/usr/java/jdk1.6.0_15
export PATH=$PATH:$HOME/bin:/bin:/usr/local/bin:/usr/bin:/usr/java/jdk1.6.0_15/bin/
Setting Tomcat
Download the binary version to your preferred download directory from here: http://tomcat.apache.org/download-55.cgi. Choose the tar.gz from the core section for 5.5.15.
Now change to that directory and extract the files using the following command:
cd /mydownloads (be sure to change to your download directory)
tar xvzf apache-tomcat-5.5.15.tar.gz
You should now have a new directory called apache-tomcat-5.5.15. Now move this directory to the location where it should be installed. Again, I chose /usr/lib/. Note that this location will be referred to as CATALINA_HOME in the Tomcat documentation.
mv apache-tomcat-5.5.15 /usr/lib
Next change to the /usr/lib/ directory.
cd /usr/lib
Now create a symbolic link called apache-tomcat to CATALINA_HOME by the following command.
ln -s apache-tomcat-5.5.15 apache-tomcat
[root@linuxguy bin]# echo $CATALINA_HOME
/usr/lib/apache-tomcat
[root@linuxguy bin]# pwd
/usr/lib/apache-tomcat/bin
[root@linuxguy bin]# ./startup.sh
The BASEDIR environment variable is not defined correctly
This environment variable is needed to run this program
How to troubleshoot?
[root@linuxguy bin]# chmod +x *.sh
[root@linuxguy bin]# ./startup.sh
Using CATALINA_BASE: /usr/lib/apache-tomcat
Using CATALINA_HOME: /usr/lib/apache-tomcat
Using CATALINA_TMPDIR: /usr/lib/apache-tomcat/temp
Using JRE_HOME: /usr/java/jdk1.6.0_15
Using CLASSPATH: /usr/lib/apache-tomcat/bin/bootstrap.jar
[root@linuxguy bin]#
[root@linuxguy bin]#
Sunday, December 6, 2009
JBoss: Stopping JBoss when running multiple JBoss instances using the Service Binding Manager
If you launched JBoss from the command line, the easiest way to stop it is to press ctrl-C. JBoss should begin it's shutdown. Alternatively, you can invoke the shutdown script in the JBoss bin directory.
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -S
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
There're several ways to shutdown JBoss as explained below. If you want to know what JBoss logs in each situation please visit ShutdownLogs wiki.
Stopping JBoss on a remote machine
Note that you will use the lower-case -s flag along with the jnp protocol plus address and port of the Naming service specified in conf/jboss-service.xml
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://myremotemachineOrIP:1099
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
Stopping JBoss when running multiple JBoss instances using the Service Binding Manager
service-bindings
server name="ports-default"
service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate"
delegate-config portName="Port" hostName="BindAddress">
attribute name="RmiPort">1098
/delegate-config>
binding port="1099" host="${jboss.bind.address}">
/service-config>
.
.
.
server name="ports-01">
service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate"
>
delegate-config portName="Port" hostName="BindAddress">
attribute name="RmiPort">1198
/delegate-config>
binding port="1199" host="${jboss.bind.address}">
/service-config>
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://localhost:1099
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://localhost:1199
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -S
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
There're several ways to shutdown JBoss as explained below. If you want to know what JBoss logs in each situation please visit ShutdownLogs wiki.
Stopping JBoss on a remote machine
Note that you will use the lower-case -s flag along with the jnp protocol plus address and port of the Naming service specified in conf/jboss-service.xml
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://myremotemachineOrIP:1099
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
Stopping JBoss when running multiple JBoss instances using the Service Binding Manager
service-bindings
server name="ports-default"
service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate"
delegate-config portName="Port" hostName="BindAddress">
attribute name="RmiPort">1098
/delegate-config>
binding port="1099" host="${jboss.bind.address}">
/service-config>
.
.
.
server name="ports-01">
service-config name="jboss:service=Naming"
delegateClass="org.jboss.services.binding.AttributeMappingDelegate"
>
delegate-config portName="Port" hostName="BindAddress">
attribute name="RmiPort">1198
/delegate-config>
binding port="1199" host="${jboss.bind.address}">
/service-config>
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://localhost:1099
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
[ajeet:/tmp/jboss-3.2.3/bin] % ./shutdown.sh -s jnp://localhost:1199
Shutdown message has been posted to the server.
Server shutdown may take a while - check logfiles for completion
JBoss: A Boot-up Script for Jboss Start $ Shutdown
The Content of this site is moved to new location.
Saturday, December 5, 2009
LinuxInterview: How to make script run as service?
Making a script run at boot time needs certain consideration and configuration.The Startup script are usually under /etc/init.d directory.
Some Admin think that by just putting the script under /etc/init.d will make it run as service.
No !! The Story is little different.
Say, I have a script called myscript which I want to run as service either:
/etc/init.d/myscript [restart|reload|start|stop]
or
service myscript start
But little more steps are usually needed.
I am talking about Red Hat Distribution but may run comfortably in other *nix too.
I have a script called myscript which contains:
#cat myscript
#!/bin/sh
service nfs stop
Being a Linux Admin, I will try to put it under /etc/init.d/ directory.
Try to run it as:
service myscript start
And It does run comfortably:
#service myscript start
Shutting down NFS mountd: [ OK ]
Shutting down NFS daemon: [ OK ]
Shutting down NFS services:
But when I try making this service run at boot time:
#chkconfig myscript on
service myscript does not support chkconfig
Hmm...Not working !!!
How to fix it????
So here is the complete solution:
(Assume the name of my script is myscript)
1 - Copy your script into /etc/init.d folder
2 - cd /etc/init.d
3 - chmod +x myscript
4 - Add these lines, including #, right after #!/bin/bash or #!/bin/sh:
# chkconfig: 2345 95 20
# description: Some description
# What your script does (not sure if this is necessary though)
# processname: myscript
5 - chkconfig –level 2345 myscript on
Try now !!!
It will work.
Some Admin think that by just putting the script under /etc/init.d will make it run as service.
No !! The Story is little different.
Say, I have a script called myscript which I want to run as service either:
/etc/init.d/myscript [restart|reload|start|stop]
or
service myscript start
But little more steps are usually needed.
I am talking about Red Hat Distribution but may run comfortably in other *nix too.
I have a script called myscript which contains:
#cat myscript
#!/bin/sh
service nfs stop
Being a Linux Admin, I will try to put it under /etc/init.d/ directory.
Try to run it as:
service myscript start
And It does run comfortably:
#service myscript start
Shutting down NFS mountd: [ OK ]
Shutting down NFS daemon: [ OK ]
Shutting down NFS services:
But when I try making this service run at boot time:
#chkconfig myscript on
service myscript does not support chkconfig
Hmm...Not working !!!
How to fix it????
So here is the complete solution:
(Assume the name of my script is myscript)
1 - Copy your script into /etc/init.d folder
2 - cd /etc/init.d
3 - chmod +x myscript
4 - Add these lines, including #, right after #!/bin/bash or #!/bin/sh:
# chkconfig: 2345 95 20
# description: Some description
# What your script does (not sure if this is necessary though)
# processname: myscript
5 - chkconfig –level 2345 myscript on
Try now !!!
It will work.
LinuxInterview: Difference between Hard Link and Soft Link? - Creative Understanding
There's an enormous difference, actually. There's really no such thing as a "hard link". If anything, there is an action that you can call "creating a hard link".
The thing is, a file can have several names. If you create a hard link (by running `ln' without `-s'), you simply create a new name which points to the exact same file as the original name. For example, if you run the following commands:
Code:
cd /tmp
echo test >file1
ln file1 file2
Then you will have two filenames, /tmp/file1 and /tmp/file2, which both point to the same actual file. Notice the important distinction between a file and its name(s): A name knows which file it points to, but a file doesn't know what name(s) it has.
The reason that I say that there's no such thing as a hard link is because the names file1 and file2 are equivalent. There's no "original" name. You can in no way tell that "file2 is a hard link to file1", or the opposite, or anything evem similar -- they are simply two different names for the same file.
An interesting implication of this is that the `rm' command doesn't actually remove files. Instead, it only removes filenames (the system call that it uses is called `unlink', not `remove' or `delete'). The actual file is only automatically deleted by the system when it has no more names. Thus, if you delete file1, file2 will still points to the same file, and conversely, if you delete file2, file1 will still be pointing to the same file.
A symlink, on the other hand, is a file in its own right. It contains the filename of the file that it points to. If file2 were a symlink to file1, and you deleted file1, the file2 symlink would be "broken" (since the filename that it points to no longer exists). In this case, file1 is the name of the actual, original file, and file2 is just a symlink that points to it by name.
For bonus points: What would be the difference in output from the cat command in the following two sequences of commands, and why?
Sequence 1:
Code:
cd /tmp
echo 1 >file1
ln file1 file2
rm file1
echo 2 >file1
cat file2
rm file1 file2
Sequence 2:
Code:
cd /tmp
echo 1 >file1
ln -s file1 file2
rm file1
echo 2 >file1
cat file2
rm file1 file2
The thing is, a file can have several names. If you create a hard link (by running `ln' without `-s'), you simply create a new name which points to the exact same file as the original name. For example, if you run the following commands:
Code:
cd /tmp
echo test >file1
ln file1 file2
Then you will have two filenames, /tmp/file1 and /tmp/file2, which both point to the same actual file. Notice the important distinction between a file and its name(s): A name knows which file it points to, but a file doesn't know what name(s) it has.
The reason that I say that there's no such thing as a hard link is because the names file1 and file2 are equivalent. There's no "original" name. You can in no way tell that "file2 is a hard link to file1", or the opposite, or anything evem similar -- they are simply two different names for the same file.
An interesting implication of this is that the `rm' command doesn't actually remove files. Instead, it only removes filenames (the system call that it uses is called `unlink', not `remove' or `delete'). The actual file is only automatically deleted by the system when it has no more names. Thus, if you delete file1, file2 will still points to the same file, and conversely, if you delete file2, file1 will still be pointing to the same file.
A symlink, on the other hand, is a file in its own right. It contains the filename of the file that it points to. If file2 were a symlink to file1, and you deleted file1, the file2 symlink would be "broken" (since the filename that it points to no longer exists). In this case, file1 is the name of the actual, original file, and file2 is just a symlink that points to it by name.
For bonus points: What would be the difference in output from the cat command in the following two sequences of commands, and why?
Sequence 1:
Code:
cd /tmp
echo 1 >file1
ln file1 file2
rm file1
echo 2 >file1
cat file2
rm file1 file2
Sequence 2:
Code:
cd /tmp
echo 1 >file1
ln -s file1 file2
rm file1
echo 2 >file1
cat file2
rm file1 file2
Sunday, November 29, 2009
JAVA: Installing jdk on Linux
Follow the steps mentioned below to install java-1.6.
1.Download jdk-6u16-linux-x64.bin (From the URL mentioned in the prerequisites section) to /opt directory.
2.Change the permission of jdk-6u16-linux-x64.bin file to 755.
[root@bang opt]# chmod 755 jdk-6u16-linux-x64.bin
3.Execute the jdk-6u16-linux-x64.bin file to start installation.
[root@bang opt]# ./jdk-6u16-linux-x64.bin
Sun Microsystems, Inc. Binary Code License Agreement
for the JAVA 2 PLATFORM STANDARD EDITION DEVELOPMENT KIT 6.0
SUN MICROSYSTEMS, INC. ("SUN") IS WILLING TO LICENSE THE
SOFTWARE IDENTIFIED BELOW TO YOU ONLY UPON THE CONDITION
THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS BINARY
CODE LICENSE AGREEMENT AND SUPPLEMENTAL LICENSE TERMS
(COLLECTIVELY "AGREEMENT"). PLEASE READ THE AGREEMENT
CAREFULLY. BY DOWNLOADING OR INSTALLING THIS SOFTWARE, YOU
ACCEPT THE TERMS OF THE AGREEMENT. INDICATE ACCEPTANCE BY
SELECTING THE "ACCEPT" BUTTON AT THE BOTTOM OF THE
AGREEMENT. IF YOU ARE NOT WILLING TO BE BOUND BY ALL THE
TERMS, SELECT THE "DECLINE" BUTTON AT THE BOTTOM OF THE
AGREEMENT AND THE DOWNLOAD OR INSTALL PROCESS WILL NOT
CONTINUE.
1. DEFINITIONS. "Software" means the identified above in
binary form, any other machine readable materials
(including, but not limited to, libraries, source files,
header files, and data files), any updates or error
corrections provided by Sun, and any user manuals,
programming guides and other documentation provided to you
by Sun under this Agreement. "General Purpose Desktop
Computers and Servers" means computers, including desktop,
laptop and tablet computers, or servers, used for general
computing functions under end user control (such as but not
specifically limited to email, general purpose Internet
browsing, and office suite productivity tools). The use of
Software in systems and solutions that provide dedicated
functionality (other than as mentioned above) or designed
for use in embedded or function-specific software
applications, for example but not limited to: Software
embedded in or bundled with industrial control systems,
wireless mobile telephones, wireless handheld devices,
kiosks, TV/STB, Blu -ray Disc devices, telematics and
network control switching equipment, printers and storage
management systems, and other related systems are excluded
from this definition and not licensed under this Agreement.
"Programs" means Java technology applets and applications
intended to run on the Java Platform Standard Edition (Java
SE) ptaform on Java-enabled General Purpose Desktop
Computers and Servers.
4.Press the Tab key until you reach the End of License Agreement Screen
5.Type yes and hit Enter key
6.It will installs jdk-1.6.0_16
F. Source Code. Software may contain source code that,
unless expressly licensed for other purposes, is provided
solely for reference purposes pursuant to the terms of this
Agreement. Source code may not be redistributed unless
expressly provided for in this Agreement.
G. Third Party Code. Additional copyright notices and
license terms applicable to portions of the Software are set
forth in the THIRDPARTYLICENSEREADME.txt file. In addition
to any terms and conditions of any third party
opensource/freeware license identified in the
THIRDPARTYLICENSEREADME.txt file, the disclaimer of warranty
and limitation of liability provisions in paragraphs 5 and 6
of the Binary Code License Agreement shall apply to all
Software in this distribution.
H. Termination for Infringement. Either party may
terminate this Agreement immediately should any Software
become, or in either party's opinion be likely to become,
the subject of a claim of infringement of any intellectual
property right.
I. Installation and Auto-Update. The Software's
installation and auto-update processes transmit a limited
amount of data to Sun (or its service provider) about those
specific processes to help Sun understand and optimize them.
Sun does not associate the data with personally identifiable
information. You can find more information about the data
Sun collects at http://java.com/data/.
For inquiries please contact: Sun Microsystems, Inc., 4150
Network Circle, Santa Clara, California 95054, U.S.A.
(LFI#143333/Form ID#011801)
Do you agree to the above license terms? [yes or no]
yes
Unpacking...
Checksumming...
0
0
Extracting...
UnZipSFX 5.50 of 17 February 2002, by Info-ZIP (Zip-Bugs@lists.wku.edu).
inflating: jdk-6u16-linux-x64-rpm
Preparing... #################################### [100%]
1:jdk #################################### [100%]
Done.
#
7.Add below lines in /etc/profile file to define JAVA_HOME and its PATH
export JAVA_HOME=/usr/java/jdk-1.6.0_16
export PATH=$PATH:$HOME/bin:$JAVA_HOME/bin:
8. Verify the java installation by running the following command in the new window.`
[root@bang opt]# java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
[root@bangvbapp opt]#
1.Download jdk-6u16-linux-x64.bin (From the URL mentioned in the prerequisites section) to /opt directory.
2.Change the permission of jdk-6u16-linux-x64.bin file to 755.
[root@bang opt]# chmod 755 jdk-6u16-linux-x64.bin
3.Execute the jdk-6u16-linux-x64.bin file to start installation.
[root@bang opt]# ./jdk-6u16-linux-x64.bin
Sun Microsystems, Inc. Binary Code License Agreement
for the JAVA 2 PLATFORM STANDARD EDITION DEVELOPMENT KIT 6.0
SUN MICROSYSTEMS, INC. ("SUN") IS WILLING TO LICENSE THE
SOFTWARE IDENTIFIED BELOW TO YOU ONLY UPON THE CONDITION
THAT YOU ACCEPT ALL OF THE TERMS CONTAINED IN THIS BINARY
CODE LICENSE AGREEMENT AND SUPPLEMENTAL LICENSE TERMS
(COLLECTIVELY "AGREEMENT"). PLEASE READ THE AGREEMENT
CAREFULLY. BY DOWNLOADING OR INSTALLING THIS SOFTWARE, YOU
ACCEPT THE TERMS OF THE AGREEMENT. INDICATE ACCEPTANCE BY
SELECTING THE "ACCEPT" BUTTON AT THE BOTTOM OF THE
AGREEMENT. IF YOU ARE NOT WILLING TO BE BOUND BY ALL THE
TERMS, SELECT THE "DECLINE" BUTTON AT THE BOTTOM OF THE
AGREEMENT AND THE DOWNLOAD OR INSTALL PROCESS WILL NOT
CONTINUE.
1. DEFINITIONS. "Software" means the identified above in
binary form, any other machine readable materials
(including, but not limited to, libraries, source files,
header files, and data files), any updates or error
corrections provided by Sun, and any user manuals,
programming guides and other documentation provided to you
by Sun under this Agreement. "General Purpose Desktop
Computers and Servers" means computers, including desktop,
laptop and tablet computers, or servers, used for general
computing functions under end user control (such as but not
specifically limited to email, general purpose Internet
browsing, and office suite productivity tools). The use of
Software in systems and solutions that provide dedicated
functionality (other than as mentioned above) or designed
for use in embedded or function-specific software
applications, for example but not limited to: Software
embedded in or bundled with industrial control systems,
wireless mobile telephones, wireless handheld devices,
kiosks, TV/STB, Blu -ray Disc devices, telematics and
network control switching equipment, printers and storage
management systems, and other related systems are excluded
from this definition and not licensed under this Agreement.
"Programs" means Java technology applets and applications
intended to run on the Java Platform Standard Edition (Java
SE) ptaform on Java-enabled General Purpose Desktop
Computers and Servers.
4.Press the Tab key until you reach the End of License Agreement Screen
5.Type yes and hit Enter key
6.It will installs jdk-1.6.0_16
F. Source Code. Software may contain source code that,
unless expressly licensed for other purposes, is provided
solely for reference purposes pursuant to the terms of this
Agreement. Source code may not be redistributed unless
expressly provided for in this Agreement.
G. Third Party Code. Additional copyright notices and
license terms applicable to portions of the Software are set
forth in the THIRDPARTYLICENSEREADME.txt file. In addition
to any terms and conditions of any third party
opensource/freeware license identified in the
THIRDPARTYLICENSEREADME.txt file, the disclaimer of warranty
and limitation of liability provisions in paragraphs 5 and 6
of the Binary Code License Agreement shall apply to all
Software in this distribution.
H. Termination for Infringement. Either party may
terminate this Agreement immediately should any Software
become, or in either party's opinion be likely to become,
the subject of a claim of infringement of any intellectual
property right.
I. Installation and Auto-Update. The Software's
installation and auto-update processes transmit a limited
amount of data to Sun (or its service provider) about those
specific processes to help Sun understand and optimize them.
Sun does not associate the data with personally identifiable
information. You can find more information about the data
Sun collects at http://java.com/data/.
For inquiries please contact: Sun Microsystems, Inc., 4150
Network Circle, Santa Clara, California 95054, U.S.A.
(LFI#143333/Form ID#011801)
Do you agree to the above license terms? [yes or no]
yes
Unpacking...
Checksumming...
0
0
Extracting...
UnZipSFX 5.50 of 17 February 2002, by Info-ZIP (Zip-Bugs@lists.wku.edu).
inflating: jdk-6u16-linux-x64-rpm
Preparing... #################################### [100%]
1:jdk #################################### [100%]
Done.
#
7.Add below lines in /etc/profile file to define JAVA_HOME and its PATH
export JAVA_HOME=/usr/java/jdk-1.6.0_16
export PATH=$PATH:$HOME/bin:$JAVA_HOME/bin:
8. Verify the java installation by running the following command in the new window.`
[root@bang opt]# java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
[root@bangvbapp opt]#
RHCE : How to create a new Linux Partition?
Imagine that we have a server running RHEL 4 and our supervisor comes over and wants a 10 GB partition created for the data processing department. This is in addition to what the server currently has allocated, so we can either create a partition out of unpartitioned space on the existing disk (experienced Linux system administrators will leave unpartitioned disk space for future expansion) if available, or we can add another drive. This scenario actually happens quite frequently in the production world, so this is a valuable skill to have even if you administer nothing more than your home machines.
We'll assume that your supervisor has given you the latitude of deciding which of the above options you'll use, so your first task is to check to see if space is available on your existing media. We'll run "fdisk -l" to see the size of the disk; the data we need is on the first line of output.
[root@station17 ~]# fdisk -l
Disk /dev/sda: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 38 305203+ 83 Linux
/dev/sda2 39 7687 61440592+ 83 Linux
/dev/sda3 7688 7942 2048287+ 82 Linux swap
From this we can see the size of our drive is 80.0 GB. Now, we'll use "df -h" to calculate the size of the partitions that are on our system. We only need to be concerned with the rows that have a device label, the others (labeled with "none") don't concern us. The column labeled "Size" has the numbers we'll need to add up to get a overall size.
[root@station17 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 58G 6.5G 49G 12% /
/dev/sda1 289M 17M 258M 6% /boot
none 1013M 0 1013M 0% /dev/shm
[root@station17 ~]#
From this, we can see that /dev/sda2 is 58G and /dev/sda1 is 289M - a total of 58.3GB. Now we need to add in our swap size; "cat /proc/swaps" will tell us what size our swap partition is.
[ If you feel like using an actual system utility for this, "swapon -s" will do the same thing. -- Ben ]
[root@station17 ~]# cat /proc/swaps
Filename Type Size Used Priority
/dev/sda3 partition 2048276 0 -1
[root@station17 ~]#
Adding in the 2GB from this means that we have 19.7 GB to work with - well over what we need. Now, let's move on to creating our partition: "fdisk /dev/sda" will open our drive's partition table for modification. Since we're already using 3 partitions on the drive, we'll have to make our 4th one an extended one - a container to house any additional partitions, including the one we are creating now. We'll want to accept the defaults on this extended partition, which will make the whole rest of the drive available for our new partitions. We'll be using an ext3 filesystem, so we also need to keep this in mind: the "mkfs" command reserves 5% of the blocks for root. Given all that, we'll make our new partition 11.5GB to compensate for the blocks reserved for root plus a little extra.
[root@station17 ~]# fdisk /dev/sda
The number of cylinders for this disk is set to 9726.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
e
Selected partition 4
First cylinder (7943-9726, default 7943):
Using default value 7943
Last cylinder or +size or +sizeM or +sizeK (7943-9726, default 9726):
Using default value 9726
Here you can see where I selected "n" for a new partition and "e" to make a extended partition. I then accepted the defaults for both the starting cylinder and again for the ending cylinder.
Command (m for help): n
First cylinder (7943-9726, default 7943):
Using default value 7943
Last cylinder or +size or +sizeM or +sizeK (7943-9726, default 9726):.+11500M
Next, I hit "n" to create a new partition; then, when prompted to use a starting cylinder, I hit 'enter' to accept the default. For the ending cylinder I entered "+11500M" to specify the size. The plus is important - without it, you will get an error. Its a good idea to hit "p" to at this point to get "fdisk" to print the partition table. This will show what we have done before saving our changes.
Command (m for help):.p
Disk /dev/sda: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 38 305203+ 83 Linux
/dev/sda2 39 7687 61440592+ 83 Linux
/dev/sda3 7688 7942 2048287+ 82 Linux swap
/dev/sda4 7943 9726 14329980 5 Extended
/dev/sda5 7943 9341 11237436 83 Linux
If there are any mistakes just quit "fdisk" with a "q" and no changes will be saved. This looks right - so lets write our changes with a "w".
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
[root@station17 ~]#
This warning can be remedied by using the 'partprobe' command to force the kernel to reread the partition table. Remember - if this were a production machine, we wouldn't want to have to reboot it.
[root@station17 ~]# partprobe
At this point our 11.5G partition is /dev/sda5 and raw - it has neither a file system nor a label descriptor - so let's format it and give it a label. Giving the partition a label can be done at the same time that the file system is being created with the -L option, but I prefer to do it in a separate step.
[root@station17 ~]# mkfs.ext3 /dev/sda5
mke2fs 1.35 (28-Feb-2004)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1406272 inodes, 2809359 blocks
140467 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2877292544
86 block groups
32768 blocks per group, 32768 fragments per group
16352 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 34 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
[root@station17 ~]#
Now we'll give it label ("/data"):
[root@station17 ~]# e2label /dev/sda5 /data
[root@station17 ~]#
Next, we need to create a mount point in our filesystem and make sure that it's mounted at boot time. Let's create a directory on our system called /data.
[ The usual method of allocating new space is often much more complex than that - at least in the planning stages. In fact, creating a non-standard directory name in the root of the filesystem as suggested here is incorrect and violates the Filesystem Hierarchy Standard (FHS). As an example of a more typical situation, if an administrator finds that a shared machine's drive is running out of room, he may first examine the machine to see where the most activity/space consumption is occuring. Assuming that it's in the space assigned to users (i.e., "/home"), he would most likely back up the data in that subdirectory, restore it to the newly-created partition, delete "/home", and mount the new partition as "/home". This would recover all the space used by the original "/home" and leave it available for the rest of the system to use - and most users would not even realize that any change had been made. This approach doesn't require rebooting the machine either. -- Ben ]
[ I do understand that the partitioning is inconsistent with the FHS, but our RedHat course materials do instruct us to create directories in / for simplicity and ease in the aid backups. We are also led by instruction to do things such as specialized partitioning schemes for different things this way here at the RedHat academy. -- Joey ]
[root@station17 ~]# mkdir /data
[root@station17 ~]#
Now we put it in the file system table, '/etc/fstab', so it gets mounted on every boot.
[root@station17 ~]# vi /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/ / ext3 defaults 1 1
LABEL=/data /data ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
LABEL=SWAP-sda3 swap swap defaults 0 0
/dev/scd0 /media/cdrecorder auto pamconsole,exec,noauto,managed 0 0
I used the root partition as a guide in this sample. The label is in the first column, the mount point is in the second, then we have the file system type and the mount options. The last two numbers are the dump indicator and the fsck indicator; they determine when the system gets backed up if you're using 'dump', and when the system gets checked for errors. Basically, you can copy these numbers and options just as I have. Write your changes and exit the editor. Then, to make sure that there were no errors, run "mount -a" to mount all the partitions listed in /etc/fstab. Any errors would be reported at this point.
[root@station17 ~]# mount -a
Since we didn't get any errors, let's do a "df -h" and see how everything looks.
[root@station17 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 58G 6.6G 49G 12% /
/dev/sda1 289M 17M 258M 6% /boot
none 1013M 0 1013M 0% /dev/shm
/dev/sda5 11G 59M 10G 1% /data
[root@station17 ~]#
That's it - we are now ready to start using this new partition, keeping in mind we may have to modify permissions as needed for our users and groups. This is a very common task, one that all Linux users should become familiar with because you will almost certainly be faced with needing more room. This process is very similar to adding another disk - you would simply substitute your device labels as required.
We'll assume that your supervisor has given you the latitude of deciding which of the above options you'll use, so your first task is to check to see if space is available on your existing media. We'll run "fdisk -l" to see the size of the disk; the data we need is on the first line of output.
[root@station17 ~]# fdisk -l
Disk /dev/sda: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 38 305203+ 83 Linux
/dev/sda2 39 7687 61440592+ 83 Linux
/dev/sda3 7688 7942 2048287+ 82 Linux swap
From this we can see the size of our drive is 80.0 GB. Now, we'll use "df -h" to calculate the size of the partitions that are on our system. We only need to be concerned with the rows that have a device label, the others (labeled with "none") don't concern us. The column labeled "Size" has the numbers we'll need to add up to get a overall size.
[root@station17 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 58G 6.5G 49G 12% /
/dev/sda1 289M 17M 258M 6% /boot
none 1013M 0 1013M 0% /dev/shm
[root@station17 ~]#
From this, we can see that /dev/sda2 is 58G and /dev/sda1 is 289M - a total of 58.3GB. Now we need to add in our swap size; "cat /proc/swaps" will tell us what size our swap partition is.
[ If you feel like using an actual system utility for this, "swapon -s" will do the same thing. -- Ben ]
[root@station17 ~]# cat /proc/swaps
Filename Type Size Used Priority
/dev/sda3 partition 2048276 0 -1
[root@station17 ~]#
Adding in the 2GB from this means that we have 19.7 GB to work with - well over what we need. Now, let's move on to creating our partition: "fdisk /dev/sda" will open our drive's partition table for modification. Since we're already using 3 partitions on the drive, we'll have to make our 4th one an extended one - a container to house any additional partitions, including the one we are creating now. We'll want to accept the defaults on this extended partition, which will make the whole rest of the drive available for our new partitions. We'll be using an ext3 filesystem, so we also need to keep this in mind: the "mkfs" command reserves 5% of the blocks for root. Given all that, we'll make our new partition 11.5GB to compensate for the blocks reserved for root plus a little extra.
[root@station17 ~]# fdisk /dev/sda
The number of cylinders for this disk is set to 9726.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
e
Selected partition 4
First cylinder (7943-9726, default 7943):
Using default value 7943
Last cylinder or +size or +sizeM or +sizeK (7943-9726, default 9726):
Using default value 9726
Here you can see where I selected "n" for a new partition and "e" to make a extended partition. I then accepted the defaults for both the starting cylinder and again for the ending cylinder.
Command (m for help): n
First cylinder (7943-9726, default 7943):
Using default value 7943
Last cylinder or +size or +sizeM or +sizeK (7943-9726, default 9726):.+11500M
Next, I hit "n" to create a new partition; then, when prompted to use a starting cylinder, I hit 'enter' to accept the default. For the ending cylinder I entered "+11500M" to specify the size. The plus is important - without it, you will get an error. Its a good idea to hit "p" to at this point to get "fdisk" to print the partition table. This will show what we have done before saving our changes.
Command (m for help):.p
Disk /dev/sda: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 38 305203+ 83 Linux
/dev/sda2 39 7687 61440592+ 83 Linux
/dev/sda3 7688 7942 2048287+ 82 Linux swap
/dev/sda4 7943 9726 14329980 5 Extended
/dev/sda5 7943 9341 11237436 83 Linux
If there are any mistakes just quit "fdisk" with a "q" and no changes will be saved. This looks right - so lets write our changes with a "w".
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.
[root@station17 ~]#
This warning can be remedied by using the 'partprobe' command to force the kernel to reread the partition table. Remember - if this were a production machine, we wouldn't want to have to reboot it.
[root@station17 ~]# partprobe
At this point our 11.5G partition is /dev/sda5 and raw - it has neither a file system nor a label descriptor - so let's format it and give it a label. Giving the partition a label can be done at the same time that the file system is being created with the -L option, but I prefer to do it in a separate step.
[root@station17 ~]# mkfs.ext3 /dev/sda5
mke2fs 1.35 (28-Feb-2004)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1406272 inodes, 2809359 blocks
140467 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2877292544
86 block groups
32768 blocks per group, 32768 fragments per group
16352 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 34 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
[root@station17 ~]#
Now we'll give it label ("/data"):
[root@station17 ~]# e2label /dev/sda5 /data
[root@station17 ~]#
Next, we need to create a mount point in our filesystem and make sure that it's mounted at boot time. Let's create a directory on our system called /data.
[ The usual method of allocating new space is often much more complex than that - at least in the planning stages. In fact, creating a non-standard directory name in the root of the filesystem as suggested here is incorrect and violates the Filesystem Hierarchy Standard (FHS). As an example of a more typical situation, if an administrator finds that a shared machine's drive is running out of room, he may first examine the machine to see where the most activity/space consumption is occuring. Assuming that it's in the space assigned to users (i.e., "/home"), he would most likely back up the data in that subdirectory, restore it to the newly-created partition, delete "/home", and mount the new partition as "/home". This would recover all the space used by the original "/home" and leave it available for the rest of the system to use - and most users would not even realize that any change had been made. This approach doesn't require rebooting the machine either. -- Ben ]
[ I do understand that the partitioning is inconsistent with the FHS, but our RedHat course materials do instruct us to create directories in / for simplicity and ease in the aid backups. We are also led by instruction to do things such as specialized partitioning schemes for different things this way here at the RedHat academy. -- Joey ]
[root@station17 ~]# mkdir /data
[root@station17 ~]#
Now we put it in the file system table, '/etc/fstab', so it gets mounted on every boot.
[root@station17 ~]# vi /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/ / ext3 defaults 1 1
LABEL=/data /data ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
LABEL=SWAP-sda3 swap swap defaults 0 0
/dev/scd0 /media/cdrecorder auto pamconsole,exec,noauto,managed 0 0
I used the root partition as a guide in this sample. The label is in the first column, the mount point is in the second, then we have the file system type and the mount options. The last two numbers are the dump indicator and the fsck indicator; they determine when the system gets backed up if you're using 'dump', and when the system gets checked for errors. Basically, you can copy these numbers and options just as I have. Write your changes and exit the editor. Then, to make sure that there were no errors, run "mount -a" to mount all the partitions listed in /etc/fstab. Any errors would be reported at this point.
[root@station17 ~]# mount -a
Since we didn't get any errors, let's do a "df -h" and see how everything looks.
[root@station17 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 58G 6.6G 49G 12% /
/dev/sda1 289M 17M 258M 6% /boot
none 1013M 0 1013M 0% /dev/shm
/dev/sda5 11G 59M 10G 1% /data
[root@station17 ~]#
That's it - we are now ready to start using this new partition, keeping in mind we may have to modify permissions as needed for our users and groups. This is a very common task, one that all Linux users should become familiar with because you will almost certainly be faced with needing more room. This process is very similar to adding another disk - you would simply substitute your device labels as required.
Saturday, November 21, 2009
Fedora DS : Setting up Fedora DS for Linux, HP and Solaris
THE FEDORA DIRECTORY SERVER
Implementation and Configurations
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
8. Authenticating the Fedora DS Client with the Server
9. Single Master Replication within the two Fedora DS Machine
10. Users, Groups Creation and Restriction on Domains
11. Password Ageing and Account Lockout Policy
12. Fedora DS Client Setup on RHEL 4.0
13. Fedora DS SSL Configuration
14. Configuring Fedora DS Client on RHEL 4.0
14. Configuring Fedora DS Client on Solaris 8/9/10
15. Configuring Fedora DS Client on HP-UNIX
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]
1. 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-LOGICA-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
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 = pe.im.logica.com
getFQDN: host test01 = ;;
getFQDN: host test01 has length 7
getFQDN: new max host pe has length 7
getFQDN: host ;; has length 3
getFQDN: host pe.im.logica.com has length 21
getFQDN: new max host pe.im.logica.com has length 21
getFQDN: host test01 has length 7
Hostname to use (default: pe.im.logica.com)
Server user ID to use (default: nobody) fds
Server group ID to use (default: nobody) fds
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://pe.im.logica.com:27856
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://pe.im.logica.com:27856
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=pe,dc=im,dc=logica,dc=com
[Quick Trick : Open the /tmp/passwd.ldif file through vi editor & provide the following command:
:%s/padl/
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://pe.im.logica.com:27856
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.
09. Authenticating the Fedora DS Client with the Server
( Yet to be added)
10. Single Master Replication within the two Fedora DS
Single-Master Replication
In the simplest replication scenario, the master copy of directory data is held in a single read-write replica on one server called the supplier server. The supplier server also maintains change log for this replica. On another server, called the consumer server you have as many read-only replicas as you like. Such scenarios are called single-master configurations. Figure shows an example of single-master replication.
Single-Master Replication ( Figure 8.1)
In this particular configuration the ou=people,dc=example,dc=com suffix receives a large number of search requests. Therefore, to distribute the load, this tree, which is mastered on Server A, is replicated to two read-only replicas located on Server B and Server C.
Configuring Single-Master Replication
This section provides information on configuring single-master replication. The steps described in this section provide a high level overview of the procedure you need to follow. Cross-references to the detailed task descriptions are provided at each step.
To set up single-master replication such as the configuration shown in Figure 8-1, between supplier Server A that holds a read-write replica, and the two consumers Server B and Server C that each hold a read-only replica, you need to perform the following procedures:
• Configuring the Read-Only Replica on the Consumer Server
• Configuring the Read-Write Replica on the Supplier Server
• Initializing the Replicas for Single-Master Replication
Configuring the Read-Only Replica on the Consumer Server
1. Create the database for the read-only replica, if it does not exist.
2. Create the entry corresponding to the supplier bind DN on the consumer server, if it does not exist. This is the special entry that the supplier will use to bind.
a. In the Directory Server Console, click the Directory tab, and create an entry. For example you could use cn=Replication Manager,cn=config.
b. Specify a userPassword attribute-value pair.
c. If you have enabled the password expiration policy, or intend to do so in future, you must remember to disable it to prevent replication from failing due to passwords expiring. To disable the password expiration policy on the userPassword attribute, add the passwordExpirationTime attribute with a value of 20380119031407Z which means that the password will never expire.
Note This entry must not be part of the replicated database.
3. Specify the replication settings required for a read-only replica.
a. In the Directory Server Console, click the Configuration tab.
b. In the navigation tree, expand the Replication folder, and highlight the replica database.
The Replica Settings tab is displayed in the right-hand side of the window.
c. Check the Enable Replica checkbox.
d. In the Replica Role section, select the Dedicated Consumer radio button.
e. In the Common Settings section, specify a purge delay in the Purge delay field.
This option indicates how often the state information stored in the replicated entries is purged.
f. In the Replica Update Settings section, specify the bind DN or entry DN that the supplier will use to bind to the replica.You can now specify multiple supplier bind DNs per replica but only one supplier DN per replication agreement. To specify your supplier bind DN:
g. In the Replica Update Settings section enter your supplier bind DN in the Enter a new Supplier DN or entry DN field.
h. Click Add. You supplier bind DN will appear in the Current Supplier DNs or entry DNs to which the supplier's certificate is mapped field directly above.
i. Repeat the operation for every supplier bind DN you want to include in the list. Click Save when you have finished.
This supplier bind DN should correspond to the entry created in Step 2. Note that the supplier bind DN corresponds to a privileged user, because it is not subject to access control.
j. Specify any supplier servers to which you want to refer updates.
By default, all updates are first referred to the supplier servers that you specify here. If you specify none, updates are referred to the supplier servers that have a replication agreement that includes the current replica.
Automatic referrals assume that clients will bind over a regular connection, and therefore, are of the form ldap://servername:port. If you want clients to bind to the supplier using SSL, you can use this field to specify a referral of the form ldaps://servername:port where the s in ldaps indicates secure connections.
4. Click Save to save the replication settings for the replica.
5. Repeat these steps for every read-only replica in your replication configuration.
Configuring the Read-Write Replica on the Supplier Server
1. Specify the supplier settings for the server.
a. In the Directory Server Console, click the Configuration tab.
b. In the navigation tree, highlight the Replication node.
c. In the right-hand side of the window, click the Supplier Settings tab.
d. Check the Enable Change Log checkbox.
This activates all of the fields in the pane below that were previously greyed out.
e. Specify a change log by clicking the Use Default button, or click the Browse button to display a file selector.
f. Set the change log parameters (number and age).
You must clear the unlimited checkboxes if you want to specify different values.
g. Click Save to save the supplier settings.
2. Specify the replication settings required for a read-write replica.
a. In the navigation tree on the Configuration tab, expand the Replication node and highlight the database to replicate.
The Replica Settings tab is displayed in the right-hand side of the window.
b. Check the Enable Replica checkbox.
c. In the Replica Role section, select the Single Master radio button.
d. In the Common Settings section, specify a Replica ID (an integer between 1 and 254 inclusive).
The replica ID must be unique for a given suffix, that is to say, different from the IDs used for read-write replicas on this server and on other servers.
e. In the Common Settings section specify a purge delay in the Purge delay field.
This option indicates how often the state information stored in the replicated entries is purged.
f. Click Save to save the replication settings for the database.
3. Create a replication agreement.
You must create one replication agreement for each read-only replica. For example, in the case illustrated in Figure 8-1, Server A holds two replication agreements, one for Server B, and one for Server C.
a. In the navigation tree on the Configuration tab, right-click the database to replicate, and select New Replication Agreement.
Alternatively, highlight the database and select New Replication Agreement from the Object menu. This will start the Replication Agreement Wizard.
b. Go through the steps in the replication wizard by clicking Next to move to the following step.
c. When you have finished, the replication agreement is set up.
Lets say we have two RHEL machine(or any Linux Distros) we need to have the following requisite parameters set in both the machines:
Host 1 -- dogmatix.groupinfra.com
Host 2 -- test02.groupinfra.com
1. Two machines, each running Fedora Directory Server
2. Password for "cn=directory manager" must be the same on both machines
3. LDAP naming context must be the same on both machines
4. The perl module Net::LDAP ( the mmr.pl script if you are thinking to configure through the command line)
[Note: Keep all the information same( Ldap and Admin port ,password etc) in the both server same during the setup time ]
The Configuration through the Directory Server Console consists of the following steps:
Thus , the last snapshot shows the Replication status as :
1. NSMMReplicationPlugin started at 16:32 on 27th September
2. Beginning of the Export of NetscapeRoot
3. And Finally Finished the Export Successfully.
10. Users, Groups Creation and Restriction on Domains
Creating Users, groups and domains through the Directory Console is very easy.The Fedora Directory Console provides a console for the User and group configurations.
Few screenshots for the User and group creation has been caught below:
1. Click on users and Groups tab:
2. Select the subtree or the domain you want your user to be placed at.
.
3.Fill in the different attributes for the Home directory.
The Posix user and simple Users entry is for the Linux Machines but the NT user option is used when we try to authenticate the client from the Windows Terminal.
11. Password Ageing and Account Lockout Policy
Managing the Password Policy
A password policy minimizes the risks of using passwords by enforcing the following:
• Users must change their passwords according to a schedule.
• Users must provide non-trivial passwords.
Once you have established a password policy, which can be for the entire directory or for specific subtrees or users, you can protect your user passwords from potential threats by configuring an account lockout policy. Account lockout protects against hackers who try to break into the directory by repeatedly guessing a user's password.
This section provides information about configuring your password and account lockout policies:
• Configuring the Password Policy
• Setting User Passwords
• Password Change Extended Operation
• Configuring the Account Lockout Policy
• Managing the Password Policy in a Replicated Environment
• Sycnhronizing Passwords
.
Configuring the Password Policy
Directory Server supports fine-grained password policy, enabling you to define a policy that can be applied to the entire directory (global password policy), a particular subtree (subtree level or local password policy), or a particular user (user level or local password policy).
Essentially, your password policy is comprised of the following information:
• The type or level of password policy checks. This information indicates whether the server should check for and enforce a global password policy or local (subtree/user level) password policies.
• Password add and modify information. The password information includes password syntax and password history details.
• Bind information. The bind information includes the number of grace logins permitted, password aging attributes, and tracking bind failures
Configuring a Global Password Policy Using the Console
To set up or modify the password policy for an entire directory:
1. In the Directory Server Console, select the Configuration tab and then the Data node.
2. In the right pane, select the Passwords tab.
This tab contains the password policy for the entire Directory Server.
3. If you want users to change their password the first time they log on, select the "User must change password after reset" checkbox.
If you select this checkbox, only the Directory Manager is authorized to reset the users's password. A regular administrative user cannot force the users to update their password.
4. If you want to allow users to change their own passwords, select the "User may change password" checkbox.
5. If you want to prevent users from changing their password for a specific duration, enter the number of days in the "Allow changes in X day(s)" text box.
6. If you want the server to maintain a history list of passwords used by each user, select the "Keep password history" checkbox. Enter the number of passwords you want the server to keep for each user in the "Remember X passwords" text box.
7. If you do not want user passwords to expire, select the "Password never expires" radio button.
8. If you want users to change their passwords periodically, select the "Password expires after X days" radio button, and then enter the number of days that a user password is valid.
The maximum value for the password age is derived by subtracting January 18, 2038, from today's date. The value you enter must not be set to the maximum value or too close to the maximum value. If you set the value to the maximum value, Directory Server may fail to start because the number of seconds will go past the epoch date. In such an event, the error log will indicate that the password maximum age is invalid. To resolve this problem, you must correct the passwordMaxAge attribute value in the dse.ldif file.
A common policy is to have passwords expire every 30 to 90 days. By default, the password maximum age is set to 8640000 seconds (100 days).
9. If you have selected the "Password expire after X days" radio button, you need to specify how long before the password expires to send a warning to the user. In the "Send Warning X Days Before Password Expires" text enter the number of days before password expiration to send a warning.
10. If you want the server to check the syntax of a user password to make sure it meets the minimum requirements set by the password policy, select the "Check Password Syntax" checkbox. Then, specify the minimum acceptable password length in the "Password Minimum Length" text box.
11. From the "Password Encryption" pull-down menu, select the encryption method you want the server to use when storing passwords.
For detailed information about the encryption methods, refer to the passwordStorageScheme attribute in Table 7-1, on page 287,.
The Password Encryption menu might contain other encryption methods, as the directory dynamically creates the menu depending upon the existing encryption methods it finds in your directory.
12. When you have finished making changes to the password policy, click Save
Configuring a Subtree/User Password Policy Using the Console
To set up the password policy for a subtree or user, you need to add the required entries and attributes at the subtree or user level, set the appropriate values to the password policy attributes, and enable fine-grained password policy checking.
1. Enable fine-grained password policy.
a. In the Directory Server Console, select the Configuration tab.
b. In the navigation tree, select the Data node.
c. In the right pane, select the Passwords tab.
d. Check the "Enable fine-grained password policy" checkbox.
e. Click Save to save your changes.
2. Create the local password policy for the subtree or user.
a. In the Directory Server Console, select the Directory tab.
b. In the navigation pane, select the subtree or user entry for which you want to set up the password policy.
c. From the Object menu, select the Manage Password Policy option, and then select the "For user" or "For subtree."
Depending on your selection, the User Password Policy or Subtree Password Policy window appears.
a. In the Passwords tab, select the "Create subtree/user level password policy" checkbox to add the required attributes, fill in the appropriate values, and click Save.
b. In the Account Lockout tab, specify the appropriate information, and click Save
Configuring the Account Lockout Policy Using the Console
To set up or modify the account lockout policy for your Directory Server:
1. In the Directory Server Console, select the Configuration tab and then the Data node.
2. In the right pane, select the Account Lockout tab.
3. To enable account lockout, select the "Accounts may be locked out" checkbox.
4. Enter the maximum number of allowed bind failures in the "Lockout account after X login failures" text box. The server locks out users who exceed the limit you specify here.
5. Enter the number of minutes you want the server to wait before resetting the bind failure counter to 0 in the "Reset failure counter after X minutes" text box.
6. Set the interval you want users to be locked out of the directory.
Select the Lockout Forever radio button to lock users out until their passwords have been reset by the administrator.
Set a specific lockout period by selecting the Lockout Duration radio button and entering the time (in minutes) in the text box.
7. When you have finished making changes to the account lockout policy, click Save.
13. All the Unix, Linux, Solaris machines should be able
to sync with the LDAP Server.
In order to configure the Server-Client Architecture for the entire Fedora DS so as to make the client authenticate whenever the logging in activity is performed, we need to set up the following architecture:
Let see how we are going to connect clients with Fedora-ds installed in another Ubuntu server. we will stick to the following example scenario. Change your setting appropriately.
A test setup is like this:
Installing LDAP Client Packages
We need to install necessary client packages and setup them initially. To install all packages:
# yum install pam_ldap
# yum install nss_ldap
Or, You can check whether the rpm packages has been insatlled or not through
#rpm –qa nss_ldap
#rpm –qa pam_ldap
During the installation it will ask few questions and don't worry about them but keep accepting the default settings since we are going to modify them manually later.
Configuring nsswitch.conf file
The nsswitch.conf file is responsible for switching the authentication order in Linux and we need to setup to accept LDAP authentication. To edit the file:
sudo vi /etc/nsswitch.conf
Then we need change compat with files ldap. Use the following command in vi command mode
%s/compat/files ldap/g
Now your changes will reflect as follows in /etc/nsswitch.conf
...
passwd: files ldap
group: files ldap
shadow: files ldap
...
The order files ldap will look /etc/passwd file first and then look LDAP for authentication.
File: /etc/nsswitch.conf
/etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
# nis or yp Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# db Use the local database (.db) files
# compat Use NIS on compat mode
# hesiod Use Hesiod for user lookups
# ldap Use LDAP (only if nss_ldap is installed)
# nisplus or nis+ Use NIS+ (NIS version 3), unsupported
# [NOTFOUND=return] Stop searching if not found so far
#
# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd: db files ldap nis
#shadow: db files ldap nis
#group: db files ldap nis
passwd: files ldap
shadow: files ldap
group: files ldap
#hosts: db files ldap nis dns
hosts: files dns
# Example - obey only what ldap tells us...
#services: ldap [NOTFOUND=return] files
#networks: ldap [NOTFOUND=return] files
"/etc/nsswitch.conf" 58L, 1658C
#protocols: ldap [NOTFOUND=return] files
#rpc: ldap [NOTFOUND=return] files
#ethers: ldap [NOTFOUND=return] files
bootparams: files
ethers: files
netmasks: files
networks: files
protocols: files ldap
rpc: files
services: files ldap
netgroup: files ldap
publickey: files
automount: files ldap
aliases: files
/etc/pam.d/sshd
#%PAM-1.0
auth required pam_stack.so service=system-auth
#auth required pam_unix.so
#auth sufficient pam_ldap.so
auth required pam_nologin.so
#auth required pam_unix.so
#auth sufficient pam_ldap.so
account required pam_stack.so service=system-auth
#account required pam_unix.so
#account sufficient pam_ldap.so
password required pam_stack.so service=system-auth
#password required pam-unix.so nullok obscure min=4
#password sufficient pam_ldap.so
session required pam_stack.so service=system-auth
session required pam_loginuid.so
#session sufficient pam_ldap.so
#session required pam_unix.so
auth sufficient /lib/security/pam_ldap.so
account sufficient /lib/security/pam_ldap.so
password sufficient /lib/security/pam_ldap.so
/etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so broken_shadow
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_ldap.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_ldap.so # @(#)$Id: ldap.conf,v 1.34 2004/09/16 23:32:02 lukeh Exp $ # # This is the configuration file for the LDAP nameservice # switch library and the LDAP PAM module. # # PADL Software # http://www.padl.com # # Your LDAP server. Must be resolvable without using LDAP. # Multiple hosts may be specified, each separated by a # space. How long nss_ldap takes to failover depends on # whether your LDAP client library supports configurable # network or connect timeouts (see bind_timelimit). host 10.14.236.169 /etc/ldap.conf # The distinguished name of the search base. base dc=csse,dc=uwa,dc=edu,dc=au # Another way to specify your LDAP server is to provide an # uri with the server name. This allows to use # Unix Domain Sockets to connect to a local LDAP Server. #uri ldap://127.0.0.1/ #uri ldaps://10.14.236.169/ #uri ldapi://%2fvar%2frun%2fldapi_sock/ # Note: %2f encodes the '/' used as directory separator # The LDAP version to use (defaults to 3 # if supported by client library) ldap_version 3 # The distinguished name to bind to the server with. # Optional: default is to bind anonymously. #binddn cn=proxyuser,dc=example,dc=com # The credentials to bind with. # Optional: default is no credential. #bindpw secret # The distinguished name to bind to the server with # if the effective user ID is root. Password is # stored in /etc/ldap.secret (mode 600) #rootbinddn cn=manager,dc=example,dc=com # The port. # Optional: default is 389. port 389 # The search scope. #scope sub #scope one #scope base # Search timelimit #timelimit 30 #timelimit 120 # Bind/connect timelimit # bind_timelimit 30 # bind_timelimit 120 # Reconnect policy: hard (default) will retry connecting to # the software with exponential backoff, soft will fail # immediately. # bind_policy hard # Idle timelimit; client will close connections # (nss_ldap only) if the server has not been contacted # for the number of seconds specified below. #idle_timelimit 3600 # idle_timelimit 3600 # Filter to AND with uid=%s #pam_filter objectclass=account # The user ID attribute (defaults to uid) pam_login_attribute uid # Search the root DSE for the password policy (works # with Netscape Directory Server) pam_lookup_policy yes # Check the 'host' attribute for access control # Default is no; if set to yes, and user has no # value for the host attribute, and pam_ldap is # configured for account management (authorization) # then the user will not be allowed to login. #pam_check_host_attr yes # Check the 'authorizedService' attribute for access # control # Default is no; if set to yes, and the user has no # value for the authorizedService attribute, and # pam_ldap is configured for account management # (authorization) then the user will not be allowed # to login. #pam_check_service_attr yes # Group to enforce membership of #pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com # Group member attribute #pam_member_attribute uniquemember # Specify a minium or maximum UID number allowed #pam_min_uid 0 #pam_max_uid 0 # Template login attribute, default template user # (can be overriden by value of former attribute # in user's entry) #pam_login_attribute userPrincipalName #pam_template_login_attribute uid #pam_template_login nobody # HEADS UP: the pam_crypt, pam_nds_passwd, # and pam_ad_passwd options are no # longer supported. # # If you are using XAD, you can set pam_password # to racf, ad, or exop. Make sure that you have # SSL enabled. # Do not hash the password at all; presume # the directory server will do it, if # necessary. This is the default. pam_password md5 # Hash password locally; required for University of # Michigan LDAP server, and works with Netscape # Directory Server if you're using the UNIX-Crypt # hash mechanism and not using the NT Synchronization # service. #pam_password crypt # Remove old password first, then update in # cleartext. Necessary for use with Novell # Directory Services (NDS) #pam_password nds # RACF is an alias for the above. For use with # IBM RACF #pam_password racf # Update Active Directory password, by # creating Unicode password and updating # unicodePwd attribute. #pam_password ad # Use the OpenLDAP password change # extended operation to update the password. #pam_password exop # Redirect users to a URL or somesuch on password # changes. #pam_password_prohibit_message Please visit http://internal to change your password. # RFC2307bis naming contexts # Syntax: # nss_base_XXX base?scope?filter # where scope is {base,one,sub} # and filter is a filter to be &'d with the # default filter. # You can omit the suffix eg: # nss_base_passwd ou=People, # to append the default base DN but this # may incur a small performance impact. nss_base_passwd ou=People,dc=csse,dc=uwa,dc=edu,dc=au nss_base_shadow ou=People,dc=csse,dc=uwa,dc=edu,dc=au nss_base_group ou=Group,dc=csse,dc=uwa,dc=edu,dc=au #nss_base_hosts ou=Hosts,dc=example,dc=com?one #nss_base_services ou=Services,dc=example,dc=com?one #nss_base_networks ou=Networks,dc=example,dc=com?one #nss_base_protocols ou=Protocols,dc=example,dc=com?one #nss_base_rpc ou=Rpc,dc=example,dc=com?one #nss_base_ethers ou=Ethers,dc=example,dc=com?one #nss_base_netmasks ou=Networks,dc=example,dc=com?ne #nss_base_bootparams ou=Ethers,dc=example,dc=com?one #nss_base_aliases ou=Aliases,dc=example,dc=com?one #nss_base_netgroup ou=Netgroup,dc=example,dc=com?one # attribute/objectclass mapping # Syntax: #nss_map_attribute rfc2307attribute mapped_attribute #nss_map_objectclass rfc2307objectclass mapped_objectclass # configure --enable-nds is no longer supported. # NDS mappings #nss_map_attribute uniqueMember member # Services for UNIX 3.5 mappings #nss_map_objectclass posixAccount User #nss_map_objectclass shadowAccount User #nss_map_attribute uid msSFU30Name #nss_map_attribute uniqueMember msSFU30PosixMember #nss_map_attribute userPassword msSFU30Password #nss_map_attribute homeDirectory msSFU30HomeDirectory #nss_map_attribute homeDirectory msSFUHomeDirectory #nss_map_objectclass posixGroup Group #pam_login_attribute msSFU30Name #pam_filter objectclass=User #pam_password ad # configure --enable-mssfu-schema is no longer supported. # Services for UNIX 2.0 mappings #nss_map_objectclass posixAccount User #nss_map_objectclass shadowAccount user #nss_map_attribute uid msSFUName #nss_map_attribute uniqueMember posixMember #nss_map_attribute userPassword msSFUPassword #nss_map_attribute homeDirectory msSFUHomeDirectory #nss_map_attribute shadowLastChange pwdLastSet #nss_map_objectclass posixGroup Group #nss_map_attribute cn msSFUName #pam_login_attribute msSFUName #pam_filter objectclass=User #pam_password ad # RFC 2307 (AD) mappings #nss_map_objectclass posixAccount user #nss_map_objectclass shadowAccount user #nss_map_attribute uid sAMAccountName #nss_map_attribute homeDirectory unixHomeDirectory #nss_map_attribute shadowLastChange pwdLastSet #nss_map_objectclass posixGroup group #nss_map_attribute uniqueMember member #pam_login_attribute sAMAccountName #pam_filter objectclass=User #pam_password ad # configure --enable-authpassword is no longer supported # AuthPassword mappings #nss_map_attribute userPassword authPassword # AIX SecureWay mappings #nss_map_objectclass posixAccount aixAccount #nss_base_passwd ou=aixaccount,?one #nss_map_attribute uid userName #nss_map_attribute gidNumber gid #nss_map_attribute uidNumber uid #nss_map_attribute userPassword passwordChar #nss_map_objectclass posixGroup aixAccessGroup #nss_base_group ou=aixgroup,?one #nss_map_attribute cn groupName #nss_map_attribute uniqueMember member #pam_login_attribute userName #pam_filter objectclass=aixAccount #pam_password clear # Netscape SDK LDAPS #ssl on # Netscape SDK SSL options # sslpath /etc/ssl/certs/cert7.db # OpenLDAP SSL mechanism # start_tls mechanism uses the normal LDAP port, LDAPS typically 636 # ssl no # OpenLDAP SSL options # Require and verify server certificate (yes/no) # Default is "no" # tls_checkpeer yes # CA certificates for server certificate verification # At least one of these are required if tls_checkpeer is "yes" # tls_cacertfile /etc/ssl/ca.cert # tls_cacertdir /etc/ssl/certs # Seed the PRNG if /dev/urandom is not provided #tls_randfile /var/run/egd-pool # SSL cipher suite # See man ciphers for syntax # tls_ciphers TLSv1 # Client certificate and key # Use these, if your server requires client authentication. #tls_cert #tls_key # Disable SASL security layers. This is needed for AD. #sasl_secprops maxssf=0 # Override the default Kerberos ticket cache location. #krb5_ccname FILE:/etc/.ldapcache # SASL mechanism for PAM authentication - use is experimental # at present and does not support password policy control # pam_sasl_mech DIGEST-MD5 # tls_cacertdir /etc/openldap/cacerts # pam_password md5 # ssl no # tls_cacertdir /etc/openldap/cacerts # ssl start_tls # tls_cacertdir /etc/openldap/cacerts # ssl no # tls_cacertdir /etc/openldap/cacerts Further Aspects: Automatically Mounting User's Home Directory We need to mount user's home directory when they login to a system and we try to manage our users as roaming users. Install following packages in all of your client system to enable this. Setup your server for NFS Exports In the Ubuntu server to which your have install Fedora-ds we need to export users home directories via NFS To install NFS server sudo apt-get install nfs-kernel-server To export the file system, setup /etc/exports. sudo vi /etc/exports Add the following code segment into the file. /ahome 10.0.0.0/24(rw,sync,root_squash) Export the file system sudo exportfs -arv Your output should look like: exporting 10.0.0.0/24:/ahome To veryfiy nfs exports sudo exportfs -v Output: /home 10.0.0.0/24(rw,wdelay,root_squash) Setting up clients for NFS and autofs To install nfs clients and autofs sudo apt-get install autofs nfs-common Setting autofs Create auto.ahome file. sudo vi /etc/auto.ahome Add the following code segment to this file. * -fstype=nfs,rw,hard,intr,rsize=2048,wsize=2048,nosuid,nfsvers=3 10.0.0.1:/ahome/& Create a mount point for auto homes sudo mkdir /ahome Add auto.home file to /etc/auto.master sudo vi /etc/auto.master Add the the following code segment to the above file /ahome /etc/auto.ahome --timeout=120 Restart autofs sudo /etc/init.d/autofs restart To test your setup login as fmaster Testing the Client #getent passwd < The output should show all the users added through the Directory Server Console in the Server side>
Type #id
12. Fedora DS SSL Configuration
Manual Method:
As I mentioned before, with Fedora Directory Server there are two components the Directory Server (LDAP backend) and Administration Server (remote Administration GUI interface). So we have to generate two sets of certificates one for secure Directory Server LDAP backend and one for the secure Administration Server connections. (You could use one certificate and share it between the two, but if one is compromise so is the other component)
If you don’t plan to use SSL connections you basically can skip this entire section.
You need to have openssl packages installed on your system before you can generate a certificate.
[root@jhett tmp]# rpm -qa |grep –i openssl
openssl-0.9.7f-7.10
openssl-devel-0.9.7f-7.10
openssl-perl-0.9.7f-7.10
These are the packages which are installed on my system. Now lets create the secure certificates I’ll create two directories one for Directory Server, and one for the Administration Server.
mkdir /tmp/ldap (Temp area for creating Directory Server backend certificates)
mkdir /tmp/admingui (Temp area for creating Admin Server certificates)
cd /tmp/ldap
Please note I’m only signing the certificates for 365 days, after that it will expire and you have to regenerate the certificates.
Generate your own Certificate Authority (CA) for LDAP Backend
[root@jhett ldap]# openssl genrsa -des3 -out ca.key 4096
Generating RSA private key, 4096 bit long modulus
................................................................................................................++
......................................++
e is 65537 (0x10001)
Enter pass phrase for ca.key:dspassword1
Verifying - Enter pass phrase for ca.key: dspassword1
[root@jhett ldap]# openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Enter pass phrase for ca.key: (Should be dspassword1)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:au
State or Province Name (full name) [Berkshire]:Western Australia
Locality Name (eg, city) [Newbury]:Perth
Organization Name (eg, company) [My Company Ltd]:UWA-DS
Organizational Unit Name (eg, section) []:CSSE-DS
Common Name (eg, your name or your server's hostname) []:jhett.csse.uwa.edu.au
Email Address []:support@csse.uwa.edu.au
Now you should of generated Certificate Authority File (ca.crt) and Certificate Authority Key File for LDAP Backend.
Generate a Server Key and request for Signing
[root@jhett ldap]# openssl genrsa -des3 -out server.key 4096
Generating RSA private key, 4096 bit long modulus
............................................................................................................................................................................................................................++
..................................................................................................++
e is 65537 (0x10001)
Enter pass phrase for server.key: dspassword2
Verifying - Enter pass phrase for server.key: dspassword2
[root@jhett admingui]# openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Enter pass phrase for ca.key: (dspassword2)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:au
State or Province Name (full name) [Berkshire]:Western Australia
Locality Name (eg, city) [Newbury]:Perth
Organization Name (eg, company) [My Company Ltd]:UWA-Admin
Organizational Unit Name (eg, section) []:CSSE-Admin
Common Name (eg, your name or your server's hostname) []:jhett.csse.uwa.edu.au
Email Address []:support@csse.uwa.edu.au
[root@jhett ldap]# openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key: (dspassword2)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:au
State or Province Name (full name) [Berkshire]:Western Australia
Locality Name (eg, city) [Newbury]:Perth
Organization Name (eg, company) [My Company Ltd]:UWA-DS-Server
Organizational Unit Name (eg, section) []:CSSE-DS-Server
Common Name (eg, your name or your server's hostname) []:jhett.csse.uwa.edu.au
Email Address []:support@csse.uwa.edu.au
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Sign the Certificate signing request that you’ve created with the self signed certificate authority for LDAP Backend.
[root@jhett ldap]# openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
Signature ok
subject=/C=au/ST=Western Australia/L=Perth/O=UWA-DS-Server/OU=CSSE-DS-Server/CN=jhett.csse.uwa.edu.au/emailAddress=support@csse.uwa.edu.au
Getting CA Private Key
Enter pass phrase for ca.key: (should be dspassword1)
That’s all the certificate files you will need for the Directory Server LDAP Backend, now you will need to generate the certificate files for Administration Server which is essentially the same process.
cd /tmp/admingui
pwd
/tmp/admin/gui
Generate your own Certificate Authority (CA) for Server Administration
[root@jhett admingui]# openssl genrsa -des3 -out ca.key 4096
Generating RSA private key, 4096 bit long modulus
......................................................................................++
.....................................................++
e is 65537 (0x10001)
Enter pass phrase for ca.key: adminpassword1
Verifying - Enter pass phrase for ca.key: adminpassword1
[root@jhett admingui]# openssl genrsa -des3 -out ca.key 4096
Generating RSA private key, 4096 bit long modulus
.............................++
..++
e is 65537 (0x10001)
Enter pass phrase for ca.key:
Verifying - Enter pass phrase for ca.key:
[root@jhett admingui]# openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Enter pass phrase for ca.key: (adminpassword1)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:au
State or Province Name (full name) [Berkshire]:Western Australia
Locality Name (eg, city) [Newbury]:Perth
Organization Name (eg, company) [My Company Ltd]:UWA-Admin
Organizational Unit Name (eg, section) []:CSSE-Admin
Common Name (eg, your name or your server's hostname) []:jhett.csse.uwa.edu.au
Email Address []:support@csse.uwa.edu.au
[root@jhett admingui]#
Now you should of generated Certificate Authority File (ca.crt) and Certificate Authority Key File (ca.key) for Administration Server.
Generate a Server Key and request for Signing
[root@jhett admingui]# openssl genrsa -des3 -out server.key 4096
Generating RSA private key, 4096 bit long modulus
.......++
....................................................++
e is 65537 (0x10001)
Enter pass phrase for server.key: (adminpassword2)
Verifying - Enter pass phrase for server.key: (adminpassword2)
[root@jhett admingui]# openssl req -new -key server.key -out server.csr
Enter pass phrase for server.key: (adminpassword2)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:au
State or Province Name (full name) [Berkshire]:Western Australia
Locality Name (eg, city) [Newbury]:Perth
Organization Name (eg, company) [My Company Ltd]:UWA-Admin-Server
Organizational Unit Name (eg, section) []:CSSE-Admin-Server
Common Name (eg, your name or your server's hostname) []:jhett.csse.uwa.edu.au
Email Address []:support@csse.uwa.edu.au
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Sign the Certificate signing request that you’ve created with the self signed certificate authority for Administration Server.
[root@jhett admingui]# openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
Signature ok
subject=/C=au/ST=Western Australia/L=Perth/O=UWA-Admin-Server/OU=CSSE-Admin-Server/CN=jhett.csse.uwa.edu.au/emailAddress=support@csse.uwa.edu.au
Getting CA Private Key
Enter pass phrase for ca.key: (adminpassword1)
Now we have basically generated two sets of self signed SSL certificates, one for Directory Server and the other for Administration Server. But these certificates needs to be converted to pkcs12 format for it to be used in the Fedora Directory Server. So we have to convert both sets to pkcs12 which then we can proceed to install the Fedora Directory Server.
[root@jhett ldap]# pwd
/tmp/ldap
[root@jhett ldap]# openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12 -name "DS-Server-Cert"
Enter pass phrase for server.key: (dspassword2)
Enter Export Password: (dspassword3)
Verifying - Enter Export Password: (dspassword3)
[root@jhett ldap]# pwd
[root@jhett ldap]# openssl pkcs12 -export -in ca.crt -inkey ca.key -out ca.p12 -name "DS-Cert"
Enter pass phrase for ca.key: (dspassword1)
Enter Export Password: (dspassword4)
Verifying - Enter Export Password: (dspassword4)
And similarly for Administration Server
[root@jhett admingui]# pwd
/tmp/admingui
[root@jhett admingui]# openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12 -name "Admin-Server-Cert"
Enter pass phrase for server.key: (adminpassword2)
Enter Export Password: (adminpassword3)
Verifying - Enter Export Password: (adminpassword3)
[root@jhett admingui]# openssl pkcs12 -export -in ca.crt -inkey ca.key -out ca.p12 -name "Admin-Cert"
Enter pass phrase for ca.key: (adminpassword1)
Enter Export Password: (adminpassword4)
Verifying - Enter Export Password: (adminpassword4)
Now basically you have your files in pkcs12 format which essentially contains the key and certificate in one file. Now don’t forget the export password or it will be next to useless. Now we can proceed to do Fedora Directory Server Installation
Figure 2 – Fedora Management Console
2.4 Importing SSL Certificates into Fedora Directory Server
Notice its states it not running Secure Connection, and its just allows the normal non-secure LDAP connection though default port of 389, normally secure LDAP connections are though port 636.
Now we are going to enable the SSL connections but to this, we have to import the SSL certificates for both Directory Server and Administration Server. Close the Fedora Management Console for now.
Basically there are two set of Database files which store the SSL certificate, one for Directory Server and one for the Administration Server. These database file are usually stored in /opt/fedora-ds/alias ie
[root@jhett alias]# pwd
/opt/fedora-ds/alias
[root@jhett alias]# ls -al
total 344
drwxr-xr-x 2 nobody nobody 4096 Jul 12 10:56 .
drwxr-xr-x 15 root root 4096 Jul 12 10:56 ..
-rwxr-xr-x 1 root nobody 235936 Mar 2 03:58 libnssckbi.so
-rw------- 1 nobody nobody 16384 Jul 12 10:56 secmod.db
-rw------- 1 nobody nobody 65536 Jul 12 10:56 slapd-jhett-cert8.db
-rw------- 1 nobody nobody 16384 Jul 12 10:56 slapd-jhett-key3.db
[root@jhett alias]#
As you can see only the LDAP backend slapd database file are initialise by default, for my piece of mind I usually re-initialise the db files for Directory and Administration Server.
Delete the LDAP backend database files and re-initialise them ie
[root@jhett alias]# cd /opt/fedora-ds/alias/
[root@jhett alias]# rm -rf *.db
[root@jhett alias]# ls -al
total 244
drwxr-xr-x 2 nobody nobody 4096 Jul 12 11:49 .
drwxr-xr-x 15 root root 4096 Jul 12 10:56 ..
-rwxr-xr-x 1 root nobody 235936 Mar 2 03:58 libnssckbi.so
Now I’ve delete it, run the startconsole command again from earlier, which you should see this again as show in Figure 3.
Figure 3 – Fedora Management Console
Under the domain, then your Directory Server machine, then server group there is a link for Administration Server. Double Click on Administration Server, it will bring you a new window such as that in Figure 4.
Figure 4 – Administration Server
Now to initialise the Admin Server Certificates database, click on console -> security -> Manager Certificates, it will then prompt you for a password to set for access the certificate (adminserverpw1), it should create a new database certificate set for Administration Server and it should be empty for Server Certs, Revoked Certs but there are some default Certificate Authorities for CA Certs. Close that Windows, and close the Administration Window.
Now similarly for the Directory Server on the Fedora Directory Management Console, double click on the Directory Server (Under the domain, then your Directory Server machine, then server group there is a link for Directory Server) which should look like in Figure 5.
Figure 5 – Directory Server
To initialise the Directory Server Certificates database, click on console -> security -> Manager Certificates, it will then prompt you for a password to set for access the certificate (directoryserverpw1), it should create a new database certificate set for Directory Server and it should be empty for Server Certs, Revoked Certs but there are some default Certificate Authorities for CA Certs just like the Administration. Close that Windows, and close the Directory Server Window.
You can verify that the Certificate Database has been created by going to the /opt/fedora-ds/alias. As you can see, before there was only one file now its populated with several .db files for the Directory Server Components ie.
[root@jhett alias]# cd /opt/fedora-ds/alias
[root@jhett alias]# pwd
/opt/fedora-ds/alias
[root@jhett alias]# ls -al
total 428
drwxr-xr-x 2 nobody nobody 4096 Jul 12 13:26 .
drwxr-xr-x 15 root root 4096 Jul 12 10:56 ..
-rw------- 1 nobody nobody 65536 Jul 12 12:06 admin-serv-jhett-cert8.db
-rw------- 1 nobody nobody 16384 Jul 12 12:11 admin-serv-jhett-key3.db
-rwxr-xr-x 1 root nobody 235936 Mar 2 03:58 libnssckbi.so
-rw------- 1 nobody nobody 16384 Jul 12 12:06 secmod.db
-rw------- 1 nobody nobody 65536 Jul 12 13:26 slapd-jhett-cert8.db
-rw------- 1 nobody nobody 16384 Jul 12 13:30 slapd-jhett-key3.db
[root@jhett alias]#
Directory Server comprises of slapd-jhett-cert8.db and slapd-jhett-key3.db, where Admin Server comprises of admin-serv-jhett-cert8.db and admin-serv-jhett-key3.db.
Now we have to import Secure Certificates we created earlier, we will import pkcs12 format of keys into database base file fro Directory Server and Admin Server by using the pk12util provided by the Fedora Directory Server.
The general command layout is shown below.
root@jhett bin]# pwd
/opt/fedora-ds/shared/bin
[root@jhett bin]# ./pk12util
Usage: pk12util-bin -i importfile [-d certdir] [-P dbprefix] [-h tokenname]
[-k slotpwfile | -K slotpw] [-w p12filepwfile | -W p12filepw]
[-v]
Usage: pk12util-bin -l listfile [-d certdir] [-P dbprefix] [-h tokenname]
[-k slotpwfile | -K slotpw] [-w p12filepwfile | -W p12filepw]
Usage: pk12util-bin -o exportfile -n certname [-d certdir] [-P dbprefix]
[-k slotpwfile | -K slotpw] [-w p12filepwfile | -W p12filepw]
[-v]
(Note the relatively where you execute the command when using the –d switch and check the prefix name of the db files when using the –p switch)
Now I’m going to insert the pkcs12 converted keys we generated earlier for Directory Server and Administration Server both into Certificate Database for Admin Server and Directory Server ie (Noticed that the files created are associated with your hostname of your machine so change it appropriately)
[root@jhett fedora-ds]# cd /opt/fedora-ds
[root@jhett fedora-ds]# pwd
/opt/fedora-ds
[root@jhett fedora-ds]# /opt/fedora-ds/shared/bin/pk12util -i /tmp/ldap/server.p12 -d alias -P admin-serv-jhett-
Enter Password or Pin for "NSS Certificate DB": (adminserverpw1)
Enter password for PKCS12 file: (dspassword4)
pk12util-bin: PKCS12 IMPORT SUCCESSFUL
[root@jhett fedora-ds]# /opt/fedora-ds/shared/bin/pk12util -i /tmp/admingui/server.p12 -d alias -P admin-serv-jhett-
Enter Password or Pin for "NSS Certificate DB": (adminserverpw1)
Enter password for PKCS12 file: (adminpassword4)
pk12util-bin: PKCS12 IMPORT SUCCESSFUL
[root@jhett fedora-ds]# /opt/fedora-ds/shared/bin/pk12util -i /tmp/admingui/server.p12 -d alias -P slapd-jhett-
Enter Password or Pin for "NSS Certificate DB": (directoryserverpw1)
Enter password for PKCS12 file: (adminpassword4)
pk12util-bin: PKCS12 IMPORT SUCCESSFUL
[root@jhett fedora-ds]# /opt/fedora-ds/shared/bin/pk12util -i /tmp/ldap/server.p12 -d alias -P slapd-jhett-
Enter Password or Pin for "NSS Certificate DB": (directoryserverpw1)
Enter password for PKCS12 file: (dspassword4)
pk12util-bin: PKCS12 IMPORT SUCCESSFUL
Now lets verify if the Certificate is imported, relaunch the console by running the startconsole command again.
Check the Administration Server, double click on it and then again click
console -> security -> Manager Certificates which again should be similar to Figure 6.
Figure 6 – Admin Server Certificate Manager
As you can see the Certificates we created earlier is imported into the Certificate Manager for Administration Server.
Now let us check the Directory Server, double click on it and then again click
console -> security -> Manager Certificates which you can see in Figure 7.
Figure 7 - Directory Server Certificate Manager
As you can see the Certificates we created earlier, is imported into the Certificate Manager for Directory Server.
Now although the certificate is imported they are not valid, so the Directory Server will not use it. You can verify the certificate is not valid on either the Directory Server or Admin Server by doing this.
Lets check the Directory Server, double click on it and then again click
console -> security -> Manager Certificates
or similarly
Lets check the Administration Server, double click on it and then again click
console->security->Manager Certificates
But if you look at the Server Certs, and click on any of the imported certificates you created, click detail. Now if you click under general, you will see that the certificate is has not been verified for any type of use and if you click on Certification Path, you will see it says “BROKEN_CERTIFICATE_CHAIN” as in Figure 8.
Figure 8 – NonValid Certificates
Now we have to make the Certificates we imported for the Directory Server and Administration Server valid. To do this all we have to import the Certificate Authority we created earlier for the two sets of certificates for Directory Server and Administration Server.
Lets make the Certificates imported into the Administration Server valid. To do this we run the startconsole and double click on the Administration Server, bringing up a new window. Click console -> Security -> Manage certificates.
Then click on CA Certs, and click install, you should see something similar to this in Figure 9.
Figure 9 – Step 1 of 4 Certificate Location
To make the Secure Certificates set generated for the Directory Server valid(Was generated/stored in /tmp/ldap), we need to install the Certificate Authority (/tmp/ldap/ca.crt) file that we generated for that set. Similary for the Secure Certificate set generated for the Administration Server (generated/stored in /tmp/admingui/ca.crt) we need to install the Certificate Authority (/tmp/admingui/ca.crt) to make that set valid.
In saying that, later we need to install the certificates for the Directory Server Set sy repeating the process of installing, by pointing the Certificate location for /tmp/ldap/ca.crt.
Now as we click next, you should see Figure 10.
Figure 10 - Step 2 of 4 Certificate Information
We click next again, you should see this in Figure 11
Figure 11 - Step 3 of 4 Certificate Install Wizard
Finally the last step, we click next and you should see this as in Figure 12.
Figure 12 - Step 4 of 4 Intended Purpose
Make sure you have both options ticked for Client Authentication and Server Authentication. (We can always un-tick it later), then click done. You should now see your CA certificate that you have imported appear under “CA Certs” tab.
Now if I click details on any Certificate Authority files we imported, you will see that it has all the details we put earlier when we generated the Certificates.
Now as you can see in Figure 13, in this particular case we are examining the Certificate Authority for Secure Certificate set of the Directory Server.
Figure 13 – Directory Server Certificate Authority File “Detail” tab
Now if we clicked on the “Server Certs” tab and re-examine the Server Cert generated for the Directory Server Set which is called DS-Server-Cert and click on detail and select the general tab. We can see now that the certificate is valid for SSL Server and Client use where as before it was not valid for any use as in Figure 14.
Figure 14 – Directory Server Certificate “General” tab
Similarly if we click on the Certification path it is no longer has a broken certificate chain as in Figure 15.
Figure 15 – Directory Server Certificate “Certification Path” tab
Now you have to repeat this process to import the Certificate Authority to make the existing SSL certificates imported into the Directory Server / Admin Server valid this is dependent on which Certificate Authority file was signed off with.
Ie import
/tmp/ldap/ca.crt. -> Import in to Directory Server
/tmp/ldap/ca.crt. -> Import in to Administration Server
/tmp/admingui/ca.crt. -> Import in to Directory Server
/tmp/admingui/ca.crt. -> Import in to Administration Server
Now once you’ve imported , verify that the Certificates in your Server Certificate for Directory Server and Administration Server are valid. Once you have done that, I would recommend again you to do a backup of it.
tar cpfz /opt/fedora-ds.backup.sslimported.tgz /opt/fedora-ds
This is important, as if you screw up configuring the SSL, it may fail to come up. You can always restore it instead of redoing the steps from the instructions prior.
2.5 Configuring SSL on the Fedora Directory Server
Now we are going to configure SSL for the Directory Server and Administration Server, lets enable the SSL encryption connection for the Administration Server.
At the Fedora Management Console, double click on the Administration Server, click on configuration tab, then select encryption. Check the box for “Enable SSL for this server”, check the box “use the cipher family: RSA,” then pick the appropriate Certificate to use for encryption. In this case since it is the Administration Server, we should pick Admin-Server-Cert such as in Figure 16.
Figure 16 – Administration Server “Encryption” Tab
Similarly for the Directory Server, double click on the Directory Server at the Fedora Management Console, click on configuration tab, then select encryption. Check the box for “Enable SSL for this server”, check the box “use the cipher family: RSA”, then pick the appropriate Certificate to use for encryption which is DS-Server-Cert as show below
in Figure 17.
Figure 17 – Directory Server Encryption Settings
Once you’ve done that, the Directory Server indicates now LDAP connections on port 389 and LDAPs (Secure LDAP) connections on port 636.
Now we have enabled the encryption for the Directory Server and the Administration Server. We have to restart the service for both of them to enable the secure SSL connections.
/opt/fedora-ds/slapd-jhett/restart-slapd (To restart Directory Server)
/opt/fedora-ds/restart-admin (To restart Administration Server Server)
Now you would of noticed if you ever restarted the Directory and Administration Server any point in time prior to the SSL being enabled, you would not of been asked a password. After SSL is enabled to start and restart the service you need to enter the password to access the keys which you’ve imported previously ie adminserverpw1 for Administration Server and directoryserverpw1 for the Directory Server.
After restarting the services, the Administration Server, now can be bound via SSL connections and the LDAP can be connected via normal LDAP and Secure LDAP connections.
But currently the Administration Server is binding to the Directory Server via LDAP and not LDAPs. Now we have to rebind the Administration Server via LDAPs to the Directory Server.
Note when you run startconsole, because now you have made the Administration Server use SSL, you have to change the administration URL from http to https such as shown in Figure 18 to successfully login.
Figure 18 – Fedora Management Console Login via HTTPs
In the Fedora Management Console, double click on the Administration Server, now click on the configuration tab of the Administration Server, then select User DS tab, then configure the user DS.
LDAP Host and port: jhett.csse.uwa.edu.au:636
Enable Secure Connection
User Directory Subtree: dc=csse,dc=uwa,dc=edu,dc=au
Bind DN: cn=Directory Manager (Administrator Account used to change details)
Bind Password: XXXXXXXX
As shown in Figure 19
Figure 19 – Administration Server “User DS” configeration
Now basically save it quit the Administration Server, and quit Directory Server (If opened) and the Fedora Management console. Now again we have to restart the Admin Server.
/opt/fedora-ds/restart-admin (Enter your password to access its secure certificates), verify its still working ie by running the startconsole command and try logging in which should work.
Note that you only have a partial SSL connection between the Administration Server and the Directory Server. Now at the Fedora Console Management, run the Administration Server, click on the configuration tab then the configuration DS. Enable the Secure Connection which should swap it from port 389 to 636 and click save. Again quit the Administration Server, Directory Server (If opened) and the Fedora Management console and restart the Admin Server.
/opt/fedora-ds/restart-admin
Again run the startconsole command, if you check the configuration tabs for the administration server all options are checked for SSL its binding via LDAPs.
That’s Basically it, to installing and configuring a Fedora Directory LDAP server for LDAP and LDAPs connections.
2.6) Fedora Directory Server - Points of Interest & Bugs
Now if you have an Fedora Directory Server working normally via LDAP but as soon as you switch to bind via LDAPs and fails it was a bug with Fedora Directory Server, but it should have been rectified see this.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175170
Before you starting creating users, groups etc in your LDAP directory it’s a good idea to take a backup of it. As I’ve mentioned several times over, the Fedora Directory Server is self contained all you have to do is take a copy of the Directory /opt/fedora-ds ie such as creating a tar ball. All you have to do is basically stop the Directoy Server/ Administarion Server delete /opt/fedora-ds and untar the backup.
If you have problems don’t be afraid to check the logs. The Directory Server stores its logs /opt/fedora-ds/slapd-jhett/logs (Relative to your machine hostname). Ie if I wanted to see if the Directory Server is accepting both LDAP and LDAPs connection.
[root@jhett logs]# pwd
/opt/fedora-ds/slapd-jhett/logs
[root@jhett logs]# cat errors
Fedora-Directory/1.0.2 B2006.060.1951
jhett.csse.uwa.edu.au:636 (/opt/fedora-ds/slapd-jhett)
[14/Jul/2006:11:23:13 +0800] - Fedora-Directory/1.0.2 B2006.060.1951 starting up
[14/Jul/2006:11:23:15 +0800] - slapd started. Listening on All Interfaces port 389 for LDAP requests
[14/Jul/2006:11:23:15 +0800] - Listening on All Interfaces port 636 for LDAPS requests
As you can see its binded to port 636 for LDAPs and 389 for LDAP connection etc. Similarly for Administration Server logs are keep in /opt/fedora-ds/admin-server/logs.
3.1 Configuring Password Policy
The common password format that works on all platforms is common crypt hash method, so before creating users on the system. I would force all users password to be stored in the crypt format thus if the machine be it linux / unix, windows or a Mac OSX binded to the LDAP directory the authentication will work.
And doing this even older machines ie such as Unix variants like Tru64 which does not support LDAP you can generate a NIS mappings from your LDAP server and bind it via NIS (Known as YP or formerly Yellow Pages).
To do this run, the Fedora Management Console, Launch the Directory Server. What we are going to do is set a Managed Password Policy for all Users in the LDAP Directory.
Now Click on the Directory tab, expand config, right click on plugins and select managed Password Policy and select For User which you should see something like this as show in Figure 20.
Figure 20 – Directory Server “User Password Policy”
Under the Passwords Tab, enable Create user level password policy. The one I’m most interested in is the Password Syntax. Enable the Check password syntax and for the encryption method select Unix crypt algorithm (CRYPT) and click save. You might want to change the Password syntax like character length, its also worth taking a look at account lockout if you want to lock accounts out if there is to many bad attempts.
From now on all accounts password will be stored in the Directory Server as a CRYPT format.
3.2 Binding Linux/Unix Machines to LDAP
The client system I’m using to bind to the LDAP directory is Fedora Core 4 system. Which is pretty straight forward, if you want to bind just via LDAP. Run the command setup and select Authentication configuration such as shown below in Figure 21
Figure 21 – Fedora Setup tools
Now you will be prompted now for how it will Authenticate, which you choose LDAP, Authentication all you really need is “Use LDAP authentication”, but I also have local users on the machine which use MD5 Passwords and Shadow passwords so I check those as well as shown in Figure 22.
Figure 22 – Authentication Configuration
Now it will ask you details about your LDAP Server settings. In my example the server is jhett.csse.uwa.edu.au and the Base DN is dc=csse,dc=uwa,dc=edu,dc=au
You only tick TLS if you have SSL enabled on your server as shown in figure 23(We are not enabling the LDAP connection for the moment, LDAPs involves more work which requires manual intervention)
Figure 23 – LDAP Settings
If you unchecked TLS that’s fine. Your machine will only connect via normal LDAP connections and not LDAPs.
Else if you’ve checked TLS you will need to do further configuration to enable it to connect via LDAPs which are not enabled in the RedHat menu configuration which you have to do manually.
You probably asked what happens if I’m not using a RedHat Enterprise or RedHat Fedora Core distribution so I don’t have the authentification menu to do my configurations.
That’s okay read the next section which will detail what configurations files are modified to get LDAPs working which incidently tell you also what files to modify to get LDAP working as well.
This should work just about on any Linux/Unix configurations as the authentication menu will only really do the basic things, the more complex LDAPs requires all user to manually configure it.
3.3 Binding Linux/Unix Machines to LDAPs
First of all for your client LDAP machine to connect via LDAPs you need to have the Certificate Authority file installed on your client which was generated for the Directory Server to allow it to recognize that the SSL connection is valid.
So on your client lets you have to copy the file /tmp/ldap/ca.crt on the Fedora Direcotry server in my case the machine as called jhett.csse.uwa.edu.au . I’ll copy ca.crt onto my local machine into /etc/cert/ca.crt.
Now we have the Certificate Authority file stored locally on the client machine, now we have to tell the machine to use LDAP.
Previously you saw me using the setup then running the authentification menu to configure for LDAP. One of the files that authentification GUI menu edits for you is /etc/nsswitch.conf which governs several things one is the authentification lookup method, the field headings in this file is password, shadow and group.
For those who don’t have that GUI edit this file and change the field for password, shadow and group. You can also incorporate over services lookup from LDAP but that’s another story for another day.
[root@jhett etc]# pwd
/etc
[root@jhett etc]# cat nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
# nisplus or nis+ Use NIS+ (NIS version 3)
# nis or yp Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# db Use the local database (.db) files
# compat Use NIS on compat mode
# hesiod Use Hesiod for user lookups
# [NOTFOUND=return] Stop searching if not found so far
#
# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd: db files nisplus nis
#shadow: db files nisplus nis
#group: db files nisplus nis
passwd: files ldap
shadow: files ldap
group: files ldap
#hosts: db files nisplus nis dns
hosts: files dns
# Example - obey only what nisplus tells us...
#services: nisplus [NOTFOUND=return] files
#networks: nisplus [NOTFOUND=return] files
#protocols: nisplus [NOTFOUND=return] files
#rpc: nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks: nisplus [NOTFOUND=return] files
#bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files ldap
rpc: files
services: files ldap
netgroup: files ldap
#publickey: nisplus
automount: files ldap
aliases: files nis
Editing nsswitch.conf now tell your machine to use LDAP after it fails the local user accounts on the local machine. But you still have to tell the LDAP machine where to use SSL certificates and which LDAP server etc. The other file which the authentification GUI edit is /etc/ldap.conf (Some distribution store it in /etc/openldap/ldap.comf but neverless you just need to locate it and edit it)
The fields that we are interested in are host, base, nss_base_passwd, nss_base_shadow, nss_base_group, tls_cacertfile, tls_cacertdir and ssl which are in bold as indicated below.
The mapping between for nss_base_passwd, nss_base_shadow and nss_base_group shown in my configuration file are the default Fedora Directory Schema, you can remap them accordingly if you choose to change the schema along with other values you place in your LDAP.
[root@jhett etc]# cd /etc
[root@jhett etc]# pwd
/etc
[root@jhett etc]# cat ldap.conf
# @(#)$Id: ldap.conf,v 1.34 2004/09/16 23:32:02 lukeh Exp $
#
# This is the configuration file for the LDAP nameservice
# switch library and the LDAP PAM module.
#
# PADL Software
# http://www.padl.com
#
# Your LDAP server. Must be resolvable without using LDAP.
# Multiple hosts may be specified, each separated by a
# space. How long nss_ldap takes to failover depends on
# whether your LDAP client library supports configurable
# network or connect timeouts (see bind_timelimit).
host pe.im.logica.com
# The distinguished name of the search base.
base dc=pe,dc=im,dc=logica,dc=com
# Another way to specify your LDAP server is to provide an
# uri with the server name. This allows to use
# Unix Domain Sockets to connect to a local LDAP Server.
#uri ldap://127.0.0.1/
#uri ldaps://127.0.0.1/
#uri ldapi://%2fvar%2frun%2fldapi_sock/
# Note: %2f encodes the '/' used as directory separator
# The LDAP version to use (defaults to 3
# if supported by client library)
#ldap_version 3
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
#binddn cn=proxyuser,dc=example,dc=com
# The credentials to bind with.
# Optional: default is no credential.
#bindpw secret
# The distinguished name to bind to the server with
# if the effective user ID is root. Password is
# stored in /etc/ldap.secret (mode 600)
#rootbinddn cn=manager,dc=example,dc=com
# The port.
# Optional: default is 389.
# port 389
# The search scope.
#scope sub
#scope one
#scope base
# Search timelimit
#timelimit 30
# Bind/connect timelimit
#bind_timelimit 30
# Reconnect policy: hard (default) will retry connecting to
# the software with exponential backoff, soft will fail
# immediately.
#bind_policy hard
# Idle timelimit; client will close connections
# (nss_ldap only) if the server has not been contacted
# for the number of seconds specified below.
#idle_timelimit 3600
# Filter to AND with uid=%s
#pam_filter objectclass=account
# The user ID attribute (defaults to uid)
#pam_login_attribute uid
# Search the root DSE for the password policy (works
# with Netscape Directory Server)
#pam_lookup_policy yes
# Check the 'host' attribute for access control
# Default is no; if set to yes, and user has no
# value for the host attribute, and pam_ldap is
# configured for account management (authorization)
# then the user will not be allowed to login.
#pam_check_host_attr yes
# Check the 'authorizedService' attribute for access
# control
# Default is no; if set to yes, and the user has no
# value for the authorizedService attribute, and
# pam_ldap is configured for account management
# (authorization) then the user will not be allowed
# to login.
#pam_check_service_attr yes
# Group to enforce membership of
#pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com
# Group member attribute
#pam_member_attribute uniquemember
# Specify a minium or maximum UID number allowed
#pam_min_uid 0
#pam_max_uid 0
# Template login attribute, default template user
# (can be overriden by value of former attribute
# in user's entry)
#pam_login_attribute userPrincipalName
#pam_template_login_attribute uid
#pam_template_login nobody
# HEADS UP: the pam_crypt, pam_nds_passwd,
# and pam_ad_passwd options are no
# longer supported.
#
# If you are using XAD, you can set pam_password
# to racf, ad, or exop. Make sure that you have
# SSL enabled.
# Do not hash the password at all; presume
# the directory server will do it, if
# necessary. This is the default.
# pam_password clear
# Hash password locally; required for University of
# Michigan LDAP server, and works with Netscape
# Directory Server if you're using the UNIX-Crypt
# hash mechanism and not using the NT Synchronization
# service.
# pam_password md5
# Remove old password first, then update in
# cleartext. Necessary for use with Novell
# Directory Services (NDS)
# pam_password nds
# RACF is an alias for the above. For use with
# IBM RACF
# pam_password racf
# Update Active Directory password, by
# creating Unicode password and updating
# unicodePwd attribute.
# pam_password ad
# Use the OpenLDAP password change
# extended operation to update the password.
# pam_password exop
# Redirect users to a URL or somesuch on password
# changes.
#pam_password_prohibit_message Please visit http://internal to change your password.
# RFC2307bis naming contexts
# Syntax:
# nss_base_XXX base?scope?filter
# where scope is {base,one,sub}
# and filter is a filter to be &'d with the
# default filter.
# You can omit the suffix eg:
# nss_base_passwd ou=People,
# to append the default base DN but this
# may incur a small performance impact.
#nss_base_passwd ou=People,dc=example,dc=com?one
nss_base_passwd ou=People,dc=im,dc=logica,dc=com
#nss_base_shadow ou=People,dc=example,dc=com?one
nss_base_shadow ou=People,dc=im,dc=logica,dc=com
#nss_base_group ou=Group,dc=example,dc=com?on
nss_base_group ou=Groups,dc=im,dc=logica,dc=com
#nss_base_hosts ou=Hosts,dc=example,dc=com?one
#nss_base_services ou=Services,dc=example,dc=com?one
#nss_base_networks ou=Networks,dc=example,dc=com?one
#nss_base_protocols ou=Protocols,dc=example,dc=com?one
#nss_base_rpc ou=Rpc,dc=example,dc=com?one
#nss_base_ethers ou=Ethers,dc=example,dc=com?one
#nss_base_netmasks ou=Networks,dc=example,dc=com?ne
#nss_base_bootparams ou=Ethers,dc=example,dc=com?one
#nss_base_aliases ou=Aliases,dc=example,dc=com?one
#nss_base_netgroup ou=Netgroup,dc=example,dc=com?one
# attribute/objectclass mapping
# Syntax:
#nss_map_attribute rfc2307attribute mapped_attribute
#nss_map_objectclass rfc2307objectclass mapped_objectclass
# configure --enable-nds is no longer supported.
# NDS mappings
#nss_map_attribute uniqueMember member
# Services for UNIX 3.5 mappings
#nss_map_objectclass posixAccount User
#nss_map_objectclass shadowAccount User
#nss_map_attribute uid msSFU30Name
#nss_map_attribute uniqueMember msSFU30PosixMember
#nss_map_attribute userPassword msSFU30Password
#nss_map_attribute homeDirectory msSFU30HomeDirectory
#nss_map_attribute homeDirectory msSFUHomeDirectory
#nss_map_objectclass posixGroup Group
#pam_login_attribute msSFU30Name
#pam_filter objectclass=User
#pam_password ad
# configure --enable-mssfu-schema is no longer supported.
# Services for UNIX 2.0 mappings
#nss_map_objectclass posixAccount User
#nss_map_objectclass shadowAccount user
#nss_map_attribute uid msSFUName
#nss_map_attribute uniqueMember posixMember
#nss_map_attribute userPassword msSFUPassword
#nss_map_attribute homeDirectory msSFUHomeDirectory
#nss_map_attribute shadowLastChange pwdLastSet
#nss_map_objectclass posixGroup Group
#nss_map_attribute cn msSFUName
#pam_login_attribute msSFUName
#pam_filter objectclass=User
#pam_password ad
# RFC 2307 (AD) mappings
#nss_map_objectclass posixAccount user
#nss_map_objectclass shadowAccount user
#nss_map_attribute uid sAMAccountName
#nss_map_attribute homeDirectory unixHomeDirectory
#nss_map_attribute shadowLastChange pwdLastSet
#nss_map_objectclass posixGroup group
#nss_map_attribute uniqueMember member
#pam_login_attribute sAMAccountName
#pam_filter objectclass=User
#pam_password ad
# configure --enable-authpassword is no longer supported
# AuthPassword mappings
#nss_map_attribute userPassword authPassword
# AIX SecureWay mappings
#nss_map_objectclass posixAccount aixAccount
#nss_base_passwd ou=aixaccount,?one
#nss_map_attribute uid userName
#nss_map_attribute gidNumber gid
#nss_map_attribute uidNumber uid
#nss_map_attribute userPassword passwordChar
#nss_map_objectclass posixGroup aixAccessGroup
#nss_base_group ou=aixgroup,?one
#nss_map_attribute cn groupName
#nss_map_attribute uniqueMember member
#pam_login_attribute userName
#pam_filter objectclass=aixAccount
#pam_password clear
# Netscape SDK LDAPS
#ssl on
# Netscape SDK SSL options
#sslpath /etc/ssl/certs/cert7.db
# OpenLDAP SSL mechanism
# start_tls mechanism uses the normal LDAP port, LDAPS typically 636
#ssl start_tls
#ssl on
# OpenLDAP SSL options
# Require and verify server certificate (yes/no)
# Default is "no"
#tls_checkpeer yes
# CA certificates for server certificate verification
# At least one of these are required if tls_checkpeer is "yes"
#tls_cacertfile /etc/ssl/ca.cert
#tls_cacertdir /etc/ssl/certs
tls_cacertfile /etc/cacerts/ca.crt
tls_cacertdir /etc/cacerts
# Seed the PRNG if /dev/urandom is not provided
#tls_randfile /var/run/egd-pool
# SSL cipher suite
# See man ciphers for syntax
#tls_ciphers TLSv1
# Client certificate and key
# Use these, if your server requires client authentication.
#tls_cert
#tls_key
# Disable SASL security layers. This is needed for AD.
#sasl_secprops maxssf=0
# Override the default Kerberos ticket cache location.
#krb5_ccname FILE:/etc/.ldapcache
# SASL mechanism for PAM authentication - use is experimental
# at present and does not support password policy control
#pam_sasl_mech DIGEST-MD5
ssl start_tls
ssl on
That’s basically it, there was only one other problem that I cam across. Normal users don’t have the necessary previledges to do the look up in the LDAP information although they authenticated.
Ie when a user logs in, there is an error message saying something like this
id:cannot find name for user ID 10001
id:cannot find name for group ID 1002
id:cannot find name for group ID 1003
id:cannot find name for group ID 1003
This is solved by switching on nscd (You can turn nscd by running setup, select system services and turn on nscd). The service nscd binds as root but caches the information for the user.
Method II :
A script called setupssl can automatically configure SSL on the Linux machine.
#!/bin/sh
if [ "$1" -a -d "$1" ] ; then
echo "Using $1 as alias directory"
else
sroot=/opt/fedora-ds
cd $sroot/alias
fi
if [ "$2" ] ; then
ldapport=$2
else
ldapport=389
fi
me=`whoami`
if [ "$me" = "root" ] ; then
isroot=1
fi
# see if there are already certs and keys
prefix=`ls -1 slapd-*-cert8.db | head -1 | sed -e s/cert8.db\$//`
if [ -f ${prefix}cert8.db ] ; then
# look for CA cert
if test -n "$prefix" ; then
prefixarg="-P $prefix"
fi
if ../shared/bin/certutil -L $prefixarg -d . -n "CA certificate" 2> /dev/null ; then
echo "Using existing CA certificate"
else
echo "No CA certificate found - will create new one"
needCA=1
fi
# look for server cert
if ../shared/bin/certutil -L $prefixarg -d . -n "Server-Cert" 2> /dev/null ; then
echo "Using existing directory Server-Cert"
else
echo "No Server Cert found - will create new one"
needServerCert=1
fi
# look for admin server cert
if ../shared/bin/certutil -L $prefixarg -d . -n "server-cert" 2> /dev/null ; then
echo "Using existing admin server-cert"
else
echo "No Admin Server Cert found - will create new one"
needASCert=1
fi
fi
if test -z "$needCA" -a -z "$needServerCert" -a -z "$needASCert" ; then
echo "No certs needed - exiting"
exit 0
fi
# get our user and group
if test -n "$isroot" ; then
uid=`/bin/ls -ald . | awk '{print $3}'`
gid=`/bin/ls -ald . | awk '{print $4}'`
fi
# 2. Create a password file for your security token password:
if [ -f pwdfile.txt ] ; then
echo "Using existing pwdfile.txt"
else
echo "Creating password file for security token"
(ps -ef ; w ) | sha1sum | awk '{print $1}' > pwdfile.txt
if test -n "$isroot" ; then
chown $uid:$gid pwdfile.txt
fi
chmod 400 pwdfile.txt
fi
# 3. Create a "noise" file for your encryption mechanism:
if [ -f noise.txt ] ; then
echo "Using existing noise.txt file"
else
echo "Creating noise file"
(w ; ps -ef ; date ) | sha1sum | awk '{print $1}' > noise.txt
if test -n "$isroot" ; then
chown $uid:$gid noise.txt
fi
chmod 400 noise.txt
fi
# 4. Create the key3.db and cert8.db databases:
if [ ! -f cert8.db ] ; then
echo "Creating initial key and cert db"
../shared/bin/certutil -N -d . -f pwdfile.txt
if test -n "$isroot" ; then
chown $uid:$gid key3.db cert8.db
fi
chmod 600 key3.db cert8.db
fi
if test -n "$needCA" ; then
# 5. Generate the encryption key:
echo "Creating encryption key for CA"
../shared/bin/certutil -G -d . -z noise.txt -f pwdfile.txt
# 6. Generate the self-signed certificate:
echo "Creating self-signed CA certificate"
../shared/bin/certutil -S -n "CA certificate" -s "cn=CAcert" -x -t "CT,," -m 1000 -v 120 -d . -z noise.txt -f pwdfile.txt
# export the CA cert for use with other apps
echo Exporting the CA certificate to cacert.asc
../shared/bin/certutil -L -d . -n "CA certificate" -a > cacert.asc
fi
if test -n "$needServerCert" ; then
# 7. Generate the server certificate:
myhost=`hostname --fqdn`
echo "Generating server certificate for Fedora Directory Server on host $myhost"
echo Using fully qualified hostname $myhost for the server name in the server cert subject DN
echo Note: If you do not want to use this hostname, edit this script to change myhost to the
echo real hostname you want to use
../shared/bin/certutil -S -n "Server-Cert" -s "cn=$myhost,ou=Fedora Directory Server" -c "CA certificate" -t "u,u,u" -m 1001 -v 120 -d . -z noise.txt -f pwdfile.txt
fi
if test -n "$needASCert" ; then
# Generate the admin server certificate
echo Creating the admin server certificate
../shared/bin/certutil -S -n "server-cert" -s "cn=$myhost,ou=Fedora Administration Server" -c "CA certificate" -t "u,u,u" -m 1002 -v 120 -d . -z noise.txt -f pwdfile.txt
# export the admin server certificate/private key for import into its key/cert db
echo Exporting the admin server certificate pk12 file
../shared/bin/pk12util -d . -o adminserver.p12 -n server-cert -w pwdfile.txt -k pwdfile.txt
if test -n "$isroot" ; then
chown $uid:$gid adminserver.p12
fi
chmod 400 adminserver.p12
fi
if test -n "$prefix" ; then
# Copy the key3.db and cert8.db you created to the default databases created at Directory Server installation:
# assume there is already the default empty key and cert db for the directory instance
echo Creating real key and cert db for directory server
keydb=`ls -1 slapd-*-key3.db | head -1`
certdb=`ls -1 slapd-*-cert8.db | head -1`
# backup the old one, just in case
mv $keydb $keydb.bak
mv $certdb $certdb.bak
# move over the new ones
mv key3.db $keydb
mv cert8.db $certdb
fi
# create the pin file
if [ ! -f ${prefix}pin.txt ] ; then
echo Creating pin file for directory server
pinfile=`echo $keydb | sed -e s/key3.db/pin.txt/`
echo 'Internal (Software) Token:'`cat pwdfile.txt` > $pinfile
if test -n "$isroot" ; then
chown $uid:$gid $pinfile
fi
chmod 400 $pinfile
else
echo Using existing ${prefix}pin.txt
fi
# create the admin server key/cert db
asprefix=`echo $prefix | sed -e s/slapd/admin-serv/`
if [ ! -f ${asprefix}cert8.db ] ; then
echo Creating key and cert db for admin server $asprefix
../shared/bin/certutil -N -d . -P $asprefix -f pwdfile.txt
if test -n "$isroot" ; then
chown $uid:$gid admin-serv-*.db
fi
chmod 600 admin-serv-*.db
fi
if test -n "$needASCert" ; then
# import the admin server key/cert
echo "Importing the admin server key and cert (created above)"
../shared/bin/pk12util -d . -P $asprefix -n server-cert -i adminserver.p12 -w pwdfile.txt -k pwdfile.txt
# import the CA cert to the admin server cert db
echo Importing the CA certificate from cacert.asc
../shared/bin/certutil -A -d . -P $asprefix -n "CA certificate" -t "CT,," -a -i cacert.asc
fi
if [ ! -f password.conf ] ; then
# create the admin server password file
echo Creating the admin server password file
echo 'internal:'`cat pwdfile.txt` > password.conf
if test -n "$isroot" ; then
chown $uid:$gid password.conf
fi
chmod 400 password.conf
fi
# tell admin server to use the password file
echo Enabling the use of a password file in admin server
sed -e "s@^NSSPassPhraseDialog .*@NSSPassPhraseDialog file:`pwd`/password.conf@" ../admin-serv/config/nss.conf > /tmp/nss.conf && mv /tmp/nss.conf ../admin-serv/config/nss.conf
if test -n "$isroot" ; then
chown $uid:$gid ../admin-serv/config/nss.conf
fi
chmod 400 ../admin-serv/config/nss.conf
# enable SSL in the directory server
echo "Enabling SSL in the directory server - when prompted, provide the directory manager password"
ldapmodify -x -h localhost -p $ldapport -D "cn=directory manager" -W <
dn: cn=schema
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.0 NAME 'defaultServerList' DESC 'Default LDAP server host address used by a DUA' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.1 NAME 'defaultSearchBase' DESC 'Default LDAP base DN used by a DUA' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList' DESC 'Preferred LDAP server host addresses to be used by a DUA' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.3 NAME 'searchTimeLimit' DESC 'Maximum time in seconds a DUA should allow for a search to complete' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.4 NAME 'bindTimeLimit' DESC 'Maximum time in seconds a DUA should allow for the bind operation to complete' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.5 NAME 'followReferrals' DESC 'Tells DUA if it should follow referrals returned by a DSA search result' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' DESC 'A keystring which identifies the type of authentication method used to contact the DSA' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.7 NAME 'profileTTL' DESC 'Time to live, in seconds, before a client DUA should re-read this configuration profile' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.14 NAME 'serviceSearchDescriptor' DESC 'LDAP search descriptor list used by a DUA' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.9 NAME 'attributeMap' DESC 'Attribute mappings used by a DUA' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.10 NAME 'credentialLevel' DESC 'Identifies type of credentials a DUA should use when binding to the LDAP server' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.11 NAME 'objectclassMap' DESC 'Objectclass mappings used by a DUA' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.12 NAME 'defaultSearchScope' DESC 'Default search scope used by a DUA' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.13 NAME 'serviceCredentialLevel' DESC 'Identifies type of credentials a DUA should use when binding to the LDAP server for a specific service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
attributeTypes:( 1.3.6.1.4.1.11.1.3.1.1.15 NAME 'serviceAuthenticationMethod' DESC 'Authentication method used by a service of the DUA' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
objectClasses:( 1.3.6.1.4.1.11.1.3.1.2.4 NAME 'DUAConfigProfile' SUP top STRUCTURAL DESC 'Abstraction of a base configuration for a DUA' MUST ( cn ) MAY ( defaultServerList $ preferredServerList $ defaultSearchBase $ defaultSearchScope $ searchTimeLimit $ bindTimeLimit $ credentialLevel $ authenticationMethod $ followReferrals $ serviceSearchDescriptor $ serviceCredentialLevel $ serviceAuthenticationMethod $ objectclassMap $ attributeMap $ profileTTL ) )
EOF
cat <
dn: cn=schema
attributeTypes:( 1.3.6.1.1.1.1.30 NAME 'nisDomain' DESC 'NIS domain' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'user defined' )
objectClasses:( 1.3.6.1.1.1.2.15 NAME 'nisDomainObject' SUP top STRUCTURAL MUST nisDomain X-ORIGIN 'user defined' )
EOF
/bin/cp -f /tmp/61DUAConfigProfile.ldif $FDS1_PATH/slapd-pe/config/schema
/bin/cp -f /tmp/62nisDomain.ldif $FDS1_PATH/slapd-pe/config/schema
chown $SLAPD_OWNER:$SLAPD_GROUP $FDS1_PATH/slapd-pe/config/schema/61DUAConfigProfile.ldif
chown $SLAPD_OWNER:$SLAPD_GROUP $FDS1_PATH/slapd-pe/config/schema/62nisDomain.ldif
$FDS1_PATH/slapd-pe/stop-slapd
$FDS1_PATH/slapd-pe/start-slapd
# Add nisDomainObject
echo Hello2
cat <
dn: $BASEDN
changetype: modify
add: objectclass
objectclass: nisdomainobject
-
replace: nisdomain
nisdomain: $DOMAIN
EOF
echo Hello3
cd /opt/fedora-ds/shared/bin
./ldapmodify -D "cn=Directory Manager" -w `cat /home/ldap/dirmgr.pwd` -f /tmp/add_nisDomainObject.ldif
# Add two ACIs
cat <
dn: $BASEDN
changetype: modify
add: aci
aci: (targetattr = "cn||uid||uidNumber||gidNumber||homeDirectory||shadowLastChange||shadowMin||shadowMax||shadowWarning||shadowInactive||shadowExpire||shadowFlag||memberUid")(version 3.0; acl LDAP_Naming_Services_deny_write_access;deny (write) userdn = "ldap:///self";)
-
add: aci
aci: (target="ldap:///$BASEDN")(targetattr="userPassword")(version 3.0; acl LDAP_Naming_Services_proxy_password_read; allow (compare,search) userdn = "ldap:///cn=proxyagent,ou=profile,$BASEDN";)
EOF
echo Hello3.3
cd /opt/fedora-ds/shared/bin
./ldapmodify -D "cn=Directory Manager" -w `cat /home/ldap/dirmgr.pwd` -f /tmp/add_two_ACIs.ldif
# Modify default password storage scheme
cat <
dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: CRYPT
EOF
echo Hello3.8
cd /opt/fedora-ds/shared/bin
./ldapmodify -D "cn=Directory Manager" -w `cat /home/ldap/dirmgr.pwd` -f /tmp/mod_passwordStorageScheme.ldif
# Create ou=group, proxyAgent and ldapclient profiles
cat <
dn: uid=gtay, ou=People, $BASEDN
givenName: Gary
sn: Tay
loginShell: /bin/bash
uidNumber: 6167
gidNumber: 102
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
objectClass: shadowAccount
uid: gtay
cn: Gary Tay
homeDirectory: /home/gtay
userPassword: {CRYPT}U8bo2twhJ9Kkg
dn: uid=tuser, ou=People, $BASEDN
givenName: Test
sn: User
loginShell: /bin/bash
uidNumber: 9999
gidNumber: 102
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
objectClass: shadowAccount
uid: tuser
cn: Test User
homeDirectory: /home/tuser
userPassword: {SHA}MWxHz/4F3kXGXlfK4EvIJUo2C2U=
EOF
echo Hello5
cd /opt/fedora-ds/shared/bin
./ldapmodify -a -c -D "cn=Directory Manager" -w `cat /home/ldap/dirmgr.pwd` -f /tmp/People.ldif
cat <
dn: ou=group,$BASEDN
objectClass: organizationalUnit
objectClass: top
ou: group
dn: cn=Users,ou=group,$BASEDN
cn: Users
gidNumber: 102
objectClass: top
objectClass: posixGroup
memberUid: gtay
memberUid: tuser
dn: ou=netgroup,$BASEDN
objectClass: organizationalUnit
objectClass: top
ou: netgroup
dn: ou=sudoers,$BASEDN
objectClass: organizationalUnit
objectClass: top
ou: sudoers
EOF
echo Hello6
cd /opt/fedora-ds/shared/bin
./ldapmodify -a -c -D "cn=Directory Manager" -w `cat /home/ldap/dirmgr.pwd` -f /tmp/group_and_other_OUs.ldif
cat <
dn: ou=profile,$BASEDN
objectClass: top
objectClass: organizationalUnit
ou: profile
dn: cn=proxyAgent,ou=profile,$BASEDN
objectClass: top
objectClass: person
cn: proxyAgent
sn: proxyAgent
userPassword: {CRYPT}l14aeXtphVSUg
dn: cn=default,ou=profile,$BASEDN
objectClass: top
objectClass: DUAConfigProfile
defaultServerList: 10.14.236.169
defaultSearchBase: $BASEDN
authenticationMethod: simple
followReferrals: TRUE
defaultSearchScope: one
searchTimeLimit: 30
profileTTL: 43200
cn: default
credentialLevel: proxy
bindTimeLimit: 2
serviceSearchDescriptor: passwd: ou=People,$BASEDN?one
serviceSearchDescriptor: group: ou=group,$BASEDN?one
serviceSearchDescriptor: shadow: ou=People,$BASEDN?one
serviceSearchDescriptor: netgroup: ou=netgroup,$BASEDN?one
serviceSearchDescriptor: sudoers: ou=sudoers,$BASEDN?one
dn: cn=tls_profile,ou=profile,$BASEDN
ObjectClass: top
ObjectClass: DUAConfigProfile
defaultServerList: 10.14.236.169
defaultSearchBase: $BASEDN
authenticationMethod: tls:simple
followReferrals: FALSE
defaultSearchScope: one
searchTimeLimit: 30
profileTTL: 43200
bindTimeLimit: 10
cn: tls_profile
credentialLevel: proxy
serviceSearchDescriptor: passwd: ou=People,$BASEDN?one
serviceSearchDescriptor: group: ou=group,$BASEDN?one
serviceSearchDescriptor: shadow: ou=People,$BASEDN?one
serviceSearchDescriptor: netgroup: ou=netgroup,$BASEDN?one
serviceSearchDescriptor: sudoers: ou=sudoers,$BASEDN?one
EOF
echo hello7
cd /opt/fedora-ds/shared/bin
./ldapmodify -a -c -D "cn=Directory Manager" -w `cat /home/ldap/dirmgr.pwd` -f /tmp/proxyAgent_and_profiles.ldif
echo "Rebuild done."
Now the Server is ready to answer to Solaris Client request.
Next, lets configure the Fedora DS Client so as to work with the Server.A script called ldapclient_init_defaultprofile_sol10.sh will help us to make necessary changes :
/usr/sbin/ldapclient -v init -a profileName=default -a domainName=im.logica.com -a proxyDn=cn=proxyagent,ou=profile,dc=im,dc=logica,dc=com -a proxyPassword=password 10.14.236.169
# As ldapclient overwrites /etc/nsswitch.conf with /etc/nsswitch.ldap
# which contains a bug in "hosts:" entry, we need to repair it
sed -e '/^hosts:/s/ldap.*files$/files dns/' \
-e '/^passwd:/a\
shadow: files ldap' \
/etc/nsswitch.ldap >/etc/nsswitch.work
cp /etc/nsswitch.work /etc/nsswitch.conf
# Refresh Name Service Cache Daemon after repairing /etc/nsswitch.conf
/etc/init.d/nscd stop
/etc/init.d/nscd start
On running this script the following output should get displayed:
Parsing profileName=default
Parsing domainName=im.logica.com
Parsing proxyDn=cn=proxyagent,ou=profile,dc=im,dc=logica,dc=com
Parsing proxyPassword=password
Arguments parsed:
domainName: im.logica.com
proxyDN: cn=proxyagent,ou=profile,dc=im,dc=logica,dc=com
profileName: default
proxyPassword: password
defaultServerList: 10.14.236.169
Handling init option
About to configure machine by downloading a profile
findBaseDN: begins
findBaseDN: ldap not running
findBaseDN: calling __ns_ldap_default_config()
found 2 namingcontexts
findBaseDN: __ns_ldap_list(NULL, "(&(objectclass=nisDomainObject)(nisdomain=im.l ogica.com))"
rootDN[0] dc=im,dc=logica,dc=com
found baseDN dc=im,dc=logica,dc=com for domain im.logica.com
Proxy DN: cn=proxyagent,ou=profile,dc=im,dc=logica,dc=com
Proxy password: {NS1}ecfa88f3a945c411
Credential level: 1
Authentication method: 1
About to modify this machines configuration by writing the files
Stopping network services
Stopping sendmail
stop: sleep 100000 microseconds
stop: sleep 200000 microseconds
stop: network/smtp:sendmail... success
Stopping nscd
stop: sleep 100000 microseconds
stop: system/name-service-cache:default... success
Stopping autofs
stop: sleep 100000 microseconds
stop: sleep 200000 microseconds
stop: sleep 400000 microseconds
stop: sleep 800000 microseconds
stop: sleep 1600000 microseconds
stop: sleep 3200000 microseconds
stop: system/filesystem/autofs:default... success
ldap not running
nisd not running
nis(yp) not running
file_backup: stat(/etc/nsswitch.conf)=0
file_backup: (/etc/nsswitch.conf -> /var/ldap/restore/nsswitch.conf)
file_backup: stat(/etc/defaultdomain)=-1
file_backup: No /etc/defaultdomain file.
file_backup: stat(/var/nis/NIS_COLD_START)=-1
file_backup: No /var/nis/NIS_COLD_START file.
file_backup: nis domain is "EMPTY"
file_backup: stat(/var/ldap/ldap_client_file)=-1
file_backup: No /var/ldap/ldap_client_file file.
Starting network services
start: /usr/bin/domainname im.logica.com... success
start: sleep 100000 microseconds
start: sleep 200000 microseconds
start: network/ldap/client:default... success
start: sleep 100000 microseconds
start: sleep 200000 microseconds
start: system/filesystem/autofs:default... success
start: sleep 100000 microseconds
start: sleep 200000 microseconds
start: system/name-service-cache:default... success
start: sleep 100000 microseconds
start: sleep 200000 microseconds
start: network/smtp:sendmail... success
restart: sleep 100000 microseconds
restart: sleep 200000 microseconds
restart: milestone/name-services:default... success
System successfully configured
This script will create two files:
1. ldap_client_cred
NS_LDAP_BINDDN= cn=proxyagent,ou=profile,dc=im,dc=logica,dc=com
NS_LDAP_BINDPASSWD= {NS1}ecfa88f3a945c411
2.ldap_client_file
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= 10.14.236.169
NS_LDAP_SEARCH_BASEDN= dc=im,dc=logica,dc=com
NS_LDAP_AUTH= simple
NS_LDAP_SEARCH_REF= TRUE
NS_LDAP_SEARCH_SCOPE= one
NS_LDAP_SEARCH_TIME= 30
NS_LDAP_CACHETTL= 43200
NS_LDAP_PROFILE= default
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=People,dc=im,dc=logica,dc=com?one
NS_LDAP_SERVICE_SEARCH_DESC= group: ou=group,dc=im,dc=logica,dc=com?one
NS_LDAP_SERVICE_SEARCH_DESC= shadow: ou=People,dc=im,dc=logica,dc=com?one
NS_LDAP_SERVICE_SEARCH_DESC= netgroup: ou=netgroup,dc=im,dc=logica,dc=com?one
NS_LDAP_SERVICE_SEARCH_DESC= sudoers: ou=sudoers,dc=im,dc=logica,dc=com?one
NS_LDAP_BIND_TIME= 2
Also, we need to run the following commands:
Check and change the file permission of BOTH ldap_client_file and ldap_client_cred if needed
# cd /var/ldap
# chmod 400 ldap_client_file ldap_client_cred
Edit /etc/nsswitch.conf, make sure that these lines exist:
passwd: files ldap
group: files ldap
shadow: files ldap
hosts: files dns
Now try refreshing ldap_cachemgr and nscd
# /etc/init.d/ldap.client stop
# /etc/init.d/ldap.client start
# ps -ef | grep ldap
# /etc/init.d/nscd stop
# /etc/init.d/nscd start
# ps -ef | grep nscd
Make sure also that ldap1.example is defined in BOTH "/etc/hosts" files and DNS, and that "hosts: files dns" instead of "host: files ldap" is defined in /etc/nsswitch.conf. If "hosts: files ldap" is used, there will be error messages during login, i.e. "unknown host or invalid literal address".
To test the name service, on top of using "id" and "getent", there is also "ldaplist" command
# /usr/lib/ldap/ldap_cachemgr -g
# id tuser
uid=9999(tuser) gid=102(Users)
# getent passwd tuser
tuser::9999:102::/home/tuser:/bin/bash
# ldaplist -l passwd tuser
dn: uid=tuser,ou=People,dc=example,dc=com
givenName: Test
sn: User
loginShell: /bin/bash
uidNumber: 9999
gidNumber: 102
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
objectClass: shadowAccount
uid: tuser
cn: Test User
homeDirectory: /home/tuser
Now we need to configure nsswitch file so as to let users login into the Client.The format for nsswitch and pam.conf should match the following :
File : /etc/nsswitch.conf
# more /etc/nsswitch.conf
#
# Copyright 2006 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# ident "@(#)nsswitch.ldap 1.10 06/05/03 SMI"
#
# /etc/nsswitch.ldap:
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# uses LDAP in conjunction with files.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.
# LDAP service requires that svc:/network/ldap/client:default be enabled
# and online.
# the following two lines obviate the "+" entry in /etc/passwd and /etc/group.
passwd: files ldap
group: files ldap
# consult /etc "files" only if ldap is down.
hosts: files dns
# Note that IPv4 addresses are searched for in all of the ipnodes databases
# before searching the hosts databases.
ipnodes: files
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files
bootparams: files
publickey: files
netgroup: files
automount: files
aliases: files
# more /etc/pam.conf
#
#ident "@(#)pam.conf 1.29 07/04/10 SMI"
#
# Copyright 2007 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# PAM configuration
#
# Unless explicitly defined, all services use the modules
# defined in the "other" section.
#
# Modules are defined with relative pathnames, i.e., they are
# relative to /usr/lib/security/$ISA. Absolute path names, as
# present in this file in previous releases are still acceptable.
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login auth requisite pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_unix_cred.so.1
login auth required pam_unix_auth.so.1
# login auth required pam_ldap.so.1
login auth required pam_dial_auth.so.1 debug
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin auth sufficient pam_rhosts_auth.so.1
rlogin auth requisite pam_authtok_get.so.1
rlogin auth required pam_dhkeys.so.1
rlogin auth required pam_unix_cred.so.1
rlogin auth required pam_unix_auth.so.1
rlogin auth required pam_ldap.so.1 debug
#
# Kerberized rlogin service
#
krlogin auth required pam_unix_cred.so.1
krlogin auth required pam_krb5.so.1
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh auth sufficient pam_rhosts_auth.so.1
rsh auth required pam_unix_cred.so.1
#
# Kerberized rsh service
#
krsh auth required pam_unix_cred.so.1
krsh auth required pam_krb5.so.1
#
# Kerberized telnet service
#
ktelnet auth required pam_unix_cred.so.1
ktelnet auth required pam_krb5.so.1
#
# PPP service (explicit because of pam_dial_auth)
#
ppp auth requisite pam_authtok_get.so.1
ppp auth required pam_dhkeys.so.1
ppp auth required pam_unix_cred.so.1
ppp auth required pam_unix_auth.so.1
ppp auth required pam_dial_auth.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth sufficient pam_unix_auth.so.1
other auth required pam_ldap.so.1
#
# passwd command (explicit because of a different authentication module)
#
passwd auth sufficient pam_passwd_auth.so.1
passwd auth required pam_ldap.so.1
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron account required pam_unix_account.so.1
#
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other account sufficient pam_ldap.so.1
other account requisite pam_roles.so.1
other account required pam_unix_account.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session management
#
other session required pam_unix_session.so.1
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
#
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1
#
# Support for Kerberos V5 authentication and example configurations can
# be found in the pam_krb5(5) man page under the "EXAMPLES" section.
#
Try these commands:
1 id
2. getent passwd
This will display the ids of users being inputted and also do show the passwd policy of the requested users.
In this way we can configure a Solaris Native LDAP Client that is capable for querying name service (uid) from the LDAP Server.
14. Configuring Fedora DS Client on HP-UNIX
For Configuring the Fedora DS Client on HP Unix we need the following package to be installed :
J4269AA_B.04.15.01_HP-UX_B.11.23_IA_PA.depot
The package can be downloaded from the link :
http://h20392.www2.hp.com/portal/swdepot/index.do
After downloading the package,we need to run the following command:
# swinstall –s /
This package will install the required directory:
Run the following step-by-step configurations:
# cd /opt/ldapux
# ls
README config newconfig
README-LdapUxClient contrib share
README-NisLdap lib ypldapd
bin migrate
# cd config
# ls
create_profile_cache display_profile_cache setup
create_profile_entry get_profile_entry
create_profile_schema ldap_proxy_config
#./setup
When we run the setup script it will ask for the list of queries to be responded:
Would you like to continue with the setup? [Yes]:
Directory Server: [1]:
Directory server host [hpux.sis.personal.net.py =
port number [389]:
Would you like to extend the schema in this directory server? [Yes]:
The LDAP printer schema does not exist in the directory.
Note: The LDAP printer schema is based on IETF RFC 3712.
Would you like to extend the printer schema in this directory server? [Yes]:no
PublicKey schema does not exist in the directory server.
Would you like to install PublicKey schema in this directory server? [Yes]:no
Would you like to install the new automount schema ? [Yes]:no
Profile Entry DN: []: cn=ldapuxprofile,ou=People,dc=pe,dc=im,dc=logica,dc=com
User DN [cn=Directory Manager]:
Password:
Authentication method: [1]:
Would you like to start/restart the LDAP-UX daemon (y/n) ? [y]:
LDAP-UX Client Services setup complete.
After these series of responses , we need to edit the /etc/nsswitch.conf:
File : /etc/nsswitch.conf
#
# /etc/nsswitch.hp_defaults:
#
# @(#)B.11.11_LR
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# uses NIS (YP) in conjunction with files.
#
passwd: compat ldap
group: compat ldap
shadow: compat ldap
hosts: files dns
networks: files
protocols: nis [NOTFOUND=return] files
rpc: nis [NOTFOUND=return] files
publickey: nis [NOTFOUND=return] files
netgroup: nis [NOTFOUND=return] files
automount: files nis
aliases: files nis
services: nis [NOTFOUND=return] files
Also, copy the /etc/pam.ldap file to /etc/pam.conf .The file should resemble the following:
File : /etc/pam.conf
# PAM configuration
#
# This pam.conf file is intended as an example only.
#
# Please note that this configuration file has only been modified for the
# default services. Other services can be added or modified as
# needed or desired. If a service is not listed, it will use the
# OTHER classification
#
# the format for a entry is
#
#
# see pam.conf(4) for more details
#
# Authentication management
#
login auth sufficient /usr/lib/security/libpam_unix.1
login auth required /usr/lib/security/libpam_ldap.1 try_first_pass
su auth sufficient /usr/lib/security/libpam_unix.1
su auth required /usr/lib/security/libpam_ldap.1 try_first_pass
dtlogin auth sufficient /usr/lib/security/libpam_unix.1
dtlogin auth required /usr/lib/security/libpam_ldap.1 try_first_pass
dtaction auth sufficient /usr/lib/security/libpam_unix.1
dtaction auth required /usr/lib/security/libpam_ldap.1 try_first_pass
ftp auth sufficient /usr/lib/security/libpam_unix.1
ftp auth required /usr/lib/security/libpam_ldap.1 try_first_pass
OTHER auth sufficient /usr/lib/security/libpam_unix.1
OTHER auth required /usr/lib/security/libpam_ldap.1 try_first_pass
#
# Account management
#
login account sufficient /usr/lib/security/libpam_unix.1
login account required /usr/lib/security/libpam_ldap.1
su account sufficient /usr/lib/security/libpam_unix.1
su account required /usr/lib/security/libpam_ldap.1
dtlogin account sufficient /usr/lib/security/libpam_unix.1
dtlogin account required /usr/lib/security/libpam_ldap.1
dtaction account sufficient /usr/lib/security/libpam_unix.1
dtaction account required /usr/lib/security/libpam_ldap.1
ftp account sufficient /usr/lib/security/libpam_unix.1
ftp account required /usr/lib/security/libpam_ldap.1
OTHER account sufficient /usr/lib/security/libpam_unix.1
#
# Session management
#
login session sufficient /usr/lib/security/libpam_unix.1
login session required /usr/lib/security/libpam_ldap.1
dtlogin session sufficient /usr/lib/security/libpam_unix.1
dtlogin session required /usr/lib/security/libpam_ldap.1
dtaction session sufficient /usr/lib/security/libpam_unix.1
dtaction session required /usr/lib/security/libpam_ldap.1
OTHER session sufficient /usr/lib/security/libpam_unix.1
OTHER session required /usr/lib/security/libpam_ldap.1
#
# Password management
#
login password sufficient /usr/lib/security/libpam_unix.1
login password required /usr/lib/security/libpam_ldap.1 try_first_pass
passwd password sufficient /usr/lib/security/libpam_unix.1
passwd password required /usr/lib/security/libpam_ldap.1 try_first_pass
dtlogin password sufficient /usr/lib/security/libpam_unix.1
dtlogin password required /usr/lib/security/libpam_ldap.1 try_first_pass
dtaction password sufficient /usr/lib/security/libpam_unix.1
dtaction password required /usr/lib/security/libpam_ldap.1 try_first_pass
OTHER password sufficient /usr/lib/security/libpam_unix.1
OTHER password required /usr/lib/security/libpam_ldap.1 try_first_pass
Try these commands to check if the configuration is really working:
# id shreya
uid=527(shreya) gid=99()
# getent passwd
sh: getent: not found.
# nsquery passwd shreya ldap
Using "ldap" for the passwd policy.
Searching ldap for shreya
User name: shreya
User Id: 527
Group Id: 99
Gecos: shreya
Home Directory: /home/shreya
Shell: /bin/sh
Switch configuration: Terminates Search
#
Now try logging in from the Client to any user added in the Server.
In case the login is unsuccessful we need to check the PAM module or check the logs in the Server /opt/feodora-ds/slapd/logs/access file.
References :
1. http://www.directory.fedora.redhat.com/wiki/Documentation
2.http://web.singnet.com.sg/~garyttt/http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1197308
3.http://web.singnet.com.sg/~garyttt/Configuring%20Solaris%20Native%20LDAP%20Client%20for%20Fedora%20Directory%20Server.htm
4. www.enterprisenetworkingplanet.com/netos/article.php/3624006
5. www.linux.com/feature/58731
6. http://docs.safehaus.org/display/PENROSE10/Fedora+Directory+Server
Subscribe to:
Posts (Atom)