Allan Feid - OpenSolaris

Central login management with OpenLDAP

Allan Feid — Sun, 28 Mar 2010 17:18:58 +0000

Over the weekend I spent some time learning how to configure OpenLDAP to provide a central login server at home. This is pretty useful since I was tired of either syncing UID/GID's across servers or setting directories to 777 on my NFSv4 server. I chose Fedora 12 as my OS for the server, and will show how easy it is to configure authentication on both Fedora and OpenSolaris.

Some information about the network

I'll give you a quick overview of how the network looks from home.

DNS: ns1.crazy.lan (172.16.1.3)
LDAP: ldap1.crazy.lan (10.10.1.1)
Client 1: test.crazy.lan (10.10.2.1)
Client 2: virt.crazy.lan (192.168.1.8)

I'm not going to go over the importance of DNS (both forward and reverse lookups should work!) right now, but you will save yourself plenty of headaches by making sure DNS is setup properly on your network.

Basic configurations

Install the needed software!

For Fedora 12, installing OpenLDAP is easy:

# yum install -y openldap*

This will get you everything you need to get started.

There are a few things you need to change in order to really start using OpenLDAP. Everything is all in one file slapd.conf. Prior to editing the file, you'll want to generate a password to use in this configuration.

# slappasswd
New password: 
Re-enter new password: 
{SSHA}fFVfwsztHn+xuQPjN/q/urdNC+V0G+dW

Copy the new hash as you will need to paste it into the configuration file. Add or modify the following in /etc/openldap/ldap.conf:

suffix      "dc=crazy,dc=lan"
rootdn      "cn=Manager,dc=crazy,dc=lan"
rootpw      {SSHA}fFVfwsztHn+xuQPjN/q/urdNC+V0G+dW

# ACL's to use
loglevel acl stats
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
        by self write
        by * read
        by anonymous auth

That's all you need there for a basic configuration. This will not be using TLS/SSL, I will cover that in a later post. It's always good to start with the basics so that you can spend more time learning the protocol. Once you've gotten that down hardening a service is easy.

Now we just need to finish up and start the service. Since slapd.conf is deprecated in favor of the slapd.d/ directory, we can use the configuration file to generate the appropriate directory structure. The huge advantage of this style is dynamic backend configuration changes. Yes, that means persistent dynamic changes. No more restarting your directory server to make changes to things such as your logging level.

# cd /etc/openldap
# rm -rf slapd.d
# mkdir slapd.d
# slaptest -f slapd.conf -F slapd.d
# chown -R ldap:ldap slapd.d
# chkconfig slapd on
# service slapd start

You can test for functionality by running the following:

ldapsearch -x -h localhost

If all went well you will see some output and no errors.

Configure rsyslog for logging

If you're not using Fedora, or rsyslog, you'll want to lookup the specifics for your logging daemon's configuration. OpenLDAP sends it's logging output to the local4 log facility. For rsyslog, just add the following line to /etc/rsyslog.conf:

local4.*                                                -/var/log/ldap

Then restart your logging service.

service rsyslog restart

Importing some data to LDAP

The LDIF formatted file is where things start to get a little bit tricky. Don't worry about it so much as there are plenty of good GUI clients for LDAP, but we do need to get a few things imported.

# crazy.lan
dn: dc=crazy,dc=lan
objectClass: dcObject  
objectClass: organization
o: Crazy Organization  
dc: crazy

# Manager, crazy.lan   
dn: cn=Manager,dc=crazy,dc=lan
objectClass: organizationalRole
cn: manager

# People, crazy.lan
dn: ou=People,dc=crazy,dc=lan
objectClass: organizationalUnit
ou: People

# Group, crazy.lan
dn: ou=Group,dc=crazy,dc=lan
objectClass: organizationalUnit
ou: Group

# users, Group, crazy.lan
dn: cn=users,ou=Group,dc=crazy,dc=lan
objectClass: posixGroup
objectClass: top
cn: users
gidNumber: 2000

# myaccount, People, crazy.lan
dn: uid=myaccount,ou=People,dc=crazy,dc=lan
uid: myaccount
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
gidNumber: 2000
uidNumber: 3000
homeDirectory: /home/myaccount
loginShell: /bin/bash
userPassword: {SSHA}cc696ZrGCPmgx0/CD2zGJrMqR3tb8iMk
cn: Allan Feid

I saved the above as import.ldif. You will probably want to generate a new password with slappaswd to use with the userPassword section above. Now to import, it all I have to do is this:

ldapadd -f import.ldif -D "cn=Manager,dc=crazy,dc=lan" -W

This will prompt you for your rootdn password that you created earlier using slappasswd. Now you have the following basic hierarchy configured:

Base Domain: crazy.lan
- Organizational Unit: People
  - User: myaccount
- Organizational Unit: Group
  - Group: users

User accounts will go into the People OU, and group accounts will be assigned the Group OU. This is a pretty standard configuration as the pam_ldap plugin will look in these OU's later for user/group information.

Client configuration

Fedora 12

