From mike at flyn.org Tue Apr 1 13:53:27 2008 From: mike at flyn.org (W. Michael Petullo) Date: Tue, 1 Apr 2008 18:23:27 +0430 Subject: [Freeipa-devel] [PATCH] Replace OpenLDAP with mozldap In-Reply-To: <20080228091514.GA21896@imp.flyn.org> References: <20080224141040.GA19318@imp.flyn.org> <1204066438.5684.47.camel@localhost.localdomain> <20080228091514.GA21896@imp.flyn.org> Message-ID: <20080401135327.GA27918@imp.flyn.org> >>> I've attached a patch that begins the process of replacing OpenLDAP with >>> mozldap. FreeIPA relies on RedHat's Directory Server, which uses mozldap. A >>> FreeIPA build using mozldap would reduce the project's dependencies and >>> redundant code. In addition, mozldap uses NSS instead of OpenSSL. This is >>> beneficial for the reasons listed in [1]. >>> >>> [1] http://fedoraproject.org/wiki/FedoraCryptoConsolidation >> patch may make sense for shipping for Fedora, but it would be better to >> have a patch that makes the choice between mozldap or openldap libraries >> a compile time option. >> This is because admin tools and client tools are not meant to be run on >> the server only and other distributions may not ship the mozldap bits. >> >> Do you think you can modify the patch to make it possible to select >> either library through a configure option ? > > Attached is a new patch. > > This patch now allows one to specify --with-openldap if they want to continue > using OpenLDAP, otherwise mozldap is used. The exception is ipa-server's > ipa-slapi-plugins, which will not build against OpenLDAP. Is there any interest in this patch? Is there something I can do to improve it in order to get it accepted? Mike Petullo -------------- next part -------------- Only in freeipa-0.99/ipa-client: aclocal.m4 Only in freeipa-0.99/ipa-client: autom4te.cache Only in freeipa-0.99/ipa-client: config.guess Only in freeipa-0.99/ipa-client: config.h.in Only in freeipa-0.99/ipa-client: config.sub Only in freeipa-0.99/ipa-client: configure diff -u --recursive freeipa-0.99-vanilla/ipa-client/configure.ac freeipa-0.99/ipa-client/configure.ac --- freeipa-0.99-vanilla/ipa-client/configure.ac 2008-02-18 18:21:39.000000000 +0430 +++ freeipa-0.99/ipa-client/configure.ac 2008-02-28 01:22:57.000000000 +0430 @@ -82,42 +82,47 @@ AC_SUBST(KRB5_LIBS) dnl --------------------------------------------------------------------------- -dnl - Check for LDAP +dnl - Check for Mozilla LDAP or OpenLDAP SDK dnl --------------------------------------------------------------------------- -LDAP_LIBS= -AC_CHECK_HEADER(ldap.h) -AC_CHECK_HEADER(lber.h) - -AC_CHECK_LIB(ldap, ldap_search, with_ldap=yes) -dnl Check for other libraries we need to link with to get the main routines. -test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes], , -llber) } -test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes with_ldap_krb=yes], , -llber -lkrb) } -test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes with_ldap_krb=yes with_ldap_des=yes], , -llber -lkrb -ldes) } -dnl Recently, we need -lber even though the main routines are elsewhere, -dnl because otherwise be get link errors w.r.t. ber_pvt_opt_on. So just -dnl check for that (it's a variable not a fun but that doesn't seem to -dnl matter in these checks) and stick in -lber if so. Can't hurt (even to -dnl stick it in always shouldn't hurt, I don't think) ... #### Someone who -dnl #### understands LDAP needs to fix this properly. -test "$with_ldap_lber" != "yes" && { AC_CHECK_LIB(lber, ber_pvt_opt_on, with_ldap_lber=yes) } - -if test "$with_ldap" = "yes"; then - if test "$with_ldap_des" = "yes" ; then - LDAP_LIBS="${LDAP_LIBS} -ldes" - fi - if test "$with_ldap_krb" = "yes" ; then - LDAP_LIBS="${LDAP_LIBS} -lkrb" - fi - if test "$with_ldap_lber" = "yes" ; then - LDAP_LIBS="${LDAP_LIBS} -llber" - fi - LDAP_LIBS="${LDAP_LIBS} -lldap" +AC_ARG_WITH(openldap, [ --with-openldap Use OpenLDAP]) + +if test x$with_openldap = xyes; then + AC_CHECK_LIB(ldap, ldap_search, with_ldap=yes) + dnl Check for other libraries we need to link with to get the main routines. + test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes], , -llber) } + test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes with_ldap_krb=yes], , -llber -lkrb) } + test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes with_ldap_krb=yes with_ldap_des=yes], , -llber -lkrb -ldes) } + dnl Recently, we need -lber even though the main routines are elsewhere, + dnl because otherwise be get link errors w.r.t. ber_pvt_opt_on. So just + dnl check for that (it's a variable not a fun but that doesn't seem to + dnl matter in these checks) and stick in -lber if so. Can't hurt (even to + dnl stick it in always shouldn't hurt, I don't think) ... #### Someone who + dnl #### understands LDAP needs to fix this properly. + test "$with_ldap_lber" != "yes" && { AC_CHECK_LIB(lber, ber_pvt_opt_on, with_ldap_lber=yes) } + + if test "$with_ldap" = "yes"; then + if test "$with_ldap_des" = "yes" ; then + OPENLDAP_LIBS="${OPENLDAP_LIBS} -ldes" + fi + if test "$with_ldap_krb" = "yes" ; then + OPENLDAP_LIBS="${OPENLDAP_LIBS} -lkrb" + fi + if test "$with_ldap_lber" = "yes" ; then + OPENLDAP_LIBS="${OPENLDAP_LIBS} -llber" + fi + OPENLDAP_LIBS="${OPENLDAP_LIBS} -lldap" + else + AC_MSG_ERROR([OpenLDAP not found]) + fi + + AC_SUBST(OPENLDAP_LIBS) else - AC_MSG_ERROR([LDAP not found]) + PKG_CHECK_MODULES(MOZLDAP, mozldap > 6) + MOZLDAP_CFLAGS="${MOZLDAP_CFLAGS} -DWITH_MOZLDAP" + AC_SUBST(MOZLDAP_CFLAGS) fi -AC_SUBST(LDAP_LIBS) dnl --------------------------------------------------------------------------- dnl - Check for POPT Only in freeipa-0.99/ipa-client: COPYING Only in freeipa-0.99/ipa-client: depcomp Only in freeipa-0.99/ipa-client/firefox: Makefile.in Only in freeipa-0.99/ipa-client: INSTALL Only in freeipa-0.99/ipa-client: install-sh Only in freeipa-0.99/ipa-client/ipaclient: Makefile.in diff -u --recursive freeipa-0.99-vanilla/ipa-client/ipa-getkeytab.c freeipa-0.99/ipa-client/ipa-getkeytab.c --- freeipa-0.99-vanilla/ipa-client/ipa-getkeytab.c 2008-02-18 18:21:39.000000000 +0430 +++ freeipa-0.99/ipa-client/ipa-getkeytab.c 2008-02-28 09:42:09.000000000 +0430 @@ -31,7 +31,11 @@ #include #include #include +#ifdef WITH_MOZLDAP +#include +#else #include +#endif #include #include @@ -275,7 +279,6 @@ BerElement *ctrl = NULL; BerElement *sctrl = NULL; struct berval *control = NULL; - char *ldap_uri = NULL; struct berval **ncvals; char *ldap_base = NULL; char *retoid = NULL; @@ -306,23 +309,16 @@ goto error_out; } - /* connect to ldap server */ - ret = asprintf(&ldap_uri, "ldap://%s:389", servername); - if (ret == -1) { - fprintf(stderr, "Unable to determine server URI!\n"); - goto error_out; - } - /* TODO: support referrals ? */ - ret = ldap_initialize(&ld, ldap_uri); - if(ret != LDAP_SUCCESS) { + ld = ldap_init(servername, 389); + if(ld == NULL) { fprintf(stderr, "Unable to initialize ldap library!\n"); goto error_out; } version = LDAP_VERSION3; ret = ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &version); - if (ret != LDAP_OPT_SUCCESS) { + if (ret != LDAP_SUCCESS) { fprintf(stderr, "Unable to set ldap options!\n"); goto error_out; } @@ -427,8 +423,7 @@ ber_free(sctrl, 1); ldap_controls_free(srvctrl); ldap_msgfree(res); - ldap_unbind_ext_s(ld, NULL, NULL); - free(ldap_uri); + ldap_unbind_ext(ld, NULL, NULL); return kvno; error_out: @@ -436,8 +431,7 @@ if (srvctrl) ldap_controls_free(srvctrl); if (err) ldap_memfree(err); if (res) ldap_msgfree(res); - if (ld) ldap_unbind_ext_s(ld, NULL, NULL); - if (ldap_uri) free(ldap_uri); + if (ld) ldap_unbind_ext(ld, NULL, NULL); if (control) ber_bvfree(control); if (encs) free(encs); return 0; Only in freeipa-0.99/ipa-client/ipa-install: Makefile.in Only in freeipa-0.99/ipa-client: ltmain.sh diff -u --recursive freeipa-0.99-vanilla/ipa-client/Makefile.am freeipa-0.99/ipa-client/Makefile.am --- freeipa-0.99-vanilla/ipa-client/Makefile.am 2008-02-18 18:21:39.000000000 +0430 +++ freeipa-0.99/ipa-client/Makefile.am 2008-02-28 00:42:37.000000000 +0430 @@ -13,7 +13,8 @@ -DLIBEXECDIR=\""$(libexecdir)"\" \ -DDATADIR=\""$(datadir)"\" \ $(KRB5_CFLAGS) \ - $(LDAP_CFLAGS) \ + $(OPENLDAP_CFLAGS) \ + $(MOZLDAP_CFLAGS) \ $(SASL_CFLAGS) \ $(POPT_CFLAGS) \ $(WARN_CFLAGS) \ @@ -29,7 +30,8 @@ ipa_getkeytab_LDADD = \ $(KRB5_LIBS) \ - $(LDAP_LIBS) \ + $(OPENLDAP_LIBS) \ + $(MOZLDAP_LIBS) \ $(SASL_LIBS) \ $(POPT_LIBS) \ $(NULL) Only in freeipa-0.99/ipa-client: Makefile.in Only in freeipa-0.99/ipa-client: missing Only in freeipa-0.99/ipa-client: py-compile Only in freeipa-0.99/ipa-server: aclocal.m4 Only in freeipa-0.99/ipa-server: autom4te.cache Only in freeipa-0.99/ipa-server: config.guess Only in freeipa-0.99/ipa-server: config.h.in Only in freeipa-0.99/ipa-server: config.sub Only in freeipa-0.99/ipa-server: configure diff -u --recursive freeipa-0.99-vanilla/ipa-server/configure.ac freeipa-0.99/ipa-server/configure.ac --- freeipa-0.99-vanilla/ipa-server/configure.ac 2008-02-18 18:21:39.000000000 +0430 +++ freeipa-0.99/ipa-server/configure.ac 2008-02-28 13:13:16.000000000 +0430 @@ -87,48 +87,55 @@ AC_SUBST(KRB5_LIBS) dnl --------------------------------------------------------------------------- -dnl - Check for LDAP +dnl - Check for Mozilla LDAP or OpenLDAP SDK dnl --------------------------------------------------------------------------- -LDAP_LIBS= -AC_CHECK_HEADER(ldap.h) -AC_CHECK_HEADER(lber.h) - -AC_CHECK_LIB(ldap, ldap_search, with_ldap=yes) -dnl Check for other libraries we need to link with to get the main routines. -test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes], , -llber) } -test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes with_ldap_krb=yes], , -llber -lkrb) } -test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes with_ldap_krb=yes with_ldap_des=yes], , -llber -lkrb -ldes) } -dnl Recently, we need -lber even though the main routines are elsewhere, -dnl because otherwise be get link errors w.r.t. ber_pvt_opt_on. So just -dnl check for that (it's a variable not a fun but that doesn't seem to -dnl matter in these checks) and stick in -lber if so. Can't hurt (even to -dnl stick it in always shouldn't hurt, I don't think) ... #### Someone who -dnl #### understands LDAP needs to fix this properly. -test "$with_ldap_lber" != "yes" && { AC_CHECK_LIB(lber, ber_pvt_opt_on, with_ldap_lber=yes) } - -if test "$with_ldap" = "yes"; then - if test "$with_ldap_des" = "yes" ; then - LDAP_LIBS="${LDAP_LIBS} -ldes" - fi - if test "$with_ldap_krb" = "yes" ; then - LDAP_LIBS="${LDAP_LIBS} -lkrb" - fi - if test "$with_ldap_lber" = "yes" ; then - LDAP_LIBS="${LDAP_LIBS} -llber" - fi - LDAP_LIBS="${LDAP_LIBS} -lldap" -else - AC_MSG_ERROR([LDAP not found]) -fi +AC_ARG_WITH(openldap, [ --with-openldap Use OpenLDAP]) -AC_SUBST(LDAP_LIBS) +dnl The mozldap libraries are always needed because ipa-slapi-plugins/dna/ +dnl will not build against OpenLDAP. +PKG_CHECK_MODULES(MOZLDAP, mozldap > 6) -dnl --------------------------------------------------------------------------- -dnl - Check for Mozilla LDAP SDK -dnl --------------------------------------------------------------------------- +if test x$with_openldap = xyes; then + AC_CHECK_LIB(ldap, ldap_search, with_ldap=yes) + dnl Check for other libraries we need to link with to get the main routines. + test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes], , -llber) } + test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes with_ldap_krb=yes], , -llber -lkrb) } + test "$with_ldap" != "yes" && { AC_CHECK_LIB(ldap, ldap_open, [with_ldap=yes with_ldap_lber=yes with_ldap_krb=yes with_ldap_des=yes], , -llber -lkrb -ldes) } + dnl Recently, we need -lber even though the main routines are elsewhere, + dnl because otherwise be get link errors w.r.t. ber_pvt_opt_on. So just + dnl check for that (it's a variable not a fun but that doesn't seem to + dnl matter in these checks) and stick in -lber if so. Can't hurt (even to + dnl stick it in always shouldn't hurt, I don't think) ... #### Someone who + dnl #### understands LDAP needs to fix this properly. + test "$with_ldap_lber" != "yes" && { AC_CHECK_LIB(lber, ber_pvt_opt_on, with_ldap_lber=yes) } + + if test "$with_ldap" = "yes"; then + if test "$with_ldap_des" = "yes" ; then + LDAP_LIBS="${LDAP_LIBS} -ldes" + fi + if test "$with_ldap_krb" = "yes" ; then + LDAP_LIBS="${LDAP_LIBS} -lkrb" + fi + if test "$with_ldap_lber" = "yes" ; then + LDAP_LIBS="${LDAP_LIBS} -llber" + fi + LDAP_LIBS="${LDAP_LIBS} -lldap" + else + AC_MSG_ERROR([OpenLDAP not found]) + fi + + AC_SUBST(LDAP_LIBS) -PKG_CHECK_MODULES(MOZLDAP, mozldap > 6) + LDAP_CFLAGS="${LDAP_CFLAGS} -DWITH_OPENLDAP" + AC_SUBST(LDAP_CFLAGS) +else + LDAP_LIBS="${MOZLDAP_LIBS}" + AC_SUBST(LDAP_LIBS) + + LDAP_CFLAGS="${LDAP_CFLAGS} -DWITH_MOZLDAP" + AC_SUBST(LDAP_CFLAGS) +fi dnl --------------------------------------------------------------------------- dnl - Check for OpenSSL Crypto library Only in freeipa-0.99/ipa-server: COPYING Only in freeipa-0.99/ipa-server: depcomp Only in freeipa-0.99/ipa-server: INSTALL Only in freeipa-0.99/ipa-server: install-sh Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/config: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/forms: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/helpers: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/static/css: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/static/images/branding: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/static/images: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/static/images/template: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/static/javascript: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/static: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/subcontrollers: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/templates: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipagui/tests: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui/ipa_gui.egg-info: Makefile.in Only in freeipa-0.99/ipa-server/ipa-gui: Makefile.in Only in freeipa-0.99/ipa-server/ipa-install: Makefile.in Only in freeipa-0.99/ipa-server/ipa-install/share: Makefile.in diff -u --recursive freeipa-0.99-vanilla/ipa-server/ipa-kpasswd/ipa_kpasswd.c freeipa-0.99/ipa-server/ipa-kpasswd/ipa_kpasswd.c --- freeipa-0.99-vanilla/ipa-server/ipa-kpasswd/ipa_kpasswd.c 2008-02-18 18:21:39.000000000 +0430 +++ freeipa-0.99/ipa-server/ipa-kpasswd/ipa_kpasswd.c 2008-02-28 09:41:37.000000000 +0430 @@ -39,13 +39,23 @@ #include #include #include +#ifdef WITH_MOZLDAP +#include +#else #include +#endif #include #define DEFAULT_KEYTAB "FILE:/var/kerberos/krb5kdc/kpasswd.keytab" #define TMP_TEMPLATE "/tmp/kpasswd.XXXXXX" #define KPASSWD_PORT 464 +#ifdef WITH_MOZLDAP +/* From OpenLDAP's ldap.h */ +#define LDAP_TAG_EXOP_MODIFY_PASSWD_ID ((ber_tag_t) 0x80U) +#define LDAP_TAG_EXOP_MODIFY_PASSWD_NEW ((ber_tag_t) 0x82U) +#endif + /* blacklist entries are released only BLCAKLIST_TIMEOUT seconds * after the children performing the noperation has finished. * this is to avoid races */ @@ -310,7 +320,6 @@ struct berval control; struct berval newpw; char hostname[1024]; - char *ldap_uri = NULL; struct berval **ncvals; char *ldap_base = NULL; char *filter; @@ -367,17 +376,10 @@ goto done; } - ret = asprintf(&ldap_uri, "ldap://%s:389", hostname); - if (ret == -1) { - syslog(LOG_ERR, "Out of memory!"); - ret = KRB5_KPASSWD_HARDERROR; - goto done; - } - /* connect to ldap server */ /* TODO: support referrals ? */ - ret = ldap_initialize(&ld, ldap_uri); - if(ret != LDAP_SUCCESS) { + ld = ldap_init(hostname, 389); + if(ld == NULL) { syslog(LOG_ERR, "Unable to connect to ldap server"); ret = KRB5_KPASSWD_HARDERROR; goto done; @@ -385,7 +387,7 @@ version = LDAP_VERSION3; ret = ldap_set_option(ld, LDAP_OPT_PROTOCOL_VERSION, &version); - if (ret != LDAP_OPT_SUCCESS) { + if (ret != LDAP_SUCCESS) { syslog(LOG_ERR, "Unable to set ldap protocol version"); ret = KRB5_KPASSWD_HARDERROR; goto done; @@ -480,11 +482,12 @@ ret = KRB5_KPASSWD_HARDERROR; goto done; } + ber_printf(ctrl, "{tstON}", LDAP_TAG_EXOP_MODIFY_PASSWD_ID, userdn, LDAP_TAG_EXOP_MODIFY_PASSWD_NEW, &newpw); - ret = ber_flatten2(ctrl, &control, 0); + ret = ber_flatten(ctrl, &control); if (ret < 0) { syslog(LOG_ERR, "ber flattening failed!"); ret = KRB5_KPASSWD_HARDERROR; @@ -645,8 +648,7 @@ if (exterr1) free(exterr1); if (exterr2) free(exterr2); if (userdn) free(userdn); - if (ld) ldap_unbind_ext_s(ld, NULL, NULL); - if (ldap_uri) free(ldap_uri); + if (ld) ldap_unbind_ext(ld, NULL, NULL); if (tmp_file) { unlink(tmp_file); free(tmp_file); Only in freeipa-0.99/ipa-server/ipa-kpasswd: Makefile.in Only in freeipa-0.99/ipa-server/ipaserver: Makefile.in diff -u --recursive freeipa-0.99-vanilla/ipa-server/ipa-slapi-plugins/dna/Makefile.am freeipa-0.99/ipa-server/ipa-slapi-plugins/dna/Makefile.am --- freeipa-0.99-vanilla/ipa-server/ipa-slapi-plugins/dna/Makefile.am 2008-02-18 18:21:39.000000000 +0430 +++ freeipa-0.99/ipa-server/ipa-slapi-plugins/dna/Makefile.am 2008-02-28 13:05:26.000000000 +0430 @@ -9,7 +9,6 @@ -DLIBEXECDIR=\""$(libexecdir)"\" \ -DDATADIR=\""$(datadir)"\" \ $(MOZLDAP_CFLAGS) \ - $(LDAP_CFLAGS) \ $(KRB5_CFLAGS) \ $(WARN_CFLAGS) \ $(NULL) Only in freeipa-0.99/ipa-server/ipa-slapi-plugins/dna: Makefile.in diff -u --recursive freeipa-0.99-vanilla/ipa-server/ipa-slapi-plugins/ipa-memberof/Makefile.am freeipa-0.99/ipa-server/ipa-slapi-plugins/ipa-memberof/Makefile.am --- freeipa-0.99-vanilla/ipa-server/ipa-slapi-plugins/ipa-memberof/Makefile.am 2008-02-18 18:21:39.000000000 +0430 +++ freeipa-0.99/ipa-server/ipa-slapi-plugins/ipa-memberof/Makefile.am 2008-02-28 13:05:17.000000000 +0430 @@ -9,7 +9,6 @@ -DLIBEXECDIR=\""$(libexecdir)"\" \ -DDATADIR=\""$(datadir)"\" \ $(MOZLDAP_CFLAGS) \ - $(LDAP_CFLAGS) \ $(KRB5_CFLAGS) \ $(WARN_CFLAGS) \ $(NULL) Only in freeipa-0.99/ipa-server/ipa-slapi-plugins/ipa-memberof: Makefile.in diff -u --recursive freeipa-0.99-vanilla/ipa-server/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am freeipa-0.99/ipa-server/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am --- freeipa-0.99-vanilla/ipa-server/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am 2008-02-18 18:21:39.000000000 +0430 +++ freeipa-0.99/ipa-server/ipa-slapi-plugins/ipa-pwd-extop/Makefile.am 2008-02-28 13:04:58.000000000 +0430 @@ -9,7 +9,6 @@ -DLIBEXECDIR=\""$(libexecdir)"\" \ -DDATADIR=\""$(datadir)"\" \ $(MOZLDAP_CFLAGS) \ - $(LDAP_CFLAGS) \ $(KRB5_CFLAGS) \ $(SSL_CFLAGS) \ $(WARN_CFLAGS) \ Only in freeipa-0.99-vanilla/ipa-server/ipa-slapi-plugins/ipa-pwd-extop: .Makefile.am.swp Only in freeipa-0.99/ipa-server/ipa-slapi-plugins/ipa-pwd-extop: Makefile.in Only in freeipa-0.99/ipa-server/ipa-slapi-plugins: Makefile.in Only in freeipa-0.99/ipa-server: ltmain.sh Only in freeipa-0.99/ipa-server: Makefile.in Only in freeipa-0.99/ipa-server: missing Only in freeipa-0.99/ipa-server: py-compile Only in freeipa-0.99/ipa-server/xmlrpc-server: Makefile.in Only in freeipa-0.99/ipa-server/xmlrpc-server/test: Makefile.in From rcritten at redhat.com Tue Apr 1 19:44:18 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Apr 2008 15:44:18 -0400 Subject: [Freeipa-devel] [PATCH] fix an selinux problem with ipa_kpasswd Message-ID: <47F29092.80508@redhat.com> An SELinux AVC was thrown related to /proc during a password reset. This fixes that on some systems. It is still broken on Fedora 7 at least. Pushed under one-liner rule. Patch provided by Dan Walsh. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-775-selinux.patch Type: text/x-patch Size: 780 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Apr 1 19:48:03 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Apr 2008 15:48:03 -0400 Subject: [Freeipa-devel] [PATCH] fix crash iterating over None variable Message-ID: <47F29173.8090203@redhat.com> In the group_members() function I wasn't checking to see if a variable was None and we were iterating over it, causing a crash. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-776-groups.patch Type: text/x-patch Size: 1335 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Tue Apr 1 20:01:58 2008 From: jdennis at redhat.com (John Dennis) Date: Tue, 01 Apr 2008 16:01:58 -0400 Subject: [Freeipa-devel] [PATCH] fix an selinux problem with ipa_kpasswd In-Reply-To: <47F29092.80508@redhat.com> References: <47F29092.80508@redhat.com> Message-ID: <47F294B6.9040208@redhat.com> Rob Crittenden wrote: > An SELinux AVC was thrown related to /proc during a password reset. This > fixes that on some systems. It is still broken on Fedora 7 at least. Rob, are you aware there is a tool which will watch a running system and pop up a notification whenever an AVC denial occurs? This can be a useful thing during development because AVC's may go unnoticed and it's best to get them fixed ASAP. The tool also works in permissive mode so you still get the notifications but nothing is blocked. The tool is setroubleshoot and the desktop GUI component is sealert. Typically it's installed and enabled. The sealert GUI depends on the setroubleshoot service, the normal service and chkconfig commands apply. -- John Dennis From ssorce at redhat.com Tue Apr 1 20:05:17 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Apr 2008 16:05:17 -0400 Subject: [Freeipa-devel] [PATCH] fix an selinux problem with ipa_kpasswd In-Reply-To: <47F29092.80508@redhat.com> References: <47F29092.80508@redhat.com> Message-ID: <1207080317.3533.244.camel@localhost.localdomain> On Tue, 2008-04-01 at 15:44 -0400, Rob Crittenden wrote: > An SELinux AVC was thrown related to /proc during a password reset. > This > fixes that on some systems. It is still broken on Fedora 7 at least. > > Pushed under one-liner rule. Patch provided by Dan Walsh. ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Apr 1 20:06:17 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Apr 2008 16:06:17 -0400 Subject: [Freeipa-devel] [PATCH] fix crash iterating over None variable In-Reply-To: <47F29173.8090203@redhat.com> References: <47F29173.8090203@redhat.com> Message-ID: <1207080377.3533.246.camel@localhost.localdomain> On Tue, 2008-04-01 at 15:48 -0400, Rob Crittenden wrote: > In the group_members() function I wasn't checking to see if a > variable > was None and we were iterating over it, causing a crash. ack only the group part, I wll take on the ipa_kpasswd fix which need changes the path used in the spec file and makefiles as well. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Apr 1 20:17:15 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Apr 2008 16:17:15 -0400 Subject: [Freeipa-devel] [PATCH] fix an selinux problem with ipa_kpasswd In-Reply-To: <47F294B6.9040208@redhat.com> References: <47F29092.80508@redhat.com> <47F294B6.9040208@redhat.com> Message-ID: <47F2984B.5000102@redhat.com> John Dennis wrote: > Rob Crittenden wrote: >> An SELinux AVC was thrown related to /proc during a password reset. >> This fixes that on some systems. It is still broken on Fedora 7 at least. > > Rob, are you aware there is a tool which will watch a running system and > pop up a notification whenever an AVC denial occurs? This can be a > useful thing during development because AVC's may go unnoticed and it's > best to get them fixed ASAP. The tool also works in permissive mode so > you still get the notifications but nothing is blocked. > > The tool is setroubleshoot and the desktop GUI component is sealert. > Typically it's installed and enabled. The sealert GUI depends on the > setroubleshoot service, the normal service and chkconfig commands apply. Yes but it doesn't always recommend the best way to do things because it doesn't seem to be aware of the SELinux macros like files_manage_generic_tmp_dirs() I appreciate the suggestion though. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Apr 1 22:06:03 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Apr 2008 18:06:03 -0400 Subject: [Freeipa-devel] [PATCH] Better nss_ldap default configuration Message-ID: <47F2B1CB.9040604@redhat.com> Better timeout defaults, and also configuration that prevents looking up root (and dirsrv) on ldap so that root logins can never timeout. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-758-ldap-conf.patch Type: text/x-patch Size: 4195 bytes Desc: not available URL: From ssorce at redhat.com Tue Apr 1 22:09:01 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Apr 2008 18:09:01 -0400 Subject: [Freeipa-devel] [PATCH] kpasswd and selinux Message-ID: <47F2B27D.9060408@redhat.com> Change kpasswd credential cache directory as it is better for selinux stuff Patch selinux policy to cope with it and make it stricter for ipa_webgui too -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-754-ipa-kpasswd-ccache.patch Type: text/x-patch Size: 2598 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-760-ipa-daemons-selinux.patch Type: text/x-patch Size: 2213 bytes Desc: not available URL: From rcritten at redhat.com Wed Apr 2 01:44:39 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Apr 2008 21:44:39 -0400 Subject: [Freeipa-devel] [PATCH] Better nss_ldap default configuration In-Reply-To: <47F2B1CB.9040604@redhat.com> References: <47F2B1CB.9040604@redhat.com> Message-ID: <47F2E507.9040804@redhat.com> Simo Sorce wrote: > Better timeout defaults, and also configuration that prevents looking up > root (and dirsrv) on ldap so that root logins can never timeout. > > Simo. From my meager understanding of nss_ldap this looks ok, just a few related questions: 1. Are you also going to update documentation on other operating systems to do something similar? 2. What if people, for reasons good or bad, actually want the root password to be stored in LDAP? 3. If DS fails to start will the machine be able to boot at all? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Apr 2 01:45:48 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Apr 2008 21:45:48 -0400 Subject: [Freeipa-devel] [PATCH] kpasswd and selinux In-Reply-To: <47F2B27D.9060408@redhat.com> References: <47F2B27D.9060408@redhat.com> Message-ID: <47F2E54C.6080102@redhat.com> Simo Sorce wrote: > Change kpasswd credential cache directory as it is better for selinux stuff > Patch selinux policy to cope with it and make it stricter for ipa_webgui > too > > > Looks great! rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Apr 2 02:04:28 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Apr 2008 22:04:28 -0400 Subject: [Freeipa-devel] [PATCH] Better nss_ldap default configuration In-Reply-To: <47F2E507.9040804@redhat.com> References: <47F2B1CB.9040604@redhat.com> <47F2E507.9040804@redhat.com> Message-ID: <1207101868.3533.254.camel@localhost.localdomain> On Tue, 2008-04-01 at 21:44 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Better timeout defaults, and also configuration that prevents looking up > > root (and dirsrv) on ldap so that root logins can never timeout. > > > > Simo. > > From my meager understanding of nss_ldap this looks ok, just a few > related questions: > > 1. Are you also going to update documentation on other operating systems > to do something similar? Each OS has specific options, but I've seen most of them are in better shape as they use a daemon to handle ldap communication (at least AIX and HP-UX) didn't show the kind of problems I am working around with this configuration fine tuning. > 2. What if people, for reasons good or bad, actually want the root > password to be stored in LDAP? They are free to change configuration options and pay the consequences :) > 3. If DS fails to start will the machine be able to boot at all? Boot is not a problem, and the changes I made also are useful to avoid long timeouts in nss_ldap. I am still thinking we should probably use nscd, for the simple reason it does negative caching and will therefore further reduce timeouts in the case none of the servers respond. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Apr 2 02:06:10 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Apr 2008 22:06:10 -0400 Subject: [Freeipa-devel] [PATCH] kpasswd and selinux In-Reply-To: <47F2E54C.6080102@redhat.com> References: <47F2B27D.9060408@redhat.com> <47F2E54C.6080102@redhat.com> Message-ID: <1207101970.3533.256.camel@localhost.localdomain> On Tue, 2008-04-01 at 21:45 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Change kpasswd credential cache directory as it is better for selinux stuff > > Patch selinux policy to cope with it and make it stricter for ipa_webgui > > too > > > > > > > > Looks great! pushed -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Apr 2 02:06:28 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Apr 2008 22:06:28 -0400 Subject: [Freeipa-devel] [PATCH] Better nss_ldap default configuration In-Reply-To: <47F2E507.9040804@redhat.com> References: <47F2B1CB.9040604@redhat.com> <47F2E507.9040804@redhat.com> Message-ID: <1207101988.3533.258.camel@localhost.localdomain> On Tue, 2008-04-01 at 21:44 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Better timeout defaults, and also configuration that prevents looking up > > root (and dirsrv) on ldap so that root logins can never timeout. > > > > Simo. > > From my meager understanding of nss_ldap this looks ok, just a few > related questions: [..] pushed -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Apr 2 02:06:52 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Apr 2008 22:06:52 -0400 Subject: [Freeipa-devel] [PATCH] fix crash iterating over None variable In-Reply-To: <1207080377.3533.246.camel@localhost.localdomain> References: <47F29173.8090203@redhat.com> <1207080377.3533.246.camel@localhost.localdomain> Message-ID: <47F2EA3C.2010708@redhat.com> Simo Sorce wrote: > On Tue, 2008-04-01 at 15:48 -0400, Rob Crittenden wrote: >> In the group_members() function I wasn't checking to see if a >> variable >> was None and we were iterating over it, causing a crash. > > ack only the group part, I wll take on the ipa_kpasswd fix which need > changes the path used in the spec file and makefiles as well. > Yeah, that ipa_kpasswd.c part was a mistake. Pushed the group fix. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Apr 2 16:00:15 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Apr 2008 12:00:15 -0400 Subject: [Freeipa-devel] freeipa: changeset 1533a4a1711d Message-ID: <1207152015.3533.273.camel@localhost.localdomain> http://hg.fedorahosted.org/hg/freeipa/rev/1533a4a1711d pushed as trivial From ssorce at redhat.com Wed Apr 2 16:38:44 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Apr 2008 12:38:44 -0400 Subject: [Freeipa-devel] freeipa: changeset a7a2ef687916 Message-ID: <1207154324.3533.284.camel@localhost.localdomain> http://hg.fedorahosted.org/hg/freeipa/rev/a7a2ef687916 Very simple dependency fix. Pushed as trivial From rcritten at redhat.com Wed Apr 2 21:12:59 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Apr 2008 17:12:59 -0400 Subject: [Freeipa-devel] [PATCH] fix problem on IPA policy update page Message-ID: <47F3F6DB.3060801@redhat.com> Don't try to update ipauserobjectclasses or ipagroupobjectclasses since they aren't being displayed anymore. They will just get blanked. Also add some error handling in ipahelper.fix_incoming_fields() rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-806-objectclass.patch Type: text/x-patch Size: 3158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Apr 2 21:19:32 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Apr 2008 17:19:32 -0400 Subject: [Freeipa-devel] [PATCH] fix problem on IPA policy update page In-Reply-To: <47F3F6DB.3060801@redhat.com> References: <47F3F6DB.3060801@redhat.com> Message-ID: <1207171172.3533.291.camel@localhost.localdomain> On Wed, 2008-04-02 at 17:12 -0400, Rob Crittenden wrote: > Don't try to update ipauserobjectclasses or ipagroupobjectclasses > since they aren't being displayed anymore. They will just get blanked. > > Also add some error handling in ipahelper.fix_incoming_fields() Ack. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Apr 2 23:16:26 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Apr 2008 19:16:26 -0400 Subject: [Freeipa-devel] freeipa: changeset c105e6cad516 Message-ID: <1207178186.3533.302.camel@localhost.localdomain> http://hg.fedorahosted.org/hg/freeipa/rev/c105e6cad516 Trivial fix to spec file. From mike at flyn.org Thu Apr 3 10:04:03 2008 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 3 Apr 2008 14:34:03 +0430 Subject: [Freeipa-devel] Automount support Message-ID: <20080403100403.GB13252@imp.flyn.org> Looking forward to the planned automount support, what Fedora package should own a new autofs schema? /etc/openldap/schema/samba.schema is owned by the samba package. But (as an example), the samba package does not provide a schema for Fedora Directory Server. The autofs package could provide a schema for FDS, but then it would have to provide one for OpenLDAP too. FDS itself could provide the schema, but would we want to set the precedent that FDS provides all possible schemas? Or should FreeIPA provide the schema? What if someone wanted to use the schema without installing FreeIPA? There are nice directions for FDS / autofs at http://directory.fedoraproject.org/wiki/Howto:Automount. -- Mike :wq From ssorce at redhat.com Thu Apr 3 13:04:56 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 03 Apr 2008 09:04:56 -0400 Subject: [Freeipa-devel] Automount support In-Reply-To: <20080403100403.GB13252@imp.flyn.org> References: <20080403100403.GB13252@imp.flyn.org> Message-ID: <1207227896.3533.310.camel@localhost.localdomain> On Thu, 2008-04-03 at 14:34 +0430, W. Michael Petullo wrote: > Looking forward to the planned automount support, what Fedora package > should own a new autofs schema? /etc/openldap/schema/samba.schema is > owned by the samba package. But (as an example), the samba package does > not provide a schema for Fedora Directory Server. This is probably my fault, we have a schema file for FDS upstream, and now that FDS is in fedora I should probably start putting the schema somewhere, more easily reachable than the docs package I guess ... > The autofs package could provide a schema for FDS, but then it would have > to provide one for OpenLDAP too. FDS itself could provide the schema, > but would we want to set the precedent that FDS provides all possible > schemas? Or should FreeIPA provide the schema? What if someone wanted > to use the schema without installing FreeIPA? > > There are nice directions for FDS / autofs at > http://directory.fedoraproject.org/wiki/Howto:Automount. Imo each package with LDAP support should provide the default schema for the distribution supported Directory Servers. My only question, is where should we put them for FDS ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Apr 3 19:24:10 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Apr 2008 15:24:10 -0400 Subject: [Freeipa-devel] [PATCH] root everything into /ipa Message-ID: <47F52EDA.3050306@redhat.com> Refine our web space some more so that everything we reference is in /ipa UI: /ipa/ui XML-RPC: /ipa/xml errors: /ipa/errors config: /ipa/config I had to hardcode that URI into the CSS pages but TurboGears handles the rest of the translations with tg.url(). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-769-webroot.patch Type: text/x-patch Size: 13272 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Apr 3 19:27:39 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Apr 2008 15:27:39 -0400 Subject: [Freeipa-devel] [PATCH] move ipa.conf creation earlier Message-ID: <47F52FAB.909@redhat.com> Create /etc/ipa/ipa.conf before we configure ipa_webgui because ipa.config() will raise an error if it can't load a configuration. This means that after install ipa_webgui may not be running. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-770-ipaconf.patch Type: text/x-patch Size: 1599 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Apr 3 19:38:43 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 03 Apr 2008 15:38:43 -0400 Subject: [Freeipa-devel] [PATCH] root everything into /ipa In-Reply-To: <47F52EDA.3050306@redhat.com> References: <47F52EDA.3050306@redhat.com> Message-ID: <1207251523.3533.353.camel@localhost.localdomain> On Thu, 2008-04-03 at 15:24 -0400, Rob Crittenden wrote: > > Refine our web space some more so that everything we reference is > in /ipa > > UI: /ipa/ui > XML-RPC: /ipa/xml > errors: /ipa/errors > config: /ipa/config > > I had to hardcode that URI into the CSS pages but TurboGears handles > the > rest of the translations with tg.url(). Looks good! Thanks, Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Apr 3 20:01:00 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 03 Apr 2008 16:01:00 -0400 Subject: [Freeipa-devel] [PATCH] move ipa.conf creation earlier In-Reply-To: <47F52FAB.909@redhat.com> References: <47F52FAB.909@redhat.com> Message-ID: <1207252860.3533.358.camel@localhost.localdomain> On Thu, 2008-04-03 at 15:27 -0400, Rob Crittenden wrote: > Create /etc/ipa/ipa.conf before we configure ipa_webgui because > ipa.config() will raise an error if it can't load a configuration. > This > means that after install ipa_webgui may not be running. ack Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Apr 3 21:36:41 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Apr 2008 17:36:41 -0400 Subject: [Freeipa-devel] [PATCH] move ipa.conf creation earlier In-Reply-To: <1207252860.3533.358.camel@localhost.localdomain> References: <47F52FAB.909@redhat.com> <1207252860.3533.358.camel@localhost.localdomain> Message-ID: <47F54DE9.7050209@redhat.com> Simo Sorce wrote: > On Thu, 2008-04-03 at 15:27 -0400, Rob Crittenden wrote: >> Create /etc/ipa/ipa.conf before we configure ipa_webgui because >> ipa.config() will raise an error if it can't load a configuration. >> This >> means that after install ipa_webgui may not be running. > > ack > Simo. > pushed -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Apr 4 20:14:12 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 04 Apr 2008 16:14:12 -0400 Subject: [Freeipa-devel] [PATCH] more DN normalization Message-ID: <47F68C14.3030107@redhat.com> Found another place we need to normalize the DN. This time when we're removing a member from a group. The membere are stored as a python list and I'm using the .remove() function so the strings need to match. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-771-remove.patch Type: text/x-patch Size: 3396 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Apr 4 20:45:37 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 04 Apr 2008 16:45:37 -0400 Subject: [Freeipa-devel] [PATCH] more DN normalization In-Reply-To: <47F68C14.3030107@redhat.com> References: <47F68C14.3030107@redhat.com> Message-ID: <1207341937.9925.26.camel@localhost.localdomain> On Fri, 2008-04-04 at 16:14 -0400, Rob Crittenden wrote: > Found another place we need to normalize the DN. This time when we're > removing a member from a group. The membere are stored as a python > list > and I'm using the .remove() function so the strings need to match. ack -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Apr 4 21:19:15 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 04 Apr 2008 17:19:15 -0400 Subject: [Freeipa-devel] [PATCH] admin must be in admins group Message-ID: <47F69B53.1090209@redhat.com> Don't allow the admin user to be removed from the admins group. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-772-admins.patch Type: text/x-patch Size: 2349 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Fri Apr 4 21:21:00 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 04 Apr 2008 14:21:00 -0700 Subject: [Freeipa-devel] [PATCH] Fix memory leaks in memberOf plug-in Message-ID: <47F69BBC.5040607@redhat.com> Fixed a number of leaks in the memberOf plug-in. Some common cases, such as adding and removing member attributes from groups were leaking entries. The the referenced bug report for more information. 440474 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-770-memberof.patch Type: text/x-patch Size: 2163 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Apr 4 21:21:15 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 04 Apr 2008 17:21:15 -0400 Subject: [Freeipa-devel] [PATCH] admin must be in admins group In-Reply-To: <47F69B53.1090209@redhat.com> References: <47F69B53.1090209@redhat.com> Message-ID: <1207344075.9925.34.camel@localhost.localdomain> On Fri, 2008-04-04 at 17:19 -0400, Rob Crittenden wrote: > Don't allow the admin user to be removed from the admins group. ack -- Simo Sorce * Red Hat, Inc * New York From mike at flyn.org Sat Apr 5 10:23:25 2008 From: mike at flyn.org (W. Michael Petullo) Date: Sat, 5 Apr 2008 14:53:25 +0430 Subject: [Freeipa-devel] Automount support In-Reply-To: <1207227896.3533.310.camel@localhost.localdomain> References: <20080403100403.GB13252@imp.flyn.org> <1207227896.3533.310.camel@localhost.localdomain> Message-ID: <20080405102324.GA31647@imp.flyn.org> >> Looking forward to the planned automount support, what Fedora package >> should own a new autofs schema? /etc/openldap/schema/samba.schema is >> owned by the samba package. But (as an example), the samba package does >> not provide a schema for Fedora Directory Server. > > This is probably my fault, we have a schema file for FDS upstream, and > now that FDS is in fedora I should probably start putting the schema > somewhere, more easily reachable than the docs package I guess ... > >> The autofs package could provide a schema for FDS, but then it would have >> to provide one for OpenLDAP too. FDS itself could provide the schema, >> but would we want to set the precedent that FDS provides all possible >> schemas? Or should FreeIPA provide the schema? What if someone wanted >> to use the schema without installing FreeIPA? >> >> There are nice directions for FDS / autofs at >> http://directory.fedoraproject.org/wiki/Howto:Automount. > > Imo each package with LDAP support should provide the default schema for > the distribution supported Directory Servers. My only question, is where > should we put them for FDS ? I just added an autofs bug to Fedora's Bugzilla. See https://bugzilla.redhat.com/show_bug.cgi?id=441026 . Mike From mike at flyn.org Mon Apr 7 08:35:29 2008 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 7 Apr 2008 13:05:29 +0430 Subject: [Freeipa-devel] Automount support In-Reply-To: <20080405102324.GA31647@imp.flyn.org> References: <20080403100403.GB13252@imp.flyn.org> <1207227896.3533.310.camel@localhost.localdomain> <20080405102324.GA31647@imp.flyn.org> Message-ID: <20080407083529.GA8165@imp.flyn.org> >>> Looking forward to the planned automount support, what Fedora package >>> should own a new autofs schema? /etc/openldap/schema/samba.schema is >>> owned by the samba package. But (as an example), the samba package does >>> not provide a schema for Fedora Directory Server. >> >> This is probably my fault, we have a schema file for FDS upstream, and >> now that FDS is in fedora I should probably start putting the schema >> somewhere, more easily reachable than the docs package I guess ... >> >>> The autofs package could provide a schema for FDS, but then it would have >>> to provide one for OpenLDAP too. FDS itself could provide the schema, >>> but would we want to set the precedent that FDS provides all possible >>> schemas? Or should FreeIPA provide the schema? What if someone wanted >>> to use the schema without installing FreeIPA? >>> >>> There are nice directions for FDS / autofs at >>> http://directory.fedoraproject.org/wiki/Howto:Automount. >> >> Imo each package with LDAP support should provide the default schema for >> the distribution supported Directory Servers. My only question, is where >> should we put them for FDS ? > > I just added an autofs bug to Fedora's Bugzilla. See > https://bugzilla.redhat.com/show_bug.cgi?id=441026 . The maintainer of the Fedora autofs package has come up with some good reasons why the autofs package should not install the autofs schema. To summarize: - It is inappropriate for the autofs package to change the LDAP configuration in any way on production systems. - It is inappropriate for autofs to add schema files at the location a directory server stores its schema files as that location may change without warning. - Autofs is more of a client system and might not be installed on an LDAP server. So, perhaps the schema should be installed by fedora-ds-base? I suppose we could even make a fedora-ds-schema-autofs package. Again, the purpose of this would be to avoid including every possible schema in fedora-ds-base. But, this may be overkill. Mike From ssorce at redhat.com Mon Apr 7 13:31:49 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2008 09:31:49 -0400 Subject: [Freeipa-devel] [PATCH] Fix some password policy checking issues Message-ID: <1207575109.9925.70.camel@localhost.localdomain> Check provided password != old password Limit the history also based on the length defined in the policy -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-770-pwd-policy-fixes.patch Type: text/x-patch Size: 7427 bytes Desc: not available URL: From rcritten at redhat.com Mon Apr 7 13:42:41 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Apr 2008 09:42:41 -0400 Subject: [Freeipa-devel] [PATCH] Fix some password policy checking issues In-Reply-To: <1207575109.9925.70.camel@localhost.localdomain> References: <1207575109.9925.70.camel@localhost.localdomain> Message-ID: <47FA24D1.2050406@redhat.com> Simo Sorce wrote: > Check provided password != old password > Limit the history also based on the length defined in the policy > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel In two places you have this: /* if shorter than GENERALIZED_TIME_LENGTH, it * is garbage, we never set timeless entries */ Should this be logged? Otherwise ack. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Apr 7 14:11:46 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2008 10:11:46 -0400 Subject: [Freeipa-devel] [PATCH] Fix some password policy checking issues In-Reply-To: <47FA24D1.2050406@redhat.com> References: <1207575109.9925.70.camel@localhost.localdomain> <47FA24D1.2050406@redhat.com> Message-ID: <1207577506.9925.96.camel@localhost.localdomain> On Mon, 2008-04-07 at 09:42 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Check provided password != old password > > Limit the history also based on the length defined in the policy > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > In two places you have this: > > /* if shorter than GENERALIZED_TIME_LENGTH, it > * is garbage, we never set timeless entries */ > > Should this be logged? No, it is just an extreme paranoia check, it should never happen, but as it may affect ordering if it does, I want to make sure we cover the very unlikely case (I should also check the 15 bytes actually do represent a date to be honest). > Otherwise ack. Ok, I'll push. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Apr 7 19:33:22 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2008 15:33:22 -0400 Subject: [Freeipa-devel] [PATCH] add ntp service record Message-ID: <1207596802.9925.105.camel@localhost.localdomain> This adds _ntp._udp to the sample zone file. This is not yet supported by the linux ntp daemon but maybe by other platforms (IIRC I've seen something about that for Apple machines). It doesn't hurt to have it there IMO. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-771-ntp-srv.patch Type: text/x-patch Size: 654 bytes Desc: not available URL: From rcritten at redhat.com Mon Apr 7 19:41:30 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Apr 2008 15:41:30 -0400 Subject: [Freeipa-devel] [PATCH] add ntp service record In-Reply-To: <1207596802.9925.105.camel@localhost.localdomain> References: <1207596802.9925.105.camel@localhost.localdomain> Message-ID: <47FA78EA.50404@redhat.com> Simo Sorce wrote: > This adds _ntp._udp to the sample zone file. > > This is not yet supported by the linux ntp daemon but maybe by other > platforms (IIRC I've seen something about that for Apple machines). > > It doesn't hurt to have it there IMO. > > Simo. seems reasonable. ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Apr 7 20:01:56 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2008 16:01:56 -0400 Subject: [Freeipa-devel] [PATCH] add ntp service record In-Reply-To: <47FA78EA.50404@redhat.com> References: <1207596802.9925.105.camel@localhost.localdomain> <47FA78EA.50404@redhat.com> Message-ID: <1207598516.9925.112.camel@localhost.localdomain> On Mon, 2008-04-07 at 15:41 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > This adds _ntp._udp to the sample zone file. > > > > This is not yet supported by the linux ntp daemon but maybe by other > > platforms (IIRC I've seen something about that for Apple machines). > > > > It doesn't hurt to have it there IMO. > > > > Simo. > > seems reasonable. > > ack pushed -- Simo Sorce * Red Hat, Inc * New York From gjansen at redhat.com Mon Apr 7 20:02:55 2008 From: gjansen at redhat.com (Geert Jansen) Date: Mon, 07 Apr 2008 22:02:55 +0200 Subject: [Freeipa-devel] Planning for v2: How to deal with kerberos trusts? In-Reply-To: <1206924493.3533.115.camel@localhost.localdomain> References: <1206924493.3533.115.camel@localhost.localdomain> Message-ID: <47FA7DEF.8050608@redhat.com> Hi Simo, List, tough questions :) First some things that I do not think we can do. Maybe this will make things clearer: - I do not think we can require posix user names to be unique across trusted realms. To make them unique, we could augment them with the realm (user at realm). However I don't think we can do this either... Some applications break with user names > 8 characters (notably older Oracle versions). It would also break the default aname to lname mapping in Kerberos as that just appends @domain to the posix name. - I do not think we can require numeric user id's to be unique across trusted realms. Here we don't even have an option of prefixing them with something else as our name space is too small. So what is the use case for multiple realms? I can think of a few: - Delegation or administrative duties (user mgmt etc): should be achievable without trusted realms so not an argument. - Privilege separation: yes, as long as local administrators control what privileges are assigned to foreign principals. - A merger of two companies (or two independent naming domains): two trusted realms could be useful during the transition period where there is non-unique data across the realms. - Performance improvements. I assume there is no or very little synchronization traffic between the trusted realms so you could use this to separate different regions and save on inter-regional bandwidth cost. So given these the idea that pops to my mind is to use some kind of user mapping process to map foreign principals onto local posix accounts. Essentially, the mapping information should be held in the local realm to ensure proper security separation. Administrators should be able to set up a default mapping such as "guest", and also per-user mappings. Now is this useful, or is this scheme so watered down that it does not give you much value when compared to a single big realm and no user mapping? I think this depends on how many user mappings you will need. If the primary use case is to give foreign users access to data that requires authentication but no authorisation then a single default mapping could suffice and the whole scheme could be quite useful. If on the other hand every foreign user needs a locally mapped user then maybe there are not many advantages of a single big realm without user mapping. Just my 2 cents. Regards, Geert -- Geert Jansen Product Manager EMEA Red Hat Nederland B.V. T: +31 6 293 191 57 Printerweg 44 E: gjansen at redhat.com 3821 AD Amersfoort, NL From gjansen at redhat.com Mon Apr 7 20:14:35 2008 From: gjansen at redhat.com (Geert Jansen) Date: Mon, 07 Apr 2008 22:14:35 +0200 Subject: [Freeipa-devel] [PATCH] Avoid listing a group as a memberOf itself In-Reply-To: <47ED6189.8030708@redhat.com> References: <47ED6189.8030708@redhat.com> Message-ID: <47FA80AB.7050309@redhat.com> Nathan Kinder wrote: > If you create a circular grouping, a group will be listed as a > memberOf itself. > > We just need to do a check when processing any type of operation to > see if > we're attempting to use a group's DN as the value of memberOf on > itself. We > had a check like that for a fixup operation, but it needed to be moved > up in the > code so it's used for any operations. I'm not familiar with the directory server code at all, so forgive me if this is obvious. Does your patch prevent memberships such as a -> b -> a? Regards, -- Geert Jansen Product Manager EMEA Red Hat Nederland B.V. T: +31 6 293 191 57 Printerweg 44 E: gjansen at redhat.com 3821 AD Amersfoort, NL From nkinder at redhat.com Mon Apr 7 20:22:15 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 07 Apr 2008 13:22:15 -0700 Subject: [Freeipa-devel] [PATCH] Avoid listing a group as a memberOf itself In-Reply-To: <47FA80AB.7050309@redhat.com> References: <47ED6189.8030708@redhat.com> <47FA80AB.7050309@redhat.com> Message-ID: <47FA8277.4040506@redhat.com> Geert Jansen wrote: > Nathan Kinder wrote: >> If you create a circular grouping, a group will be listed as a >> memberOf itself. >> >> We just need to do a check when processing any type of operation to >> see if >> we're attempting to use a group's DN as the value of memberOf on >> itself. We >> had a check like that for a fixup operation, but it needed to be >> moved up in the >> code so it's used for any operations. > > I'm not familiar with the directory server code at all, so forgive me > if this is obvious. Does your patch prevent memberships such as a -> b > -> a? No, it doesn't prevent you from creating any sort of loop with your member attribute values. The memberOf plug-in will detect loops to avoid recursive memberOf values though. -NGK > > Regards, > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From gjansen at redhat.com Mon Apr 7 20:27:36 2008 From: gjansen at redhat.com (Geert Jansen) Date: Mon, 07 Apr 2008 22:27:36 +0200 Subject: [Freeipa-devel] [PATCH] Avoid listing a group as a memberOf itself In-Reply-To: <47FA8277.4040506@redhat.com> References: <47ED6189.8030708@redhat.com> <47FA80AB.7050309@redhat.com> <47FA8277.4040506@redhat.com> Message-ID: <47FA83B8.6020302@redhat.com> Nathan Kinder wrote: >> >> I'm not familiar with the directory server code at all, so forgive me >> if this is obvious. Does your patch prevent memberships such as a -> >> b -> a? > No, it doesn't prevent you from creating any sort of loop with your > member attribute values. The memberOf plug-in will detect loops to > avoid recursive memberOf values though. Should we detect these kinds of loops to protect buggy clients that do not expect this? I know the PADL nss_ldap has proper loop detection for this but other os's may not. Geert From ssorce at redhat.com Mon Apr 7 20:31:19 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2008 16:31:19 -0400 Subject: [Freeipa-devel] Planning for v2: How to deal with kerberos trusts? In-Reply-To: <47FA7DEF.8050608@redhat.com> References: <1206924493.3533.115.camel@localhost.localdomain> <47FA7DEF.8050608@redhat.com> Message-ID: <1207600279.9925.133.camel@localhost.localdomain> On Mon, 2008-04-07 at 22:02 +0200, Geert Jansen wrote: > Hi Simo, List, > > tough questions :) First some things that I do not think we can do. > Maybe this will make things clearer: > > - I do not think we can require posix user names to be unique across > trusted realms. To make them unique, we could augment them with the > realm (user at realm). However I don't think we can do this either... Some > applications break with user names > 8 characters (notably older Oracle > versions). It would also break the default aname to lname mapping in > Kerberos as that just appends @domain to the posix name. This is true, and false :-) In Samba's Winbind we support trusted users and we make them unique prefixing the trusted domain's short name, and by default even our main domain has a prefixed name: example: WINDOM\user1 WINDOM\user2 TRUSTDOM\user1 etc... While some very old app may not like it, I think the advantages are noticeable and we should support a schema like this. To do that we need of course to have a way to locally resolve the name so that you can obtain the right kerberos principal name without actually just appending the domain. This would make it also possible to handle migrations where you need to keep the uinx user name mapped to something that does not directly map back to user+domain as krb principal. Therefore using user1 at MY.COOL.REALM, could actually be a good idea, and we may have some configuration option to map (optionally) our own default account usernames to just the use rpart without the REALM part. This would also allow us to more freely use real "local" accounts without fear of clashes, something we can't actually completely avoid. > - I do not think we can require numeric user id's to be unique across > trusted realms. Here we don't even have an option of prefixing them with > something else as our name space is too small. I think we can handle this case in various ways. True a 32bit id space is tiny. But, for planned use of trusted domains we could configure servers so that they use a 24bit id + 8 bit Realm selector. For unplanned trusts we could use some realms as a wildcard realm and just map new user Ids there. 24bit is just 1.6 million user accounts, not much but should still cover most scenarios for v1 and v2. It would also mean we cannot support more than 255 trusted realms, but that again shouldn't be a big deal. In the long term we have 2 options: 1. we are able to make linux (at least) adopt 64/128 bit user ids 2. we never keep user ids on the directory, but our local daemon instead maps users on the fly to local uids, and network file systems are made mapping aware and use an idmapper that plugs into the local daemon. Both CIFS and NFSv4 can already do this at the protocol level. > So what is the use case for multiple realms? I can think of a few: > > - Delegation or administrative duties (user mgmt etc): should be > achievable without trusted realms so not an argument. agree > - Privilege separation: yes, as long as local administrators control > what privileges are assigned to foreign principals. This is an interesting point, would you mind expanding on it a bit ? > - A merger of two companies (or two independent naming domains): two > trusted realms could be useful during the transition period where there > is non-unique data across the realms. For this my proposal above might work. > - Performance improvements. I assume there is no or very little > synchronization traffic between the trusted realms so you could use this > to separate different regions and save on inter-regional bandwidth cost. I am not sure there is any performance benefit, we would need to analyze the flux of information, but unless we completely discard foreign users posix data I am not sure we will have much of a performance benefit. > So given these the idea that pops to my mind is to use some kind of user > mapping process to map foreign principals onto local posix accounts. Yep this was one of the ideas I had as well, although I'd like to try to map users from the trusted domain in the way I described above. > Essentially, the mapping information should be held in the local realm > to ensure proper security separation. Administrators should be able to > set up a default mapping such as "guest", and also per-user mappings. Yes this could be done, I am not sure mapping to a guest user will actually give any benefit. A 1-1 mapping would probably be more beneficial, but if we finally decide to go there, we need to talk about how to do it and how to keep it correctly updated. Users, also are just one part of the equation, what about group memberships ? Would it make sense to consider foreign group memberships at all ? > Now is this useful, or is this scheme so watered down that it does not > give you much value when compared to a single big realm and no user > mapping? I think this depends on how many user mappings you will need. > If the primary use case is to give foreign users access to data that > requires authentication but no authorisation then a single default > mapping could suffice and the whole scheme could be quite useful. Or in case authorization is enforced separately (ex: app server on the web). > If on > the other hand every foreign user needs a locally mapped user then maybe > there are not many advantages of a single big realm without user mapping. Yes there aren't many except it enables, mergers, privilege separation and admin responsibilities. I think come companies that are split in very separate groups might find it compelling. more comments are very welcome, I'd like to analyze pros. and cons. and even consider hybrid modes or different behaviour given different configurations. Simo. -- Simo Sorce * Red Hat, Inc * New York From nkinder at redhat.com Mon Apr 7 20:36:40 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 07 Apr 2008 13:36:40 -0700 Subject: [Freeipa-devel] [PATCH] Avoid listing a group as a memberOf itself In-Reply-To: <47FA83B8.6020302@redhat.com> References: <47ED6189.8030708@redhat.com> <47FA80AB.7050309@redhat.com> <47FA8277.4040506@redhat.com> <47FA83B8.6020302@redhat.com> Message-ID: <47FA85D8.5000802@redhat.com> Geert Jansen wrote: > Nathan Kinder wrote: >>> >>> I'm not familiar with the directory server code at all, so forgive >>> me if this is obvious. Does your patch prevent memberships such as a >>> -> b -> a? >> No, it doesn't prevent you from creating any sort of loop with your >> member attribute values. The memberOf plug-in will detect loops to >> avoid recursive memberOf values though. > > Should we detect these kinds of loops to protect buggy clients that do > not expect this? I know the PADL nss_ldap has proper loop detection > for this but other os's may not. I thought about adding detection for this sort of thing, but I don't feel that the negative performance impact is worth the benefit. We would need to trace through the grouping structure before accepting the change for all modifications to "member" attributes. Depending on how complex the groupings are, this will take a bit of time. The client would have to wait for this check before they get a result back since it's at the pre-operation stage. Clients would also have to deal with us rejecting this type of modification, as we'd likely return a constraint violation error. The loop will not cause any problems, other than causing you to really have one big group instead of two (in the a->b->a case at least). -NGK > > Geert -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Apr 7 20:37:10 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2008 16:37:10 -0400 Subject: [Freeipa-devel] [PATCH] Avoid listing a group as a memberOf itself In-Reply-To: <47FA83B8.6020302@redhat.com> References: <47ED6189.8030708@redhat.com> <47FA80AB.7050309@redhat.com> <47FA8277.4040506@redhat.com> <47FA83B8.6020302@redhat.com> Message-ID: <1207600630.9925.138.camel@localhost.localdomain> On Mon, 2008-04-07 at 22:27 +0200, Geert Jansen wrote: > Nathan Kinder wrote: > >> > >> I'm not familiar with the directory server code at all, so forgive me > >> if this is obvious. Does your patch prevent memberships such as a -> > >> b -> a? > > No, it doesn't prevent you from creating any sort of loop with your > > member attribute values. The memberOf plug-in will detect loops to > > avoid recursive memberOf values though. > > Should we detect these kinds of loops to protect buggy clients that do > not expect this? I know the PADL nss_ldap has proper loop detection for > this but other os's may not. Maybe in the CLI utilities, but for v1 I think this will just be a recommended best practice. I do not expect group nesting to be used much anyway until v2 as some client may not support it at all. (and yes we probably need to document this). Simo. -- Simo Sorce * Red Hat, Inc * New York From kwirth at redhat.com Tue Apr 8 00:46:34 2008 From: kwirth at redhat.com (Karl Wirth) Date: Mon, 07 Apr 2008 20:46:34 -0400 Subject: [Freeipa-devel] updated freeIPA site and v2 plans Message-ID: <47FAC06A.6040401@redhat.com> We've updated the look and feel of freeIPA.org, put up some new content as well including a new PRD for v2, and made it clearer how to contribute to the project. Your suggestions and contributions to freeIPA are very welcome! Check it out at - www.freeIPA.org - www.freeipa.org/page/Roadmap#Release_2 - http://www.freeipa.org/page/Contribute Best regards, Karl From ssorce at redhat.com Tue Apr 8 02:04:51 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Apr 2008 22:04:51 -0400 Subject: [Freeipa-devel] [ALL] How to contribute to FreeIPA Message-ID: <1207620291.9925.144.camel@localhost.localdomain> Good news! We now have clear guidelines for contributions of code, documentation, patches, and artwork to the FreeIPA project. Every free software/open source (FOSS) project requires legal guidance with regard to copyrights, patents, and trademarks. While some projects require full copyright assignment to the project or a sponsoring organization, others allow individual contributors to retain their copyright. We have decided to expand on the popular Fedora model and, with the community in mind, developed a generic Contributor License Agreement (CLA): [link here]. The CLA grants to Red Hat, as the sponsor of the project, a license on all code contributed to the project. This permits Red Hat to license the code under a FOSS license of its choice. The author of the code continues to hold the copyright in that code, and is free to contribute the same code to other projects and to license it under whatever terms the author desires. The CLA needs to be completed and sent to Red Hat before you begin contributing code to any of the projects listed in Appendix A of the document. At that point all your contributions, if accepted by the project, are covered by the CLA. Q: Why do you require me to sign a CLA ? A: We think it is important for a central organization to manage the various legal issues surrounding FOSS projects. With a CLA, we will be able to react and respond to these issues on behalf of the entire project. We are committed to the values underlying FOSS, and these provisions are meant solely to keep the project safe from legal problems that may arise. Q: What if I am already contributing code to Fedora? Does this CLA still need to be completed? A: Yes. This CLA is modeled on the original Fedora CLA, but with some improvements. By completing the new CLA, you can begin contributing code to any of the projects listed in Appendix A. This doesn't affect any of your rights in your previous contributions. Q: Why is the license granted to Red Hat and not to the project? A: Most FOSS projects are not organized as legal entities. In some cases, difficult issues can arise if ownership and licensing of copyright is not administered properly. By licensing the code to Red Hat, the author retains ownership of the copyright. Red Hat helps by managing the licensing of the project code under the appropriate FOSS license. If you want to contribute, please complete the form and send it back to the address indicated on the form. If you have any questions or concerns regarding the CLA, please contact Richard Fontana or Bill Baroniunas . -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Apr 8 02:11:54 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Apr 2008 22:11:54 -0400 Subject: [Freeipa-devel] [PATCH] SELinux policy changes Message-ID: <47FAD46A.8040703@redhat.com> I've committed the attached patch which contains some SELinux policy changes from Dan Walsh. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-779-selinux.patch Type: text/x-patch Size: 3318 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From gpaterno at redhat.com Tue Apr 8 06:28:42 2008 From: gpaterno at redhat.com (Giuseppe "Gippa" Paterno') Date: Tue, 08 Apr 2008 08:28:42 +0200 Subject: [Freeipa-devel] Planning for v2 & Co.... In-Reply-To: <47FA7DEF.8050608@redhat.com> References: <1206924493.3533.115.camel@localhost.localdomain> <47FA7DEF.8050608@redhat.com> Message-ID: <47FB109A.6080803@redhat.com> Just if someone doesn't know this patch: http://dev.inversepath.com/trac/openssh-lpk I think can be useful for FreeIPAv2 to solve ssh key distribution (and don't want to/can't use kerberos). Cheers, Gippa P.S. Bugzilla was opened for this: https://bugzilla.redhat.com/show_bug.cgi?id=215741 From ssorce at redhat.com Tue Apr 8 13:30:32 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 08 Apr 2008 09:30:32 -0400 Subject: [Freeipa-devel] freeipa: changeset 424195beca58 Message-ID: <1207661432.9925.164.camel@localhost.localdomain> http://hg.fedorahosted.org/hg/freeipa/rev/424195beca58 Pushed under the trivial rule. From dpal at redhat.com Tue Apr 8 15:24:34 2008 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 08 Apr 2008 11:24:34 -0400 Subject: [Freeipa-devel] [ALL] How to contribute to FreeIPA In-Reply-To: <1207620291.9925.144.camel@localhost.localdomain> References: <1207620291.9925.144.camel@localhost.localdomain> Message-ID: <47FB8E32.5080907@redhat.com> The link to CLA: http://www.freeipa.org/wiki/images/2/2b/GenericCLA.pdf. Simo Sorce wrote: > Good news! > > We now have clear guidelines for contributions of code, documentation, > patches, and artwork to the FreeIPA project. > > Every free software/open source (FOSS) project requires legal guidance > with regard to copyrights, patents, and trademarks. While some > projects require full copyright assignment to the project or a > sponsoring organization, others allow individual contributors to > retain their copyright. > > We have decided to expand on the popular Fedora model and, with the > community in mind, developed a generic Contributor License Agreement > (CLA): [link here]. The CLA grants to Red Hat, as the sponsor of the > project, a license on all code contributed to the project. This > permits Red Hat to license the code under a FOSS license of its > choice. The author of the code continues to hold the copyright in > that code, and is free to contribute the same code to other projects > and to license it under whatever terms the author desires. > > The CLA needs to be completed and sent to Red Hat before you begin > contributing code to any of the projects listed in Appendix A of the > document. At that point all your contributions, if accepted by the > project, are covered by the CLA. > > Q: Why do you require me to sign a CLA ? > > A: We think it is important for a central organization to manage the > various legal issues surrounding FOSS projects. With a CLA, we will be > able to react and respond to these issues on behalf of the entire > project. We are committed to the values underlying FOSS, and these > provisions are meant solely to keep the project safe from legal > problems that may arise. > > Q: What if I am already contributing code to Fedora? Does this CLA > still need to be completed? > > A: Yes. This CLA is modeled on the original Fedora CLA, but with some > improvements. By completing the new CLA, you can begin contributing > code to any of the projects listed in Appendix A. This doesn't affect > any of your rights in your previous contributions. > > Q: Why is the license granted to Red Hat and not to the project? > > A: Most FOSS projects are not organized as legal entities. In some > cases, difficult issues can arise if ownership and licensing of > copyright is not administered properly. By licensing the code to Red > Hat, the author retains ownership of the copyright. Red Hat helps by > managing the licensing of the project code under the appropriate FOSS > license. > > If you want to contribute, please complete the form and send it back > to the address indicated on the form. > > If you have any questions or concerns regarding the CLA, please > contact Richard Fontana or Bill Baroniunas > . > > > -- Dmitri Pal Engineering Manager Red Hat Inc. From ssorce at redhat.com Tue Apr 8 16:53:31 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 08 Apr 2008 12:53:31 -0400 Subject: [Freeipa-devel] [ALL] How to contribute to FreeIPA In-Reply-To: <47FB8E32.5080907@redhat.com> References: <1207620291.9925.144.camel@localhost.localdomain> <47FB8E32.5080907@redhat.com> Message-ID: <1207673611.9925.179.camel@localhost.localdomain> On Tue, 2008-04-08 at 11:24 -0400, Dmitri Pal wrote: > The link to CLA: http://www.freeipa.org/wiki/images/2/2b/GenericCLA.pdf. I knew I forgot something :-( Thanks for fixing it. Simo. -- Simo Sorce * Red Hat, Inc * New York From gdk at redhat.com Tue Apr 8 17:18:51 2008 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Tue, 8 Apr 2008 13:18:51 -0400 (EDT) Subject: [Freeipa-devel] [ALL] How to contribute to FreeIPA In-Reply-To: <1207673611.9925.179.camel@localhost.localdomain> References: <1207620291.9925.144.camel@localhost.localdomain> <47FB8E32.5080907@redhat.com> <1207673611.9925.179.camel@localhost.localdomain> Message-ID: On Tue, 8 Apr 2008, Simo Sorce wrote: > > On Tue, 2008-04-08 at 11:24 -0400, Dmitri Pal wrote: >> The link to CLA: http://www.freeipa.org/wiki/images/2/2b/GenericCLA.pdf. > > I knew I forgot something :-( > Thanks for fixing it. OK, wait, hold on, wait wait wait. I've gone through the headaches of administering the CLA process. We are working in Fedora to make the CLA process as painless as possible. Are you *absolutely sure* that you want to maintain your own CLA process? Really? Because this is one of the *huge* benefits of being a Fedora project: you get this stuff for free. --g -- Greg DeKoenigsberg Community Development Manager Red Hat, Inc. :: 1-919-754-4255 "To whomsoever much hath been given... ...from him much shall be asked" From ssorce at redhat.com Tue Apr 8 19:23:23 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 08 Apr 2008 15:23:23 -0400 Subject: [Freeipa-devel] [PATCH] fix ipa-pwpolicy Message-ID: <47FBC62B.6090301@redhat.com> Fix wrong checks for input validation was wxluding 0 as an allowed value. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-778-fix-pwpolicy.patch Type: text/x-patch Size: 2320 bytes Desc: not available URL: From ssorce at redhat.com Tue Apr 8 19:25:53 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 08 Apr 2008 15:25:53 -0400 Subject: [Freeipa-devel] [PATCH] start nscd on client install Message-ID: <47FBC6C1.6030609@redhat.com> Activate NSCD by default, the performance boost and lessened load on server are all worth it. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-779-start-nscd.patch Type: text/x-patch Size: 1181 bytes Desc: not available URL: From rcritten at redhat.com Tue Apr 8 20:54:54 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Apr 2008 16:54:54 -0400 Subject: [Freeipa-devel] [PATCH] fix ipa-pwpolicy In-Reply-To: <47FBC62B.6090301@redhat.com> References: <47FBC62B.6090301@redhat.com> Message-ID: <47FBDB9E.7060909@redhat.com> Simo Sorce wrote: > Fix wrong checks for input validation was wxluding 0 as an allowed value. > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Apr 8 20:56:35 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 08 Apr 2008 16:56:35 -0400 Subject: [Freeipa-devel] [PATCH] start nscd on client install In-Reply-To: <47FBC6C1.6030609@redhat.com> References: <47FBC6C1.6030609@redhat.com> Message-ID: <47FBDC03.7080606@redhat.com> Simo Sorce wrote: > Activate NSCD by default, the performance boost and lessened load on > server are all worth it. > > Simo. ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Apr 8 21:05:17 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 08 Apr 2008 17:05:17 -0400 Subject: [Freeipa-devel] [PATCH] fix ipa-pwpolicy In-Reply-To: <47FBDB9E.7060909@redhat.com> References: <47FBC62B.6090301@redhat.com> <47FBDB9E.7060909@redhat.com> Message-ID: <1207688717.9925.204.camel@localhost.localdomain> On Tue, 2008-04-08 at 16:54 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Fix wrong checks for input validation was wxluding 0 as an allowed value. > > > > ack pushed -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Apr 8 21:05:26 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 08 Apr 2008 17:05:26 -0400 Subject: [Freeipa-devel] [PATCH] start nscd on client install In-Reply-To: <47FBDC03.7080606@redhat.com> References: <47FBC6C1.6030609@redhat.com> <47FBDC03.7080606@redhat.com> Message-ID: <1207688726.9925.206.camel@localhost.localdomain> On Tue, 2008-04-08 at 16:56 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Activate NSCD by default, the performance boost and lessened load on > > server are all worth it. > > > > Simo. > > ack pushed -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Apr 8 22:08:01 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 08 Apr 2008 18:08:01 -0400 Subject: [Freeipa-devel] [PATCH] show permitted enctypes Message-ID: <1207692481.9925.210.camel@localhost.localdomain> Display list of permitted encryption types. Update man page with common examples. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-780-permitted-enctypes.patch Type: text/x-patch Size: 3925 bytes Desc: not available URL: From foss.mailinglists at gmail.com Wed Apr 9 03:07:13 2008 From: foss.mailinglists at gmail.com (Sankarshan Mukhopadhyay) Date: Wed, 09 Apr 2008 08:37:13 +0530 Subject: [Freeipa-devel] [ALL] How to contribute to FreeIPA In-Reply-To: <1207620291.9925.144.camel@localhost.localdomain> References: <1207620291.9925.144.camel@localhost.localdomain> Message-ID: <47FC32E1.1050706@gmail.com> Simo Sorce wrote: > We have decided to expand on the popular Fedora model and, with the > community in mind, developed a generic Contributor License Agreement > (CLA): [link here]. The CLA grants to Red Hat, as the sponsor of the > project, a license on all code contributed to the project. This > permits Red Hat to license the code under a FOSS license of its > choice. The author of the code continues to hold the copyright in > that code, and is free to contribute the same code to other projects > and to license it under whatever terms the author desires. is this over and above the Fedora CLA (which is being looked into for simplification) ? -- http://www.gutenberg.net - Fine literature digitally re-published http://www.plos.org - Public Library of Science http://www.creativecommons.org - Flexible copyright for creative work From foss.mailinglists at gmail.com Wed Apr 9 03:08:39 2008 From: foss.mailinglists at gmail.com (Sankarshan Mukhopadhyay) Date: Wed, 09 Apr 2008 08:38:39 +0530 Subject: [Freeipa-devel] [ALL] How to contribute to FreeIPA In-Reply-To: <1207620291.9925.144.camel@localhost.localdomain> References: <1207620291.9925.144.camel@localhost.localdomain> Message-ID: <47FC3337.8060201@gmail.com> Simo Sorce wrote: > Good news! > > We now have clear guidelines for contributions of code, documentation, > patches, and artwork to the FreeIPA project. > > Every free software/open source (FOSS) project requires legal guidance > with regard to copyrights, patents, and trademarks. While some > projects require full copyright assignment to the project or a > sponsoring organization, others allow individual contributors to > retain their copyright. > > We have decided to expand on the popular Fedora model and, with the > community in mind, developed a generic Contributor License Agreement > (CLA): [link here]. The CLA grants to Red Hat, as the sponsor of the > project, a license on all code contributed to the project. This > permits Red Hat to license the code under a FOSS license of its > choice. The author of the code continues to hold the copyright in > that code, and is free to contribute the same code to other projects > and to license it under whatever terms the author desires. > > The CLA needs to be completed and sent to Red Hat before you begin > contributing code to any of the projects listed in Appendix A of the > document. At that point all your contributions, if accepted by the > project, are covered by the CLA. > > Q: Why do you require me to sign a CLA ? > > A: We think it is important for a central organization to manage the > various legal issues surrounding FOSS projects. With a CLA, we will be > able to react and respond to these issues on behalf of the entire > project. We are committed to the values underlying FOSS, and these > provisions are meant solely to keep the project safe from legal > problems that may arise. > > Q: What if I am already contributing code to Fedora? Does this CLA > still need to be completed? > > A: Yes. This CLA is modeled on the original Fedora CLA, but with some > improvements. By completing the new CLA, you can begin contributing > code to any of the projects listed in Appendix A. This doesn't affect > any of your rights in your previous contributions. > > Q: Why is the license granted to Red Hat and not to the project? > > A: Most FOSS projects are not organized as legal entities. In some > cases, difficult issues can arise if ownership and licensing of > copyright is not administered properly. By licensing the code to Red > Hat, the author retains ownership of the copyright. Red Hat helps by > managing the licensing of the project code under the appropriate FOSS > license. > > If you want to contribute, please complete the form and send it back > to the address indicated on the form. > > If you have any questions or concerns regarding the CLA, please > contact Richard Fontana or Bill Baroniunas > . > > -- http://www.gutenberg.net - Fine literature digitally re-published http://www.plos.org - Public Library of Science http://www.creativecommons.org - Flexible copyright for creative work From rcritten at redhat.com Wed Apr 9 12:57:12 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Apr 2008 08:57:12 -0400 Subject: [Freeipa-devel] [PATCH] show permitted enctypes In-Reply-To: <1207692481.9925.210.camel@localhost.localdomain> References: <1207692481.9925.210.camel@localhost.localdomain> Message-ID: <47FCBD28.10300@redhat.com> Simo Sorce wrote: > Display list of permitted encryption types. > Update man page with common examples. > > > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Apr 9 13:23:31 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Apr 2008 09:23:31 -0400 Subject: [Freeipa-devel] [ALL] How to contribute to FreeIPA In-Reply-To: <47FC32E1.1050706@gmail.com> References: <1207620291.9925.144.camel@localhost.localdomain> <47FC32E1.1050706@gmail.com> Message-ID: <1207747411.9925.216.camel@localhost.localdomain> On Wed, 2008-04-09 at 08:37 +0530, Sankarshan Mukhopadhyay wrote: > Simo Sorce wrote: > > > We have decided to expand on the popular Fedora model and, with the > > community in mind, developed a generic Contributor License Agreement > > (CLA): [link here]. The CLA grants to Red Hat, as the sponsor of the > > project, a license on all code contributed to the project. This > > permits Red Hat to license the code under a FOSS license of its > > choice. The author of the code continues to hold the copyright in > > that code, and is free to contribute the same code to other projects > > and to license it under whatever terms the author desires. > > is this over and above the Fedora CLA (which is being looked into for > simplification) ? As far as I understood it is basically the same CLA that Fedora uses. Simo. -- Simo Sorce * Red Hat, Inc * New York From stickster at gmail.com Wed Apr 9 13:51:10 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 09 Apr 2008 13:51:10 +0000 Subject: [Freeipa-devel] [ALL] How to contribute to FreeIPA In-Reply-To: <1207747411.9925.216.camel@localhost.localdomain> References: <1207620291.9925.144.camel@localhost.localdomain> <47FC32E1.1050706@gmail.com> <1207747411.9925.216.camel@localhost.localdomain> Message-ID: <1207749070.5428.140.camel@localhost.localdomain> On Wed, 2008-04-09 at 09:23 -0400, Simo Sorce wrote: > On Wed, 2008-04-09 at 08:37 +0530, Sankarshan Mukhopadhyay wrote: > > Simo Sorce wrote: > > > > > We have decided to expand on the popular Fedora model and, with the > > > community in mind, developed a generic Contributor License Agreement > > > (CLA): [link here]. The CLA grants to Red Hat, as the sponsor of the > > > project, a license on all code contributed to the project. This > > > permits Red Hat to license the code under a FOSS license of its > > > choice. The author of the code continues to hold the copyright in > > > that code, and is free to contribute the same code to other projects > > > and to license it under whatever terms the author desires. > > > > is this over and above the Fedora CLA (which is being looked into for > > simplification) ? > > As far as I understood it is basically the same CLA that Fedora uses. Actually, it's subtly different from our current CLA. Maybe this is intended to succeed our current one at some point, but since this introduction is the first I've seen of this new version, I'm not sure. I've asked Red Hat Legal to give us some clarification. I wonder if we should move this discussion to fedora-legal-list. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Wed Apr 9 13:58:33 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Apr 2008 09:58:33 -0400 Subject: [Freeipa-devel] [PATCH] show permitted enctypes In-Reply-To: <47FCBD28.10300@redhat.com> References: <1207692481.9925.210.camel@localhost.localdomain> <47FCBD28.10300@redhat.com> Message-ID: <1207749513.9925.228.camel@localhost.localdomain> On Wed, 2008-04-09 at 08:57 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Display list of permitted encryption types. > > Update man page with common examples. > > > > > > > > ack pushed Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Apr 9 18:43:43 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Apr 2008 14:43:43 -0400 Subject: [Freeipa-devel] [PATCH] configured server first Message-ID: <1207766623.9925.249.camel@localhost.localdomain> Use the configured server in ipa.conf first. This is a kind of poor man server affinity but helps admins have a server of preference they always contact if it is available. Normal fallback still works if that server does not work. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-782-ipa-config.patch Type: text/x-patch Size: 3215 bytes Desc: not available URL: From rcritten at redhat.com Wed Apr 9 18:46:49 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Apr 2008 14:46:49 -0400 Subject: [Freeipa-devel] [PATCH] include kpasswd.keytab in replicas Message-ID: <47FD0F19.1040904@redhat.com> We discovered a problem when changing passwords on replicas. The problem was that kpasswd.keytab was being regenerated for each replica. This effectively made just the last replica made authoritative in setting passwords. So the short-term fix is to include kpasswd.keytab in the replica file so we use the same one everywhere. Longer-term fix would be to create a separate entry for each replica to be able to change passwords. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-790-kpasswd.patch Type: text/x-patch Size: 4054 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Apr 9 18:49:53 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Apr 2008 14:49:53 -0400 Subject: [Freeipa-devel] [PATCH] include kpasswd.keytab in replicas In-Reply-To: <47FD0F19.1040904@redhat.com> References: <47FD0F19.1040904@redhat.com> Message-ID: <1207766993.9925.251.camel@localhost.localdomain> On Wed, 2008-04-09 at 14:46 -0400, Rob Crittenden wrote: > We discovered a problem when changing passwords on replicas. The > problem > was that kpasswd.keytab was being regenerated for each replica. This > effectively made just the last replica made authoritative in setting > passwords. > > So the short-term fix is to include kpasswd.keytab in the replica > file > so we use the same one everywhere. Longer-term fix would be to create > a > separate entry for each replica to be able to change passwords. ack Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Apr 9 18:54:47 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Apr 2008 14:54:47 -0400 Subject: [Freeipa-devel] [PATCH] configured server first In-Reply-To: <1207766623.9925.249.camel@localhost.localdomain> References: <1207766623.9925.249.camel@localhost.localdomain> Message-ID: <47FD10F7.8010906@redhat.com> Simo Sorce wrote: > Use the configured server in ipa.conf first. > This is a kind of poor man server affinity but helps admins have a > server of preference they always contact if it is available. > Normal fallback still works if that server does not work. > > Simo. ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Apr 9 20:03:06 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Apr 2008 16:03:06 -0400 Subject: [Freeipa-devel] [PATCH] fix ipa-client-install when options are provided Message-ID: <1207771386.9925.264.camel@localhost.localdomain> ipa-client-install was overwriting command line provided options with discovered ones, even when discovery failed. This patch makes sure provided options are never overwritten by discovered ones. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-783-fix-ipa-cli-inst.patch Type: text/x-patch Size: 10075 bytes Desc: not available URL: From ssorce at redhat.com Wed Apr 9 20:04:19 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Apr 2008 16:04:19 -0400 Subject: [Freeipa-devel] [PATCH] configured server first In-Reply-To: <47FD10F7.8010906@redhat.com> References: <1207766623.9925.249.camel@localhost.localdomain> <47FD10F7.8010906@redhat.com> Message-ID: <1207771459.9925.267.camel@localhost.localdomain> On Wed, 2008-04-09 at 14:54 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Use the configured server in ipa.conf first. > > This is a kind of poor man server affinity but helps admins have a > > server of preference they always contact if it is available. > > Normal fallback still works if that server does not work. > > > > Simo. > > ack pushed -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Apr 9 20:14:43 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Apr 2008 16:14:43 -0400 Subject: [Freeipa-devel] [PATCH] fix ipa-client-install when options are provided In-Reply-To: <1207771386.9925.264.camel@localhost.localdomain> References: <1207771386.9925.264.camel@localhost.localdomain> Message-ID: <47FD23B3.6000509@redhat.com> Simo Sorce wrote: > ipa-client-install was overwriting command line provided options with > discovered ones, even when discovery failed. > > This patch makes sure provided options are never overwritten by > discovered ones. > > Simo. ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Apr 9 20:15:33 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Apr 2008 16:15:33 -0400 Subject: [Freeipa-devel] [PATCH] fix ipa-client-install when options are provided In-Reply-To: <47FD23B3.6000509@redhat.com> References: <1207771386.9925.264.camel@localhost.localdomain> <47FD23B3.6000509@redhat.com> Message-ID: <1207772133.9925.270.camel@localhost.localdomain> On Wed, 2008-04-09 at 16:14 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > ipa-client-install was overwriting command line provided options with > > discovered ones, even when discovery failed. > > > > This patch makes sure provided options are never overwritten by > > discovered ones. > > > > Simo. > > ack pushed -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Apr 9 20:27:16 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Apr 2008 16:27:16 -0400 Subject: [Freeipa-devel] [PATCH] include kpasswd.keytab in replicas In-Reply-To: <1207766993.9925.251.camel@localhost.localdomain> References: <47FD0F19.1040904@redhat.com> <1207766993.9925.251.camel@localhost.localdomain> Message-ID: <47FD26A4.7030600@redhat.com> Simo Sorce wrote: > On Wed, 2008-04-09 at 14:46 -0400, Rob Crittenden wrote: >> We discovered a problem when changing passwords on replicas. The >> problem >> was that kpasswd.keytab was being regenerated for each replica. This >> effectively made just the last replica made authoritative in setting >> passwords. >> >> So the short-term fix is to include kpasswd.keytab in the replica >> file >> so we use the same one everywhere. Longer-term fix would be to create >> a >> separate entry for each replica to be able to change passwords. > > ack > > Simo. > pushed -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mike at flyn.org Thu Apr 10 14:20:41 2008 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 10 Apr 2008 18:50:41 +0430 Subject: [Freeipa-devel] Asterisk VoIP support Message-ID: <20080410142041.GA3286@imp.flyn.org> The upcoming Asterisk 1.6 telephony solution will have support for using LDAP as its configuration backend. Could we integrate support for this into FreeIPA? For example, a VoIP telephone could be associated with each user in the LDAP database. Asterisk's LDAP schema may be found at: http://svn.digium.com/view/asterisk/trunk/contrib/scripts/asterisk.ldap-schema?view=markup -- Mike :wq From ssorce at redhat.com Thu Apr 10 15:10:55 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 10 Apr 2008 11:10:55 -0400 Subject: [Freeipa-devel] Asterisk VoIP support In-Reply-To: <20080410142041.GA3286@imp.flyn.org> References: <20080410142041.GA3286@imp.flyn.org> Message-ID: <1207840255.9925.326.camel@localhost.localdomain> On Thu, 2008-04-10 at 18:50 +0430, W. Michael Petullo wrote: > The upcoming Asterisk 1.6 telephony solution will have support for using > LDAP as its configuration backend. Could we integrate support for this > into FreeIPA? For example, a VoIP telephone could be associated with > each user in the LDAP database. > > Asterisk's LDAP schema may be found at: > > http://svn.digium.com/view/asterisk/trunk/contrib/scripts/asterisk.ldap-schema?view=markup Michael is there any document that defines the expected directory tree layout (if any) ? An howto doc on how to set it up would also probably be enough for me to understand if their requirements are in line with FreeIPA ones. Simo. -- Simo Sorce * Red Hat, Inc * New York From mike at flyn.org Thu Apr 10 16:10:19 2008 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 10 Apr 2008 20:40:19 +0430 Subject: [Freeipa-devel] Asterisk VoIP support In-Reply-To: <1207840255.9925.326.camel@localhost.localdomain> References: <20080410142041.GA3286@imp.flyn.org> <1207840255.9925.326.camel@localhost.localdomain> Message-ID: <20080410161019.GA6213@imp.flyn.org> >> The upcoming Asterisk 1.6 telephony solution will have support for using >> LDAP as its configuration backend. Could we integrate support for this >> into FreeIPA? For example, a VoIP telephone could be associated with >> each user in the LDAP database. >> >> Asterisk's LDAP schema may be found at: >> >> http://svn.digium.com/view/asterisk/trunk/contrib/scripts/asterisk.ldap-schema?view=markup > > Michael is there any document that defines the expected directory tree > layout (if any) ? > > An howto doc on how to set it up would also probably be enough for me to > understand if their requirements are in line with FreeIPA ones. I have been waiting for this LDAP configuration feature in Asterisk for a while. Now that version 1.6 is going to support it, I plan on experimenting with it. I will report back to the list with more details once I have a running configuration. -- Mike :wq From ssorce at redhat.com Thu Apr 10 17:03:39 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 10 Apr 2008 13:03:39 -0400 Subject: [Freeipa-devel] {DRAFT} [DEVEL NEWS] Changing SCM to Git Message-ID: <1207847019.9925.344.camel@localhost.localdomain> We are moving to Git (http://git.or.cz/) After some long thinking about it, we decided to move form Mercurial* to Git for our source code management. The reasons behind the change are a mixture of personal preference of the developers, the need to reduce the number of SCM to learn for some of us (git is in use by other projects the FreeIPA developers work on), and the perceived better handling of branches in git. So we did it. The new repo is available for browsing here: http://git.fedorahosted.org/git/freeipa.git/ To get the code on your machine check it out with this command: git clone git://git.fedorahosted.org/git/freeipa.git Please use the git transport by preference, it is much more efficient than http which is also available. So far only the master branch is available, but we plan to branch out 1.0 very soon so that v2 development commits can be accepted. use git branch -r to find out the available branches. If you are not familiar with git, here there is a tutorial to start playing with it: http://www.kernel.org/pub/software/scm/git/docs/tutorial.html See http://freeipa.org/page/Contribute#Development_Process for our coding style and patch submission process. If you have questions about git and freeipa feel free to ask on this mailing list or stop by #freeipa (FreeNode server) on IRC. The FreeIPA Team. * Mercurial served very well the project and it is a good SCM, this change by no means wants to signify Mercurial was not up to the task. We wish long life to Mercurial. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Apr 10 17:05:59 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 10 Apr 2008 13:05:59 -0400 Subject: [Freeipa-devel] [DEVEL NEWS] Changing SCM to Git Message-ID: <1207847159.9925.346.camel@localhost.localdomain> We are moving to Git (http://git.or.cz/) After some long thinking about it, we decided to move form Mercurial* to Git for our source code management. The reasons behind the change are a mixture of personal preference of the developers, the need to reduce the number of SCM to learn for some of us (git is in use by other projects the FreeIPA developers work on), and the perceived better handling of branches in git. So we did it. The new repo is available for browsing here: http://git.fedorahosted.org/git/freeipa.git/ To get the code on your machine check it out with this command: git clone git://git.fedorahosted.org/git/freeipa.git Please use the git transport by preference, it is much more efficient than http which is also available. So far only the master branch is available, but we plan to branch out 1.0 very soon so that v2 development commits can be accepted. use git branch -r to find out the available branches. If you are not familiar with git, here there is a tutorial to start playing with it: http://www.kernel.org/pub/software/scm/git/docs/tutorial.html See http://freeipa.org/page/Contribute#Development_Process for our coding style and patch submission process. If you have questions about git and freeipa feel free to ask on this mailing list or stop by #freeipa (FreeNode server) on IRC. The FreeIPA Team. * Mercurial served very well the project and it is a good SCM, this change by no means wants to signify Mercurial was not up to the task. We wish long life to Mercurial. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Apr 10 17:19:36 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 10 Apr 2008 13:19:36 -0400 Subject: [Freeipa-devel] {DRAFT} [DEVEL NEWS] Changing SCM to Git In-Reply-To: <1207847019.9925.344.camel@localhost.localdomain> References: <1207847019.9925.344.camel@localhost.localdomain> Message-ID: <1207847976.9925.350.camel@localhost.localdomain> Sigh! resent without {DRAFT} ... apologies. Simo. -- Simo Sorce * Red Hat, Inc * New York From mike at flyn.org Fri Apr 11 10:18:40 2008 From: mike at flyn.org (W. Michael Petullo) Date: Fri, 11 Apr 2008 14:48:40 +0430 Subject: [Freeipa-devel] Asterisk VoIP support In-Reply-To: <20080410161019.GA6213@imp.flyn.org> References: <20080410142041.GA3286@imp.flyn.org> <1207840255.9925.326.camel@localhost.localdomain> <20080410161019.GA6213@imp.flyn.org> Message-ID: <20080411101840.GA4841@imp.flyn.org> >>> The upcoming Asterisk 1.6 telephony solution will have support for using >>> LDAP as its configuration backend. Could we integrate support for this >>> into FreeIPA? For example, a VoIP telephone could be associated with >>> each user in the LDAP database. >>> >>> Asterisk's LDAP schema may be found at: >>> >>> http://svn.digium.com/view/asterisk/trunk/contrib/scripts/asterisk.ldap-schema?view=markup >> >> Michael is there any document that defines the expected directory tree >> layout (if any) ? >> >> An howto doc on how to set it up would also probably be enough for me to >> understand if their requirements are in line with FreeIPA ones. > > I have been waiting for this LDAP configuration feature in Asterisk for > a while. Now that version 1.6 is going to support it, I plan on > experimenting with it. I will report back to the list with more details > once I have a running configuration. I now have a document describing how to configure Asterisk to use LDAP at: http://www.flyn.org/astldap/astldap.html This document provides example configuration files, LDAP schema and LDAP data. There are some outstanding issues with the version of Asterisk I am using (1.6 Beta 7). These are noted at the bottom of the document. -- Mike :wq From ssorce at redhat.com Fri Apr 11 14:10:20 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 11 Apr 2008 10:10:20 -0400 Subject: [Freeipa-devel] Asterisk VoIP support In-Reply-To: <20080411101840.GA4841@imp.flyn.org> References: <20080410142041.GA3286@imp.flyn.org> <1207840255.9925.326.camel@localhost.localdomain> <20080410161019.GA6213@imp.flyn.org> <20080411101840.GA4841@imp.flyn.org> Message-ID: <1207923020.14795.24.camel@localhost.localdomain> On Fri, 2008-04-11 at 14:48 +0430, W. Michael Petullo wrote: > I now have a document describing how to configure Asterisk to use LDAP at: > > http://www.flyn.org/astldap/astldap.html > > This document provides example configuration files, LDAP schema and > LDAP data. If I read this right it means each user entry need to extended with the AsteriskExtension objectclass, and at least the AstExtention, AstContext,AstPriority,Astapplication and AstApplicationData attrtibutes need to be provided. Is that all is needed to associate a user and an extension ? What's the phone-test entry ? Is it another user type? (I notice an AsteriskSIPUser objectclass there. What is the password used for ? Is it required ? Can something else be used? Simo. -- Simo Sorce * Red Hat, Inc * New York From dqarras at yahoo.com Fri Apr 11 19:55:20 2008 From: dqarras at yahoo.com (Daniel Qarras) Date: Fri, 11 Apr 2008 12:55:20 -0700 (PDT) Subject: [Freeipa-devel] nss-ldapd Message-ID: <586111.63534.qm@web36806.mail.mud.yahoo.com> Hi! I was wondering are you IPA devs aware of nss-ldapd? It is a fork of nss_ldap and it's largely rewritten, the new design has received some positive comments. More information about if can be found from: http://ch.tudelft.nl/~arthur/nss-ldapd/ http://ch.tudelft.nl/~arthur/nss-ldapd/design.html FWIW, I'm posting this because I mentioned nss-ldapd in nss/ldap related RH Bugzilla reports and there's some speculation would it be possible to include nss-ldapd in Fedora. I think SuSE is already opted for it. https://bugzilla.redhat.com/show_bug.cgi?id=186527 https://bugzilla.redhat.com/show_bug.cgi?id=206399 Thanks. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rcritten at redhat.com Mon Apr 14 20:39:07 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2008 13:39:07 -0700 Subject: [Freeipa-devel] [PATCH] configure ipa_pwd_extop on replicas Message-ID: <4803C0EB.9050503@redhat.com> We weren't setting up the password extended operation plugin on replicas so any new user's added there (or passwords changed) would not update/create a krbPrincipalKey attribute. This meant that user's added there couldn't use their passwords for kinit (or anything else) because it didn't exist. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Configure-the-ipa_pwd_extop-plugin-on-replicas.patch Type: text/x-patch Size: 2133 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Apr 14 21:00:24 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 14 Apr 2008 17:00:24 -0400 Subject: [Freeipa-devel] [PATCH] configure ipa_pwd_extop on replicas In-Reply-To: <4803C0EB.9050503@redhat.com> References: <4803C0EB.9050503@redhat.com> Message-ID: <4803C5E8.3060908@redhat.com> Rob Crittenden wrote: > We weren't setting up the password extended operation plugin on replicas > so any new user's added there (or passwords changed) would not > update/create a krbPrincipalKey attribute. This meant that user's added > there couldn't use their passwords for kinit (or anything else) because > it didn't exist. Wow I totally missed that :-/ Thanks for finding this one, very well done and full ack on all changes. Simo. From rcritten at redhat.com Mon Apr 14 21:12:49 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2008 14:12:49 -0700 Subject: [Freeipa-devel] [PATCH] handle python-ldap 2.2.0 errors more gracefully Message-ID: <4803C8D1.4010008@redhat.com> python-ldap 2.2.0 doesn't have the same error structure so our error processing in ipadiscovery.py was itself throwing an error. Try to catch that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Handle-exceptions-more-gracefully-on-systems-with-py.patch Type: text/x-patch Size: 1315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Apr 14 21:14:45 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2008 14:14:45 -0700 Subject: [Freeipa-devel] [PATCH] configure ipa_pwd_extop on replicas In-Reply-To: <4803C5E8.3060908@redhat.com> References: <4803C0EB.9050503@redhat.com> <4803C5E8.3060908@redhat.com> Message-ID: <4803C945.2090605@redhat.com> Simo Sorce wrote: > Rob Crittenden wrote: >> We weren't setting up the password extended operation plugin on >> replicas so any new user's added there (or passwords changed) would >> not update/create a krbPrincipalKey attribute. This meant that user's >> added there couldn't use their passwords for kinit (or anything else) >> because it didn't exist. > > Wow I totally missed that :-/ > > Thanks for finding this one, very well done and full ack on all changes. > > Simo. Yeah, this one had me scratching my head for a while :-) Pushed rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Apr 14 21:17:09 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 14 Apr 2008 17:17:09 -0400 Subject: [Freeipa-devel] [PATCH] handle python-ldap 2.2.0 errors more gracefully In-Reply-To: <4803C8D1.4010008@redhat.com> References: <4803C8D1.4010008@redhat.com> Message-ID: <4803C9D5.9040803@redhat.com> Rob Crittenden wrote: > python-ldap 2.2.0 doesn't have the same error structure so our error > processing in ipadiscovery.py was itself throwing an error. Try to catch > that. ACK From rcritten at redhat.com Mon Apr 14 21:26:37 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2008 14:26:37 -0700 Subject: [Freeipa-devel] [PATCH] handle python-ldap 2.2.0 errors more gracefully In-Reply-To: <4803C9D5.9040803@redhat.com> References: <4803C8D1.4010008@redhat.com> <4803C9D5.9040803@redhat.com> Message-ID: <4803CC0D.7070400@redhat.com> Simo Sorce wrote: > Rob Crittenden wrote: >> python-ldap 2.2.0 doesn't have the same error structure so our error >> processing in ipadiscovery.py was itself throwing an error. Try to >> catch that. > > ACK pushed -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Apr 14 21:55:40 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2008 14:55:40 -0700 Subject: [Freeipa-devel] [PATCH] detect existing instances in replica install Message-ID: <4803D2DC.8030401@redhat.com> ipa-server-install will detect existing FDS instances and prompt to remove them. ipa-replica-install will not, so I stole the code from ipa-server-install to make things work nicer. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Detect-existing-DS-instances-and-prompt-for-removal.patch Type: text/x-patch Size: 2034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Apr 14 22:48:16 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2008 15:48:16 -0700 Subject: [Freeipa-devel] [PATCH] fix ipa-lockuser Message-ID: <4803DF30.407@redhat.com> Don't stop trying to lock a user because they aren't explicitly in the cn=activated group. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Handle-exceptions-more-gracefully-on-systems-with-py.patch Type: text/x-patch Size: 1315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Apr 14 23:35:12 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2008 16:35:12 -0700 Subject: [Freeipa-devel] [PATCH] detect whether DS is running Message-ID: <4803EA30.4010402@redhat.com> The dirsrv init script always returns 0 when you check it for status. During install this is a problem because if DS doesn't start you get a slew of weird, unhelpful output from ldap_modify. So instead look at the output of dirsrv to test for status. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Better-detection-of-DS-not-starting.patch Type: text/x-patch Size: 2442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Apr 15 00:54:16 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2008 17:54:16 -0700 Subject: [Freeipa-devel] [PATCH] fix ipa-lockuser In-Reply-To: <4803DF30.407@redhat.com> References: <4803DF30.407@redhat.com> Message-ID: <4803FCB8.3070109@redhat.com> Rob Crittenden wrote: > Don't stop trying to lock a user because they aren't explicitly in the > cn=activated group. Bleh, I attached the wrong patch. The right one is attached now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Don-t-quit-trying-to-lock-a-user-if-they-aren-t-in-t.patch Type: text/x-patch Size: 1354 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Apr 15 00:58:26 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2008 17:58:26 -0700 Subject: [Freeipa-devel] [PATCH] fix ipa-lockuser In-Reply-To: <4803FCB8.3070109@redhat.com> References: <4803DF30.407@redhat.com> <4803FCB8.3070109@redhat.com> Message-ID: <4803FDB2.6050804@redhat.com> Rob Crittenden wrote: > Rob Crittenden wrote: >> Don't stop trying to lock a user because they aren't explicitly in the >> cn=activated group. > > Bleh, I attached the wrong patch. The right one is attached now. > > I pushed this patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Apr 15 00:58:39 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Apr 2008 17:58:39 -0700 Subject: [Freeipa-devel] [PATCH] detect whether DS is running In-Reply-To: <4803EA30.4010402@redhat.com> References: <4803EA30.4010402@redhat.com> Message-ID: <4803FDBF.1000503@redhat.com> Rob Crittenden wrote: > The dirsrv init script always returns 0 when you check it for status. > During install this is a problem because if DS doesn't start you get a > slew of weird, unhelpful output from ldap_modify. > > So instead look at the output of dirsrv to test for status. > > rob I pushed this. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Apr 15 10:29:51 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 15 Apr 2008 06:29:51 -0400 Subject: [Freeipa-devel] [PATCH] detect existing instances in replica install In-Reply-To: <4803D2DC.8030401@redhat.com> References: <4803D2DC.8030401@redhat.com> Message-ID: <4804839F.2050908@redhat.com> Rob Crittenden wrote: > ipa-server-install will detect existing FDS instances and prompt to > remove them. ipa-replica-install will not, so I stole the code from > ipa-server-install to make things work nicer. > ACK From rcritten at redhat.com Wed Apr 16 01:04:15 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Apr 2008 18:04:15 -0700 Subject: [Freeipa-devel] [PATCH] Handle all connection errors Message-ID: <4805508F.2070605@redhat.com> Add an 'except Exception' when trying to get an LDAP connection so we can handle any error type gracefully. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Catch-all-errors-when-obtaining-an-LDAP-connection.patch Type: text/x-patch Size: 895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Apr 16 01:30:38 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 15 Apr 2008 18:30:38 -0700 Subject: [Freeipa-devel] [PATCH] move print statement to correct scope Message-ID: <480556BE.5010006@redhat.com> ipa-lockuser -u wasn't displaying any output because the print statement was in the wrong scope. I've pushed the attached patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Move-print-statement-to-the-correct-scope-so-it-disp.patch Type: text/x-patch Size: 739 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From daobrien at redhat.com Wed Apr 16 03:24:48 2008 From: daobrien at redhat.com (David O'Brien) Date: Wed, 16 Apr 2008 13:24:48 +1000 Subject: [Freeipa-devel] [PATCH] configured server first In-Reply-To: <1207766623.9925.249.camel@localhost.localdomain> References: <1207766623.9925.249.camel@localhost.localdomain> Message-ID: <48057180.30706@redhat.com> Simo Sorce wrote: > Use the configured server in ipa.conf first. > This is a kind of poor man server affinity but helps admins have a > server of preference they always contact if it is available. > Normal fallback still works if that server does not work. > > Simo. > > > ------------------------------------------------------------------------ > > # HG changeset patch > # User Simo Sorce > # Date 1207766221 14400 > # Node ID fd06d4b83d08f666c681b3df85698d5350c2972a > # Parent 0e829d2c4448273e279fd57e93dc0f33a4603d82 > Make sure we use the configured server in ipa.conf first, and > fallback to the discovered ones only if that's not available > > > if not config.default_realm: > raise IPAConfigError("IPA realm not found in DNS, in the config file (/etc/ipa/ipa.conf) or on the command line.") > Question about this, or maybe an example would clear it up... Is fallback going to work also from the cli? e.g. pass the realm on the cli and if that's not found look in ipa.conf and if not there use DNS and if all that fails spit out the above error? What's an example of passing the realm on the cli? I thought it was optional... /me the not quite grokking it yet... -- David O'Brien IPA Content Author Red Hat Asia Pacific "We couldn't care less about comfort. We make you feel good." Federico Minoli CEO Ducati Motor S.p.A. From peter at numbersusa.com Fri Apr 18 15:21:10 2008 From: peter at numbersusa.com (Peter Halliday) Date: Fri, 18 Apr 2008 11:21:10 -0400 Subject: [Freeipa-devel] using ipa-server in a mix OS world Message-ID: We have successfully used ipa-server in an environment in a homogeneous office of Mac computers. We are looking to spread it to another office where there is mixed, but mostly windows. The windows computers using roaming profiles right now and samba. I'm trying to figure out how to be able to store the NFS (for the non-wndows users's home dirs) and the Samba stuff in the same place for ease of backup. Anyone know how this best can be solved. -- Peter Halliday NumbersUSA (Phone:) 607-936-3717 Ext. 102 (Cell:) 607-329-6905 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Mon Apr 21 13:15:40 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 21 Apr 2008 09:15:40 -0400 Subject: [Freeipa-devel] nss-ldapd In-Reply-To: <586111.63534.qm@web36806.mail.mud.yahoo.com> References: <586111.63534.qm@web36806.mail.mud.yahoo.com> Message-ID: <1208783740.3329.4.camel@localhost.localdomain> On Fri, 2008-04-11 at 12:55 -0700, Daniel Qarras wrote: > Hi! > > I was wondering are you IPA devs aware of nss-ldapd? It is a fork of > nss_ldap and it's largely rewritten, the new design has received some > positive comments. More information about if can be found from: > > http://ch.tudelft.nl/~arthur/nss-ldapd/ > http://ch.tudelft.nl/~arthur/nss-ldapd/design.html > > FWIW, I'm posting this because I mentioned nss-ldapd in nss/ldap > related RH Bugzilla reports and there's some speculation would it be > possible to include nss-ldapd in Fedora. I think SuSE is already opted > for it. > > https://bugzilla.redhat.com/show_bug.cgi?id=186527 > https://bugzilla.redhat.com/show_bug.cgi?id=206399 Hi Daniel, yes I know of nss-ldapd and I've read through the sources for a bit last year. We plan on building something a bit more sophisticated, but I will keep that code as a reference for some of the work we need to do. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Apr 21 18:44:59 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 21 Apr 2008 14:44:59 -0400 Subject: [Freeipa-devel] [PATCH] Fix memory leaks in memberOf plug-in In-Reply-To: <47F69BBC.5040607@redhat.com> References: <47F69BBC.5040607@redhat.com> Message-ID: <1208803499.3329.31.camel@localhost.localdomain> On Fri, 2008-04-04 at 14:21 -0700, Nathan Kinder wrote: > Fixed a number of leaks in the memberOf plug-in. Some common cases, > such as adding and removing member attributes from groups were > leaking > entries. The the referenced bug report for more information. Looks good, ack Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Apr 21 22:25:15 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Apr 2008 18:25:15 -0400 Subject: [Freeipa-devel] [PATCH] fix 'make dist' Message-ID: <480D144B.9010807@redhat.com> 'make dist' still required a mercurial command to run to ensure that it was building from untainted sources. I've converted it to use git and added an argument, TARGET, if you want to have it pull a specific branch. By default it uses 'master'. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Convert-mercurial-command-to-git-equivalent-for-crea.patch Type: text/x-patch Size: 1078 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Apr 22 13:59:24 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Apr 2008 09:59:24 -0400 Subject: [Freeipa-devel] [PATCH] Don't create a replica for itself Message-ID: <480DEF3C.4040003@redhat.com> Don't allow a host to prepare a replica for a host of the same name. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Don-t-allow-a-replica-to-prepare-a-replica-for-itsel.patch Type: text/x-patch Size: 902 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Apr 22 15:52:25 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Apr 2008 11:52:25 -0400 Subject: [Freeipa-devel] [PATCH] fix self-service uid change Message-ID: <480E09B9.5080808@redhat.com> I try to do some sanity checks to be sure that the user we're changing is the one that was pulled up to edit to prevent injection attacks. In this case I was using the wrong uid field to be sure that in the case of a self-service edit the user doing the editing is the user logged in. The uid wasn't matching it was being rejected, but that is of course the point because comparison. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-3-changeuid.patch Type: text/x-patch Size: 1280 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Apr 22 16:37:13 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 22 Apr 2008 12:37:13 -0400 Subject: [Freeipa-devel] [PATCH] Don't create a replica for itself In-Reply-To: <480DEF3C.4040003@redhat.com> References: <480DEF3C.4040003@redhat.com> Message-ID: <1208882233.3329.116.camel@localhost.localdomain> On Tue, 2008-04-22 at 09:59 -0400, Rob Crittenden wrote: > Don't allow a host to prepare a replica for a host of the same name. Full ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Apr 22 18:35:14 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 22 Apr 2008 14:35:14 -0400 Subject: [Freeipa-devel] [PATCH] Domain realm section for clients Message-ID: <1208889314.3329.139.camel@localhost.localdomain> Make sure we always have [domain-realm] -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Apr 22 18:43:25 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 22 Apr 2008 14:43:25 -0400 Subject: [Freeipa-devel] [PATCH] Domain realm section for clients Message-ID: <1208889805.3329.142.camel@localhost.localdomain> Let's try to see if evolution screws up also with an inlined patch :/ >From dc3dc3d970d9e2584827f29fcc6a03211f6e1ca6 Mon Sep 17 00:00:00 2001 From: Simo Sorce Date: Tue, 22 Apr 2008 14:11:34 -0400 Subject: [PATCH] Make sure we always have the [domain-realm] section or kerberos libs misbheave. --- ipa-client/ipa-install/ipa-client-install | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 976416d..56fcb32 100644 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -287,11 +287,11 @@ def main(): opts.append({'name':'realms', 'type':'section', 'value':ropts}) opts.append({'name':'empty', 'type':'empty'}) - #[domain_realm] - dropts = [{'name':'.'+cli_domain, 'type':'option', 'value':cli_realm}, - {'name':cli_domain, 'type':'option', 'value':cli_realm}] - opts.append({'name':'domain_realm', 'type':'section', 'value':dropts}) - opts.append({'name':'empty', 'type':'empty'}) + #[domain_realm] + dropts = [{'name':'.'+cli_domain, 'type':'option', 'value':cli_realm}, + {'name':cli_domain, 'type':'option', 'value':cli_realm}] + opts.append({'name':'domain_realm', 'type':'section', 'value':dropts}) + opts.append({'name':'empty', 'type':'empty'}) #[appdefaults] pamopts = [{'name':'debug', 'type':'option', 'value':'false'}, -- 1.5.4.1 -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Apr 22 19:31:09 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Apr 2008 15:31:09 -0400 Subject: [Freeipa-devel] [PATCH] Domain realm section for clients In-Reply-To: <1208889805.3329.142.camel@localhost.localdomain> References: <1208889805.3329.142.camel@localhost.localdomain> Message-ID: <480E3CFD.8020507@redhat.com> Simo Sorce wrote: > Let's try to see if evolution screws up also with an inlined patch :/ > > ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Apr 22 19:34:36 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 22 Apr 2008 15:34:36 -0400 Subject: [Freeipa-devel] [PATCH] Domain realm section for clients In-Reply-To: <480E3CFD.8020507@redhat.com> References: <1208889805.3329.142.camel@localhost.localdomain> <480E3CFD.8020507@redhat.com> Message-ID: <1208892876.3329.144.camel@localhost.localdomain> On Tue, 2008-04-22 at 15:31 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Let's try to see if evolution screws up also with an inlined patch :/ > > > > > > ack pushed both to master and ipa-1-0 branches Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Apr 22 20:05:24 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Apr 2008 16:05:24 -0400 Subject: [Freeipa-devel] [PATCH] fix self-service uid change In-Reply-To: <480E09B9.5080808@redhat.com> References: <480E09B9.5080808@redhat.com> Message-ID: <480E4504.70202@redhat.com> Rob Crittenden wrote: > I try to do some sanity checks to be sure that the user we're changing > is the one that was pulled up to edit to prevent injection attacks. In > this case I was using the wrong uid field to be sure that in the case of > a self-service edit the user doing the editing is the user logged in. > > The uid wasn't matching it was being rejected, but that is of course the > point because comparison. > > New patch. Simo hit me up in #freeipa with some questions and concerns. uid_hidden is kinda poorly named. It really should be uid_orig or something. In any case, it is what we loaded vs what we are now. We use the TG user context to tell who we really are. I've fixed a bug there too. At one time I assumed that uid == principalname - REALM. This no longer assumes that and sets the name being displayed as "logged in" as the uid. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-4-changuid.patch Type: text/x-patch Size: 2711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Apr 22 20:32:14 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 22 Apr 2008 16:32:14 -0400 Subject: [Freeipa-devel] [PATCH] fix self-service uid change In-Reply-To: <480E4504.70202@redhat.com> References: <480E09B9.5080808@redhat.com> <480E4504.70202@redhat.com> Message-ID: <1208896334.3329.156.camel@localhost.localdomain> On Tue, 2008-04-22 at 16:05 -0400, Rob Crittenden wrote: > New patch. Simo hit me up in #freeipa with some questions and > concerns. > > uid_hidden is kinda poorly named. It really should be uid_orig or > something. > > In any case, it is what we loaded vs what we are now. We use the TG > user > context to tell who we really are. I've fixed a bug there too. At one > time I assumed that uid == principalname - REALM. This no longer > assumes > that and sets the name being displayed as "logged in" as the uid. Ack -- Simo Sorce * Red Hat, Inc * New York From aGiggins at wcg.net.au Wed Apr 23 01:40:16 2008 From: aGiggins at wcg.net.au (Anthony Giggins) Date: Wed, 23 Apr 2008 11:40:16 +1000 Subject: [Freeipa-devel] RHEL5/Centos Installation instructions? Message-ID: Hello, Silly question it says on the website that freeipa can be installed in RHEL5/Centos but I cant find any instructions on the website can anyone point me in the right direction? Regards, Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Apr 23 19:43:11 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Apr 2008 15:43:11 -0400 Subject: [Freeipa-devel] [PATCH] Don't create a replica for itself In-Reply-To: <1208882233.3329.116.camel@localhost.localdomain> References: <480DEF3C.4040003@redhat.com> <1208882233.3329.116.camel@localhost.localdomain> Message-ID: <480F914F.3060209@redhat.com> Simo Sorce wrote: > On Tue, 2008-04-22 at 09:59 -0400, Rob Crittenden wrote: >> Don't allow a host to prepare a replica for a host of the same name. > > Full ack > Pushed to ipa-1-0 and master. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Apr 23 19:43:34 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Apr 2008 15:43:34 -0400 Subject: [Freeipa-devel] [PATCH] fix self-service uid change In-Reply-To: <1208896334.3329.156.camel@localhost.localdomain> References: <480E09B9.5080808@redhat.com> <480E4504.70202@redhat.com> <1208896334.3329.156.camel@localhost.localdomain> Message-ID: <480F9166.7010104@redhat.com> Simo Sorce wrote: > On Tue, 2008-04-22 at 16:05 -0400, Rob Crittenden wrote: >> New patch. Simo hit me up in #freeipa with some questions and >> concerns. >> >> uid_hidden is kinda poorly named. It really should be uid_orig or >> something. >> >> In any case, it is what we loaded vs what we are now. We use the TG >> user >> context to tell who we really are. I've fixed a bug there too. At one >> time I assumed that uid == principalname - REALM. This no longer >> assumes >> that and sets the name being displayed as "logged in" as the uid. > > Ack > Pushed to ipa-1-0 and master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Apr 24 14:45:02 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Apr 2008 10:45:02 -0400 Subject: [Freeipa-devel] [PATCH] add verbose flag to admin tools Message-ID: <48109CEE.7020105@redhat.com> The python xmlrpclib library offers a verbose option to print the HTTP headers and the XML request and response. Added a --verbose flag to the admin tools and the client API to enable this. Also fix the python imports. I had attempted to wrap everything in a try/except so we could catch a ^C without a backtrace during imports but this masked other errors. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-5-verbose.patch Type: text/x-patch Size: 38497 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Apr 24 14:52:34 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 24 Apr 2008 10:52:34 -0400 Subject: [Freeipa-devel] [PATCH] add verbose flag to admin tools In-Reply-To: <48109CEE.7020105@redhat.com> References: <48109CEE.7020105@redhat.com> Message-ID: <1209048754.3329.233.camel@localhost.localdomain> On Thu, 2008-04-24 at 10:45 -0400, Rob Crittenden wrote: > The python xmlrpclib library offers a verbose option to print the > HTTP > headers and the XML request and response. Added a --verbose flag to > the > admin tools and the client API to enable this. > > Also fix the python imports. I had attempted to wrap everything in a > try/except so we could catch a ^C without a backtrace during imports > but > this masked other errors. ack Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Apr 25 13:27:47 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 25 Apr 2008 09:27:47 -0400 Subject: [Freeipa-devel] FreeIPA 1.0 Released Message-ID: <1209130067.3329.250.camel@localhost.localdomain> The FreeIPA Project (http://freeipa.org) is proud to present FreeIPA version 1.0. FreeIPA is an integrated security information management solution combining Linux (Fedora), Fedora Directory Server, MIT Kerberos and NTP. FreeIPA binds together a number of technologies and adds a web interface and command-line administration tools. Currently it supports identity management with plans to support policy and auditing management. We were able to achieve most of the planned features[1] for this release though we had to postpone some of them to later versions we are very happy about the outcome. Of the three letters of IPA (Identity, Policy, Audit), we were able to implement a substantial part of the Identity management. The integration of Fedora Directory Server and MIT Kerberos provide our framework for authentication and authorization, the Web UI and the CLI tools allow for easy and effective administration of Identities. The use of standard protocols like LDAP and Kerberos allows for easy integration of other Operating Systems into an IPA realm for centralized Identity Management. We encourage users and developers to start testing and deploying FreeIPA in their environments. A very simple installation procedure is provided and is part of the effort of making these complex technologies simple to use and friendly to administrators. We encourage people to experiment and evaluate the current release, we welcome feedback on the overall experience and bug reports[2]. We also would like to encourage interested users and developers to join our mailing list and discuss version 2 features and development directions. We have already identified a number of features[3] and components we are going to integrate for the next release, and we would welcome feedback on the perceived needs and problems, as well as solution proposals and contributions[4]. The complete source code[5] is available for download here: http://www.freeipa.org/page/Downloads We are also pleased to announce that FreeIPA 1.0 will be available in Fedora 9 [6] and RPM packages are available for Fedora 7 and Fedora 8 in their respective repositories [7]. Have Fun! The FreeIPA Project Team. --- [1] http://freeipa.org/page/V1PRD [2] https://bugzilla.redhat.com/enter_bug.cgi?product=freeIPA [3] http://freeipa.org/page/V2BPRD [4] http://freeipa.org/page/Contribute [5] The source code does not include Fedora Directory Server or MIT Kerberos which are available for the respective websites. [6] http://fedoraproject.org/wiki/Releases/9/FeatureList#head-81923ae2b95ffc70af5c4623a0106615e97a94f1 [7] http://freeipa.org/page/Downloads#Yum_Repo -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Apr 25 14:43:00 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Apr 2008 10:43:00 -0400 Subject: [Freeipa-devel] [PATCH] add verbose flag to admin tools In-Reply-To: <1209048754.3329.233.camel@localhost.localdomain> References: <48109CEE.7020105@redhat.com> <1209048754.3329.233.camel@localhost.localdomain> Message-ID: <4811EDF4.8010902@redhat.com> Simo Sorce wrote: > On Thu, 2008-04-24 at 10:45 -0400, Rob Crittenden wrote: >> The python xmlrpclib library offers a verbose option to print the >> HTTP >> headers and the XML request and response. Added a --verbose flag to >> the >> admin tools and the client API to enable this. >> >> Also fix the python imports. I had attempted to wrap everything in a >> try/except so we could catch a ^C without a backtrace during imports >> but >> this masked other errors. > > ack > > Simo. > Pushed to ipa-1-0 and head -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Apr 25 17:35:14 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Apr 2008 13:35:14 -0400 Subject: [Freeipa-devel] [PATCH] Make search limit option work Message-ID: <48121652.1000107@redhat.com> Fix the client-side search size limit. I've changed the variable name searchlimit to sizelimit to match the name in python-ldap (and hopefully therefore be more readable). The big change was changing the default value from 0 to -1. As 0 we were never using the value from cn=ipaconfig python-ldap expects this to be an int type In the UI sizelimit was hardcoded at 0 for users rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-6-sizelimit.patch Type: text/x-patch Size: 19316 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Apr 25 18:18:07 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 25 Apr 2008 14:18:07 -0400 Subject: [Freeipa-devel] [PATCH] make newer ldapmodify happy Message-ID: <4812205F.8030000@redhat.com> Rob please apply to Fedora 9 packages and respin. I am about to push to both branches, under the trivial rule. Simo. From ssorce at redhat.com Fri Apr 25 18:32:29 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 25 Apr 2008 14:32:29 -0400 Subject: [Freeipa-devel] [PATCH] Make search limit option work In-Reply-To: <48121652.1000107@redhat.com> References: <48121652.1000107@redhat.com> Message-ID: <1209148349.3329.275.camel@localhost.localdomain> On Fri, 2008-04-25 at 13:35 -0400, Rob Crittenden wrote: > Fix the client-side search size limit. > > I've changed the variable name searchlimit to sizelimit to match the > name in python-ldap (and hopefully therefore be more readable). > > The big change was changing the default value from 0 to -1. As 0 we > were > never using the value from cn=ipaconfig > > python-ldap expects this to be an int type > > In the UI sizelimit was hardcoded at 0 for users ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Apr 25 18:41:24 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 25 Apr 2008 14:41:24 -0400 Subject: [Freeipa-devel] [PATCH] make newer ldapmodify happy In-Reply-To: <4812205F.8030000@redhat.com> References: <4812205F.8030000@redhat.com> Message-ID: <1209148884.3329.278.camel@localhost.localdomain> On Fri, 2008-04-25 at 14:18 -0400, Simo Sorce wrote: > Rob please apply to Fedora 9 packages and respin. > > I am about to push to both branches, under the trivial rule. Wow both thunderbird and eveolution manage to screw up git patches if not inlined ... what a shame. Here again inline: >From f681e3d265a0e84ccef2451ffd82497ff908c697 Mon Sep 17 00:00:00 2001 From: Simo Sorce Date: Fri, 25 Apr 2008 14:06:24 -0400 Subject: [PATCH] Make sure recent ldapmodify tool (as in F9) do not complain by splitting the operation into 2 modify operations --- ipa-server/ipa-install/share/default-keytypes.ldif | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/ipa-server/ipa-install/share/default-keytypes.ldif b/ipa-server/ipa-install/share/default-keytypes.ldif index 9cafacd..1d54a05 100644 --- a/ipa-server/ipa-install/share/default-keytypes.ldif +++ b/ipa-server/ipa-install/share/default-keytypes.ldif @@ -11,6 +11,11 @@ krbSupportedEncSaltTypes: des-cbc-md5:normal krbSupportedEncSaltTypes: des-cbc-crc:normal krbSupportedEncSaltTypes: des-cbc-crc:v4 krbSupportedEncSaltTypes: des-cbc-crc:afs3 + +#kerberos keytypes +dn: cn=$REALM,cn=kerberos,$SUFFIX +changetype: modify +add: krbDefaultEncSaltTypes krbDefaultEncSaltTypes: aes256-cts:normal krbDefaultEncSaltTypes: aes128-cts:normal krbDefaultEncSaltTypes: des3-hmac-sha1:normal -- 1.5.4.1 -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Apr 25 20:44:27 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Apr 2008 16:44:27 -0400 Subject: [Freeipa-devel] [PATCH] Make search limit option work In-Reply-To: <1209148349.3329.275.camel@localhost.localdomain> References: <48121652.1000107@redhat.com> <1209148349.3329.275.camel@localhost.localdomain> Message-ID: <481242AB.1050202@redhat.com> Simo Sorce wrote: > On Fri, 2008-04-25 at 13:35 -0400, Rob Crittenden wrote: >> Fix the client-side search size limit. >> >> I've changed the variable name searchlimit to sizelimit to match the >> name in python-ldap (and hopefully therefore be more readable). >> >> The big change was changing the default value from 0 to -1. As 0 we >> were >> never using the value from cn=ipaconfig >> >> python-ldap expects this to be an int type >> >> In the UI sizelimit was hardcoded at 0 for users > > > ack > > Pushed to master rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Apr 25 20:58:28 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Apr 2008 16:58:28 -0400 Subject: [Freeipa-devel] [PATCH] Don't allow default service principals to be removed Message-ID: <481245F4.3050905@redhat.com> Don't allow default service principals to be removed (it would hork up the IPA server). I use cn=kerberos in the DN as the identifier of a non-removable principal. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-7-principals.patch Type: text/x-patch Size: 1513 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From dhollis at davehollis.com Fri Apr 25 21:38:55 2008 From: dhollis at davehollis.com (David Hollis) Date: Fri, 25 Apr 2008 17:38:55 -0400 Subject: [Freeipa-devel] [PATCH] Don't allow default service principals to be removed In-Reply-To: <481245F4.3050905@redhat.com> References: <481245F4.3050905@redhat.com> Message-ID: <1209159535.4417.26.camel@dhollis-lnx> On Fri, 2008-04-25 at 16:58 -0400, Rob Crittenden wrote: > if entry is None: > raise ipaerror.gen_exception(ipaerror.LDAP_NOT_FOUND) > + dn_list = ldap.explode_dn(entry['dn'].lower()) > + if "cn=kerberos" in dn_list: > + raise ipaerror.gen_exception(ipaerror.LDAP_NOT_FOUND) I don't know squat about python, but should the exception thrown be LDAP_NOT_FOUND or should it be INPUT_SERVICE_PRINCIPAL_REQUIRED that was defined higher up in the patch? From rcritten at redhat.com Fri Apr 25 21:44:58 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Apr 2008 17:44:58 -0400 Subject: [Freeipa-devel] [PATCH] Don't allow default service principals to be removed In-Reply-To: <1209159535.4417.26.camel@dhollis-lnx> References: <481245F4.3050905@redhat.com> <1209159535.4417.26.camel@dhollis-lnx> Message-ID: <481250DA.4050801@redhat.com> David Hollis wrote: > On Fri, 2008-04-25 at 16:58 -0400, Rob Crittenden wrote: >> if entry is None: >> raise ipaerror.gen_exception(ipaerror.LDAP_NOT_FOUND) >> + dn_list = ldap.explode_dn(entry['dn'].lower()) >> + if "cn=kerberos" in dn_list: >> + raise ipaerror.gen_exception(ipaerror.LDAP_NOT_FOUND) > > I don't know squat about python, but should the exception thrown be > LDAP_NOT_FOUND or should it be INPUT_SERVICE_PRINCIPAL_REQUIRED that was > defined higher up in the patch? > > Ack, nice catch. I'll fix it up and resubmit. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From bigjoe1008 at gmail.com Sat Apr 26 01:00:45 2008 From: bigjoe1008 at gmail.com (Joe Harnish) Date: Fri, 25 Apr 2008 21:00:45 -0400 Subject: [Freeipa-devel] ipa-server conflicts with mod_ssl Message-ID: <763fc8580804251800j4ef10139t465f43976a0d173c@mail.gmail.com> All, I just installed Fedora 9 Preview, updated went to install ipa-server. It complained that ipa-server conflicts with mod_ssl. Is the this expected behaviour? Thanks --Joe From rcritten at redhat.com Sat Apr 26 02:13:00 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Apr 2008 22:13:00 -0400 Subject: [Freeipa-devel] ipa-server conflicts with mod_ssl In-Reply-To: <763fc8580804251800j4ef10139t465f43976a0d173c@mail.gmail.com> References: <763fc8580804251800j4ef10139t465f43976a0d173c@mail.gmail.com> Message-ID: <48128FAC.2090107@redhat.com> Joe Harnish wrote: > All, > > I just installed Fedora 9 Preview, updated went to install ipa-server. > It complained that ipa-server conflicts with mod_ssl. Is the this > expected behaviour? > Yes. We use mod_proxy which has only one set of hooks to do SSL proxying. Because we use mod_nss for SSL we have to disable mod_ssl. Unfortunately this can be problematic if mod_ssl is upgraded (and a new ssl.conf is installed) so for now the two can't co-exist. It isn't enough to set the mod_ssl SSLEngine off either. If the .so is loaded by Apache then mod_proxy will try to use mod_ssl instead of mod_nss for SSL proxying. Perhaps we can come up with a better way of doing this so that mod_ssl doesn't have to be removed but is still not loaded. The long-term fix is to patch mod_proxy to be configurable as to the SSL engine it uses. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Apr 28 13:46:44 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Apr 2008 09:46:44 -0400 Subject: [Freeipa-devel] [PATCH] Don't allow default service principals to be removed In-Reply-To: <481250DA.4050801@redhat.com> References: <481245F4.3050905@redhat.com> <1209159535.4417.26.camel@dhollis-lnx> <481250DA.4050801@redhat.com> Message-ID: <4815D544.4090407@redhat.com> Rob Crittenden wrote: > David Hollis wrote: >> On Fri, 2008-04-25 at 16:58 -0400, Rob Crittenden wrote: >>> if entry is None: >>> raise ipaerror.gen_exception(ipaerror.LDAP_NOT_FOUND) >>> + dn_list = ldap.explode_dn(entry['dn'].lower()) >>> + if "cn=kerberos" in dn_list: >>> + raise ipaerror.gen_exception(ipaerror.LDAP_NOT_FOUND) >> >> I don't know squat about python, but should the exception thrown be >> LDAP_NOT_FOUND or should it be INPUT_SERVICE_PRINCIPAL_REQUIRED that was >> defined higher up in the patch? >> >> > > Ack, nice catch. I'll fix it up and resubmit. Corrected patch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-7-principals.patch Type: text/x-patch Size: 1531 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Apr 28 20:16:36 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 28 Apr 2008 16:16:36 -0400 Subject: [Freeipa-devel] [PATCH] Fix a bug in our dns library, do not return the query as a reply Message-ID: <1209413796.3329.302.camel@localhost.localdomain> >From 8e9f6e9c6d42a552dfa7fe9dd37824fc811d7625 Mon Sep 17 00:00:00 2001 From: Simo Sorce Date: Mon, 28 Apr 2008 16:06:23 -0400 Subject: [PATCH] Fix a bug in our dns library, do not return the query as a reply if 0 replies were returned. --- ipa-python/dnsclient.py | 12 +++++------- 1 files changed, 5 insertions(+), 7 deletions(-) diff --git a/ipa-python/dnsclient.py b/ipa-python/dnsclient.py index 44dae4d..58d93d8 100644 --- a/ipa-python/dnsclient.py +++ b/ipa-python/dnsclient.py @@ -365,22 +365,22 @@ def dnsParseResults(results): if not rest: return [] - rr = DNSResult() + qq = DNSResult() (rest, label) = dnsParseLabel(rest, results) if label is None: return [] - if len(rest) < rr.qsize(): + if len(rest) < qq.qsize(): return [] - rr.qunpack(rest) + qq.qunpack(rest) - rest = rest[rr.qsize():] + rest = rest[qq.qsize():] if DEBUG_DNSCLIENT: print "Queried for '%s', class = %d, type = %d." % (label, - rr.dns_class, rr.dns_type) + qq.dns_class, qq.dns_type) for i in xrange(header.dns_ancount + header.dns_nscount + header.dns_arcount): (rest, label) = dnsParseLabel(rest, results) @@ -424,8 +424,6 @@ def dnsParseResults(results): rest = rest[rr.dns_rlength:] rrlist += [rr] - if not rrlist: - rrlist = [rr] return rrlist def query(query, qclass, qtype): -- 1.5.4.1 -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Apr 29 14:39:19 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Apr 2008 10:39:19 -0400 Subject: [Freeipa-devel] [PATCH] set perms on mod_nss database Message-ID: <48173317.1070206@redhat.com> The version of NSS in Fedora 9 required changes to mod_nss to do the NSS_Initialize() in the children. This means that the apache user needs to be able to read the database. The solution was to set the database mode to 640 root:apache. IPA creates its own database and sets the mode to 600 root:root The installer needs to accommodate this change. The F9 package has this fix as a patch in the spec file. We need to commit this to the tree as well. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-8-nssperms.patch Type: text/x-patch Size: 1538 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Apr 29 14:49:14 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 29 Apr 2008 10:49:14 -0400 Subject: [Freeipa-devel] [PATCH] set perms on mod_nss database In-Reply-To: <48173317.1070206@redhat.com> References: <48173317.1070206@redhat.com> Message-ID: <1209480554.12808.0.camel@localhost.localdomain> On Tue, 2008-04-29 at 10:39 -0400, Rob Crittenden wrote: > The version of NSS in Fedora 9 required changes to mod_nss to do the > NSS_Initialize() in the children. This means that the apache user > needs > to be able to read the database. > > The solution was to set the database mode to 640 root:apache. > > IPA creates its own database and sets the mode to 600 root:root > > The installer needs to accommodate this change. > > The F9 package has this fix as a patch in the spec file. We need to > commit this to the tree as well. Ack Simo. -- Simo Sorce * Red Hat, Inc * New York From alex at davz.net Tue Apr 29 14:49:44 2008 From: alex at davz.net (Alex Davies) Date: Tue, 29 Apr 2008 16:49:44 +0200 Subject: [Freeipa-devel] Install on RHEL5 - pointers please Message-ID: <5fb622120804290749o67af6b92x6874ff7d67672377@mail.gmail.com> Hi, I have attempted to install freeIPA on a RHEL5 machine, using FC7 RPMs. This fails with a dependency failure. My steps are as follows: 1) Fully update (yum -y update) a clean install of RHEL5, i386 2) Add fedora-testing Repo in /etc/yum.repos.d/ #Add to /etc/yum.conf [updates-testing] name=Fedora Core $releasever - $basearch - Test Updates baseurl=http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/ enabled=0 gpgcheck=1 3) Run the command [root at ipa yum.repos.d]# yum --enablerepo=updates-testing install ipa-server Loading "rhnplugin" plugin Loading "installonlyn" plugin Loading "security" plugin Setting up Install Process Setting up repositories rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package ipa-server.i386 0:0.99-12.fc7 set to be updated --> Running transaction check --> Processing Dependency: python(abi) = 2.5 for package: ipa-server --> Processing Dependency: python-pyasn1 for package: ipa-server [snipped, full output below] --> Processing Dependency: python(abi) = 2.5 for package: ipa-client --> Processing Dependency: fedora-ds-base >= 1.1 for package: ipa-server --> Finished Dependency Resolution Error: Missing Dependency: python(abi) = 2.5 is needed by package ipa-server Error: Missing Dependency: python-pyasn1 is needed by package ipa-server Error: Missing Dependency: python-krbV is needed by package ipa-server Error: Missing Dependency: krb5-server-ldap is needed by package ipa-server Error: Missing Dependency: TurboGears is needed by package ipa-server Error: Missing Dependency: python-tgexpandingformwidget is needed by package ipa-server Error: Missing Dependency: fedora-ds-base >= 1.1 is needed by package ipa-server Error: Missing Dependency: mod_nss >= 1.0.7-2 is needed by package ipa-server Error: Missing Dependency: python-kerberos is needed by package ipa-python Error: Missing Dependency: python-krbV is needed by package ipa-admintools Error: Missing Dependency: python(abi) = 2.5 is needed by package ipa-python Error: Missing Dependency: python-krbV is needed by package ipa-client Error: Missing Dependency: python(abi) = 2.5 is needed by package ipa-client Can anyone point me in the right direction here? Many thanks, Alex From ssorce at redhat.com Tue Apr 29 14:52:56 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 29 Apr 2008 10:52:56 -0400 Subject: [Freeipa-devel] Install on RHEL5 - pointers please In-Reply-To: <5fb622120804290749o67af6b92x6874ff7d67672377@mail.gmail.com> References: <5fb622120804290749o67af6b92x6874ff7d67672377@mail.gmail.com> Message-ID: <1209480776.12808.5.camel@localhost.localdomain> On Tue, 2008-04-29 at 16:49 +0200, Alex Davies wrote: > Hi, > > I have attempted to install freeIPA on a RHEL5 machine, using FC7 > RPMs. This fails with a dependency failure. My steps are as follows: > > 1) Fully update (yum -y update) a clean install of RHEL5, i386 > > 2) Add fedora-testing Repo in /etc/yum.repos.d/ > #Add to /etc/yum.conf > [updates-testing] > name=Fedora Core $releasever - $basearch - Test Updates > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/ > enabled=0 > gpgcheck=1 > > 3) Run the command > [root at ipa yum.repos.d]# yum --enablerepo=updates-testing install ipa-server > Loading "rhnplugin" plugin > Loading "installonlyn" plugin > Loading "security" plugin > Setting up Install Process > Setting up repositories > rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 > Reading repository metadata in from local files > Parsing package install arguments > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package ipa-server.i386 0:0.99-12.fc7 set to be updated > --> Running transaction check > --> Processing Dependency: python(abi) = 2.5 for package: ipa-server > --> Processing Dependency: python-pyasn1 for package: ipa-server > [snipped, full output below] > --> Processing Dependency: python(abi) = 2.5 for package: ipa-client > --> Processing Dependency: fedora-ds-base >= 1.1 for package: ipa-server > --> Finished Dependency Resolution > Error: Missing Dependency: python(abi) = 2.5 is needed by package ipa-server > Error: Missing Dependency: python-pyasn1 is needed by package ipa-server > Error: Missing Dependency: python-krbV is needed by package ipa-server > Error: Missing Dependency: krb5-server-ldap is needed by package ipa-server > Error: Missing Dependency: TurboGears is needed by package ipa-server > Error: Missing Dependency: python-tgexpandingformwidget is needed by > package ipa-server > Error: Missing Dependency: fedora-ds-base >= 1.1 is needed by package ipa-server > Error: Missing Dependency: mod_nss >= 1.0.7-2 is needed by package ipa-server > Error: Missing Dependency: python-kerberos is needed by package ipa-python > Error: Missing Dependency: python-krbV is needed by package ipa-admintools > Error: Missing Dependency: python(abi) = 2.5 is needed by package ipa-python > Error: Missing Dependency: python-krbV is needed by package ipa-client > Error: Missing Dependency: python(abi) = 2.5 is needed by package ipa-client > > Can anyone point me in the right direction here? F7 packages are not directly compatible with RHEL5, I think some of the python packages are available in EPEL, most other stuff need to be rebuilt from source rpms to make it work on RHEL5, including the kerberos package as we enabled a new subpackage (krb5-server-ldap) in the spec file that is not normally available in RHEL5. Simo. -- Simo Sorce * Red Hat, Inc * New York From alex at davz.net Tue Apr 29 15:23:45 2008 From: alex at davz.net (Alex Davies) Date: Tue, 29 Apr 2008 17:23:45 +0200 Subject: [Freeipa-devel] Install on RHEL5 - pointers please In-Reply-To: <1209480776.12808.5.camel@localhost.localdomain> References: <5fb622120804290749o67af6b92x6874ff7d67672377@mail.gmail.com> <1209480776.12808.5.camel@localhost.localdomain> Message-ID: <5fb622120804290823n74ea534blef5a08b11d883519@mail.gmail.com> Many thanks Simon. I guess its going to be easier to use Fedora then :) Alex On Tue, Apr 29, 2008 at 4:52 PM, Simo Sorce wrote: > > > On Tue, 2008-04-29 at 16:49 +0200, Alex Davies wrote: > > Hi, > > > > I have attempted to install freeIPA on a RHEL5 machine, using FC7 > > RPMs. This fails with a dependency failure. My steps are as follows: > > > > 1) Fully update (yum -y update) a clean install of RHEL5, i386 > > > > 2) Add fedora-testing Repo in /etc/yum.repos.d/ > > #Add to /etc/yum.conf > > [updates-testing] > > name=Fedora Core $releasever - $basearch - Test Updates > > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/7/i386/ > > enabled=0 > > gpgcheck=1 > > > > 3) Run the command > > [root at ipa yum.repos.d]# yum --enablerepo=updates-testing install ipa-server > > Loading "rhnplugin" plugin > > Loading "installonlyn" plugin > > Loading "security" plugin > > Setting up Install Process > > Setting up repositories > > rhel-i386-server-5 100% |=========================| 1.4 kB 00:00 > > Reading repository metadata in from local files > > Parsing package install arguments > > Resolving Dependencies > > --> Populating transaction set with selected packages. Please wait. > > ---> Package ipa-server.i386 0:0.99-12.fc7 set to be updated > > --> Running transaction check > > --> Processing Dependency: python(abi) = 2.5 for package: ipa-server > > --> Processing Dependency: python-pyasn1 for package: ipa-server > > [snipped, full output below] > > --> Processing Dependency: python(abi) = 2.5 for package: ipa-client > > --> Processing Dependency: fedora-ds-base >= 1.1 for package: ipa-server > > --> Finished Dependency Resolution > > Error: Missing Dependency: python(abi) = 2.5 is needed by package ipa-server > > Error: Missing Dependency: python-pyasn1 is needed by package ipa-server > > Error: Missing Dependency: python-krbV is needed by package ipa-server > > Error: Missing Dependency: krb5-server-ldap is needed by package ipa-server > > Error: Missing Dependency: TurboGears is needed by package ipa-server > > Error: Missing Dependency: python-tgexpandingformwidget is needed by > > package ipa-server > > Error: Missing Dependency: fedora-ds-base >= 1.1 is needed by package ipa-server > > Error: Missing Dependency: mod_nss >= 1.0.7-2 is needed by package ipa-server > > Error: Missing Dependency: python-kerberos is needed by package ipa-python > > Error: Missing Dependency: python-krbV is needed by package ipa-admintools > > Error: Missing Dependency: python(abi) = 2.5 is needed by package ipa-python > > Error: Missing Dependency: python-krbV is needed by package ipa-client > > Error: Missing Dependency: python(abi) = 2.5 is needed by package ipa-client > > > > Can anyone point me in the right direction here? > > F7 packages are not directly compatible with RHEL5, I think some of the > python packages are available in EPEL, most other stuff need to be > rebuilt from source rpms to make it work on RHEL5, including the > kerberos package as we enabled a new subpackage (krb5-server-ldap) in > the spec file that is not normally available in RHEL5. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- Alex Davies This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately by e-mail and delete this e-mail permanently. From alex at davz.net Tue Apr 29 15:50:44 2008 From: alex at davz.net (Alex Davies) Date: Tue, 29 Apr 2008 17:50:44 +0200 Subject: [Freeipa-devel] Fedora Versions Message-ID: <5fb622120804290850p4bef1b07g29dfab90aa00ccb4@mail.gmail.com> Hi All, What is the consensus view on the most stable OS to run freeIPA on? Conventionally, I would go for Fedora7 but I wonder if the changes that it makes to the OS would make Fedora9 a better bet? Many thanks, Alex From felix.schwarz at web.de Tue Apr 29 15:59:08 2008 From: felix.schwarz at web.de (Felix Schwarz) Date: Tue, 29 Apr 2008 17:59:08 +0200 Subject: [Freeipa-devel] Re: Fedora Versions In-Reply-To: <5fb622120804290850p4bef1b07g29dfab90aa00ccb4@mail.gmail.com> References: <5fb622120804290850p4bef1b07g29dfab90aa00ccb4@mail.gmail.com> Message-ID: <481745CC.9060304@web.de> Alex Davies write: > What is the consensus view on the most stable OS to run freeIPA on? > > Conventionally, I would go for Fedora7 but I wonder if the changes > that it makes to the OS would make Fedora9 a better bet? While I know next to nothing about FreeIPA, I really recommend using at least Fedora 8 given the fact that general support for Fedora 7 (security updates etc.) will be dropped soon by the Fedora Project. Therefore I guess using Fedora 8 would be the safest bet (as this the stable version of Fedora which will be supported for ~7-8 months). fs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3299 bytes Desc: S/MIME Cryptographic Signature URL: From felix.schwarz at web.de Tue Apr 29 16:01:25 2008 From: felix.schwarz at web.de (Felix Schwarz) Date: Tue, 29 Apr 2008 18:01:25 +0200 Subject: [Freeipa-devel] Re: Install on RHEL5 - pointers please In-Reply-To: <5fb622120804290823n74ea534blef5a08b11d883519@mail.gmail.com> References: <5fb622120804290749o67af6b92x6874ff7d67672377@mail.gmail.com> <1209480776.12808.5.camel@localhost.localdomain> <5fb622120804290823n74ea534blef5a08b11d883519@mail.gmail.com> Message-ID: <48174655.5040009@web.de> Alex Davies schrieb: > Many thanks Simon. I guess its going to be easier to use Fedora then :) Just in case someone starts to produce packages for RHEL/CentOS, please ping me as I'm quite interested in that and may help with some packaging. fs -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3299 bytes Desc: S/MIME Cryptographic Signature URL: From bigjoe1008 at gmail.com Tue Apr 29 17:28:52 2008 From: bigjoe1008 at gmail.com (Joe Harnish) Date: Tue, 29 Apr 2008 13:28:52 -0400 Subject: [Freeipa-devel] Re: Fedora Versions In-Reply-To: <481745CC.9060304@web.de> References: <5fb622120804290850p4bef1b07g29dfab90aa00ccb4@mail.gmail.com> <481745CC.9060304@web.de> Message-ID: <763fc8580804291028x3743e8efi759a43cf7261d896@mail.gmail.com> On Tue, Apr 29, 2008 at 11:59 AM, Felix Schwarz wrote: > > Alex Davies write: > > > What is the consensus view on the most stable OS to run freeIPA on? > > > > Conventionally, I would go for Fedora7 but I wonder if the changes > > that it makes to the OS would make Fedora9 a better bet? > > > > While I know next to nothing about FreeIPA, I really recommend using at > least Fedora 8 given the fact that general support for Fedora 7 (security > updates etc.) will be dropped soon by the Fedora Project. > > Therefore I guess using Fedora 8 would be the safest bet (as this the > stable version of Fedora which will be supported for ~7-8 months). > > fs Fedora 9 is going to have as a base package. I think Fedora 8 it is still considered as a testing app. I had issues on Fedora 8 when attempting to set it up. Fedora 9 seems to have most if not all the bugs worked out of the install process. I had my first successful installation on Fedora 9 yesterday. --Joe From rcritten at redhat.com Tue Apr 29 17:39:55 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Apr 2008 13:39:55 -0400 Subject: [Freeipa-devel] Re: Fedora Versions In-Reply-To: <763fc8580804291028x3743e8efi759a43cf7261d896@mail.gmail.com> References: <5fb622120804290850p4bef1b07g29dfab90aa00ccb4@mail.gmail.com> <481745CC.9060304@web.de> <763fc8580804291028x3743e8efi759a43cf7261d896@mail.gmail.com> Message-ID: <48175D6B.6090801@redhat.com> Joe Harnish wrote: > On Tue, Apr 29, 2008 at 11:59 AM, Felix Schwarz wrote: >> Alex Davies write: >> >>> What is the consensus view on the most stable OS to run freeIPA on? >>> >>> Conventionally, I would go for Fedora7 but I wonder if the changes >>> that it makes to the OS would make Fedora9 a better bet? >>> >> While I know next to nothing about FreeIPA, I really recommend using at >> least Fedora 8 given the fact that general support for Fedora 7 (security >> updates etc.) will be dropped soon by the Fedora Project. >> >> Therefore I guess using Fedora 8 would be the safest bet (as this the >> stable version of Fedora which will be supported for ~7-8 months). >> >> fs > Fedora 9 is going to have as a base package. I think Fedora 8 it is > still considered as a testing app. I had issues on Fedora 8 when > attempting to set it up. Fedora 9 seems to have most if not all the > bugs worked out of the install process. I had my first successful > installation on Fedora 9 yesterday. I didn't mark the package as stable in Fedora 7 or 8 because we were pre 1.0 and there were still a ton of bugs. My dev environment is currently in Fedora 7. I think I'll be moving up to 9 once it is released. There is one more bug that will be pushed out post Fedora 9 GA: https://bugzilla.redhat.com/show_bug.cgi?id=444624 Glad to hear you got it installed ok :-) rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Apr 29 18:14:07 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Apr 2008 14:14:07 -0400 Subject: [Freeipa-devel] [PATCH] Don't prompt for confirmation of DM password when installing a replica Message-ID: <4817656F.6030806@redhat.com> Don't prompt for confirmation of DM password when installing a replica. It implies that you are setting a new password and you really aren't. Also added a catch for KeyboardInterrupt with instructions on how to recover from a partial install. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-9-replica.patch Type: text/x-patch Size: 2521 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Apr 30 21:26:25 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Apr 2008 17:26:25 -0400 Subject: [Freeipa-devel] [PATCH] Change the way versioning is done Message-ID: <4818E401.7010301@redhat.com> The file VERSION is now the sole-source of versioning. The generated .spec files will been removed in the maintainer-clean targets and have been removed from the repository. By default a GIT build is done. To do a non-GIT build do: $ make TARGET IPA_VERSION_IS_GIT_SNAPSHOT=no When updating the version you can run this to regenerate the version: $ make version-update The version can be determined in Python by using ipaserver.version.VERSION Please review this patch carefully, it changes a lot of stuff :-) rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-10-version.patch Type: text/x-patch Size: 32415 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: