synapse unsync

First some background stuff - this work was all done on Centos 5.3 i386 using openldap 2.3. You need a basic working OpenLDAP configuration such as in my notes Configuring OpenLDAP. The other thing you need to be aware of when setting up LDAP sync with the Centos 5.x distro is that, like RedHat, the syncprov module is statically linked with slapd which means that the notes that refer to using the moduleload functionality with syncprov.la do not apply to Centos. LDAP sync replication is essentially a “pull” replication model which is different from the deprecated slurpd’s “push” replication.

These notes relate to a simple ldap sync setup with 1 provider and 1 consumer. In LDAP sync jargon a “provider” is the source of updates and a “consumer” is the openldap which is to be updated. There are various models for ldap sync, in this version which is the simplest all the data for all records are copied when there is a change but there are more sophisticated models which only copy the changes. This can be useful if you have a large directory.

The provider has only 2 configuration directives for setting checkpoints on the contextCSN and configuring the session log. Because ldap sync search is subject to access control you must ensure proper acl privileges are set for the replicated content.

In the provider’s slapd.conf add:

index entryCSN,entryUUID    eq,pres

then add:

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

limits dn.exact="cn=syncuser,dc=mydomain,dc=com" size=unlimited time=unlimited

The limits entry is a good idea to help keep the consumer in sync during a large modification.

I also added a syncuser to my directory with an ldif like:

dn: cn=syncuser,dc=mydomain,dc=com
uid: syncuser
cn: syncuser
sn: syncuser
objectClass: inetLocalMailRecipient
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: e1NTSEF9NERla1JTSWwxa0tDU0FHRU5SUVZudVh4L1VyamJ1dFQ=
shadowLastChange: 14387
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 501
gidNumber: 501
homeDirectory: /home/syncuser
gecos: syncuser

On the consumer add in slapd.conf:

index entryCSN,entryUUID    eq,pres

and then:

syncrepl rid=101
    provider=ldap://ldap.mydomain.com:389
    type=refreshOnly
    interval=00:01:00:00
    searchbase="dc=mydomain,dc=com"
    filter="(objectclass=*)"
    attrs="*,+"
    scope=sub
    schemachecking=off
    bindmethod=simple
    binddn="cn=syncuser,dc=mydomain,dc=com"
    credentials=secret

where:
rid=101 is the id for this query; it must be unique across all consumers
provider=xx is the server this consumer will query
type=refreshOnly means that after the initial sync the sync query will rerun at the time specified by interval
interval=00:01:00:00 means the sync query will reschedule after 1 hour
searchbase=xx the start at the root of the tree
filter="(objectclass=*)" look for everything
scope=sub search recursively
attrs="*,+" copy all attributes which is the default setting so there is no need to specify this
schemachecking=off the provider should already be doing this
binddn=xx is the user on the provider who the consumer will use for its queries
bindmethod=simple use plaintext passwords
credentials=secret the syncuser password

There are other options, instead of type=refreshOnly you could have type=refreshAndPersist which means that after the initial query the sync will stay open and any other changes will be transferred immediately. If you change your type setting you may want to remove the interval setting and add retry="60 +" which means that if network connectivity is lost between the consumer and the provider, the consumer will try every 60 seconds indefinitely to re-establish a network connection with the provider.

Now restart slapd on the provider and then on the consumer.

No comments »

These notes refer to building rssh on Centos 5.3. I do not cover chrooting the user within their restricted shell because I could not get it working satisfactorily. Nor do I cover the reasons why you might want to use a restricted shell.

The steps I followed were:

Get the code
(1) download the source rpm (2.3.2 at time of writing)
(2) install the gpg key
  rpm --import http://www.pizzashack,org/ddmkey.txt
(3) build the source package
  rpmbuild -v --rebuild rssh-2.3.2-1.src.rpm
(4) install the newly built rpm
  rpm -ivh /usr/src/redhat/RPMS/i386/rssh-2.3.2-1.i386.rpm

