12.9.06

 

Remote cleanup patch for ZFS Auto-Snapshot

This patch cleans up remote snapshots. Use with zfs-snapshot version 0.6. Thanks Tim for this great utility!

#
# CDDL HEADER START
#
# The contents of this file are subject to the terms of the
# Common Development and Distribution License, Version 1.0 only
# (the "License"). You may not use this file except in compliance
# with the License.
#
# You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
# or http://www.opensolaris.org/os/licensing.
# See the License for the specific language governing permissions
# and limitations under the License.
#
# When distributing Covered Code, include this CDDL HEADER in each
# file and include the License file at usr/src/OPENSOLARIS.LICENSE.
# If applicable, add the following below this CDDL HEADER, with the
# fields enclosed by brackets "[]" replaced with your own identifying
# information: Portions Copyright [yyyy] [name of copyright owner]
#
# CDDL HEADER END
#
# Version 0.1
# This patch adds the backup destroy functionality to zfs-auto-snapshot-0.6
#
# An additional property is needed in the manifest beside the backup-save-cmd.
# This example deletes all snapshots according to the retention policy:
#
# <propval name="backup-destroy-cmd" type="astring"
# value="/usr/bin/ssh user@host /usr/bin/pfexec /usr/sbin/zfs destroy u00/test"
# override="true"/>

281a282,284
> typeset BACKUP_DESTROY_CMD=$(svcprop -p zfs/backup-destroy-cmd $FMRI > | sed -e 's/\\//g')
>
297a301,309
>
> if [ -n "${BACKUP_DESTROY_CMD}" ]
> then
> typeset REMOTE_SNAP=${snapshot##*@}
> echo "Backup snapshot being destroyed as per retention policy."
> $($BACKUP_DESTROY_CMD@$REMOTE_SNAP)
> check_failure $? "Unable to destroy remote snapshot"
> fi

7.6.06

 

Solaris 10 and Novell NDS

I finished my project to use existing Novell NDS accounts on Solaris 10. Here you find, what is needed.

First of all, you have to make sure that all needed schemas are available. Normally the posixAccount and shadowAccount Classes should be available by default. Additional schemas can be found at docs.sun.com.

After that add these classes to the user. Keep in mind, that some attributes might have different names (uid is name userId).

Now a proxy account has to be created. This account is needed by the Solaris Client to browse the directory.

As you are already in Novell's Console One, you can export the server certificates for both LDAP Directories. Make sure they are in pem (b64) format. The certificates will be used for TLS.

Use certutil (in /usr/sfw/bin) to create the cert8 databases and importing the server certificates. Then copy all .db files to /var/ldap.

If everything is done you can initialize the client. I use manual initialization. But if you have a large environment you might find it usefull to store the initialization profile also in the ldap directory.

Initializing the ldapclinet is a little bit tricky. As soon as you run the ldapclient init command, nsswitch.conf will be replaced, with a version that doesn't search for DNS entries.

Without DNS (or at least /etc/hosts entries) the ldap server will not be found, and if you use IP-addresses the certificate will not match. Therefore I use a two step method. First binding to a LDAP Server to port 389 (unsecure), and after that I edit the nsswitch.conf and pam.conf files.

(Another way would be to edit nsswitch.conf during initialization and the kill the cachemgr daemon)

After that I will modify my configuration to use tls:simple and fully qualified hostnames.

ldapclient -v manual -a domainName=domain.net -a authenticationMethod=simple -a credentialLevel=proxy -a proxyDN=cn=proxyUser,ou=ldap,o=organisation -a proxyPassword=password -a defaultSearchBase=o=clariden -a defaultSearchScope=sub -a defaultServerList=xxx.xxx.xxx.xxx -a serviceSearchDescriptor=passwd:o=clariden?sub?groupMembership=cn=solarisprod,ou=Administration,ou=Groups,o=Organisation -a serviceSearchDescriptor=shadow:ou=users,o=organisation?sub -a serviceSearchDescriptor=user_attr:ou=users,o=organisation?sub -a serviceSearchDescriptor=group:ou=users,o=organisation?sub -a serviceSearchDescriptor=audit_user:ou=userso=organisation?sub -a attributeMap=passwd:uid=userId -a attributeMap=user_attr:uid=userId -a attributeMap=audit_user:uid=userId -a certificatePath=/var/ldap


cp /etc/nsswitch.conf.ldap /etc/nsswitch.conf
cp /etc/pam.conf.ldap /etc/pam.conf

ldapclient -v mod -a defaultServerList=ldap1.domain,ldap2.domain -a authenticationMethod=tls:simple

The nsswitch.conf looks like e.g.:

# 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


There is a pam.conf sample on docs.sun.com

A little bit about the ldapclient init attributes, where not self explanatory:

-a serviceSearchDescriptor=passwd:o=organisation?sub?groupMembership=cn=solarisprod,ou=Administration,ou=unixgroups,o=organisation

This means that password entries will be searches if the user contains the groupMembership attribute solarisprod. This is a great way to limit (filtering with LDAP URL) users to certain servers. There are default filters that every service.

-a serviceSearchDescriptor=user_attr:o=Organisation?sub

This is is used for the user_attr database.

-a attributeMap=passwd:uid=userId -a attributeMap=user_attr:uid=userId \

Novell NDS uses internally the uid-attribute for users. In Novell's LDAP implentation this is mapped to userId. Because the Solaris Client searches the attribute by the name uid, this has to be mapped.


As nice as it would be, the pam.conf entry

passwd auth binding pam_passwd_auth.so.1 server_policy

would allow a password change to send the new password in clear text (TLS encrypted) to the LDAP Server to use a universal password. This means a solaris client could also change novell passwords.

But unfortunatly, NDS does not allow a user to change the password directly. The way to achieve this would be, to first delete the password and then add a new one, all in one ldap request.

Technorati Tags: Solaris LDAP Novell

5.6.06

 

Apache 2.2.2 and Novell NDS

I had some trouble with the Sun Solaris included LDAP SDK accessing a Novell NDS for Authentication/Authorization...

Anyway, I wanted to use Secure LDAP, and there's no way to get arround the Novell CLDAP SDK.

Here's the way to compile apache on a T2000. Take a look at all those with-ldap-something paramaters. Took a long time to figure these out. Documentation sucks...

./configure --prefix=/u00/appl/apache2 \
--enable-mods-shared=all \
--enable-ssl \
--enable-authnz-ldap \
--with-ssl=/usr/sfw \
--with-ldap \
--with-ldap-dir=/u00/appl/novell-cldap \
--enable-ldap \
--with-ldap-lib=/u00/appl/novell-cldap/lib \
--with-ldap-include=/u00/appl/novell-cldap/include \
--libdir=/usr/local/lib \
--with-apr=/u00/appl/apache2/apr-httpd \
--with-apr-util=/u00/appl/apache2/apr-util-httpd

It seems there is a bug in Apache's MPM-Worker implementation as my cgi's won't run when using that options. As I don't have that much traffic I don't use it.

What I don't like is, that by default you can't make a "make install" without being root. Apache want's to install the apr stuff into /usr/local/. Therefore you shoud first set the apr prefix to your directory of choice (mine is under apache2).

Here is the httpd.conf

LDAPTrustedGlobalCert CA_BASE64 /u00/appl/apache2/conf/rootca.pem
LDAPVerifyServerCert On
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOPCacheTTL 600
LDAPSharedCacheFile /u00/appl/apache2/logs/ldap_cache

Alias /location /u00/appl/somewhere


AuthType Basic
AuthName "host.domain"
AuthBasicProvider ldap
AuthLDAPURL ldaps://ldap1.domain/o=Organisation?uid
require ldap-attribute ou=OrganisationUnit
Options Indexes
IndexOptions FancyIndexing
IndexStyleSheet "/css/font.css"
Order allow,deny
Allow from all


The certificate is in pem/b64 format.

Good luck!

Technorati Tags: Apache LDAP

22.2.06

 

Enabling LDAP Authentication/Authorization in Apache 2.2

Easy as this:

-Configure with SSL Modules

# ./configure --prefix=path_to_apache/apache2 --enable-mods-shared=all --enable-ssl=shared --enable-authnz-ldap --with-ssl=/usr/local/ssl --with-ldap --enable-ldap

-Install apache

-Configure apache


AuthType Basic
AuthName "Realm Name"
AuthBasicProvider ldap
AuthLDAPURL ldap://ldap1.domain:389/o=Company?uid
require ldap-attribute ou=someValue
Order allow,deny
Allow from all



Apache will connect anonymously to the LDAP Server ldap, to check the existence of the uid. If OK, Apache will connect again to the LDAP Server using the Basic Auth Information from the web browser.

Additionally the require ldap-attribute checks if the user belongs to an ou (Organizational Unit).

That's all, folks!

PS: I have this nasty bug, that if an existing user provides a wrong password the server will create an internal error. This does not happen for non existing users. Strange things happen...

Technorati Tags:

 

Creating a self-signed SSL Certificate for Apache 2.2

This is a great link that describes how to create a self-signed certificate e.g. for apache.
http://www.tc.umn.edu/~brams006/selfsign.html

When using apache 2.2. you can include the file conf/extra/httpd-ssl.conf in your httpd.conf:

# Secure (SSL/TLS) connections
Include conf/extra/httpd-ssl.conf


There you have to set some parameters:

-Enable httpd listening port to 443 (default):

Listen 443

-Paths to keys and certificates:

# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile path_to_apache/apache2/conf/server.key

# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. Keep
# in mind that if you have both an RSA and a DSA certificate you
# can configure both in parallel (to also allow the use of DSA
# ciphers, etc.)
SSLCertificateFile path_to_apache/apache2/conf/server.crt


The browser will negotiate the key length using the SSL Cipher Suite. As the keylenght may be even 256bit, this could slow the connection down a lot. To lower the lenght if possible to 128bit, add/replace following line:

# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite !ADH:!EXPORT56:!EXPORT40:RC4+RSA:+3DES:+MEDIUM:+HIGH:!LOW:+SSLv2:+EXP


!LOW e.g. means that 56bit keys are not allowed.
See http://httpd.apache.org/docs/2.0/mod/mod_ssl.html for a full explanation.

Don't forget to set the pseudo random number generator to /dev/urandom:

# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the SSL library.
# The seed data should be of good random quality.
# WARNING! On some platforms /dev/random blocks if not enough entropy
# is available. This means you then cannot use the /dev/random device
# because it would lead to very long connection times (as long as
# it requires to make more entropy available). But usually those
# platforms additionally provide a /dev/urandom device which doesn't
# block. So, if available, use this one instead. Read the mod_ssl User
# Manual for more details.
#
SSLRandomSeed startup file:/dev/urandom 512
SSLRandomSeed connect file:/dev/urandom 512


After that, restart apache.

Technorati Tags:

 

Solaris ACLs

I can never ever remember how to set ACLs. So this is the way to go...

To narrow it down, I have three users apache, sysaudit, syslogng.

sysaudit and syslogng should be allowed to read and write into the directory (incl. sub-directories), apache should be only allowed to read.

# ls -la
.
.
.
drwxr-x--- 5 root root 512 Feb 17 16:18 auditlog
.
.
.

# getfacl auditlog
# file: auditlog
# owner: root
# group: root
user::rwx
group::r-x #effective:r-x
mask:r-x
other:---

The acl should look like this in the end:


# getfacl auditlog
# file: auditlog
# owner: root
# group: root
user::rwx
user:apache:r-x #effective:r-x
user:syslogng:rwx #effective:rwx
user:sysaudit:rwx #effective:rwx
group::r-x #effective:r-x
mask:rwx
other:---
default:user::rwx
default:user:apache:r-x
default:user:syslogng:rwx
default:user:sysaudit:rwx
default:group::---
default:mask:rwx
default:other:---

Notice:
-default means, that all files created in this directory will inherit the same permissions.
-mask is the maximum permission allowed.
-#effective is calculated by using the AND function between the permission and the mask. As it says, it is the effective permission seen by the user.

I find it easier to edit the ACL using a textfile (once you have a template), than write complex setfacl commands (ugly syntax).

This acl-file can then be applied using setfacl [-r] -f acl_file file.

Another easy way to do this stuff is to use /usr/dt/bin/dtfile. Very usefull to apply the ACLs recursivly to subdirectories.

Technorati Tags:

 

OpenSSH Headache

Another chapter of stupid failures...

Publickey authentication does not work anymore...therefore:

Debugging OpenSSH with Level 3:

# ssh -vvv user@hostname
.
.
.
debug2: we sent a publickey packet, wait for reply
...
debug2: we did not send a packet, disable method
.
.
.

Client debugging shows no useful information...

After using snoop, dtrace and other debugging tools without any real hints, I finally found the reason, using sshd in debugging mode. Important detail: without the option -e, the failure can not be found. This was the reason for loosing a lot of time, because I tried the command already in an early debugging phase, without the option -e.

# sshd -ddd -e

.
.
.
User user not allowed because account is locked
.
.
.


Ahah. The user was locked...This was again a problem that would normally have been solved in a couple of minutes...

Technorati Tags:

28.12.05

 

Welcome to my Blog!

This is my first entry.

May the Blog be with me...

This page is powered by Blogger. Isn't yours?