Redhat has really made this easier than it used to be. Their authconfig command is pretty straight forward, the following commands will get you the nss_ldap, pam_ldap and ldap utility commands on your client:

# yum install -y openldap-clients
# authconfig --enableldap \
    --enableldapauth \
    --disablenis \
    --enablecache \
    --ldapserver=ldap1.crazy.lan \
    --ldapbasedn=dc=crazy,dc=lan \
    --updateall

That's it. You will now see the myaccount user if you run getent.

# getent passwd |grep myaccount
myaccount:x:3000:2000:Allan Feid:/home/myaccount:/bin/bash

OpenSolaris

This should also work for plain Solaris, but I prefer OpenSolaris and haven't tested on Solaris 10. This, just like Redhat, is very easy to configure, but does require one extra step. The ldapclient command by default copies /etc/nsswitch.ldap to /etc/nsswitch.conf. Which is fine, but the ldap nsswich configuration by, by default, uses ldap for hostname lookups. This is probably not desirable in most cases as that's what we use DNS for. So just change the following lines in /etc/nsswitch.ldap:

hosts:      files dns
ipnodes:    files dns

Then just a simple command will get you up and running:

# ldapclient -v manual -a defaultSearchBase=dc=crazy,dc=lan \
    -a domainName=crazy.lan \
    -a defaultServerList=ldap1.crazy.lan
# getent passwd |grep myaccount
myaccount:x:3000:2000::/home/myaccount:/bin/bas

General Configuration for client's using pam_ldap/nss_ldap

If you aren't using Fedora or OpenSolaris, anything that uses pam_ldap/nss_ldap can be configured pretty easily. The main configuration file for these two is /etc/ldap.conf. All you need is to make sure you have the following lines:

base dc=crazy,dc=lan
uri ldap://ldap1.crazy.lan/

Then you will have to configure nss by changing the following in /etc/nsswitch.conf:

passwd:     files ldap
shadow:     files ldap
group:      files ldap

You will also need to modify your PAM configuration. Generally you will want to edit /etc/pam.d/system-auth but this may very from OS to OS. Always check with the documentation!

auth        sufficient    pam_ldap.so use_first_pass

Use ADS, make your life easier!

I highly recommend Apache Directory Studio as a great LDAP client. It is cross platform (java based) and having a GUI for ldap sometimes just makes more sense as you get to visualize your hierarchy easily. Setup a new connection and login as cn=Manager,dc=crazy,dc=lan using your rootdn password. You can now easily create a template user to be copied for new users, add new groups, add OU's, etc all from a comfortable GUI.

In upcoming posts, I plan on covering enabling TLS encryption, and eventually working on Kerberos integration with LDAP for a true Single SIgn-On (SSO) environment. If all goes well I'll share how I got it all working.

Serving iSCSI targets from your zpool

Allan Feid — Mon, 01 Mar 2010 18:41:48 +0000

If you've already got an OpenSolaris based NFS server, you may be interested in serving iSCSI targets. For me, this is incredibly useful with the right network configurations and a machine running KVM based virtual machines.

What is iSCSI?

If you already know, no point in reading this section but there are some important key things to know when dealing with iSCSI. All this is, is a way of executing SCSI commands over the wire (ethernet, fibre, whatever). You are sharing space at the block level and this is important to realize before you start sharing iSCSI targets amongst multiple hosts. You WILL come into issues doing this without a cluster aware filesystem such as GFS, or a volume management system such as cLVM.

iSCSI of course has its own terminology which you should be aware of. The iSCSI "server" (also referred to as portal) presents targets, and the iSCSI "client" is called the initiator. The initiator searches for available iSCSI targets on your iSCSI portal. I suggest taking a quick glace at the wikipedia artcle on iSCSI if you want more technical knowledge, but as long as you understand these basics you will be running iSCSI in no time.

Give me some targets!

Before you can start assigning targets you need to enable the iscsitgt service.

$ pfexec svcadm enable iscsitgt

Now that we have that out of the way, we can create a zvol of 100G to serve over iSCSI as follows:

$ pfexec zfs create tank/targets
$ pfexec zfs set shareiscsi=on tank/targets
$ pfexec zfs create -V 100G 
$ iscsitadm list target
Target: tank/targets/lun0
    iSCSI Name: iqn.1986-03.com.sun:02:bf1479ba-a71d-c9d7-ab45-d51a1dca3416
    Connections: 1
 tank/targets/lun0

You now have iSCSI targets being presented from your server. Accessing these all depends on your client's OS, so you may be interested in looking at using iscsi targets on Linux. Depending on your network configuration, you may need to limit these targets from being accessible on all interfaces. I highly recommend limiting this as things will get confusing if you are serving the same iSCSI targets from multiple interfaces.

Restricting access

To limit what network interface a target group listens on:

$ pfexec iscsitadm create tpgt 1
$ pfexec iscsitadm modify tpgt -i 10.20.0.2 1
$ iscsitadm list tpgt -v 1
TPGT: 1
    IP Address: 10.20.0.2
$ iscsitadm modify target -p 1 tank/targets/lun0