Configuring rssh (no chroot)
(1) edit the /etc/rssh.conf file and uncomment the #allowsftp line (and/or #allowscp and/or #allowrsync etc) to allow sftp access (and/or scp and/or rsync etc)
(2) create your user (eg for a user John Citizen)
  useradd -m -d /home/jcitizen -s /usr/bin/rssh jcitizen
passwd jcitizen
(3) test the login for jcitizen from another machine
   (a) connect using ssh
   ssh jcitizen@rsshserver.mydomain.com

   you should see output something like:

Last login: Sat Apr 25 11:00:11 2009 from 192.168.0.10

This account is restricted by rssh.
Allowed commands: scp sftp rsync

If you believe this is in error, please contact your system administrator.

Connection to rsshserver.mydomain.com closed.

   (b) connect using sftp
   sftp jcitizen@rsshserver.mydomain.com

   You should now see some output something like:

Connecting to rsshserver.mydomain.com...
jcitizen@rsshserver.mydomain.com's password:
sftp>

(4) Important - note that this type of configuration will apply to all users with the rssh shell. It is also possible to configure rssh on a per user basis.

No comments »

How to make freeradius use openldap as an authentication source.
This was tested on Centos 5.3. Freeradius and OpenLDAP were installed using the “Add/Remove Software” item on the Applications menu - no rocket science here! The article assumes that you already have a working ldap server (or see my article on Configuring OpenLDAP).

(1) In radiusd.conf edit the modules section for ldap so that it reads something like:

