From vijivijayakumar at gmail.com Mon Jan 5 14:27:01 2009 From: vijivijayakumar at gmail.com (Viji V Nair) Date: Mon, 5 Jan 2009 19:57:01 +0530 Subject: [Freeipa-devel] Please create a login Message-ID: <84c89ac10901050627n75a9044cjad5e3f2450cb0004@mail.gmail.com> Hi Team, Please create a login for me in freeIPA site, I would like to add wiki pages for configuring freeIPA. Thanks & Regards Viji V Nair -------------- next part -------------- An HTML attachment was scrubbed... URL: From abartlet at samba.org Tue Jan 6 06:29:53 2009 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 06 Jan 2009 17:29:53 +1100 Subject: [Freeipa-devel] Re: [Samba] Samba4 and freeipa In-Reply-To: <494F8B58.2070906@spbcas.ru> References: <494F8B58.2070906@spbcas.ru> Message-ID: <1231223393.3664.58.camel@naomi.s4.naomi.abartlet.net> On Mon, 2008-12-22 at 15:43 +0300, Konstantin Kozlov wrote: > Hello, > > I want to try Samba4 using a working FreeIPA setup as LDAP/Kerberos > backend. Did anybody try it already? Or are there some known issues > about such combination? While there are some ideas about how Samba4 might bring windows client support to FreeIPA, this isn't something even remotely possible at this time. The particular sticking points are that Windows clients expect an AD-like LDAP and Kerberos server, not MIT kerberos and Fedora DS (with FreeIPA schema). Samba4 can happily provide these services, but then the FreeIPA clients will see an AD LDAP server. I suspect the long-term solution will be to have Samba4 provide the KDC and the LDAP server, and have FreeIPA clients know to use the LDAP server on another IP address or port. (But I also know this proposed solution will infuriate others). The only part of this solution currently available is the LDAP backend, which allows Samba4 to use an OpenLDAP or (less-well-supported) Fedora DS server as a data store, using the AD schema. Sorry, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- 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 sgallagh at redhat.com Tue Jan 6 13:39:48 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 06 Jan 2009 08:39:48 -0500 Subject: [Freeipa-devel] Licensing information on the wiki Message-ID: <49635F24.7070509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A user on the #freeipa channel this morning noted that we do not list the license we use for FreeIPA on the FreeIPA wiki (at least in any obvious place). This seems like the sort of thing we really should have visible. According to the git source, FreeIPA 1.2.1 is licensed under GPLv2. This should probably appear on the About page or possibly the FAQ. - -- - -------------------- Stephen Gallagher RHCE 804006346421761 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkljXyQACgkQeiVVYja6o6PRqACfTYb52T6L91Wv2F+nADodmwVC K1sAn3Hskh3ojl030u+zFFWBN9zDt8/L =2icg -----END PGP SIGNATURE----- From rcritten at redhat.com Tue Jan 6 15:22:04 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Jan 2009 10:22:04 -0500 Subject: [Freeipa-devel] Licensing information on the wiki In-Reply-To: <49635F24.7070509@redhat.com> References: <49635F24.7070509@redhat.com> Message-ID: <4963771C.6090604@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > A user on the #freeipa channel this morning noted that we do not list > the license we use for FreeIPA on the FreeIPA wiki (at least in any > obvious place). This seems like the sort of thing we really should have > visible. > > According to the git source, FreeIPA 1.2.1 is licensed under GPLv2. This > should probably appear on the About page or possibly the FAQ. I'll see what I can do. All the code isn't pure GPLv2. The FDS plugins are GPLv2 with an exception. I think that is the only gotcha though. rob From rcritten at redhat.com Tue Jan 6 15:55:06 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Jan 2009 10:55:06 -0500 Subject: [Freeipa-devel] Licensing information on the wiki In-Reply-To: <4963771C.6090604@redhat.com> References: <49635F24.7070509@redhat.com> <4963771C.6090604@redhat.com> Message-ID: <49637EDA.8080203@redhat.com> Rob Crittenden wrote: > Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> A user on the #freeipa channel this morning noted that we do not list >> the license we use for FreeIPA on the FreeIPA wiki (at least in any >> obvious place). This seems like the sort of thing we really should have >> visible. >> >> According to the git source, FreeIPA 1.2.1 is licensed under GPLv2. This >> should probably appear on the About page or possibly the FAQ. > > I'll see what I can do. All the code isn't pure GPLv2. The FDS plugins > are GPLv2 with an exception. I think that is the only gotcha though. Haven't linked to this yet but this is what I came up with: http://freeipa.org/page/License rob From rcritten at redhat.com Wed Jan 7 14:52:41 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Jan 2009 09:52:41 -0500 Subject: [Freeipa-devel] Licensing information on the wiki In-Reply-To: <49637EDA.8080203@redhat.com> References: <49635F24.7070509@redhat.com> <4963771C.6090604@redhat.com> <49637EDA.8080203@redhat.com> Message-ID: <4964C1B9.9010804@redhat.com> Rob Crittenden wrote: > Rob Crittenden wrote: >> Stephen Gallagher wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> A user on the #freeipa channel this morning noted that we do not list >>> the license we use for FreeIPA on the FreeIPA wiki (at least in any >>> obvious place). This seems like the sort of thing we really should have >>> visible. >>> >>> According to the git source, FreeIPA 1.2.1 is licensed under GPLv2. This >>> should probably appear on the About page or possibly the FAQ. >> >> I'll see what I can do. All the code isn't pure GPLv2. The FDS plugins >> are GPLv2 with an exception. I think that is the only gotcha though. > > Haven't linked to this yet but this is what I came up with: > > http://freeipa.org/page/License > Linked to the About page. rob From ssorce at redhat.com Wed Jan 7 23:59:39 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 07 Jan 2009 18:59:39 -0500 Subject: [Freeipa-devel] Re: [Samba] Samba4 and freeipa In-Reply-To: <1231223393.3664.58.camel@naomi.s4.naomi.abartlet.net> References: <494F8B58.2070906@spbcas.ru> <1231223393.3664.58.camel@naomi.s4.naomi.abartlet.net> Message-ID: <1231372779.1056.72.camel@localhost.localdomain> On Tue, 2009-01-06 at 17:29 +1100, Andrew Bartlett wrote: > On Mon, 2008-12-22 at 15:43 +0300, Konstantin Kozlov wrote: > > Hello, > > > > I want to try Samba4 using a working FreeIPA setup as LDAP/Kerberos > > backend. Did anybody try it already? Or are there some known issues > > about such combination? > > While there are some ideas about how Samba4 might bring windows client > support to FreeIPA, this isn't something even remotely possible at this > time. > > The particular sticking points are that Windows clients expect an > AD-like LDAP and Kerberos server, not MIT kerberos and Fedora DS (with > FreeIPA schema). Samba4 can happily provide these services, but then > the FreeIPA clients will see an AD LDAP server. MIT Kerberos is getting the missing bits samba4 needs, but the DIT is going to be one of the major issues to solve. > I suspect the long-term solution will be to have Samba4 provide the KDC > and the LDAP server, and have FreeIPA clients know to use the LDAP > server on another IP address or port. (But I also know this proposed > solution will infuriate others). I am not sure I can agree with this view. The point is that FreeIPA is not just a generic LDAP + Kerberos server, we are working in providing a number of features targeted specifically at unix-like hosts. Using an AD-like tree would kill a lot of these features or require other compromises that do not really make sense in a pure linux/unix environment. I think Kerberos trusts (+ other glue for account enumeration) or synchronization are better solutions to get the best for each platform set (AD like for Windows, IPA like for *nix). > The only part of this solution currently available is the LDAP backend, > which allows Samba4 to use an OpenLDAP or (less-well-supported) Fedora > DS server as a data store, using the AD schema. Another solution could be to have the LDAP backend provide different *views* depending on what is the client, I'd like to explore this possibility down the road, but it is too premature right now imo. Simo. -- Simo Sorce * Red Hat, Inc * New York From abartlet at samba.org Thu Jan 8 00:38:07 2009 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 08 Jan 2009 11:38:07 +1100 Subject: [Freeipa-devel] Re: [Samba] Samba4 and freeipa In-Reply-To: <1231372779.1056.72.camel@localhost.localdomain> References: <494F8B58.2070906@spbcas.ru> <1231223393.3664.58.camel@naomi.s4.naomi.abartlet.net> <1231372779.1056.72.camel@localhost.localdomain> Message-ID: <1231375087.3348.36.camel@ruth> On Wed, 2009-01-07 at 18:59 -0500, Simo Sorce wrote: > On Tue, 2009-01-06 at 17:29 +1100, Andrew Bartlett wrote: > > On Mon, 2008-12-22 at 15:43 +0300, Konstantin Kozlov wrote: > > > Hello, > > > > > > I want to try Samba4 using a working FreeIPA setup as LDAP/Kerberos > > > backend. Did anybody try it already? Or are there some known issues > > > about such combination? > > > > While there are some ideas about how Samba4 might bring windows client > > support to FreeIPA, this isn't something even remotely possible at this > > time. > > > > The particular sticking points are that Windows clients expect an > > AD-like LDAP and Kerberos server, not MIT kerberos and Fedora DS (with > > FreeIPA schema). Samba4 can happily provide these services, but then > > the FreeIPA clients will see an AD LDAP server. > > MIT Kerberos is getting the missing bits samba4 needs, but the DIT is > going to be one of the major issues to solve. Yeah. > > I suspect the long-term solution will be to have Samba4 provide the KDC > > and the LDAP server, and have FreeIPA clients know to use the LDAP > > server on another IP address or port. (But I also know this proposed > > solution will infuriate others). > > I am not sure I can agree with this view. The point is that FreeIPA is > not just a generic LDAP + Kerberos server, we are working in providing a > number of features targeted specifically at unix-like hosts. > Using an AD-like tree would kill a lot of these features or require > other compromises that do not really make sense in a pure linux/unix > environment. Exactly. I'm not proposing that, because you are right, it would suck to bend the whole world to Microsoft's ways. I should have made it clear, my proposal is that FreeIPA would be unmodified in this respect, but that somehow we would keep the AD-LDAP and FreeIPA-LDAP ports seperate. (And because we control the FreeIPA clients more, perhaps it could use a different port. Apparently XAD on eDirectory did this by making Linux clients send a magic control) Samba4 would then serve it's clients, FreeIPA it's clients (including the vital policy work etc), the combined KDC would serve both, and the LDAP implementations from each would serve the respective clients. > I think Kerberos trusts (+ other glue for account enumeration) or > synchronization are better solutions to get the best for each platform > set (AD like for Windows, IPA like for *nix). Given the madness that lies around Kerberos trusts, why not just have one KDC? (given the progress MIT has made, it could certainly just be more plugins to their KDC, or Samba4's Heimdal reading the shared database) > > The only part of this solution currently available is the LDAP backend, > > which allows Samba4 to use an OpenLDAP or (less-well-supported) Fedora > > DS server as a data store, using the AD schema. > > Another solution could be to have the LDAP backend provide different > *views* depending on what is the client, I'd like to explore this > possibility down the road, but it is too premature right now imo. I think that would be very interesting. Or a proxy that somehow redirects to the 'right' view, or something... Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- 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 idra at samba.org Thu Jan 8 04:15:03 2009 From: idra at samba.org (simo) Date: Wed, 07 Jan 2009 23:15:03 -0500 Subject: [Freeipa-devel] Re: [Samba] Samba4 and freeipa In-Reply-To: <1231375087.3348.36.camel@ruth> References: <494F8B58.2070906@spbcas.ru> <1231223393.3664.58.camel@naomi.s4.naomi.abartlet.net> <1231372779.1056.72.camel@localhost.localdomain> <1231375087.3348.36.camel@ruth> Message-ID: <1231388103.28789.14.camel@pico.li.ssimo.org> On Thu, 2009-01-08 at 11:38 +1100, Andrew Bartlett wrote: > Given the madness that lies around Kerberos trusts, why not just have > one KDC? (given the progress MIT has made, it could certainly just be > more plugins to their KDC, or Samba4's Heimdal reading the shared > database) At some point it would be nice, indeed, to get there, and the sooner we can start thinking about that solution the better. But in the short term we will have to support trusts anyway and in the process we will learn more about what is needed by all clients and servers alike. Simo. -- Simo Sorce Samba Team GPL Compliance Officer Principal Software Engineer at Red Hat, Inc. From rcritten at redhat.com Mon Jan 12 19:28:39 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Jan 2009 14:28:39 -0500 Subject: [Freeipa-devel] [PATCH] switch to tempdir when calling certutil In-Reply-To: <1228833254.8219.15.camel@localhost.localdomain> References: <493D51E2.40003@redhat.com> <1228833254.8219.15.camel@localhost.localdomain> Message-ID: <496B99E7.8070508@redhat.com> Simo Sorce wrote: > On Mon, 2008-12-08 at 11:57 -0500, Rob Crittenden wrote: >> Change to a temporary directory when calling certutil. We already use >> this directory for some files but certutil creates its own temporary >> files in the current directory when issuing certificates. This lets us >> be more sure we are in a writable place (/var/lib/ipa). > > ack > Pushed to master. Better late than never :-) rob From ssorce at redhat.com Mon Jan 12 21:36:34 2009 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 12 Jan 2009 16:36:34 -0500 Subject: [Freeipa-devel] [PATCH] switch to tempdir when calling certutil In-Reply-To: <496B99E7.8070508@redhat.com> References: <493D51E2.40003@redhat.com> <1228833254.8219.15.camel@localhost.localdomain> <496B99E7.8070508@redhat.com> Message-ID: <1231796194.4385.5.camel@localhost.localdomain> On Mon, 2009-01-12 at 14:28 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > On Mon, 2008-12-08 at 11:57 -0500, Rob Crittenden wrote: > >> Change to a temporary directory when calling certutil. We already use > >> this directory for some files but certutil creates its own temporary > >> files in the current directory when issuing certificates. This lets us > >> be more sure we are in a writable place (/var/lib/ipa). > > > > ack > > > > Pushed to master. > > Better late than never :-) Wow, I did not realize it was still unpushed ... Simo. -- Simo Sorce * Red Hat, Inc * New York From viji at fedoraproject.org Tue Jan 13 05:25:47 2009 From: viji at fedoraproject.org (Viji V Nair) Date: Tue, 13 Jan 2009 10:55:47 +0530 Subject: [Freeipa-devel] Re: [Freeipa-users] RHEL 5 Compiling ipa-client (only) from source In-Reply-To: <455674.63660.qm@web32604.mail.mud.yahoo.com> References: <84c89ac10901120817o2e5d0358saab96622d5466b24@mail.gmail.com> <496B7052.8020007@redhat.com> <84c89ac10901120908i6ddd70cbo392f199efcdaae25@mail.gmail.com> <455674.63660.qm@web32604.mail.mud.yahoo.com> Message-ID: <84c89ac10901122125k102b6e15v9127818a46d56d66@mail.gmail.com> Hi, I could see that you have run "./make.patch", this is not the right way. You have to patch the original Makefile with the attached patch # patch Makefile make.patch (have a look at "man patch", patch [options] [originalfile [patchfile]]) then run # make IPA_VERSION_IS_GIT_SNAPSHOT=no local-dist Also FYI, Fedora 8, 9 & 10 ships all the IPA packages. You can do a yum install Thanks & Regards Viji On Tue, Jan 13, 2009 at 2:15 AM, Peter Wolf wrote: > Hi, > it's not working for me. I'm using Fedora 10 i386. I did the following: > > - I download the http://freeipa.org/downloads/src/freeipa-1.2.1.tar.gz and > put it in a directory, I also install autoconf & automake. > - uncompressed the downloaded file > - go into the uncompressed directory and used the make.patch > - I have attached the error log > > Also, F10 is not supported, is F9 i386 supported? > > Hopefully to hear from you soon, > > regards, > > Fobe > ------------------------------ > *From:* Viji V Nair > *To:* Rob Crittenden > *Cc:* freeipa-users at redhat.com > *Sent:* Monday, January 12, 2009 6:08:20 PM > *Subject:* Re: [Freeipa-users] RHEL 5 Compiling ipa-client (only) from > source > > Hi, > > Worked for me > > Thanks > Viji > > > > On Mon, Jan 12, 2009 at 10:01 PM, Rob Crittenden wrote: > >> Viji V Nair wrote: >> >>> Hi, >>> >>> I have done a manual compilation of ipa-client on an RHEL 5.2 x86_64 >>> system. After struggling with a lot of errors I finally got it working by >>> following the below steps. >>> >>> Can anyone suggest is there anything wrong in my steps? Can I use the >>> same steps to configure other clients also? >>> >> >> You'd be better off using the attached patch. This will let you do a build >> from the top-level and avoid all the version problems. Plus it can build >> rpms for you. >> >> % make IPA_VERSION_IS_GIT_SNAPSHOT=no local-dist >> >> The rpms will be in dist/rpms >> >> rob >> >> >>> 1. Download and un-compress freeipa source, >>> http://freeipa.org/downloads/src/freeipa-1.2.1.tar.gz >>> >>> # tar -zxvf freeipa-1.2.1.tar.gz >>> # cd freeipa-1.2.1/ipa-client >>> >>> 2. I have installed the following prerequisites after seeing the >>> dependency errors. >>> >>> # yum install autoconf automake pkgconfig.x86_64 libtool.x86_64 >>> mozldap-devel.x86_64 krb5-devel.x86_64 openldap-devel.x86_64 >>> python-ldap.x86_64 >>> >>> 3. System was complaining about there is no version.m4 file, so I did a >>> copy paste of >>> >>> # cp version.m4.in version.m4 >>> >>> 4. System was telling I should add the contents of >>> /usr/share/aclocal/libtool.m4 to aclocal.m4, so I did >>> >>> # cat /usr/share/aclocal/libtool.m4 >> aclocal.m4 >>> >>> 5. After this I have complied the source using the following commands. >>> >>> # ./autogen.sh >>> # make >>> # make install >>> >>> 6. When I started ipa-client-install, it was showing so many missing >>> python module errors, so I have done the following steps to get rid of it. >>> >>> a. Downloaded python-krbV-1.0.13-5.el5.x86_64.rpm from ( >>> http://download.fedora.redhat.com/pub/epel/5Server/x86_64/python-krbV-1.0.13-5.el5.x86_64.rpm) >>> and installed >>> >>> # rpm -ivh python-krbV-1.0.13-5.el5.x86_64.rpm >>> >>> b. Manually build the other python modules. >>> >>> # cd freeipa-1.2.1/ipa-python >>> # python setup.py.in build >>> # python setup.py.in install >>> >>> c. Copied the required python modules to the actual location >>> >>> # cp -a /usr/local/lib/python2.4/site-packages/ipaclient >>> /usr/lib64/python2.4/site-packages/ >>> >>> d. Finally I got a version error, I have done a hard coding to fix it. >>> >>> # cp version.py.in >>> /usr/lib/python2.4/site-packages/ipa/version.py >>> # cat /usr/lib/python2.4/site-packages/ipa/version.py >>> >>> #VERSION="__VERSION__" >>> VERSION="1.2.1" >>> #NUM_VERSION=__NUM_VERSION__ >>> NUM_VERSION="1.2.1" >>> >>> Thanks & Regards >>> Viji >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.stromblad at hush.com Mon Jan 19 10:09:52 2009 From: chris.stromblad at hush.com (=?UTF-8?B?Q2hyaXN0b2ZmZXIgU3Ryw7ZtYmxhZA==?=) Date: Mon, 19 Jan 2009 11:09:52 +0100 Subject: [Freeipa-devel] Mixed environment - MS and NIX Message-ID: <20090119100953.29AAC20040@smtp.hushmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi list, I'm currently doing a "pre-study" for a project where a company is trying to standardize their use of Linux into a coherent, centrally managed system. Part of this is to manage and authenticate users, again centrally. Now I'm very much in-love with open source software, but as much as I'd like to simply provide a separate system for all of this we live in a mixed environment and business requirements. One of these dreaded requirements is to use AD for authentication. Now to the questions: 1) Is it possible to somehow replicate data from an AD over to fedora directory service? (I think this is a yes from what I've read) 2) If yes on 1) will it be possible for Linux computers to authenticate against the FDS rather than the AD? 3) If yes on 2), when updates are made to FreeIPA to implement more functionality, will it still be possible to replicate the basic user data for authentication without "disturbing" the new functionality? 4) Any alternatives you recommend or suggest me to look into? Kind regards, Christoffer PS: My apologies if these questions are/were not appropriate for the list. -----BEGIN PGP SIGNATURE----- Charset: UTF8 Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 3.0 wpwEAQECAAYFAkl0UXEACgkQoGiwk4tHXN2xBgP/QM6E/yEmg60pOp+jFqXCdZexI7TA wMfJIxcVJRcXlYK637AzL7uKWTz0QiOVIdMXORLrYsFxl36zUtHsb3h2jfzbcP63uqPO 8TnvMjttTmmP4jjGTdFFPy1PVFLU9gb9KXptzS7mkne8lnFEtRXfHlqQxW17fNgh15m5 QwiYNOA= =BxKf -----END PGP SIGNATURE----- From dpal at redhat.com Mon Jan 19 15:06:00 2009 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Jan 2009 10:06:00 -0500 Subject: [Freeipa-devel] Mixed environment - MS and NIX In-Reply-To: <20090119100953.29AAC20040@smtp.hushmail.com> References: <20090119100953.29AAC20040@smtp.hushmail.com> Message-ID: <497496D8.1060107@redhat.com> Hi Christoffer, There are different options you have. You can use Samba 3 to make the UNIX/Linux machines authenticate against AD. You can use pure FDS as your Linux IDM but IPA is definitely better suited for this purpose. FreeIPA 1.2.1 has the AD synch functionality. I would suggest you evaluating this component. If the capabilities it provides meet your needs then FreeIPA + winsync component will be the first choice. If the functionality is not enough you may consider using winsync that comes with FDS but in this case you would have to use bare bones FDS and would loose all the advantages of the integration of the FDS+Kerberos that IPA provides. Thank you Dmitri Christoffer Str?mblad wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi list, > > I'm currently doing a "pre-study" for a project where a company is > trying to standardize their use of Linux into a coherent, centrally > managed system. Part of this is to manage and authenticate users, > again centrally. > > Now I'm very much in-love with open source software, but as much as > I'd like to simply provide a separate system for all of this we > live in a mixed environment and business requirements. One of these > dreaded requirements is to use AD for authentication. > > Now to the questions: > 1) Is it possible to somehow replicate data from an AD over to > fedora directory service? (I think this is a yes from what I've > read) > > 2) If yes on 1) will it be possible for Linux computers to > authenticate against the FDS rather than the AD? > > 3) If yes on 2), when updates are made to FreeIPA to implement more > functionality, will it still be possible to replicate the basic > user data for authentication without "disturbing" the new > functionality? > > 4) Any alternatives you recommend or suggest me to look into? > > Kind regards, > Christoffer > > PS: My apologies if these questions are/were not appropriate for > the list. > -----BEGIN PGP SIGNATURE----- > Charset: UTF8 > Note: This signature can be verified at https://www.hushtools.com/verify > Version: Hush 3.0 > > wpwEAQECAAYFAkl0UXEACgkQoGiwk4tHXN2xBgP/QM6E/yEmg60pOp+jFqXCdZexI7TA > wMfJIxcVJRcXlYK637AzL7uKWTz0QiOVIdMXORLrYsFxl36zUtHsb3h2jfzbcP63uqPO > 8TnvMjttTmmP4jjGTdFFPy1PVFLU9gb9KXptzS7mkne8lnFEtRXfHlqQxW17fNgh15m5 > QwiYNOA= > =BxKf > -----END PGP SIGNATURE----- > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From rcritten at redhat.com Mon Jan 19 15:08:53 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Jan 2009 10:08:53 -0500 Subject: [Freeipa-devel] Mixed environment - MS and NIX In-Reply-To: <20090119100953.29AAC20040@smtp.hushmail.com> References: <20090119100953.29AAC20040@smtp.hushmail.com> Message-ID: <49749785.90900@redhat.com> Christoffer Str?mblad wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi list, > > I'm currently doing a "pre-study" for a project where a company is > trying to standardize their use of Linux into a coherent, centrally > managed system. Part of this is to manage and authenticate users, > again centrally. > > Now I'm very much in-love with open source software, but as much as > I'd like to simply provide a separate system for all of this we > live in a mixed environment and business requirements. One of these > dreaded requirements is to use AD for authentication. > > Now to the questions: > 1) Is it possible to somehow replicate data from an AD over to > fedora directory service? (I think this is a yes from what I've > read) Yes. We currently only sync the following information: - New users added to AD - Existing IPA users that have a ntuserdomainid that matches an AD user and have the objectclass ntUser (so you can create a user in IPA and then connect them to an existing AD user) - Passwords if the PassSync service is installer on AD (and every AD in the domain) > 2) If yes on 1) will it be possible for Linux computers to > authenticate against the FDS rather than the AD? Yes. Linux users can authenticate to the IPA DS using simple auth and the KDC using their password. > 3) If yes on 2), when updates are made to FreeIPA to implement more > functionality, will it still be possible to replicate the basic > user data for authentication without "disturbing" the new > functionality? That is always our goal. One may need to run a provided migration script when going between major versions but one should be able to move upward relatively easily. > > 4) Any alternatives you recommend or suggest me to look into? You might be able to authenticate against AD directly. rob From chris.stromblad at hush.com Mon Jan 19 15:12:49 2009 From: chris.stromblad at hush.com (=?UTF-8?B?Q2hyaXN0b2ZmZXIgU3Ryw7ZtYmxhZA==?=) Date: Mon, 19 Jan 2009 16:12:49 +0100 Subject: [Freeipa-devel] Mixed environment - MS and NIX Message-ID: <20090119151249.DC41120040@smtp.hushmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Dimitri, Thanks for your reply. I'll definitely try the FreeIPA + winsync combination, might be a winner. Appreciate the suggestion. Regards, Christoffer On Mon, 19 Jan 2009 16:06:00 +0100 Dmitri Pal wrote: >Hi Christoffer, > >There are different options you have. >You can use Samba 3 to make the UNIX/Linux machines authenticate >against AD. >You can use pure FDS as your Linux IDM but IPA is definitely >better >suited for this purpose. >FreeIPA 1.2.1 has the AD synch functionality. I would suggest you >evaluating this component. >If the capabilities it provides meet your needs then FreeIPA + >winsync >component will be the first choice. >If the functionality is not enough you may consider using winsync >that >comes with FDS but in this case you would have to use bare bones >FDS and >would loose all the advantages of the integration of the >FDS+Kerberos >that IPA provides. > >Thank you >Dmitri > > >Christoffer Str?mblad wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi list, >> >> I'm currently doing a "pre-study" for a project where a company >is >> trying to standardize their use of Linux into a coherent, >centrally >> managed system. Part of this is to manage and authenticate >users, >> again centrally. >> >> Now I'm very much in-love with open source software, but as much >as >> I'd like to simply provide a separate system for all of this we >> live in a mixed environment and business requirements. One of >these >> dreaded requirements is to use AD for authentication. >> >> Now to the questions: >> 1) Is it possible to somehow replicate data from an AD over to >> fedora directory service? (I think this is a yes from what I've >> read) >> >> 2) If yes on 1) will it be possible for Linux computers to >> authenticate against the FDS rather than the AD? >> >> 3) If yes on 2), when updates are made to FreeIPA to implement >more >> functionality, will it still be possible to replicate the basic >> user data for authentication without "disturbing" the new >> functionality? >> >> 4) Any alternatives you recommend or suggest me to look into? >> >> Kind regards, >> Christoffer >> >> PS: My apologies if these questions are/were not appropriate for >> the list. >> -----BEGIN PGP SIGNATURE----- >> Charset: UTF8 >> Note: This signature can be verified at >https://www.hushtools.com/verify >> Version: Hush 3.0 >> >> >wpwEAQECAAYFAkl0UXEACgkQoGiwk4tHXN2xBgP/QM6E/yEmg60pOp+jFqXCdZexI7T >A >> >wMfJIxcVJRcXlYK637AzL7uKWTz0QiOVIdMXORLrYsFxl36zUtHsb3h2jfzbcP63uqP >O >> >8TnvMjttTmmP4jjGTdFFPy1PVFLU9gb9KXptzS7mkne8lnFEtRXfHlqQxW17fNgh15m >5 >> QwiYNOA= >> =BxKf >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> -----BEGIN PGP SIGNATURE----- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wpwEAQECAAYFAkl0mHEACgkQoGiwk4tHXN0NqgP+LluHqF3BzNkQwVJ7IF6TbXWkK518 eM5JuumOEf6SOXkYDf/z04isGemD/RDnvyp6AFqoziora6pGKeKpjZgikf+Ex3gdkpud t8uVZ0zP6pWasi10l/1PWqihmYoSX4g6fqulwgiAnBW9KSdjdvSfErcs+D/xvmukzPM6 UchAkC0= =Hawj -----END PGP SIGNATURE----- From sgallagh at redhat.com Wed Jan 21 12:31:07 2009 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 21 Jan 2009 07:31:07 -0500 Subject: [Freeipa-devel] [Fwd: PolicyKit 0.90 (pre-)release] Message-ID: <4977158B.3050203@redhat.com> This was just posted to the polkit-devel mailing list, but the addition of backend policy decision support is directly relevant to FreeIPA, so I'm reposting it here. -- -------------------- Stephen Gallagher RHCE 804006346421761 -------------- next part -------------- An embedded message was scrubbed... From: David Zeuthen Subject: PolicyKit 0.90 (pre-)release Date: Wed, 21 Jan 2009 02:23:02 -0500 Size: 6445 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From jdennis at redhat.com Wed Jan 21 14:56:06 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 21 Jan 2009 09:56:06 -0500 Subject: [Freeipa-devel] [Fwd: PolicyKit 0.90 (pre-)release] In-Reply-To: <4977158B.3050203@redhat.com> References: <4977158B.3050203@redhat.com> Message-ID: <49773786.6050704@redhat.com> Stephen Gallagher wrote: > As mentioned earlier I've been working on a rewrite of PolicyKit here > > Here's a brief list of differences > > - GLib is used throughout so the porting issues (for BSD and Solaris) > with libkit etc. should be a thing of the past > In the past I had suggested using glib to gain a data structure and utility library for our use rather than rewriting and debugging common code. There was some push back about it not being available on other platforms as well as depending on an external library. I see David has adopted glib, in part to ease foreign platform porting issues. Perhaps we should reconsider our position with regards to glib and derive a benefit from reusable code. -- John Dennis From ssorce at redhat.com Wed Jan 21 15:32:17 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 21 Jan 2009 10:32:17 -0500 Subject: [Freeipa-devel] [Fwd: PolicyKit 0.90 (pre-)release] In-Reply-To: <49773786.6050704@redhat.com> References: <4977158B.3050203@redhat.com> <49773786.6050704@redhat.com> Message-ID: <1232551937.3839.70.camel@localhost.localdomain> On Wed, 2009-01-21 at 09:56 -0500, John Dennis wrote: > Stephen Gallagher wrote: > > As mentioned earlier I've been working on a rewrite of PolicyKit here > > > > Here's a brief list of differences > > > > - GLib is used throughout so the porting issues (for BSD and Solaris) > > with libkit etc. should be a thing of the past > > > In the past I had suggested using glib to gain a data structure and > utility library for our use rather than rewriting and debugging common > code. There was some push back about it not being available on other > platforms as well as depending on an external library. I see David has > adopted glib, in part to ease foreign platform porting issues. Perhaps > we should reconsider our position with regards to glib and derive a > benefit from reusable code. I still think I have a problem with libraries that use assert() ... Simo. -- Simo Sorce * Red Hat, Inc * New York From kwirth at redhat.com Mon Jan 26 17:40:06 2009 From: kwirth at redhat.com (Karl Wirth) Date: Mon, 26 Jan 2009 12:40:06 -0500 Subject: [Freeipa-devel] Separating admin policy create role from deploy role Message-ID: <497DF576.8080406@redhat.com> Hi, With IPA v2, I think we should make it easy for an organization to set up the following two different admin roles: 1) Able to create a policy but can't deploy it 2) Able to check and deploy a policy but not create it. I think this fits with the controls many organizations have. Might it be possible to accomplish this using the DS ACIs to restrict access to the policies and the policy links? Best regards, Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Mon Jan 26 18:13:40 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 26 Jan 2009 10:13:40 -0800 Subject: [Freeipa-devel] Separating admin policy create role from deploy role In-Reply-To: <497DF576.8080406@redhat.com> References: <497DF576.8080406@redhat.com> Message-ID: <497DFD54.6080701@redhat.com> Karl Wirth wrote: > Hi, > > With IPA v2, I think we should make it easy for an organization to set > up the following two different admin roles: > 1) Able to create a policy but can't deploy it > 2) Able to check and deploy a policy but not create it. > I think this fits with the controls many organizations have. > > Might it be possible to accomplish this using the DS ACIs to restrict > access to the policies and the policy links? We could handle this using ACIs in DS depending on how a policy is "deployed". If we have a particular attribute that is used as a flag to "deploy" the policy, user #2 could have write access to this one attribute in the policy portion of the tree while being able to read the rest of the policy for checking. User #1 would be able to write all of the policy attributes except for the "deploy" flag attribute. > > Best regards, > Karl > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Mon Jan 26 19:03:46 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Jan 2009 14:03:46 -0500 Subject: [Freeipa-devel] Notice: master branch updated Message-ID: <497E0912.9070802@redhat.com> We're working on a new management framework for IPA v2 that provides a more plugin and customizable interface. We started this work on a separate GIT tree to stabilize it. We've gotten to the point now where the command-line basically functions so I'm pushing this into the freeIPA master branch. It isn't yet in a buildable state, that's the next step. Lots of the v1 code will soon be disappearing, being replaced by this code. This won't affect freeIPA v1.2 which is in a separate branch in git. rob From rcritten at redhat.com Tue Jan 27 19:34:29 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Jan 2009 14:34:29 -0500 Subject: [Freeipa-devel] tree reorganization proposal Message-ID: <497F61C5.9030207@redhat.com> Now that I've muddled things up by importing Jason's tree into the master branch, here is how I propose we clean it up. I'm purposely excluding Makefiles for now. I'm not sure they are going to be needed as we can probably cover the installation as part of setup.py. I'm particularly worried about my suggestion of ipaserver/tools. I'm not sure how flexible the python setuputils is to not include subdirs when it creates packages, and to move things around. This is mostly based on cosmetic and tidiness reasons. I still need to figure out how to build rpms from these. mkdir ipaserver/install mv ipa-server/ipaserver/* ipaserver/install mkdir ipaserver/tools mkdir ipaserver/tools/man mv ipa-server/ipa-install/ipa-* ipaserver/tools mv ipa-server/ipa-install/ipactl ipaserver/tools mv ipa-server/ipa-upgradeconfig ipaserver/tools mv ipa-server/ipa-ldap-updater ipaserver/tools mv ipa-server/ipa-fix-CVE-2008-3274 ipaserver/tools mv ipa-server/man/* ipaserver/tools/man mv ipa-server/ipa-install/share ipaserver mv ipa-server/ipa-install/updates/* ipaserver/updates mkdir ipaserver/install mv ipa-server/ipaserver/* ipa-server/install mv ipa-server/selinux ipaserver mv ipa-server/ipa-kpasswd ipaserver mv ipa-server/ipa-slapi-plugins ipaserver I think after this we can remove everything in ipa-server. The resulting directories will look something like: ipalib/ ipa-python/ ipaserver/tools/ ipaserver/ ipaserver/tools/ ipaserver/tools/man/ ipaserver/share/ ipaserver/install/ ipaserver/updates/ ipaserver/ipa-kpasswd/ ipaserver/ipa-slapi-plugins/ ipaserver/selinux/ ipawebui/ tests/ ipa-client/ ipa-admintools is going away and the radius tools and functionality will be folded into the server as time permits. I suspect that ipa-python will be folded into ipalib at some point. Most of it is already re-implemented as it is. It very much depends on what the client installer will look like and whether we will include one in this tree or require people to use SSSD. Lots of this is just moving things from ipa-server into ipaserver which make Jason wince. rob From rcritten at redhat.com Tue Jan 27 20:52:22 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Jan 2009 15:52:22 -0500 Subject: [Freeipa-devel] [resend] tree reorganization proposal Message-ID: <497F7406.9010803@redhat.com> [Simo found an error in the original document (I duplicated moving from ipa-server/ipaserver/* to ipaserver/install). Removed the duplication.] Now that I've muddled things up by importing Jason's tree into the master branch, here is how I propose we clean it up. I'm purposely excluding Makefiles for now. I'm not sure they are going to be needed as we can probably cover the installation as part of setup.py. I'm particularly worried about my suggestion of ipaserver/tools. I'm not sure how flexible the python setuputils is to not include subdirs when it creates packages, and to move things around. This is mostly based on cosmetic and tidiness reasons. I still need to figure out how to build rpms from these. mkdir ipaserver/install mv ipa-server/ipaserver/* ipaserver/install mkdir ipaserver/tools mkdir ipaserver/tools/man mv ipa-server/ipa-install/ipa-* ipaserver/tools mv ipa-server/ipa-install/ipactl ipaserver/tools mv ipa-server/ipa-upgradeconfig ipaserver/tools mv ipa-server/ipa-ldap-updater ipaserver/tools mv ipa-server/ipa-fix-CVE-2008-3274 ipaserver/tools mv ipa-server/man/* ipaserver/tools/man mv ipa-server/ipa-install/share ipaserver mv ipa-server/ipa-install/updates/* ipaserver/updates mv ipa-server/selinux ipaserver mv ipa-server/ipa-kpasswd ipaserver mv ipa-server/ipa-slapi-plugins ipaserver I think after this we can remove everything in ipa-server. The resulting directories will look something like: ipalib/ ipa-python/ ipaserver/tools/ ipaserver/ ipaserver/tools/ ipaserver/tools/man/ ipaserver/share/ ipaserver/install/ ipaserver/updates/ ipaserver/ipa-kpasswd/ ipaserver/ipa-slapi-plugins/ ipaserver/selinux/ ipawebui/ tests/ ipa-client/ ipa-admintools is going away and the radius tools and functionality will be folded into the server as time permits. I suspect that ipa-python will be folded into ipalib at some point. Most of it is already re-implemented as it is. It very much depends on what the client installer will look like and whether we will include one in this tree or require people to use SSSD. Lots of this is just moving things from ipa-server into ipaserver which make Jason wince. rob _______________________________________________ Freeipa-devel mailing list Freeipa-devel at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel From ssorce at redhat.com Tue Jan 27 21:03:36 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 Jan 2009 16:03:36 -0500 Subject: [Freeipa-devel] [resend] tree reorganization proposal In-Reply-To: <497F7406.9010803@redhat.com> References: <497F7406.9010803@redhat.com> Message-ID: <1233090216.3698.2.camel@localhost.localdomain> On Tue, 2009-01-27 at 15:52 -0500, Rob Crittenden wrote: > [Simo found an error in the original document (I duplicated moving from > ipa-server/ipaserver/* to ipaserver/install). Removed the duplication.] > > Now that I've muddled things up by importing Jason's tree into the > master branch, here is how I propose we clean it up. > > I'm purposely excluding Makefiles for now. I'm not sure they are going > to be needed as we can probably cover the installation as part of > setup.py. I'm particularly worried about my suggestion of > ipaserver/tools. I'm not sure how flexible the python setuputils is to > not include subdirs when it creates packages, and to move things around. > This is mostly based on cosmetic and tidiness reasons. I still need to > figure out how to build rpms from these. > > mkdir ipaserver/install > mv ipa-server/ipaserver/* ipaserver/install > > mkdir ipaserver/tools > mkdir ipaserver/tools/man > mv ipa-server/ipa-install/ipa-* ipaserver/tools > mv ipa-server/ipa-install/ipactl ipaserver/tools > mv ipa-server/ipa-upgradeconfig ipaserver/tools > mv ipa-server/ipa-ldap-updater ipaserver/tools > mv ipa-server/ipa-fix-CVE-2008-3274 ipaserver/tools > mv ipa-server/man/* ipaserver/tools/man > > mv ipa-server/ipa-install/share ipaserver > mv ipa-server/ipa-install/updates/* ipaserver/updates > > mv ipa-server/selinux ipaserver > mv ipa-server/ipa-kpasswd ipaserver > mv ipa-server/ipa-slapi-plugins ipaserver > > I think after this we can remove everything in ipa-server. > > The resulting directories will look something like: > > ipalib/ > ipa-python/ > ipaserver/tools/ > ipaserver/ > ipaserver/tools/ > ipaserver/tools/man/ > ipaserver/share/ > ipaserver/install/ > ipaserver/updates/ > ipaserver/ipa-kpasswd/ > ipaserver/ipa-slapi-plugins/ > ipaserver/selinux/ > ipawebui/ > tests/ > ipa-client/ > > ipa-admintools is going away and the radius tools and functionality will > be folded into the server as time permits. > > I suspect that ipa-python will be folded into ipalib at some point. Most > of it is already re-implemented as it is. It very much depends on what > the client installer will look like and whether we will include one in > this tree or require people to use SSSD. > > Lots of this is just moving things from ipa-server into ipaserver which > make Jason wince. Looks good to me, but what is the plan wrt the C stuff and Makefiles ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Jan 27 21:37:03 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Jan 2009 16:37:03 -0500 Subject: [Freeipa-devel] [resend] tree reorganization proposal In-Reply-To: <1233090216.3698.2.camel@localhost.localdomain> References: <497F7406.9010803@redhat.com> <1233090216.3698.2.camel@localhost.localdomain> Message-ID: <497F7E7F.6060502@redhat.com> Simo Sorce wrote: > On Tue, 2009-01-27 at 15:52 -0500, Rob Crittenden wrote: >> [Simo found an error in the original document (I duplicated moving from >> ipa-server/ipaserver/* to ipaserver/install). Removed the duplication.] >> >> Now that I've muddled things up by importing Jason's tree into the >> master branch, here is how I propose we clean it up. >> >> I'm purposely excluding Makefiles for now. I'm not sure they are going >> to be needed as we can probably cover the installation as part of >> setup.py. I'm particularly worried about my suggestion of >> ipaserver/tools. I'm not sure how flexible the python setuputils is to >> not include subdirs when it creates packages, and to move things around. >> This is mostly based on cosmetic and tidiness reasons. I still need to >> figure out how to build rpms from these. >> >> mkdir ipaserver/install >> mv ipa-server/ipaserver/* ipaserver/install >> >> mkdir ipaserver/tools >> mkdir ipaserver/tools/man >> mv ipa-server/ipa-install/ipa-* ipaserver/tools >> mv ipa-server/ipa-install/ipactl ipaserver/tools >> mv ipa-server/ipa-upgradeconfig ipaserver/tools >> mv ipa-server/ipa-ldap-updater ipaserver/tools >> mv ipa-server/ipa-fix-CVE-2008-3274 ipaserver/tools >> mv ipa-server/man/* ipaserver/tools/man >> >> mv ipa-server/ipa-install/share ipaserver >> mv ipa-server/ipa-install/updates/* ipaserver/updates >> >> mv ipa-server/selinux ipaserver >> mv ipa-server/ipa-kpasswd ipaserver >> mv ipa-server/ipa-slapi-plugins ipaserver >> >> I think after this we can remove everything in ipa-server. >> >> The resulting directories will look something like: >> >> ipalib/ >> ipa-python/ >> ipaserver/tools/ >> ipaserver/ >> ipaserver/tools/ >> ipaserver/tools/man/ >> ipaserver/share/ >> ipaserver/install/ >> ipaserver/updates/ >> ipaserver/ipa-kpasswd/ >> ipaserver/ipa-slapi-plugins/ >> ipaserver/selinux/ >> ipawebui/ >> tests/ >> ipa-client/ >> >> ipa-admintools is going away and the radius tools and functionality will >> be folded into the server as time permits. >> >> I suspect that ipa-python will be folded into ipalib at some point. Most >> of it is already re-implemented as it is. It very much depends on what >> the client installer will look like and whether we will include one in >> this tree or require people to use SSSD. >> >> Lots of this is just moving things from ipa-server into ipaserver which >> make Jason wince. > > > Looks good to me, but what is the plan wrt the C stuff and Makefiles ? I'm going to move all the Makefiles along with the ride. Some may not last forever but as a first step they'll move along. rob From jderose at redhat.com Wed Jan 28 19:09:11 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 28 Jan 2009 12:09:11 -0700 Subject: [Freeipa-devel] tree reorganization proposal In-Reply-To: <497F61C5.9030207@redhat.com> References: <497F61C5.9030207@redhat.com> Message-ID: <1233169751.15027.58.camel@jgd-dsk> On Tue, 2009-01-27 at 14:34 -0500, Rob Crittenden wrote: > Now that I've muddled things up by importing Jason's tree into the > master branch, here is how I propose we clean it up. > > I'm purposely excluding Makefiles for now. I'm not sure they are going > to be needed as we can probably cover the installation as part of > setup.py. I'm particularly worried about my suggestion of > ipaserver/tools. I'm not sure how flexible the python setuputils is to > not include subdirs when it creates packages, and to move things around. > This is mostly based on cosmetic and tidiness reasons. I still need to > figure out how to build rpms from these. > > mkdir ipaserver/install > mv ipa-server/ipaserver/* ipaserver/install > > mkdir ipaserver/tools > mkdir ipaserver/tools/man > mv ipa-server/ipa-install/ipa-* ipaserver/tools > mv ipa-server/ipa-install/ipactl ipaserver/tools > mv ipa-server/ipa-upgradeconfig ipaserver/tools > mv ipa-server/ipa-ldap-updater ipaserver/tools > mv ipa-server/ipa-fix-CVE-2008-3274 ipaserver/tools > mv ipa-server/man/* ipaserver/tools/man > > mv ipa-server/ipa-install/share ipaserver > mv ipa-server/ipa-install/updates/* ipaserver/updates > > mkdir ipaserver/install > mv ipa-server/ipaserver/* ipa-server/install > > mv ipa-server/selinux ipaserver > mv ipa-server/ipa-kpasswd ipaserver > mv ipa-server/ipa-slapi-plugins ipaserver > > I think after this we can remove everything in ipa-server. > > The resulting directories will look something like: > > ipalib/ > ipa-python/ > ipaserver/tools/ > ipaserver/ > ipaserver/tools/ > ipaserver/tools/man/ > ipaserver/share/ > ipaserver/install/ > ipaserver/updates/ > ipaserver/ipa-kpasswd/ > ipaserver/ipa-slapi-plugins/ > ipaserver/selinux/ > ipawebui/ > tests/ > ipa-client/ > > ipa-admintools is going away and the radius tools and functionality will > be folded into the server as time permits. > > I suspect that ipa-python will be folded into ipalib at some point. Most > of it is already re-implemented as it is. It very much depends on what > the client installer will look like and whether we will include one in > this tree or require people to use SSSD. > > Lots of this is just moving things from ipa-server into ipaserver which > make Jason wince. Well, okay, I'll admit it does. I really appreciate the work you've done on this, Rob... this looks like lot of work, and tedious at that. However, I still question the value of this type of merge. I might be the only one who feels this way, but I think this is going to cost us a lot of time. IMHO, it's much more productive to merge what's needed than to merge everything and then slowly figure out what isn't needed. Aside from the issue of having to slowly remove depreciated code, I guess I see two possible approaches here: We could: 1. Merge v2 code into v1. 2. Write a layer to glue the v1 code into v2 for features we are missing in v2. 3. Someday re-write the v1 code we are using or at least add some badly needed unit tests (not to mention fixing various Unicode/i18n bugs). Or we could: 1. Using the v1 code as a reference, quickly implement missing functionality in v2, building this functionality up layer by layer with good unit tests and correct Unicode/i18n behavior from the get-go. In this particular situation, I think the second approach will only take 25%-50% of the time that the first would. Also, as far as I know, the only major piece from v1 that we're missing in v2 is the install/configure functionality. Is this correct? And this functionality really needs to be re-implemented to be plugin-friendly anyway. And aren't we planning on moving the DS plugins into a separate tree anyway? Grateful yet concerned, Jason > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part URL: From dpal at redhat.com Wed Jan 28 19:19:18 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 Jan 2009 14:19:18 -0500 Subject: [Freeipa-devel] Separating admin policy create role from deploy role In-Reply-To: <497DFD54.6080701@redhat.com> References: <497DF576.8080406@redhat.com> <497DFD54.6080701@redhat.com> Message-ID: <4980AFB6.50506@redhat.com> Nathan Kinder wrote: > Karl Wirth wrote: >> Hi, >> >> With IPA v2, I think we should make it easy for an organization to >> set up the following two different admin roles: >> 1) Able to create a policy but can't deploy it >> 2) Able to check and deploy a policy but not create it. >> I think this fits with the controls many organizations have. >> >> Might it be possible to accomplish this using the DS ACIs to >> restrict access to the policies and the policy links? > We could handle this using ACIs in DS depending on how a policy is > "deployed". If we have a particular attribute that is used as a flag > to "deploy" the policy, user #2 could have write access to this one > attribute in the policy portion of the tree while being able to read > the rest of the policy for checking. > > User #1 would be able to write all of the policy attributes except for > the "deploy" flag attribute. Yes. We have this scenario in mind and yes there is an attribute that we can key off. >> >> Best regards, >> Karl >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From dpal at redhat.com Wed Jan 28 19:25:58 2009 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 Jan 2009 14:25:58 -0500 Subject: [Freeipa-devel] tree reorganization proposal In-Reply-To: <1233169751.15027.58.camel@jgd-dsk> References: <497F61C5.9030207@redhat.com> <1233169751.15027.58.camel@jgd-dsk> Message-ID: <4980B146.6010900@redhat.com> Jason Gerard DeRose wrote: > On Tue, 2009-01-27 at 14:34 -0500, Rob Crittenden wrote: > >> Now that I've muddled things up by importing Jason's tree into the >> master branch, here is how I propose we clean it up. >> >> I'm purposely excluding Makefiles for now. I'm not sure they are going >> to be needed as we can probably cover the installation as part of >> setup.py. I'm particularly worried about my suggestion of >> ipaserver/tools. I'm not sure how flexible the python setuputils is to >> not include subdirs when it creates packages, and to move things around. >> This is mostly based on cosmetic and tidiness reasons. I still need to >> figure out how to build rpms from these. >> >> mkdir ipaserver/install >> mv ipa-server/ipaserver/* ipaserver/install >> >> mkdir ipaserver/tools >> mkdir ipaserver/tools/man >> mv ipa-server/ipa-install/ipa-* ipaserver/tools >> mv ipa-server/ipa-install/ipactl ipaserver/tools >> mv ipa-server/ipa-upgradeconfig ipaserver/tools >> mv ipa-server/ipa-ldap-updater ipaserver/tools >> mv ipa-server/ipa-fix-CVE-2008-3274 ipaserver/tools >> mv ipa-server/man/* ipaserver/tools/man >> >> mv ipa-server/ipa-install/share ipaserver >> mv ipa-server/ipa-install/updates/* ipaserver/updates >> >> mkdir ipaserver/install >> mv ipa-server/ipaserver/* ipa-server/install >> >> mv ipa-server/selinux ipaserver >> mv ipa-server/ipa-kpasswd ipaserver >> mv ipa-server/ipa-slapi-plugins ipaserver >> >> I think after this we can remove everything in ipa-server. >> >> The resulting directories will look something like: >> >> ipalib/ >> ipa-python/ >> ipaserver/tools/ >> ipaserver/ >> ipaserver/tools/ >> ipaserver/tools/man/ >> ipaserver/share/ >> ipaserver/install/ >> ipaserver/updates/ >> ipaserver/ipa-kpasswd/ >> ipaserver/ipa-slapi-plugins/ >> ipaserver/selinux/ >> ipawebui/ >> tests/ >> ipa-client/ >> >> ipa-admintools is going away and the radius tools and functionality will >> be folded into the server as time permits. >> >> I suspect that ipa-python will be folded into ipalib at some point. Most >> of it is already re-implemented as it is. It very much depends on what >> the client installer will look like and whether we will include one in >> this tree or require people to use SSSD. >> >> Lots of this is just moving things from ipa-server into ipaserver which >> make Jason wince. >> > > Well, okay, I'll admit it does. I really appreciate the work you've > done on this, Rob... this looks like lot of work, and tedious at that. > > However, I still question the value of this type of merge. I might be > the only one who feels this way, but I think this is going to cost us a > lot of time. IMHO, it's much more productive to merge what's needed > than to merge everything and then slowly figure out what isn't needed. > > Aside from the issue of having to slowly remove depreciated code, I > guess I see two possible approaches here: > > We could: > > 1. Merge v2 code into v1. > > 2. Write a layer to glue the v1 code into v2 for features we are > missing in v2. > > 3. Someday re-write the v1 code we are using or at least add > some badly needed unit tests (not to mention fixing various > Unicode/i18n bugs). > > Or we could: > > 1. Using the v1 code as a reference, quickly implement missing > functionality in v2, building this functionality up layer by > layer with good unit tests and correct Unicode/i18n behavior > from the get-go. > > In this particular situation, I think the second approach will only take > 25%-50% of the time that the first would. > > Also, as far as I know, the only major piece from v1 that we're missing > in v2 is the install/configure functionality. Is this correct? And > this functionality really needs to be re-implemented to be > plugin-friendly anyway. > > And aren't we planning on moving the DS plugins into a separate tree > anyway? > > Grateful yet concerned, > Jason > > I agree with Jason rationale. IMO there is not much left in the IPA v2 from IPA v2 so may be we should merge what makes sense from IPA v1 to the new code rather thank vice versa. But I am not an expert. Thanks Dmitri >> rob >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Wed Jan 28 19:54:47 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Jan 2009 14:54:47 -0500 Subject: [Freeipa-devel] tree reorganization proposal In-Reply-To: <1233169751.15027.58.camel@jgd-dsk> References: <497F61C5.9030207@redhat.com> <1233169751.15027.58.camel@jgd-dsk> Message-ID: <4980B807.2080807@redhat.com> Jason Gerard DeRose wrote: > On Tue, 2009-01-27 at 14:34 -0500, Rob Crittenden wrote: >> Now that I've muddled things up by importing Jason's tree into the >> master branch, here is how I propose we clean it up. >> >> I'm purposely excluding Makefiles for now. I'm not sure they are going >> to be needed as we can probably cover the installation as part of >> setup.py. I'm particularly worried about my suggestion of >> ipaserver/tools. I'm not sure how flexible the python setuputils is to >> not include subdirs when it creates packages, and to move things around. >> This is mostly based on cosmetic and tidiness reasons. I still need to >> figure out how to build rpms from these. >> >> mkdir ipaserver/install >> mv ipa-server/ipaserver/* ipaserver/install >> >> mkdir ipaserver/tools >> mkdir ipaserver/tools/man >> mv ipa-server/ipa-install/ipa-* ipaserver/tools >> mv ipa-server/ipa-install/ipactl ipaserver/tools >> mv ipa-server/ipa-upgradeconfig ipaserver/tools >> mv ipa-server/ipa-ldap-updater ipaserver/tools >> mv ipa-server/ipa-fix-CVE-2008-3274 ipaserver/tools >> mv ipa-server/man/* ipaserver/tools/man >> >> mv ipa-server/ipa-install/share ipaserver >> mv ipa-server/ipa-install/updates/* ipaserver/updates >> >> mkdir ipaserver/install >> mv ipa-server/ipaserver/* ipa-server/install >> >> mv ipa-server/selinux ipaserver >> mv ipa-server/ipa-kpasswd ipaserver >> mv ipa-server/ipa-slapi-plugins ipaserver >> >> I think after this we can remove everything in ipa-server. >> >> The resulting directories will look something like: >> >> ipalib/ >> ipa-python/ >> ipaserver/tools/ >> ipaserver/ >> ipaserver/tools/ >> ipaserver/tools/man/ >> ipaserver/share/ >> ipaserver/install/ >> ipaserver/updates/ >> ipaserver/ipa-kpasswd/ >> ipaserver/ipa-slapi-plugins/ >> ipaserver/selinux/ >> ipawebui/ >> tests/ >> ipa-client/ >> >> ipa-admintools is going away and the radius tools and functionality will >> be folded into the server as time permits. >> >> I suspect that ipa-python will be folded into ipalib at some point. Most >> of it is already re-implemented as it is. It very much depends on what >> the client installer will look like and whether we will include one in >> this tree or require people to use SSSD. >> >> Lots of this is just moving things from ipa-server into ipaserver which >> make Jason wince. > > Well, okay, I'll admit it does. I really appreciate the work you've > done on this, Rob... this looks like lot of work, and tedious at that. > > However, I still question the value of this type of merge. I might be > the only one who feels this way, but I think this is going to cost us a > lot of time. IMHO, it's much more productive to merge what's needed > than to merge everything and then slowly figure out what isn't needed. I think the steps look harder than it actually will be. The code base is rather small and huge chunks will be going away. We will end up carrying some cruft for a while but we can take another pass at it in the future. > Aside from the issue of having to slowly remove depreciated code, I > guess I see two possible approaches here: > > We could: > > 1. Merge v2 code into v1. > > 2. Write a layer to glue the v1 code into v2 for features we are > missing in v2. > > 3. Someday re-write the v1 code we are using or at least add > some badly needed unit tests (not to mention fixing various > Unicode/i18n bugs). The only thing lacking unicode would be the installer and the current client. The only glue code needed is in getting things to build and install nicely together. It is really just a packaging issue. All I'm really proposing is doing away with ipa-server and moving the few things we need into more logical places. ipa-admintools goes away easily. Simo wanted to keep the old client code so we need that and ipa-python. That is just about all there is. > Or we could: > > 1. Using the v1 code as a reference, quickly implement missing > functionality in v2, building this functionality up layer by > layer with good unit tests and correct Unicode/i18n behavior > from the get-go. > > In this particular situation, I think the second approach will only take > 25%-50% of the time that the first would. > > Also, as far as I know, the only major piece from v1 that we're missing > in v2 is the install/configure functionality. Is this correct? And > this functionality really needs to be re-implemented to be > plugin-friendly anyway. There is also ipa-kpasswd, the DS plugins, the replication management tools (though they may be able to be done via the framework), some other misc tools, the basic client code and its library. The installer is relatively modular now, it just lacks a way to automatically pick up new components and control the order of operations. IMHO it is adequate for now, despite being hardcoded. There are a lot of other things that we could be working on. > And aren't we planning on moving the DS plugins into a separate tree > anyway? No, they are going to remain. One of the goals of this was to retain as much revision history as possible. It now looks like git-mv drops history so it may well be just as easy to merge into Jason's tree the things we like from the v1 code rather than the other way around. I don't think the end-result would be much different though. What I really want is to get this to a point very quickly where we can install and test the new XML-RPC engine in a full installation. rob From jderose at redhat.com Wed Jan 28 20:34:15 2009 From: jderose at redhat.com (Jason Gerard DeRose) Date: Wed, 28 Jan 2009 13:34:15 -0700 Subject: [Freeipa-devel] tree reorganization proposal In-Reply-To: <4980B807.2080807@redhat.com> References: <497F61C5.9030207@redhat.com> <1233169751.15027.58.camel@jgd-dsk> <4980B807.2080807@redhat.com> Message-ID: <1233174855.15027.78.camel@jgd-dsk> On Wed, 2009-01-28 at 14:54 -0500, Rob Crittenden wrote: > Jason Gerard DeRose wrote: > > On Tue, 2009-01-27 at 14:34 -0500, Rob Crittenden wrote: > >> Now that I've muddled things up by importing Jason's tree into the > >> master branch, here is how I propose we clean it up. > >> > >> I'm purposely excluding Makefiles for now. I'm not sure they are going > >> to be needed as we can probably cover the installation as part of > >> setup.py. I'm particularly worried about my suggestion of > >> ipaserver/tools. I'm not sure how flexible the python setuputils is to > >> not include subdirs when it creates packages, and to move things around. > >> This is mostly based on cosmetic and tidiness reasons. I still need to > >> figure out how to build rpms from these. > >> > >> mkdir ipaserver/install > >> mv ipa-server/ipaserver/* ipaserver/install > >> > >> mkdir ipaserver/tools > >> mkdir ipaserver/tools/man > >> mv ipa-server/ipa-install/ipa-* ipaserver/tools > >> mv ipa-server/ipa-install/ipactl ipaserver/tools > >> mv ipa-server/ipa-upgradeconfig ipaserver/tools > >> mv ipa-server/ipa-ldap-updater ipaserver/tools > >> mv ipa-server/ipa-fix-CVE-2008-3274 ipaserver/tools > >> mv ipa-server/man/* ipaserver/tools/man > >> > >> mv ipa-server/ipa-install/share ipaserver > >> mv ipa-server/ipa-install/updates/* ipaserver/updates > >> > >> mkdir ipaserver/install > >> mv ipa-server/ipaserver/* ipa-server/install > >> > >> mv ipa-server/selinux ipaserver > >> mv ipa-server/ipa-kpasswd ipaserver > >> mv ipa-server/ipa-slapi-plugins ipaserver > >> > >> I think after this we can remove everything in ipa-server. > >> > >> The resulting directories will look something like: > >> > >> ipalib/ > >> ipa-python/ > >> ipaserver/tools/ > >> ipaserver/ > >> ipaserver/tools/ > >> ipaserver/tools/man/ > >> ipaserver/share/ > >> ipaserver/install/ > >> ipaserver/updates/ > >> ipaserver/ipa-kpasswd/ > >> ipaserver/ipa-slapi-plugins/ > >> ipaserver/selinux/ > >> ipawebui/ > >> tests/ > >> ipa-client/ > >> > >> ipa-admintools is going away and the radius tools and functionality will > >> be folded into the server as time permits. > >> > >> I suspect that ipa-python will be folded into ipalib at some point. Most > >> of it is already re-implemented as it is. It very much depends on what > >> the client installer will look like and whether we will include one in > >> this tree or require people to use SSSD. > >> > >> Lots of this is just moving things from ipa-server into ipaserver which > >> make Jason wince. > > > > Well, okay, I'll admit it does. I really appreciate the work you've > > done on this, Rob... this looks like lot of work, and tedious at that. > > > > However, I still question the value of this type of merge. I might be > > the only one who feels this way, but I think this is going to cost us a > > lot of time. IMHO, it's much more productive to merge what's needed > > than to merge everything and then slowly figure out what isn't needed. > > I think the steps look harder than it actually will be. The code base is > rather small and huge chunks will be going away. We will end up carrying > some cruft for a while but we can take another pass at it in the future. > > > Aside from the issue of having to slowly remove depreciated code, I > > guess I see two possible approaches here: > > > > We could: > > > > 1. Merge v2 code into v1. > > > > 2. Write a layer to glue the v1 code into v2 for features we are > > missing in v2. > > > > 3. Someday re-write the v1 code we are using or at least add > > some badly needed unit tests (not to mention fixing various > > Unicode/i18n bugs). > > The only thing lacking unicode would be the installer and the current > client. The only glue code needed is in getting things to build and > install nicely together. It is really just a packaging issue. > > All I'm really proposing is doing away with ipa-server and moving the > few things we need into more logical places. ipa-admintools goes away > easily. Simo wanted to keep the old client code so we need that and > ipa-python. That is just about all there is. We should rename ipa-python to ipapython or ipa_python and put it in the root of the tree so the client installer can import it in-tree. > > Or we could: > > > > 1. Using the v1 code as a reference, quickly implement missing > > functionality in v2, building this functionality up layer by > > layer with good unit tests and correct Unicode/i18n behavior > > from the get-go. > > > > In this particular situation, I think the second approach will only take > > 25%-50% of the time that the first would. > > > > Also, as far as I know, the only major piece from v1 that we're missing > > in v2 is the install/configure functionality. Is this correct? And > > this functionality really needs to be re-implemented to be > > plugin-friendly anyway. > > There is also ipa-kpasswd, the DS plugins, the replication management > tools (though they may be able to be done via the framework), some other > misc tools, the basic client code and its library. > > The installer is relatively modular now, it just lacks a way to > automatically pick up new components and control the order of > operations. IMHO it is adequate for now, despite being hardcoded. There > are a lot of other things that we could be working on. > > > And aren't we planning on moving the DS plugins into a separate tree > > anyway? > > No, they are going to remain. Oh, I guess I was confused on this. I thought they were being moved to another tree. > One of the goals of this was to retain as much revision history as > possible. It now looks like git-mv drops history so it may well be just > as easy to merge into Jason's tree the things we like from the v1 code > rather than the other way around. I don't think the end-result would be > much different though. Come to think of it, this makes sense that git-mv doesn't retain the sort of history you're looking for as git doesn't have real support for renames (because its version-controlled files don't have a unique id that persists throughout revisions and renames). AFAIK, a rename in git is really just deleting one file and then creating another with the same content. Off topic, but score another point for Jason's favorite DVCS (which does have real rename support)! ;) > What I really want is to get this to a point very quickly where we > can > install and test the new XML-RPC engine in a full installation. > > rob I'm certainly on the same page here with you. I'll flesh out setup.py so it's ready to go. There are details of the v1 tree I don't understand, so, like you said, maybe what you're proposing isn't as difficult as it seems to me. Let me know what else I need to do on my end to get things installable ASAP. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Thu Jan 29 04:03:40 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Jan 2009 23:03:40 -0500 Subject: [Freeipa-devel] [PATCH] Tree reorganization patch Message-ID: <49812A9C.2090106@redhat.com> This patch moves a slew of files around. History is retained but you'll need to use git-log --follow to see it. git-log will show just the history since the move. With this (and the following delete patch) the tree will no longer build. The fix for that will be coming in the next few days. I mostly want people to take a long hard look at this before it gets committed. One other option is to move some things that now in ipaserver, such as ipa-kpasswd and the DS plugins and the selinux policy into a separate directory. This will make ipaserver more python "pure" is that is desirable. It is easy to fix now, messier to fix later. The patch is compressed because it is 2.7MB. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-108-rename.patch.gz Type: application/x-gzip Size: 627798 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 29 04:06:06 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Jan 2009 23:06:06 -0500 Subject: [Freeipa-devel] [PATCH] deprecated file removal Message-ID: <49812B2E.6020002@redhat.com> This removes the old UI and XML-RPC code as well as the admin tools. These will be replaced by the new framework and plugin code. The XML-RPC server and admin tools provide basic functionality now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-109-delete.patch.gz Type: application/x-gzip Size: 281432 bytes Desc: not available URL: From rcritten at redhat.com Thu Jan 29 16:39:31 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Jan 2009 11:39:31 -0500 Subject: [Freeipa-devel] [PATCH] Tree reorganization patch In-Reply-To: <49812A9C.2090106@redhat.com> References: <49812A9C.2090106@redhat.com> Message-ID: <4981DBC3.2030808@redhat.com> Rob Crittenden wrote: > This patch moves a slew of files around. History is retained but you'll > need to use git-log --follow to see it. git-log will show just the > history since the move. > > With this (and the following delete patch) the tree will no longer > build. The fix for that will be coming in the next few days. I mostly > want people to take a long hard look at this before it gets committed. > > One other option is to move some things that now in ipaserver, such as > ipa-kpasswd and the DS plugins and the selinux policy into a separate > directory. This will make ipaserver more python "pure" is that is > desirable. It is easy to fix now, messier to fix later. > > The patch is compressed because it is 2.7MB. Ok, Jason raised the point that ipaserver is a python lib so shouldn't be cluttered with other junk. In the old tree we had a nice separation between client, server, tools, etc. We're not necessarily going to have that but the tools are now consolidated down to one program (ipa). We may rename the client at some point to simple-client to differentiate it from SSSD which will be much more feature-rich. In any case, here is what I propose now after looking at the final tree for a while: ./install - where all files used at install time go ./install/conf - configuration file templates ./install/updates - for ipa-ldap-updater ./install/share - misc files ./install/tools - ipa-server-install, replication tools, etc ./selinux - our policy ./daemons - our other servers and DS plugins ./daemons/ipa-kpasswd ./daemons/ipa-slapi-plugins ipaserver/install - the installation library This is a lot cleaner now. I have a patch for this if anyone wants to give it a go. rob From ssorce at redhat.com Sat Jan 31 01:54:51 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Jan 2009 20:54:51 -0500 Subject: [Freeipa-devel] Some work on the base libraries for the client Message-ID: <1233366891.30808.19.camel@localhost.localdomain> I've put a tentative spec file (Matt Barnes gave the kickstart to it) and resulting rpms built on my machine for a package called samba-base that contains packages for the 4 libraries we use in the sssd client: libtalloc libtdb libtevent libldb It is based on the current samba master git tree. http://simo.fedorapeople.org/samba-base/ Simo. -- Simo Sorce * Red Hat, Inc * New York