Roczne Archiwum: 2011

make-3.82

Make jest narzędziem, które kontroluje generowanie plików wykonywalnych i innych nie źródłowych plików programu z plików źródłowych programu. Innymi słowy: generuje binarki i biblioteki ze źródeł programu na podstawie plików Makefile.

libtol-2.4

GNU libtool jest skryptem wspierającym typowe biblioteki. Libtool ukrywa komplikację używania współdzielonych bibliotek za spójnym, przenośnym interfejsem.

Konfiguracja i kompilacja przy użyciu skryptu (w załączeniu):

automake-1.11.1

GNU Automake jest narzędziem do automatycznego generowania plików 'Makefile.in’, które są zgodne z GNU Coding Standards. Automake wymaga użycia Autoconf, którego kompilację opisałem tutaj.

Konfiguracja i kompilacja Automake przy użyciu skryptu (w załączeniu):

autoconf-2.68

GNU Autoconf jest rozszerzalnym pakietem makr M4 do tworzenia skryptów powłoki do automatycznej konfiguracji pakietów oprogramowania Open Source. Tworzenie skryptów konfiguracyjnych przy użyciu Autoconf wymaga instalacji GNU M4.

m4-1.4.16

GNU M4 jest implementacją tradycyjnego UNIXowego procesora makr. Jest w większości kompatybilny z SRV4, ale posiada pewne rozszerzenia (np. przekazywanie więcej niż 9 pozycjonowanych parametrów do makr). GNU M4 posiada również wbudowane funkcje do włączania plików, wykonywania poleceń powłoki, robienia arytmetyki itp. Jednym z największych beneficjentów GNU M4 jest projekt GNU Autoconf.

Konfiguracja i kompilacja przy użyciu skryptu (w załączeniu):

tar-1.26

Solarisowy tar ma trochę braków w stosunku do programu GNU Tar. Na przykład nie rozpoznaje skompresowanych archiwów. Warto więc zainstalować jego odpowiednika GNU. Ja dla rozróżnienia dodaję do GNU Tar przedrostek 'g’ (opcja –program-prefix=g przy kompilacji).

Konfiguracja i kompilacja z użyciem skryptu (w załączeniu):

Mail system authentication in LDAP

I suppose that Dovecot and Postfix are up and running, and you can receive and send mail with system user (see previous posts). It is time to configure authentication in LDAP.

Use of directory service to user authentication allows for flexible management of mail system, hosting and so on. LDAP is established standard for authentication and authorization and almost all software which requires authentication support this protocol.

Let’s begin from POP3/IMAP Dovecot server, which also deliver authentication mechanism for Postfix:

/usr/bin/sudo -i
cd /etc/dovecot
vi dovecot-ldap.conf

Mail system authentication in LDAP

I suppose that Dovecot and Postfix are up and running, and you can receive and send mail with system user (see previous posts). It is time to configure authentication in LDAP.

Use of directory service to user authentication allows for flexible management of mail system, hosting and so on. LDAP is established standard for authentication and authorization and almost all software which requires authentication support this protocol.

Let’s begin from POP3/IMAP Dovecot server, which also deliver authentication mechanism for Postfix:


/usr/bin/sudo -i
cd /etc/dovecot
vi dovecot-ldap.conf

In this file you need to define LDAP server/s parameters, authentication method, filter and attributes. I list those most important:


hosts = localhost
auth_bind = yes
base = o=hosting,dc=example,dc=com
scope = subtree
user_attrs = homeDirectory=home
user_filter = (&(objectClass=mailUser)(mail=%u))
pass_attrs = mail=user,userPassword=password
pass_filter = (&(objectClass=mailUser)(mail=%u))

Schema conversion – LDAP to LDIF

The power of directory service is possibility to define your own object classes, attributes, rules and so on. It also allows grouping it in schemas, which you can add to LDAP configuration.

As for now most of schemas, which you can find in Internet is organized into blocks, which contains definitions of attributes and object classes. This looks like:

attribute type definition:


attributetype ( 1.3.6.1.4.1.32349.1.2.2.9 NAME 'accountStatus'
    DESC 'The status of a user account: active, disabled'
    EQUALITY caseIgnoreIA5Match
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )

Schema conversion – LDAP to LDIF

The power of directory service is possibility to define your own object classes, attributes, rules and so on. It also allows grouping it in schemas, which you can add to LDAP configuration.

As for now most of schemas, which you can find in Internet is organized into blocks, which contains definitions of attributes and object classes. This looks like:

attribute type definition:


attributetype ( 1.3.6.1.4.1.32349.1.2.2.9 NAME 'accountStatus'
    DESC 'The status of a user account: active, disabled'
    EQUALITY caseIgnoreIA5Match
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
    SINGLE-VALUE )