This creates target group 1, then modifies that group to only listen on 10.20.0.2 and finally apply group 1 to the target tank/targets/lun0. There is also a basic authentication method available called CHAP but in reality your iSCSI network should be completely isolated from other traffic. I do not see it as necessary for the authentication and that just tends to complicate things.

Ultimate File Server: OpenSolaris and ZFS

Allan Feid — Mon, 01 Mar 2010 18:20:38 +0000

When picking out a solution for your central file server, there is of course many options. None of them quite stack up to the ease of administration and redundancy, out of the box, as OpenSolaris and ZFS provide. With ZFS you can build cheap storage arrays with disks of varying size and different levels of redundancy. For this setup I'm going to go with a basic raidz configuration using 4x 1TB SATA drives.

A quick note on ZFS

For those of you aware of ZFS, you can probably go ahead and skip this section, but for those of you that don't I'll give a quick description of how things work in the ZFS world. Instead of partitions and volumes, ZFS gives you pools and datasets. The zpool command gives you control of your pools and zfs command gives you control over your datasets. There is almost no limit to the amount of ZFS datasets you can create and you shouldn't be scared to create new ones for almost everything. Each dataset created allows you to perform individual snapshots, set different share options (iscsi, nfs, etc), apply quotas, compression, and even level of redundancy for those extra important files. These datasets work in a hierarchical format, meaning that any subsets will inherit from their master. Take a look at the below as an example.

$ pfexec zfs create tank/shares
$ pfexec zfs set sharenfs=on tank/shares
$ pfexec zfs create tank/shares/music

The dataset, tank/shares/music, will inherit the sharenfs=on option applied to tank/shares. So it makes sense to create different levels of datasets. Put like datasets inside the same master dataset to easily control options for them all.

Get your ZFS raidz on

Depending on the value of your data you may wish to consider raidz2 but I'm going with the basic single parity raidz which allows for better write performance and is similar to a RAID-5 configuration. For more information on raidz you may wish to check out these RAIDZ configuration requirements and recommendations.

$ pfexec zpool create raidz tank c7d1 c8d0 c8d1 c10d1
$ zpool status tank
  pool: tank
 state: ONLINE
status: The pool is formatted using an older on-disk format.  The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
        pool will no longer be accessible on older software versions.
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            c7d1    ONLINE       0     0     0
            c8d0    ONLINE       0     0     0
            c8d1    ONLINE       0     0     0
            c10d1   ONLINE       0     0     0

errors: No known data errors

Pro tip: iostat -En will give you a list of all your disks.

The first line creates the raidz pool called "tank" using the four disks (c7d1, c8d0, c8d1, c10d1). The second one gives you a nice overview of health for your new pool. It will also tell you if you should upgrade your zpool to a newer version, which as you can see, needs to be done on my storage pool. I created it awhile ago and haven't had the time to upgrade just yet. The man pages for zpool and zfs provide a wealth of information and are good way to learn the ins and outs of maintaining a ZFS system.

NFS on ZFS

This is ridiculously easy to setup. There's no need for touching the exports file, especially since Solaris does not use /etc/exports as other Linux and BSD derivatives do. The following will set you up with a basic export to the 192.168.1.0/24 network and provide read/write access.

$ pfexec zfs create -p tank/share/movies
$ pfexec zfs set sharenfs='rw=192.168.1.0/24' tank/share
$ zfs get -r sharenfs tank/share
NAME               PROPERTY  VALUE              SOURCE
tank/share         sharenfs  rw=192.168.1.0/24  local
tank/share/movies  sharenfs  rw=192.168.1.0/24  inherited from tank/share

For those of you wondering, -r means recursive and can be applied in many different zfs sub-commands. If you need to disable root squashing (not recommended) you can do it per individual IP as follows:

$ pfexec zfs set sharenfs='rw=192.168.1.0/24,root=192.168.1.30/32' tank/share

This will only disable root squashing on 192.168.1.30. One final example, what if you need read only to a different network?

$ pfexec zfs set sharenfs='rw=192.168.1.0/24,root=192.168.1.30/32,ro=10.0.0.0/8' tank/share

Final notes

The real beauty of ZFS is that there is so much control over your file system. At first it may come off as confusing, but stick with it and you will appreciate an OpenSolaris file server over any Linux, *BSD, or Windows solution. To take this a step further, check out serving up iSCSI targets from ZFS, and with the proper network configuration, you can use these targets for KVM virtualization.

Allan Feid - OpenSolaris

Central login management with OpenLDAP

Some information about the network

Basic configurations

Install the needed software!

Configure rsyslog for logging

Importing some data to LDAP

Client configuration

Fedora 12

OpenSolaris

General Configuration for client's using pam_ldap/nss_ldap

Use ADS, make your life easier!

Tags:

Serving iSCSI targets from your zpool

What is iSCSI?

Give me some targets!

Restricting access

Tags:

Ultimate File Server: OpenSolaris and ZFS

A quick note on ZFS

Get your ZFS raidz on

NFS on ZFS

Final notes

Tags: