Hello,
AIX-en openldap library-k hasznalataval mukodik az LDAP alapu sudo.
Hozzavalok:
- sudo source (nalam 1.7.4p3)
- openldap, openldap-devel (nalam 2.4.11, bullfreeware.org-rol)
- compiler (nalam xlC 10.1, de termeszetesen gcc is megfelel)
Az openldap libraryket itt ugy hasznaltam, ahogy az rpm-ekbol telepultek, de a vegso formajaban 'nativ' AIX BFF package lesz majd belole, ami tartalmazni fogja az osszes konfigot es libraryt.
Az LDAP szerveren kell a sudoers-t konfiguralni, erre (is) remek peldak vannak a hivatalos oldalon.
1.) openldap install
2.) configure es make
Atmenetileg az alabbi flageket hasznaltam (a vegleges nem ez lesz), de van meg vagy 20-30, tetszes szerint beallithatok, a lenyeg az LDFLAGS es a --with-ldap.
Ha megvan, hogy a csomagban veglegesen hova szeretnenk tenni a librarykat, ezeket kell modositani.
$ LDFLAGS='-blibpath:/opt/freeware/lib:/usr/lib:/lib' ./configure --with-ldap=/opt/freeware --with-ldap-conf-file=/etc/ldap.conf --prefix=/usr/local --without-lecture --with-
logging=both --with-insults --with-classic-insults --without-interfaces
$ make
Ha nem a make installt hasznaljuk, a sudo binarisnak 4111 jog kell.
3.) AIX konfiguracios file-ok
/etc/ldap.conf
Nalam igy nez ki:
host 10.0.0.1
base c=(c)
sudoers_base ou=(ou),dc=(dc),c=(c)
SUDOERS_DEBUG 1
binddn cn=(cn),o=(o)
bindpw (looong hash)
port 389
scope sub
timelimit 30
bind_timelimit 10
bind_policy soft
pam_login_attribute cn
pam_lookup_policy no
pam_password foo
nss_initgroups_ignoreusers root,ldap
nss_schema rfc2307bis
nss_base_group ou=(ou),dc=(dc),c=(c)
nss_base_sudoers ou=(ou),ou=(ou),o=(o)
nss_map_attribute uniqueMember member
nss_map_attribute uid cn
ssl start_tls
ldap_version 3
pam_filter objectClass=posixAccount
tls_checkpeer no
/etc/netsvc.conf
A sudo-ba bele van hegesztve, hogy AIX-en az nsswitch.conf helyett ebben keresgeljen. Ennyi eleg a vegere:
sudoers = ldap, files
Innentol minden, LDAP-bol authentikalt es a 'central' sudoers-ben joggal rendelkezo user tudja hasznalni a sudo-t. Mivel a debug a fenti esetben be van kapcsolva a szerveren, minden sudo muveletre terjedelmes informaciot kapunk, de ebbol mar latszik, hogy mukodik a dolog.
Tovabbi tippek:
- sudo -V tobbek kozott a configure flageket is kiirja
- mivel a sudo nem engedi a LIBPATH hasznalatat, ezert ha a -blibpath opcioval nincs beforditva az openldap library path, userek nem tudjak hasznalni a binarist
- sajnos az AIX/IBM idsldap-pal nem mukodik
Hozzászólások
Könyvjelzőzés.
Kérdés: a third party forrásokat (itt a bullfreeware) mennyire bevett szokás nálatok produktív környezetben használni?
--
2e845cb4c3a5b5bd6508455b1739a8a2
Igazsag szerint erre nincsen hivatalos policy (vagy legalabbis eleg nehezen lenne ertelmezheto). Audit nincs, a 'sandbox' megvan a terjedelmes tesztkornyezet reven, a kritikusnak itelt dolgok eseten sajat buildeket hasznalunk. Amugy fel kezemen meg tudom szamolni, mikre van szukseg (pl bash, bzip2, zlib, wget, rsync, screen).
A linuxtoolbox lenyegeben kalap sz.rt sem er, annyira elavult, ezert egy ideje perzl.org RPM-eket szoktam hasznalni.
Az a baj, hogy ha elmennenk abba az iranyba, hogy sajat build kornyezetet epitsunk, nem lenne elegendo eroforras ennek a karbantartasara. De hosszu tavon persze jo lenne, sokkal jobban megfelelne az igenyeinknek.
OS/TL upgradenél nem üt ez vissza ???
A tapasztalat szerint nem szokott (ugyebar 'linuxtoolbox upgrade' sem letezik), nem veletlenul kerulnek teljesen mashova a tenyleges binarisok/libek az rpm-ekbol, /usr alatt csak linkek vannak.
Az eddigi egyetlen 'fuckup' az volt, hogy az AIX altal szallitott gyari rpm.rte az update alatt lekapott valamit, ami a gettext-hez tartozott, ezert azt ujra fel kellett tenni.