ldap {
server = "myhost.mydomain.com"
identity = "cn=manager,dc=mydomain,dc=com"
password = mysecret
basedn = "dc=mydomain,dc=com"
filter = "(uid=%u)"
start_tls = no
access_attr = uid
dictionary_mapping = $(raddbdir/ldap.attrmap
ldap_connections_number = 5
timeout = 4
timelimit = 3
net_timeout = 1
}

(2) Find the authorize section of radiusd.conf find the line which starts #ldap and remove the '#' so it reads just ldap

(3) Again in radiusd.conf, but in the authentication section, find the lines:

# Auth-Type LDAP {
#     ldap
#}

and remove the '#' so these lines read

Auth-Type LDAP {
     ldap
}

(4) In the /etc/raddb/users file find the section which reads

DEFAULT Auth-Type = System
     Fall-Through = 1

and replace it with

DEFAULT Auth-Type = LDAP
     Fall-Through = 1

(5) Restart the radiusd daemon /etc/init.d/radiusd restart
(6) Assuming that your /etc/raddb/clients.conf has a section that reads

clients 127.0.0.1 {
     secret = testing123
     shortname = localhost
     nastype = other
}

and also that you have an entry in your ldap directory like

dn: uid=john,ou=users,dc=mydomain,dc=com
uid: john
cn: john
givenName: john
sn: doe
mail: john@mydomain.com
mailRoutingAddress: john@mail.prod.mydomain.com
mailHost: mail.prod.mydomain.com
objectClass: inetLocalMailRecipient
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$EwO.4wlT$n5KoIfFE8qcDcPAC12vxn2
shadowLastChange: 14360
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 503
gidNumber: 503
homeDirectory: /home/john
gecos: john doe

and that jdoe’s password is mysecret, you can test your radius configuration by executing

radtest john mysecret 127.0.0.1 10 testing123

You should see a reply like

Sending Access-Request of id 65 to 127.0.0.1 port 1812
    User-Name = "jdoe"
    User-Password = "secret"
    NAS-IP-Address = 255.255.255.255
    NAS-Port = 10
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=65, length=20

No comments »

This is a very basic configuration for freeradius to allow authentication from passwd and shadow files. It has been tested on Centos 5.3

(1) The freeradius configuraton files are usually in /etc/raddb; make a subdirectory /etc/raddb/etc
(2) copy your /etc/passwd and /etc/shadow  files to /etc/raddb/etc
(3) edit the /etc/raddb/etc/passwd and /etc/raddb/etc/shadow files to remove all entries except for those that you want to authenticate with radius
(4) edit the /etc/raddb/radiusd.conf file; find the section:


unix {
...

and set the values for the passwd and shadow files so they read:


passwd = /etc/raddb/etc/passwd
shadow = /etc/raddb/etc/shadow


(5) save radiusd.conf
(6) make sure the radiusd user can read  the files

chmod -R 644 /etc/raddb/etc

(7) check the /etc/raddb/users file to ensure that the following exists:

DEFAULT     Auth-Type = System
Fall-Through = 1

(8) Assuming you have entries in the /etc/raddb/etc/passwd and /etc/raddb/etc/shadow for a user ‘jdoe’ with password of ’secret’ you can test your radius configuration by:
(a) start the radius daemon with ‘/etc/init.d/radiusd start’; you should see some output something like:

[root@myserver raddb]# /etc/init.d/radiusd start
Starting RADIUS server: Sun May  3 13:26:37 2009 : Info: Starting - reading configuration files … [  OK  ]

(b) execute the command ‘radtest jdoe secret 127.0.0.1 10 testing123′. Assuming it all works you should see output something like:


[root@myserver raddb]# radtest jdoe secret 127.0.0.1 10 testing123
Sending Access-Request of id 65 to 127.0.0.1 port 1812
User-Name = “jdoe”
User-Password = “secret”
NAS-IP-Address = 255.255.255.255
NAS-Port = 10
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=65, length=20


Note that the radius client password is the cleartext password specified for the client in clients.conf and the nas-port-number parameter can be any value between 0 and 2^31 so 10 is fine.

If you received the Access-Accept message then congratulations, you have radius working, if not then go back and check your configuration and permissions.

(9) You can have the radius daemon start automatically by executing ‘chkconfig radiusd on’

No comments »

I wanted to install an anti-virus scanner to work with my smtp server (exim) and since I couldn’t find a centos repository that included clamav and didn’t want to spend hours searching I just downloaded the source and installed from scratch. To do this you will need to have a compiler and development libraries installed. The steps I followed were:

• Create the clamav user and group
  

  sudo groupadd clamav
sudo useradd -g clamav -c "clamav user" -d /var/clamav -s /sbin/nologin -m clamav

• Download the source from http://www.clamav.net into a working directory and unpack (eg. tar zxvf clamav-0.93.tar.gz) which will create a source code directory called clamav-0.93 under your working directory.
• cd into the source code directory and execute ./configure in my case I didn’t want to change any of the defaults and wanted to install clamav into /usr/local which is the default location. The output will tell you if there are any missing prerequisites such as zlib. If there are any missing prerequisites then I recommend that you install them first and then start to build and install clamav.
• Execute make which will compile the clamav source with the configuration options from above.
• Install clamav
  

  sudo make install

• Edit the clamd.conf file in /usr/local/etc and set appropriate values for the various configuration items. My clamd.conf has the following settings:
  

  LogFile /tmp/clamd.log
LogFileUnlock yes
LogFileMaxSize 2M
LogTime yes
LogClean yes
LogSyslog yes
PidFile /var/run/clamd.pid
LocalSocket /var/run/clamd.exim/clamd.sock
FixStaleSocket yes
MaxRecursion 128
MaxFileSize 15M
MaxFiles 1500

  for all other settings I accepted the defaults.

• Configure /usr/local/etc/fresclam.conf - the settings I changed in my freshclam.conf were:
  

  UpdateLogFile /var/log/freshclam.log
LogTime yes
LogSyslog yes
PidFile /var/run/freshclam.pid
DatabaseMirror database.clamav.net
NotifyClamd /usr/local/etc/clamd.conf

  all other settings were at their default values

• Run freshclam once manually to seed the virus signatures in the database. Execute /usr/local/bin/freshclam
• For normal operations I also set freshclam to run once per hour by adding it to my crontab
  

  8 0-23 * * * /usr/local/bin/freshclam 2>&1

• Create a script to automatically start clamd on a system reboot in /etc/init.d. My /etc/init.d/clamd script is:
  

  
#! /bin/sh
#
### BEGIN INIT INFO
# Provides: clamd
# Required-Start: $syslog $network clamd
# X-UnitedLinux-Should-Start:
# Required-Stop: $syslog $network clamd
# X-UnitedLinux-Should-Stop:
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Short-Description: anti virus scan mails
# Description: Start clamd
### END INIT INFO
#

  # Check for missing binaries (stale symlinks should not happen)
  # Note: Special treatment of stop for LSB conformance
  CLAMD_BIN=/usr/local/sbin/clamd
  CLAMD_CONFIG=/usr/local/etc/clamd.conf
  CLAMD_PID_FILE=/var/run/clamd.pid

  test -x $CLAMD_BIN || { echo "$CLAMD_BIN not installed";
  if [ "$1" = "stop" ]; then exit 0;
  else exit 5; fi; }

  # Check for existence of needed config file and read it
  test -r $CLAMD_CONFIG || { echo “$CLAMD_CONFIG not existing”;
  if [ "$1" = "stop" ]; then exit 0;
  else exit 6; fi; }

  # Shell functions sourced from /etc/rc.status:
  # rc_check check and set local and overall rc status
  # rc_status check and set local and overall rc status
  # rc_status -v be verbose in local rc status and clear it afterwards
  # rc_status -v -r ditto and clear both the local and overall rc status
  # rc_status -s display “skipped” and exit with status 3
  # rc_status -u display “unused” and exit with status 3
  # rc_failed set local and overall rc status to failed
  # rc_failed set local and overall rc status to
  # rc_reset clear both the local and overall rc status
  # rc_exit exit appropriate to overall rc status
  # rc_active checks whether a service is activated by symlinks
  # rc_splash arg sets the boot splash screen to arg (if active)
  . /etc/rc.status

  # Reset status of this service
  rc_reset

  # Return values acc. to LSB for all commands but status:
  # 0 - success
  # 1 - generic or unspecified error
  # 2 - invalid or excess argument(s)
  # 3 - unimplemented feature (e.g. “reload”)
  # 4 - user had insufficient privileges
  # 5 - program is not installed
  # 6 - program is not configured
  # 7 - program is not running
  # 8–199 - reserved (8–99 LSB, 100–149 distrib, 150–199 appl)
  #
  # Note that starting an already running service, stopping
  # or restarting a not-running service as well as the restart
  # with force-reload (in case signaling is not supported) are
  # considered a success.

  case “$1″ in
  start)
  echo -n “Starting clamd”
  $CLAMD_BIN 2>&1

  # Remember status and be verbose
  rc_status -v
  ;;
  stop)
  echo -n “Shutting down clamd”
  CLAMD_PID=`/usr/bin/head -n 1 ${CLAMD_PID_FILE}`
  kill -TERM ${CLAMD_PID}

  # Remember status and be verbose
  rc_status -v
  ;;
  restart)
  ## Stop the service and regardless of whether it was
  ## running or not, start it again.
  $0 stop
  $0 start

  # Remember status and be quiet
  rc_status -v
  ;;
  reload)
  echo -n “Reload service clamd”
  $CLAMD_PID=`head -n 1 ${CLAMD_PID_FILEi}`
  kill -HUP ${CLAMD_PID}
  rc_status -v

  ## Otherwise:
#$0 stop && $0 start
#rc_status
;;
*)
echo “Usage: $0 {start|stop|restart|reload}”
exit 1
;;
esac
rc_exit


• Now make a link from the /etc/init.d/clamd script to the runlevel startup directories. Try
  

  chkconfig clamd on

  or possibly

  ln -s /etc/init.d/clamd /etc/rc3.d/S99clamd
ln -s /etc/init.d/clamd /etc/rc5.d/S99clamd

• Now start clamd
  

  /etc/init.d/clamd start

No comments »

dmapi is the data management api defined in the X/Open document “Systems Management Data Storage Management API dated Feb 1997. XFS, IBM JFS, VxFS, AdvFS and GPFS file systems support DMAPI for Hierarchical Storage Management

No comments »

• Open the /etc/yum.repos.d/CentOS-BASE.repo file in your favourite text editor.
• Find the [centosplus] section and set (Note: Ignore quotes) “enabled=1” then add the line “includepkgs=kernel* xfs” kmod* dmapi*”
• You can now list the available (eg. xfs related) packages using “yum list available *xfs*”

No comments »

First off I should say that my test system is pretty ancient being an AMD Duron with 512MB ram so if you are installing onto something more modern your mileage on the actual commands may vary. If you are using an x86_64 system you will need to enable the CentosPlus repository. For i386/i686 the modules you need are in the extras repository so no changes to the /etc/yum.repos.d/CentOS-Base.repo file are required. Also I refer to directories and devices on my hardware, you should replace these references with those for your own system as appropriate.

(1) Obtaining the xfs modules

This assumes you are logged into Centos and have a command prompt…

At a command prompt execute

yum list available *xfs*

and you should see something like the following output

Loading "installonlyn" plugin
Setting up repositories
base 100% |=========================| 1.1 kB 00:00
updates 100% |=========================| 951 B 00:00
addons 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
Available Packages
kmod-xfs.i686 0.4-1.2.6.18_53.1.14.e extras
kmod-xfs-PAE.i686 0.4-1.2.6.18_53.1.14.e extras
kmod-xfs-xen.i686 0.4-1.2.6.18_53.1.14.e extras
xfsdump.i386 2.2.46-1.el5.centos extras
xfsprogs.i386 2.9.4-1.el5.centos extras
xfsprogs-devel.i386 2.9.4-1.el5.centos extras
xorg-x11-xfs.i386 1:1.0.2-4 base
xorg-x11-xfs-utils.i386 1:1.0.2-4 base

The modules I loaded were kmod-xfs.i686, xfsdump.i386, xfsprogs.i386 and dmapi so execute the command

yum install kmod-xfs.i686 xfsdump.i386 xfsprogs.i386 dmapi

(2) Creating an XFS filesystem

• Use fdisk or parted to create a new partition from unused space on your hard disk. You will need to check the man pages for exact details. If you are converting an existing partition to xfs then see (3) below.
• Format the new filesystem for xfs with a command like mkfs.xfs <filesystem> eg. for a partition /dev/had3 the command would be

mkfs.xfs /dev/hda3

• You can provide a number of parameters to mkfs.xfs to set various options so it may be worth reading the man pages for mkfs.xfs.
• Create a mountpoint for the new filesystem

mkdir /mymount

• Edit /etc/fstab and add a line something like

/dev/hda3 /mymount xfs defaults 1 1

which basically means “mount the block special device /dev/hda3 on the /opt mountpoint”. This is an xfs filesystem which uses the default mount options, the filesystem does not need to be dumped but fsck can check the filesystem after it has checked the root filesystem”.

• Mount your new filesystem

mount /mymount

The mount command will read the mount options from the fstab line that refers to the /mymount mountpoint.

• You can now access the new filesystem at /mymount

(3) Converting and existing filesystem to xfs. For the purposes of these notes we will assume that /dev/hda3 is mounted on /opt formatted as ext3.

• Make a backup of any data currently on the partition you want to convert to xfs.
• Unmount the /opt partition

umount /opt

• Format the partition as XFS

mkfs.xfs -f /dev/hda3

• edit /etc/fstab
  • If you are not using LVM or your system does not use volume labels to identify partitions find the entry for /dev/hda3 and change the third item on that line of the fstab file from ext3 to xfs.
  • If you have LVM2 partitions you are probably using volume labels in your fstab file in which case I suggest that you format the partition using the command mkfs.xfs -f -L /opt /dev/hda3 then find the line in fstab that starts with “LABEL=/opt” and change the third item on that line from ext3 to xfs
• Remount the partition

mount /opt

• Restore the data you backed up in the first point above.

Congratulations, you should now have a working XFS partition that will automatically mount during a system boot.

No comments »